架构视角解读PaaS和容器平台

编者按：对于开发者来说，IaaS显然并不能很方便地满足需求，近几年随着容器技术的发展，很多技术驱动型的企业开始基于开源技术搭建内部的PaaS和容器平台，而业务驱动型的公司则开始关注PaaS和容器云服务商。本文中，Wikibon对PaaS和容器平台的基本功能，以及企业在选型时要考虑的关键问题，进行了深入地研究。

以下为译文：

开源的PaaS和容器市场在这几年来获得了飞速发展，包括内部技术以及为加速应用开发而做的多种工具。许多IT组织和开发者都要求新的软件采购都要基于开源软件，从而在评估过程中获得更多控制权。另外，很多组织还希望能够选择服务是部署在自建基础设施上，还是部署在公有云上。IT组织和开发者也在对可能的架构变迁进行评估，包括其对云原生应用的影响，以及如何集成已有的应用和数据。

不管是PaaS还是容器平台，其目的都是为了简化开发者部署应用到生产环境的工作，但是关于在哪些方面简化最重要却有很多争论。过去三四年中，以下几个话题一直是大家争论的焦点：

• 多语言支持。早期的平台都是为了特定的开发语言（比如Java，Ruby，.NET），框架或运行时所构建的，现在已经发展到了每个平台支持多种语言。这些支持可能是本地平台的功能，也可能是通过附加的服务，还有可能是通过容器技术；
• 多云支持。从定义上来说，PaaS和容器平台应该能够从任何底层云平台（比如AWS，Azure，GoogleCloud，OpenStack，VMware等）中抽象出来。大多数平台能够运行在任何平台上，通过部署包，API工具和市场，支持应用在这些云平台之间的无缝迁移；
• Docker支持。早期的平台支持多种方式的应用上传，打包以及系统的依赖。但随着更多的开发者接受了Docker容器作为其打包和交付应用的标准，对Docker的支持也成了所有PaaS和容器平台的标准配置；
• 调度器。在每个PaaS或容器平台内部都是一个复杂的分布式系统，负责管理底层的资源，支撑上层的应用运行。这些系统被称为“编排器”或“调度器”，他们的作用是协调底层容器或VM的创建和可用性，从而为平台上的应用提供基础设施。调度又是一个目前引起了多方争议的领域，因为不同调度器（比如Cloudfoundry的Diego，Kubernetes，Apache Mesos，Docker Swarm）有不同的扩展特性，并且和容器等平台组件的集成度也不同；
• 对Serverless或FaaS（Functions-as-a-Service）的支持。尽管PaaS和容器平台已经为开发者提供了一个简化的部署模式，还有一个更简单的模式正在出现，就是Serverless或FaaS。这种方式为开发者免除了更多的操作障碍，并开始在单页面开发，移动开发和IoT应用的开发中引起关注，未来可能会成为很多PaaS和容器平台的内置功能。

不到1年前，Wikibon公布了一系列关于结构化和非结构化平台的调查报告，主要研究这些平台是如何被设计，去帮助开发者们构建云原生的应用。其中PaaS和容器平台在过去9-12个月里获得了显著的发展。尽管一些平台仍然是高度结构化的，之前非结构化的平台也在向着更“composable”甚至结构化的趋势转变。Wikibon将“composable”定义为由一系列模块化的开源项目打包的交付物，被高度集成为一套服务，提高开发者的生产效率和应用部署速度。Composable的平台在架构选择上正在变得更武断，但依然允许架构师，开发者和运维人员在架构选择上，拥有比结构化平台更多的灵活性。

注意：一些供应商更喜欢用“Container-as-a-Service”这个词。这种描述能与供应商所贩卖的底层技术结合起来，但Wikibon看来这些平台不仅仅是容器，还包含了持续集成/持续部署（CI/CD），认证服务，应用服务，数据服务，安全服务，云基础设施和很多其它元素来共同服务于应用部署。

图1：结构化平台，Composable平台，非结构化平台

图1：结构化平台，Composable平台，非结构化平台

以下这些元素是PaaS和容器平台的标准配置：

• 核心平台必须要基于开源技术，比如CloudFoundry，Docker，Kubernetes。这样做的话，架构对于终端用户来说是透明的，能受益于打包/被支持的商业产品，也能获得广大开发者社区的技术支持；
• 交付物应该可以兼容自建平台和公有云产品。终端用户可以选择最适合自己商业需求的购买和操作方式；
• 交付物应该有灵活的架构，可以集成第三方工具，也能外部集成开源项目，终端用户可以决定在哪里集成这些非平台本地的工具（比如认证服务，日志，监控，功能流程，数据分析服务等）。

以下这些平台是本次研究分析的重点：

