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

探究各类云平台，帮您找到最适宜您的那一款！无论您是购置、从零开端搭建还是采用开源技术，您可能已经在使用某种软件平台来构建，部署和扩展应用程序。
一个平台的降生必定是经年锤炼而来，即从应用程序中提取通用的功能到更底层的笼统中。假设完成了既定的设计意图，那么您将得到一个可用的平台，反之，您将得到一个“烫手山芋”，既而您将再次寻找适宜的平台，这时候您会发现他人已经构建好的平台给您带来了一线希望的曙光。
正确的平台，您将在灵敏性和简单性之间到达您所需要的平衡，从而使您可以更快速地构建而不受太多限制。本文将讨论云平台的范围，以协助您找到最适宜您的那一款。
对于什么样的平台才是完美的，每个人有每个人的看法，因为每个人的使用场景有所不同。但是几乎所有人都寻求以下两个特征：

进步开发速度
运维操作的最佳理论自动化

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

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

云平台例子
软件平台
术语“软件即效劳”一词最早可追溯到2000年左右，指的是将打包的软件产品和支持效劳捆绑在托管处置方案中，以防止经常未知的执行和操作本钱。一个SaaS产品自身就是一个根底上的平台。术语描绘的一些原始用处取代了传统企业资源方案(ERP)和客户关系管理(CRM)平台。
像Salesforce和SAP这样的公司，对于那些没有大型工程师团队或IT部门来构建和管理这些复杂的系统客户，他们会在这些领域非常胜利。即便是拥有这些资源的公司也可能认为这些事情不在其核心竞争力范围之内，不值得自己去建立或经营。如今几乎所有类别的软件都可以通过SaaS获得，从电子邮件到文字处置系统，再到内容管理系统比比皆是。
Spectrum的另一端是根底设备即效劳。

将应用程序配置到根底架构平台上
根底设备平台
根底设备平台在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即效劳形式是圆满的：托管的平台成为了打包的产品，此次增加的多租户功能，允许客户自己的内部用户群体停止操作。
随之而来的应用平台。

根底设备平台上的应用平台
应用平台
Fotango的Zimki(2006)和Heroku(2007)率先使用平台即效劳。后来的Google App Engine（2008），CloudFoundry（2011）和其他几个参与了战斗。在当时，很明显，这些是真正的应用平台（aPaaS），专门用于加快开发人员的速度并降低运营开销。使得开发人员自己配置和管理他们开发的应用，进一步压缩了从开端到发布到反响到迭代的周转时间，与日益普及的敏捷软件开发思想相契合，并为刚刚起步的DevOps运动播下种子。
但进步永远不会停止。容器平台呈现了。

根底架构平台上的容器平台
容器平台
容器化已经比您想象得要深化（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应用程序，微效劳器，过时的整体架构应用，数据管道和数据存储效劳。它们使得迁移更轻松和根底设备操作更容易，但是在上面实际开发或运维应用程序，效劳或作业却更难。
应用平台和根底设备平台之间的抵触是容器平台受欢送的重要原因之一。容器平台在这两方面作出了妥协。它们允许您根据每个容器来决定您的工作负载是否需要自己的环境，或者可以作为二进制运行，支持更多品种的工作负载。但它们还像应用程序平台一样提供声明式配置，生命周期管理，复制和调度。假设您还需要更高层次的笼统，您可以轻松地在容器平台之上部署更轻量级的应用程序或功能平台，共享具有较低级别工作负载的资源和机器。假设您还需要较低级别的笼统，您可以轻松地在根底设备平台之上部署容器平台，而不是直接使用裸机。

DC/OS架构层
DC/OS——平台终极选择

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

温馨提示：

请搜索“ICT_Architect”或“扫一扫”二维码关注公众号，点击原文链接获取电子书详情。

求知若渴, 虚心若愚