从IaaS、CaaS、PaaS和FaaS中，如何选择正确的平台？

• 提高开发速度

• 运维操作的最佳实践自动化

这两个要求推动了大多数软件平台的投资。真的，这两项可以作为自动化任何事情的检验标准。
所以，没有一个平台对于任何用户来说是完美的，那么是否意味着我们要自己写呢果自己写，是否建立在一个现有的平台之上想要一个从上到下的紧密集成的平台，还是想要使用强大的扩展点松散连接的多层平台/span>
这些都是一时间难以回答的问题，并没有一个真正适合每个人的单一答案。寻找合适平台的成就感是发现，比较和权衡之一。所以我们一起来吧！

平台之美

云平台的“彩虹”，总有您喜欢的色彩。
每个厂商都会告诉你，他们的软件是特别的，甚至是独一无二的。他们都在努力区分产品，以提供不可替代的价值。但是，如果您仔细观察，并容忍一些粗糙的边缘，您可以根据它们提供的接口类型对这些产品进行分组。

将应用程序配置到基础架构平台上
基础设施平台

基础设施平台在SaaS之后不久就出现了。VMware GSX Server(2006)和亚马逊弹性计算云(EC2，2006)提供了早期的虚拟化平台。然而，VMWare最初专注在企业内部部署，亚马逊web服务则将其托管的IaaS和SaaS产品结合，定位于更广阔的市场。后来，Rackspace和美国航天局开发了OpenStack (2010)作为VMware vSphere (2009年发布，取代GSX)和亚马逊EC2的开源竞争对手。

这些IaaS主要提供了一些具体的抽象：虚拟机计算节点，软件定义的 络和可挂载的存储。在有SaaS的情况下，托管的IaaS的主要卖点是外部资源容量配置操作的自动化，但与SaaS不同，托管的IaaS会给用户带来资源规模无限大的错觉。对于大多数对基础设施外包感兴趣的公司来说，AWS会提供比客户以往任何时候资源需求量大得多的资源，在您向AWS寻求更多节点之前，已经扩展了数据中心。对于无法或者不愿意外包的公司，像OpenStack和vSphere这样的基础设施平台可以在您选择的数据中心中托管自己的云。
然而，管理不仅仅只是涉及硬件，还包括管理一个基础设施平台，并且这需要更多的工作，这是企业公司已经在自己的平台上做过的。无论是手动管理没有虚拟化层的硬件，还是渴望使配置更加自助化。因此，X即服务模式是圆满的：托管的平台成为了打包的产品，此次增加的多租户功能，允许客户自己的内部用户群体进行操作。
随之而来的应用平台。

基础架构平台上的容器平台
容器平台
容器化已经比您想象得要深入（FreeBSD Jails自2000年以来一直在使用），但是可以肯定的是直到Docker（2013）将Linux操作系统级虚拟化与文件系统镜像结合起来，容器化才真正广泛流行起来。这使得构建和部署容器化应用更加容易，这是一种可以理解为通过构建磁盘镜像来加快基础设施平台配置的IaaS用户模式。但与VM相比，同时运行的几台驱动器足以让您的工作站超负荷运行，容器则允许您在本地部署完整的微服务堆栈，大大加快了开发周期。另外，由于降低了开销，每个微服务器都可以拥有自己的容器映像，自己的发布周期和自己的滚动升级，允许更小的团队并行开发它们。

从容器运行时到容器平台，这是一个明显的进步。像CloudFoundry这样的应用平台和像Apache Mesos这样的集群资源管理系统自成立以来就一直使用容器隔离。下一步是公开一个平台API，允许开发人员在一组机器上部署越来越受欢迎的Docker镜像。像基础设施平台一样，容器平台也是在内部开始的，后来提供托管服务。

Mesosphere的Marathon（2013）是通用容器编排的首个开源平台之一，但它早期是由内部努力推动的，比如Google的Borg（?2004）和Twitter的Aurora（2010年写成，在2013年开放为Apache Aurora）。