• 基于Cloud Foundry的IBM BlueMix：IBM BlueMix是一系列云应用和基础设施服务，其中IBM Softlayer（公有部分）可以被作为公有云购买，也可以被部署在客户自建的本地服务中；
• 基于Cloud Foundry的Pivotal Cloud Foundry和Pivotal Web Services：Pivotal Cloud Foundry是一个云原生的应用平台，可以在自建平台上使用也可以在公有云上使用, 还能以公有云的形式（Pivotal Web Services）购买；
• Docker的Docker Datacenter，Docker Cloud：Docker Datacenter是一个Container-as-a-Service解决方案，可以运行在自建平台上，也可以运行在公有云中。Docker Cloud提供了一个通用的控制台，在多个云基础设施中运行Docker容器；
• 基于Kubernetes的Red Hat OpenShift（专有，在线，容器平台）：Red Hat OpenShift是一个容器应用平台，企业可以基于其进行自建，也可以通过专有或公有服务方式购买；
• 基于Mesos的Mesosphere DCOS：Mesosphere DCOS是一个用来运行容器服务和有状态服务的数据中心操作系统，可以在自建平台或公有云中使用。

注意：以上这些平台是市场中的代表产品，这个报告并不是要穷尽罗列整个市场，或者挑选出一个赢家，因为结合应用和业务需求，不同的平台有不同的特点。

注意：任何平台的特性都是发展的，包括商业版本和开源版本。本文中的数据并不一定是这些平台的现状。

在每个PaaS或容器服务的核心，底层的系统组件都是为了更新的分布式应用和模式（比如微服务和12因子应用等）。对于初创公司来说这些很重要，但却限制了那些有遗留应用的用户。任何调研PaaS或容器平台的CIO，企业架构师或DevOps团队都会问这两个基本问题：

1. 新应用：新应用如何被添加到平台中？他们是如何被维护的？
2. 已有应用：已有应用如何被添加到平台中？如何维护它们？要做哪些改变？

图2：部署新应用和已有应用到PaaS和容器平台中

新应用很好办，可以本地push到平台，或打包成容器添加到平台中。其它情况下，输入可能直接来自于一个开发者，或一个自动系统输入（比如CI/CD产品，带有容器调度器的应用等）的一部分。

对于已有应用，如何将其迁移到PaaS或容器平台上的问题，依然存在争论。一些平台建议将已有应用容器化，然后运行在这个平台上；也有平台建议这些应用依然保留在平台外，通过服务中介或API去访问。

图3：已有应用和新应用的迁移

从应用的角度来说，开发者希望有更多的方案帮助他们应对业务挑战，但是一旦应用（不管是新的还是已有的应用）运行在这个平台上，运维团队都要尽力去创造稳定和一致的环境。这会大大降低所有应用的成本，所以许多公司都非常希望能发布尽可能多的应用组合。随着自动化系统带来的效率提升，Wikibon的调查显示到2026年，自动化系统带来的效率提升，会节省3000亿美元的IT运维成本。

图4：理解新的应用和已有应用如何与PaaS和容器平台交互

当向PaaS或容器平台迁移一个已有应用时，要考虑以下几个方面：

1. 现有应用可以在没有任何模块化的情况下迁移吗？通过Docker容器化，Linux和Windows应用都可以做到，因为容器天生就能运行在PaaS或容器平台上；
2. 已有的应用可以经过最小的修改实现迁移吗？不同的语言和框架（比如Java应用的Spring或Microprofile框架，.NET应用的.NET Core或ASP.NET框架）有不同的方式，还可以利用框架内传统的服务来提高应用和平台的契合度；
3. 现有应用能够通过中介服务或API访问吗？一些已有应用，比如遗留数据库或大型机上运行的服务，尤其要保持不变，而且只能通过平台内的服务中介去访问。

评估PaaS和容器平台时，有4个重要特性，在提高开发者创建和交付软件的能力，以及运维团队保证应用按预期运行之间找到平衡，运维团队能够保证应用在预期和非预期的环境中正常的运行。这些特性体现了速度，敏捷，技术灵活性和业务灵活性。

图5：PaaS或容器平台的核心元素

1. 开发者的输入：一个应用如何被迁移到这个平台上？之后如何更新？
2. 简化应用开发：平台内的什么服务可以简化开发者构建，扩展和管理应用的工作？
3. 运维扩展：随着越来越多的应用被添加到系统中，平台中的哪些元素能够帮助扩容和高效地运维？
4. 集成：平台可能无法满足应用的所有需求，那么如何集成第三方服务帮助这些应用？

任何PaaS或容器平台的核心都是为了让应用开发者更快地构建应用，并且跟上需求的增长。

