从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”或“扫一扫”二维码关注公众号，点击原文链接获取电子书详情。

求知若渴, 客气若愚

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！