容器编排是容器平台的核心。与应用平台一样，容器平台需要提供基于约束的声明性调度。与应用平台不同的是，容器不限于十二要素应用程序。比如，有状态服务需要的持久卷，隔离保证机制，特定域的迁移过程及并行的备份作业等等。由于这种灵活性，容器平台可以轻松地变得比应用程序平台更复杂，以支持更多种类的工作负载。

功能平台

亚马逊推出了AWS Lambda（2014），引领了无服务的“热潮”，在其虚拟基础设施平台之上提供轻量级的容器化事件处理。像其他Amazon Web Services一样，Lambda仅仅只是一种托管服务。

因此，由Iron.io(2014)，Apache OpenWhisk(2016)，Fission(2016)，Galactic Fog的Gestalt(2016)，OpenLambda（2016）填补了私有化部署替代品的市场。

除了他们各自基于特定语言的框架之外，功能平台的运行方式与应用平台相同。因此，开发人员只需要开发事件处理程序，并使用平台API将触发器映射到该处理程序即可，而不是使用多个端点编写应用程序。功能平台通常与API 关配合或集成，以处理代理，负载均衡和集中式服务发现。与应用平台不同，功能平台透明地集成了基于负载的自动缩放，因为它们控制所有入口点和复用。
像容器平台一样，功能平台不一定需要基础架构平台，但与容器平台提供的灵活性不同，功能平台不是设计用于支持各种各样的工作负载。所以仅仅只运行一个功能平台可能是不明智的或不可能的。您可能还需要一个较低级别的容器或基础架构平台。一些功能平台甚至被设计成与容器平台集成，利用中间层自动化来降低较高层的复杂性。

这些平台中的每一层都提供了自己独特的抽象和API，某些层比其他层更抽象。一些更高层级的平台要么全部采用，要么就全不用。它们具有顶部到底部的集成，但只能支持您要运行的一小部分工作负载。您可能会尝试选择最高层的抽象化来最大限度地提高开发人员的速度，但是您也必须考虑到这些平台上构建的软件将与平台最紧密耦合，当您需要重新选择平台的时候， 这将增加您的风险。另一方面，较低级别的平台可以提供最大的灵活性，可以实现最广泛的工作负载，包括Web应用程序，微服务器，过时的整体架构应用，数据管道和数据存储服务。它们使得迁移更轻松和基础设施操作更容易，但是在上面实际开发或运维应用程序，服务或作业却更难。
应用平台和基础设施平台之间的冲突是容器平台受欢迎的重要原因之一。容器平台在这两方面作出了妥协。它们允许您根据每个容器来决定您的工作负载是否需要自己的环境，或者可以作为二进制运行，支持更多种类的工作负载。但它们还像应用程序平台一样提供声明式配置，生命周期管理，复制和调度。如果您还需要更高层次的抽象，您可以轻松地在容器平台之上部署更轻量级的应用程序或功能平台，共享具有较低级别工作负载的资源和机器。如果您还需要较低级别的抽象，您可以轻松地在基础设施平台之上部署容器平台，而不是直接使用裸机。

在Mesosphere，我们的使命就是让它非常容易建立和扩展规模到足以改变世界的技术。这意味着我们不仅仅服务于开发人员，也不仅仅是运营商，而是二者皆有。帮助您实现真正的敏捷性，既需要开发人员的速度和也需要运维人员的灵活性。开发人员希望减少重复工作，自动化的弹性，并建立在强大的平台服务之上。运维人员希望可见性，避免供应商锁定，以及控制成本的能力。因此，我们构建了DC/OS，以提供基于云的服务和开放的合作伙伴生态系统，与基础设施无关的容器平台。通过DC/OS，您可以获得一个坚实的容器平台，加上更高级别服务的目录：数据库，队列，自动化测试，持续交付流水线，日志记录和指标堆栈，弹性扩容及功能平台等。
文章译者：付辉(DockOne 区翻译)，原文链接：https://mesosphere.com/blog/iaas-vs-caas-vs-paas-vs-faas/

温馨提示：

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8705 人正在系统学习中