这个平台应该支持多种开发语言并能集成各种服务（数据库，队列，缓存，消息，协议等）的流行框架。虽然Java和node.js等语言和像.NET这样的框架在很多企业都很常用，但PaaS和容器平台也要支持比较新的语言，比如Ruby，Python，Go，Rust，Scala等。

图6：语言，框架和流程

虽然语言的支持对于为开发者提供灵活的应用开发至关重要，但开发软件并不是最终的商业目的，而是解决业务上的挑战。要达到这个目标需要能在平台中集成灵活的工作流，以及构建/测试/部署流程。过去持续集成和持续部署（CI/CD）系统通常是PaaS和容器平台的外部组件，但是随着越来越多的公司改进了自己的内部组织模式，来支持DevOps文化和最佳实践，CI/CD框架正在成为这些平台深度集成的组件。尽管一些PaaS和容器平台已经集成了CI/CD服务，他们也应该能够集成流行的CI/CD服务（比如Jenkins，CloudBees，CircleCI，Gitlab,TravisCI，XebiaLabs，Shippable等），还要能集成流行的代码检查工具（比如Sonar）和代码库工具（比如Artifactory，Git等）。

图7：数字业务平台：CI/CD，云和云原生平台

随着越来越多的公司开始构建云原生的应用，或者重组现有的应用，大家关注的焦点之一就是如何为开发者简化应用的开发流程。容器和PaaS平台应该交付一系列“平台原生”的服务和框架，帮助开发者将重要的功能从应用转移到平台。比如服务发现，消息，队列，路由和高级的中间件服务等应该被内置到平台中。这些服务不但能减少开发者构建常用功能的需求，提高开发效率，还能让开发者团队专注于核心业务。

图8：应用输入到平台中

图9：应用功能，代码，容器和服务

尽管任何框架都能被开发团队部署在容器中，然后运行在一个PaaS或容器平台上，还有一些服务是PaaS和容器平台本地就带的。这些服务让开发者在应用的运维上花费的精力更少，专注于模式，用户上下文，用户体验和数据模型。

图10：平台-应用框架

应用的开发和部署对于任何业务都是至关重要的，PaaS或容器平台简化运维的能力也是任何业务都要考虑的重要因素。他们必须要具备扩展能力，以便无需对底层架构做重大改变，就能应对当前和未来的工作负载，同时还能运行在多个云基础设施上（公有或私有的）。

最近关于PaaS和容器平台的热点是底层的容器调度，调度器是平台的基础设施元素，其扩展性和对运维的简化是用户做架构评估时，要考虑的关键因素。

图11：容器调度器

下面是一些关于这些调度器扩展性讨论的文章或视频：

• Cloud Foundry Diego scaling：https://youtu.be/7APZD0me1nU?t=5m30s
• Docker Swarm scaling：https://blog.docker.com/2015/11/scale-testing-docker-swarm-30000-containers/
• Kubernetes scaling：http://blog.kubernetes.io/2016/03/1000-nodes-and-beyond-updates-to-Kubernetes-performance-and-scalability-in-12.htm
• Mesosphere scaling：https://docs.mesosphere.com/1.7/usage/tutorials/autoscaling/requests-second/

一项来自NewRelic的调查显示，由于容器为应用带来的便捷性，用户对容器的采纳获得了飞速增长。这说明PaaS或容器平台的扩展特性和容器创造的平滑的环境，是开发者采用的重要原因。

图12：用户对容器的使用情况

过去12-18个月以来在不断发展的另一个方面，是PaaS和容器平台可以被部署在哪里。这个平台不但要同时支持私有和公有云的消费模式，还要有社区开发的安装程序，以便运行在任何云环境中。有些情况下安装程序可以在公有云市场中找到，有时这个平台会作为SaaS服务，直接被业务消费。

图13：平台的云基础设施支持

虽然PaaS和容器平台能运行新的应用和已有应用，许多应用还需要通过传统服务扩展，以满足关键的业务需求。这些扩展服务可能是PaaS或容器平台的本地服务，也可能是通过API，路由服务或服务中介进行访问。

图14：内部和外部的应用服务

架构师，开发者和运营团队为了当前这些服务的本地交付，要考虑PaaS和容器服务的灵活性，还要为未来集成外部服务做好准备。IoT，机器学习，Serverless应用也驱动了新的使用模式，所以未来3-5年，对平台的灵活性需求要引起大家的关注。

过去2-3年，市场中的PaaS和容器平台已经逐步成熟。虽然还需要架构师，开发者和运维去根据业务需求选择底层的技术，但技术和部署的可选择范围已经大大扩展了。IT组织和产品团队应该考虑如何将新的应用和现有应用迁移到这些云原生平台，因为这些平台不但能加速应用的交付，还能通过自动化IT运维，减少整个IT成本。