本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

容器即服务，下一代 PaaS 的基础

作者：Brendan Burns (Microsoft) |

容器正在彻底改变人们构建、打包和部署软件的方式。但常常被忽视的是，它们正在彻底改变人们构建那些用于构建、打包和部署软件的软件的方式。（这句话可能需要读两遍才能理解……）今天，以及明天在Container World的演讲中，我将探讨像Kubernetes这样的容器编排器如何成为下一代平台即服务（PaaS）的基础。特别地，我关注像Azure Container Service、Google Container Engine和其他这样的云容器即服务（CaaS）平台如何成为PaaS所构建的新的基础设施层。

要理解这一点，重要的是要考虑传统上由PaaS平台提供的一系列服务：

  • 源代码和可执行文件打包及分发
  • 可靠、零停机地推出软件版本
  • 自我修复、自动伸缩、负载均衡

当您查看这份列表时，很明显，这些传统的“PaaS”角色大部分现在已经被容器接管。容器镜像和容器镜像构建工具已成为打包应用程序的方式。容器注册表已成为在全球分发应用程序的方式。可靠的软件发布通过Kubernetes中的Deployment等编排器概念实现，而服务自我修复、自动伸缩和负载均衡都是使用ReplicaSets和Services部署在Kubernetes中的应用程序的特性。

那么PaaS还剩下什么？PaaS会被容器即服务取代吗？我认为答案是“否”。PaaS剩下的部分是它最初最重要的部分，那就是有主见的开发者体验。除了我上面列出的所有PaaS的通用部分之外，PaaS最重要的部分始终是开发者体验和应用程序框架在平台边界内使开发者更高效的方式。PaaS使开发者能够在不到一小时内将笔记本电脑上的源代码转换为全球可扩展的服务。这具有巨大的力量。

然而，在传统PaaS的世界中，构建PaaS基础设施本身（即运行用户软件的软件）所需的技能和经验要求非常强的分布式系统知识。因此，PaaS往往由分布式系统工程师而不是特定垂直领域开发者体验专家构建。这意味着PaaS平台倾向于通用基础设施，而不是针对特定垂直领域。最近，我们看到这种情况开始改变，首先是针对移动API后端的PaaS，后来是针对“函数即服务”的PaaS。然而，这些产品仍然是在原始基础设施之上从头开始构建的。

最近，我们开始看到这些平台构建在容器基础设施之上。以“函数即服务”为例，至少有两个（可能更多）在Kubernetes之上运行的开源函数即服务实现（fission 和 funktion）。这种趋势只会持续下去。在容器即服务之上构建平台即服务非常容易，您可以将其想象成作为本科计算机科学作业分发。这种开发的简易性意味着具有特定垂直领域专业知识的个人开发者（例如用于运行三维模拟的软件）能够并且将会构建针对该特定垂直体验的PaaS平台。反过来，通过针对如此狭窄的体验，他们将构建一个完美契合该狭窄垂直领域的体验，使其解决方案在该目标市场中具有吸引力。

这进而指出了下一代PaaS构建在容器即服务之上的另一个好处。它使开发者无需在特定的PaaS平台上做出“全押”的选择。当PaaS分层构建在容器即服务之上时，基本功能（命名、发现、打包等）都由CaaS提供，因此在部署在该CaaS之上的多个PaaS之间是通用的。这意味着开发者可以混合搭配，将多个PaaS部署到相同的容器基础设施上，并为每个应用程序选择最适合该特定平台的PaaS平台。同样重要的是，如果原始CaaS基础设施更适合他们的应用程序，他们可以选择“降级”到原始CaaS基础设施。将PaaS从提供基础设施层中解放出来，使PaaS能够多样化并针对特定体验，而不必担心过于狭窄。这些体验变得更加有针对性、功能更强大，而且通过构建在容器即服务之上，也更加灵活。

Kubernetes是下一代应用程序、PaaS及更多基础设施的基础。鉴于此，我非常高兴我们今天宣布 Azure 容器服务上的 Kubernetes 已普遍可用。当您将下一代应用程序部署到 Azure 时，无论是通过 PaaS 还是直接部署到 Kubernetes 本身（或两者兼有），您都可以将其部署到托管的、受支持的 Kubernetes 集群上。

此外，由于我们深知PaaS和一般软件开发的世界是混合的，我们很高兴地宣布Azure Container Service中的Windows集群的预览版可用。我们还在ACS-Engine上开发混合集群，并预计在未来几个月内将其普遍可用。

我很高兴看到容器和容器即服务正在改变计算世界，我相信我们只是触及了未来几个月和几年将要看到的变革的表面。