IaaS vs CaaS vs PaaS vs FaaS如何选？
由于没有哪个云计算平台可适合所有用例，所以我们来看看主要的云计算平台，并且确定在哪些时候选用哪些服务更合适？
无论你是否购买、构建还是部署开源服务，你可能已经在使用某种软件平台来构建、部署和扩展应用程序。
经过多年从应用程序提取常用功能到较低抽象层，平台随之出现。现在市面上有很多云计算平台，正确的平台可帮助你在灵活性和简单性之间实现所需要的平衡，从而使你能够更快地构建而不受太多限制。本文中，我们将探讨这些云计算平台以帮助你找到最适合自己的平台。
对于什么是完美的平台，每个人都有自己的想法，但每个人都希望实现的是：
。提高开发速度
。自动化操作技能
既然没有平台适合所有用户，你是否应该自己构建平台？如果你自己构建，是否在现有平台之上构建？你如何选择基础平台？你想要从上至下紧密集成的平台，还是想要松散连接强大扩展点的多层平台？
这些都不是简单的问题，也没有真正适合每个人的单一答案。下面让我们来看看如何选择：
平台类型
每个供应商都会告诉你他们的软件是特别的、独一无二的，他们都在试图区分其产品来提供不可取代的价值。但如果你足够坚定，不被他们的营销术语动摇，则应该先根据他们提供的接口类型来对这些产品进行分组。
▲云计算平台示例
软件平台“软件即服务”一词最早可追溯到2000年左右，它指的是捆绑封装软件产品和支持服务到托管解决方案中，以避免未知部署和操作成本。SaaS产品本身可作为平台。该术语的原始用例描述的是取代传统企业资源规划（ERP）和客户关系管理（CRM）平台的解决方案。
Salesforce和SAP等公司在这个领域非常成功，他们让那些没有大型工程或IT部门可构建及管理这些复杂系统。即使是拥有足够资源的企业也可能会认为这些事情不在其核心竞争力范围之内，不值得自己去构建或运作。尽管如此，几乎每个类别的软件都可从SaaS获取，从电子邮件到文字处理到内容管理系统。
另一方面是基础设施即服务。
▲在基础设施平台上配置应用程序
基础设施平台
在SaaS出现不久后，基础设施平台开始出现。VMware GSX Server（2006年）和Amazon Elastic Compute Cloud（EC2，2006年）都提供早期虚拟化平台。VMware最初专注于企业内部部署安装，而Amazon云计算服务则获得更广泛的市场，因其将托管IaaS和SaaS产品相结合。随后，Rackspace和NASA开发的OpenStack（2010年）作为VMware的vSphere（2009年发布，取代GSX）和Amazon的EC2的开源竞争对手。
这些IaaS主要提供了一些特定的抽象化：虚拟机计算节点、软件定义网络和可附加存储。与SaaS一样，托管IaaS的主要卖点是外包手动容量配置的操作和自动化，但与SaaS不同的是，托管IaaS还提供你自己软件无限量级幻影。对于大多数对外包基础设施感兴趣的公司而言，AWS提供比以往任何时候都更多的容量，甚至在你要求更多节点之前他们就已经扩展数据中心。而对于无法或不愿意外部的公司，OpenStack和vSphere等基础设施平台让你可在自己选择的数据中心托管自己的云计算。
虽然管理硬件以及基础设施平台看起来是更多的工作，但其实这是企业在内部部署的平台正在做的工作。有些企业甚至在没有虚拟层的情况下手动管理硬件，无论哪种情况，他们都渴望让配置更加自助化。这也让即服务模式更加完整：托管的平台成为封装产品，这次增加了多租户功能，允许客户自己为内部用户群体进行操作。
随之而来的是应用平台。
▲基础设施平台上的应用平台
应用平台
最早使用平台即服务的是Fotango的Zimki（2006年）以及Heroku（2007年）。随后谷歌App Engine（2008年）、CloudFoundry（2011年）等也加入这个阵营。
那个时候，这些显然都是真正的应用平台（aPaaS），专门用于加速开发人员的速度和减少运营开销。开发人员可自我配置以及管理他们开发的应用程序，这进一步压缩从开发到发布到反馈到改进的周转时间，进一步促进灵活软件开发，并与新兴的DevOps运动相结合。
但进步永远不会停止，容器平台应运而生。
▲基础设施平台上的容器平台
容器平台
容器化出现的时间可能比你想象的更长（FreeBSD Jails在2000年已经出现），但可以肯定的是，容器化在Docker（2013年）结合Linux操作系统级虚拟化及文件系统镜像才开始真正广泛流行。这使得很容易构建和部署容器化应用程序，IaaS用户熟悉这种模式，因为他们一直在构建磁盘镜像来加速基础设施平台配置。但与虚拟机不同，容器允许你在本地部署完整的微服务堆栈，大大加快了开发周期。另外，由于开销降低，每个微服务都可以有自己的容器镜像、发布周期以及更新，这允许更小的团队来同时开发。
从容器运行时到容器平台是明显的进步。CloudFoundry等应用平台和Apache Mesos等集群资源管理器一直在透明地使用容器隔离。下一步是公开平台API，允许开发人员部署日益流行的Docker镜像。与基础设施平台一样，容器平台也是在内部部署开始，后来被提供为托管服务。Mesosphere的Marathon（2013年）是第一个通用容器开源平台，但前面还有一些内部平台，例如谷歌的Borg（大约2004年）以及Twitter的Aurora（2010年编写；2013年开源化作为Apach Aurora）。
容器编排是容器平台的核心。与应用平台一样，容器平台需要提供声明性基于约束的调度。但与应用平台不同，容器不限于12因素应用。例如，状态服务需要持久卷、隔离保证、特定域迁移过程、并置备份作业等。由于这种灵活性，容器平台很容易变得比应用平台更复杂，以支持更多类型的工作负载。
▲计算机集群上的容器平台
为了增加灵活性，以及为了在没有迁移的情况下支持传统工作负载，很多人在基础设施平台上运行容器平台，但这并不是绝对必要。容器足够靠近几乎所有工作负载兼容的单个机器，所以并非每个人都需要这种灵活性。很多开发人员将所有时间花在单层堆栈中，他们试图想办法避免重复任务（例如为每个新的应用手动制作容器镜像），为了满足这个要求，功能平台（也就是无服务器）随之出现。
▲基础设施平台上容器平台上的功能平台
功能平台
亚马逊在2014年推出AWS Lambda，引发“无服务器”热潮，AWS Lambda在其虚拟基础设施平台之上提供轻量级容器化事件处理。与其他亚马逊云服务一样，Lambda只有托管形式。随后Iron.io（2014年）、Apache OpenWhisk（2016年）、Fission（2016年）、Galactic Fog的Gestalt（2016）、OpenLambda（2016）进入市场。
功能平台的运行方式与应用平台相同，它们还包括语言特定框架。因此，开发人员只需要使用平台API来编写事件处理程序以及映射触发器到处理程序，而不需要通过多个端点来编写应用程序。功能平台通常整合API网关来处理代理、负载均衡以及集中式服务发现。与应用平台不同，功能平台透明地整合基于负载的自动缩放，因为它们可控制所有入口点和多路复用。
与容器平台相同，功能平台不一定需要基础设施平台，但与容器平台提供的灵活性不同，功能平台的设计不是为了支持各种工作负载。所以仅运行一个功能平台可能不明智或者不可能，你还可能需要较低水平的容器或基础设施平台。有些功能平台甚至被设计成与容器平台整合，利用中间层自动化来降低上层的复杂性。
▲云计算平台、接口及抽象规模
平台抽象化
这些平台层都提供自己独特的抽象化和API，有些比其他层更抽象化。有些高级平台具有自上至下的集成，但仅支持你运行的小部分工作负载。你可能会选择最高层的抽象化来最大限度提高开发人员的速度，但你也必须考虑这些平台上构建的软件将与平台紧密耦合，可能需要重复大部分工作，增加你的风险。在另一方面，较低级别平台提供最大的灵活性，可支持最广泛的工作负载，包括Web应用程序、微服务、旧巨集、数据管道和数据存储服务。它们允许轻松迁移和更容易的基础设施操作，但不一定可实现更容易地开发或操作应用、服务或作业。
应用平台和基础设施平台之间的冲突是容器平台受欢迎的重要原因之一。容器平台允许你根据每个容器来决定你的工作负载是否需要自己的环境或者可作为二进制运行，支持更多种类的工作负载。它们还提供声明性配置、生命周期管理、复制和调度，就像应用平台。如果你还需要更高水平的抽象化，你可轻松地在容器平台部署应用或功能平台，与较低级别的工作负载共享资源和机器。如果你需要较低水平的抽象化，你可在基础设施平台之上部署容器平台，而不是直接在裸机上构建。
