去而复返：为何说PaaS过气了（又为何说它没有过气）？

提示您，本文原题为 -- 去而复返：为何说PaaS过气了（又为何说它没有过气）？

作者：Tyler Treat是Real Kinetic的执行合伙人。

10年后，没有人会谈论Kubernetes 。倒不是由于人们停止使用它，或由于它不受欢迎，而是由于它变成了水电：实用又普遍。容器、Kubernetes和服务网格，它们在将来都很盛行，就像虚拟机、虚拟机管理程序和交换机很盛行那样。计算是一种大众化商品，我才不在乎我的工作负载如何运行，只要它满足我公司的服务级别目标（SLO）及其他要求。单单在AWS内部，就有无数种方法来运行计算工作负载。

这是平台即服务（PaaS）当初的承诺：提供一种预先构建的运行时环境，你只需接入应用软件，就可以为你处理其余的资源（计算、网络和存储）。 Heroku（2007年）、Google App Engine（2008年）、OpenShift（2011年）和Cloud Foundry（2011年）都会浮现在脑海中。但是从许多方面来看， PaaS已成为近年来的一种禁忌。作为一名与云端公司或希望迁移到云的公司打交道的顾问，我发现PaaS几乎是个触发词。一提到PaaS ，客户几乎显而易见就会畏缩。很难确切说明为什么是这种情况，但我认为有很多原因，有的原因完全很合理，有的完全是一种心理恐吓手段（FUD）。

一提到PaaS就吓得直往后缩的这些公司常常存在认知不一致。因供应商锁定和运行时环境限制等原因（其中一些担心不无道理）明确拒绝PaaS这个想法之后，这些公司会以零敲碎打的方式描述他们自己对PaaS半生不熟的想法。 “好吧，我们将使用Kubernetes处理计算、使用ELK堆栈进行日志记录、使用Prometheus进行度量、使用OpenTracing进行分布式追踪、使用Redis进行缓存……” ，依次类推。更不用说往往偏向于自建而不是外购。而且，我们需要以某种方式将所有这一切作为一种自助式平台提供给开发人员。

虽然人们一直在努力使云计算民主化并提供各种各样的参考架构，但事实上，目前毫无标准可言，各种工具和技术继续迅猛遍地开花。另一方面，随着某些工具（比如Kubernetes）的出现，与之相关的模式和实践自然落在后头。 Serverless潮流进一步证明了这一点。 Serverless是与PaaS相当的微服务，但工具和运维方面的成熟度要低得多。这是激动人心的时期，但是毫无疑问，云已成为无法通行的荒地。即使今天所有东西可供你随意使用，构建和运营实际上是你自己的PaaS仍需要大量工作。

但是技术是周期性的，云也不例外。从某种意义上说，这种演进与NoSQL浪潮所遭遇的经历相似。 Eric Brewer在RICON 2012演讲中讨论了这个话题。如果你一眼识破炒作，就明白NoSQL旨在以较少的预包装功能为开发人员提供更大的控制权，但这并不是最终的结果，也不是SQL的替代技术。它涉及两种不同的、同样有效的世界观：自上而下和自下而上。自上向下的视图查看模型及其语义，然后搞清楚你需要做什么来实现模型。若是关系数据库，这使用SQL声明性地构建我们的模型。自下而上的视图旨在将原始组件分层为更复杂的组件。比如，像CockroachDB这样的现代数据库在事务层上提供了SQL抽象，事务层在复制层上，而复制层又在简单的键值存储层上。 NoSQL为我们提供了拥有很大灵活性的可重用存储组件；并且随着时间的推移，随着我们在顶部添加越来越多的组件，我们得到的东西看起来更像数据库。我们从低层开始，但最终目标仍然一样：漂亮的、对用户友好的语义。我认为， PaaS正出现同样的一幕。

各大云服务提供商正在做的事情就是拆分PaaS 。我们有计算，有集群调度程序，有数据库和缓存，有消息队列，还有其他组件。缺少的是粘合剂，即将这些东西连接成一个统一的、易管理的单元：PaaS的标准和工具。一切旧的又成了新的。我们会看到，随着那些标准和工具不断涌现，这些组件会逐渐重新捆绑。 AWS Fargate和Google App Engine Flexible Environment之类的工具就朝这个方向迈出了一步（由于与App Engine名称有关的所有PaaS包袱，谷歌称之为App Engine Flex确实搞砸了）。容器只是接口。但是这仅仅是开始。

PaaS和Serverless之所以出色，是由于它们真正加速了应用软件开发，并减少了操作开销。然而随之而来的缺点是，我们受到了制约。比如若使用App Engine ，我们最初受制于某些谷歌云API（比如Cloud Datastore和Task Queue）以及特定的语言运行时环境。久而久之，这种情况尤其因Cloud SQL而得到了改善；现在，我们可以使用自定义运行时环境。与之相似， PaaS为我们免费提供了服务自动扩展、高可用性和关键安全补丁，但我们对于计算特点和工作负载的处理模式失去了一定程度的控制性。

从某种意义上说， PaaS提供的是一种运行应用软件的自成一体的框架。如果你想尽快工作，自成一体很好，但是一旦你拥有成熟的产品，它就会限制你。我们想要的是PaaS的好处以及更高一点的灵活性。 PaaS为我们提供了一种自上而下的模板，我们可以由此开始，但是我们希望能够根据自己的需求进行调整。 Kubernetes是该模板的一个关键部分，但最终它只是达到目的的一种手段。

这就是为什么我认为10年后没有人会谈论Kubernetes 。但愿到那时它根本不是那么令人关注。如果它还是那么令人关注，这表明我们还没有大功告成。