IaaS vs CaaS vs PaaS vs FaaS:选择合适的平台


探索各种云平台,为您找到最好的平台。

由Jeff Kubina授权的CC By-SA 2.0“Circumhorizontal Arc”是否购买,构建或采用了开放源码,您可能已经在使用某种软件平台来构建,部署和扩展您的应用程序。

经过多年将应用程序中的常用功能提取到较低级别的抽象中之后,平台就出现了。 如果以故意的意图和设计完成,你会得到一个平台。 如果不是的话,你可能最终会在自己的手中产生一个有机的混乱,并发现自己正在寻找其他人为了出路而建造的平台,一线希望。

适合您的平台将在灵活性和简单性之间实现您所需要的平衡,使您能够更快地构建,而不会受到太多限制。 本文将分析云平台的各个方面,帮助您找到最适合您情况的方案。

每个人都有自己的想法,看看这个完美的平台是什么样子的,因为每个人的用例都有些不同。 但是每个人都在寻找两件大事:

发展速度加快

自动化操作专长

这两个需求推动了大部分软件平台的投资。 真的,他们是你可能用来自动化任何事情的相同论点:速度和可重复性。

因此,要知道没有哪个平台对所有用户都是完美的,你应该自己写吗? 如果你自己写,你是建立在现有的平台之上吗? 你如何选择一个基础平台开始? 你是否想要一个从上到下紧密集成的平台,还是你想要多层平台与强壮的扩展点松散连接?

这些都是很难回答的问题,而且没有一个适合每个人的答案。 平台幸福之旅是发现,比较和权衡之一。 所以让我们深入。

平台频谱

云平台的彩虹对每个人都有一种风味。

每个厂商都会告诉你他们的软件是特殊的,甚至是独一无二 他们都试图区分他们的产品提供不可替代的价值。 但是,如果你看起来足够硬,并容忍一些粗糙的边缘,你可以按照他们提供的接口类型对这些产品进行分组。

云平台的例子

软件平台

“软件即服务”这个术语中最古老的一个可以追溯到2000年左右,它提到将打包的软件产品和支持服务捆绑到一个托管的解决方案中,以避免经常不为人知的实施和操作成本。一个SaaS产品本身可以成为一个平台。该术语的一些原始用途描述了取代传统企业资源规划(ERP)和客户关系管理(CRM)平台的解决方案。

像Salesforce和SAP这样的公司在这个领域非常成功,没有大型工程部门或IT部门的客户可以构建和管理这些复杂的系统。即使拥有这些资源的公司也可能认为这些事情超出了自己的核心竞争力,不值得建设或运营。然而,最近几乎所有类别的软件都可以作为SaaS获得,从电子邮件到文字处理到内容管理系统。

另一方面是基础设施即服务。

Provisioning applications onto an infrastructure platform

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

基础设施平台

基础架构平台在SaaS之后不久就到了。 VMware GSX Server(2006)和Amazon Elastic Compute Cloud(EC2,2006)都提供了早期的虚拟化平台。虽然VMware最初专注于企业内部部署安装,但由于其托管的IaaS和SaaS产品的结合,亚马逊网络服务在更广阔的市场中引起了共鸣。后来,Rackspace和NASA开发了OpenStack(2010),作为VMware的vSphere(2009年发布,取代GSX)和亚马逊EC2的开源内部竞争者。

这些IaaS主要提供一些特定的抽象:虚拟机计算节点,软件定义的网络和可附加存储。与SaaS一样,托管的IaaS的主要卖点是外包运营和自动化的其他手动容量供应,但与SaaS不同的是,托管的IaaS也出售您自己软件的接近无限规模的幻想。对于大多数对基础设施外包感兴趣的公司,AWS提供的功能比他们以往需要的还要多,在您要求更多节点之前扩展数据中心。对于无法或不愿意外包的公司,OpenStack和vSphere等基础架构平台可以在您选择的数据中心内托管自己的云。

虽然不仅管理硬件,而且管理基础设施平台似乎还有更多的工作,但这正是企业已经在本土平台上所做的工作。无论是他们还是手动管理没有虚拟化层的硬件,都渴望使配置更加自助。所以,即服务模式走完全程:托管的平台成为打包产品,这次增加了多租户功能,允许客户为自己的内部用户群体操作。

接下来是应用程序平台。

Application Platform on an Infrastructure Platform

基础设施平台上的应用平台

应用平台

第一个使用“平台即服务”一词的是Fotango的Zimki(2006)和Heroku(2007)。 后来的Google App Engine(2008),CloudFoundry(2011)以及其他一些人加入了这场争斗。 到那时,很明显这些应用平台(aPaaS)是专门为加速开发速度和减少运营开销而设计的。 使开发人员能够自行配置和管理他们开发的应用程序,进一步缩短了从开始到发布的周转时间,并反馈到迭代,与敏捷软件开发的日益普及以及刚刚起步的DevOps运动紧密相连。

但进展从未停止。 集装箱平台在这里。

Container Platform on an Infrastructure Platform

基础设施平台上的集装箱平台

集装箱平台

容器化的时间比你可能意识到的还要长(自2000年以来,FreeBSD Jails已经出现了),但是可以肯定的是,在Docker(2013)将Linux操作系统级虚拟化与文件系统结合之前,集装箱化并没有真正普及图片。这使得构建和部署集装箱化应用程序变得简单易行,IaaS用户可以通过构建磁盘映像来加速基础架构平台配置。但是与虚拟机不同,虚拟机同时运行足以让你的工作站停滞不前,容器允许你在本地部署全部的微服务栈,大大加快了开发周期。另外,由于开销减少,每个微服务可以拥有自己的容器映像,自己的发布周期和自己的滚动升级,允许更小的团队并行开发它们。

从集装箱运行时到集装箱平台是一个明显的进化步骤。像CloudFoundry这样的应用程序平台和像Apache Mesos这样的集群资源管理器自从开始就一直透明地使用容器隔离。下一步是公开一个平台API,允许开发人员在一群机器上部署日益流行的Docker镜像。就像基础设施平台一样,集装箱平台在内部部署,后来作为托管服务提供。 Mesosphere公司的Marathon(2013)是第一个用于通用容器编排的开源平台之一,但是它早于Google的Borg(〜2004)和Twitter的Aurora(编写于2010年;在2013年开源为Apache Aurora )。

集装箱业务处于集装箱平台的核心。像应用平台一样,容器平台需要提供基于声明约束的调度。与应用程序平台不同的是,容器并不局限于十二个因素的应用程序。例如,有状态服务需要持久化卷,隔离保证,特定于域的迁移过程,并置备份作业等。由于这种灵活性,容器平台可能比应用程序平台更容易变得更加复杂,以支持更广泛的工作负载。

Container Platform on a Cluster of Computers

计算机集群上的容器平台

为了增加灵活性,并且在不迁移的情况下支持传统工作负载,许多人在基础架构平台上运行容器平台,但这不是必须的。 容器足够接近单个机器,几乎所有的工作负载都是兼容的,所以不是每个人都需要这种灵活性。 许多开发人员将所有时间花在堆栈的单层上。 他们正在寻找避免重复的任务的方法,比如为他们构建的每个新应用程序手工制作容器图像。 对于这些人来说,功能平台(又名无服务器)就是这样制作的。

Function Platform on a Container Platform on an Infrastructure Platform

基础设施平台上集装箱平台的功能平台

功能平台

亚马逊利用AWS Lambda(2014)开启了“无服务器”的热潮,在其虚拟基础架构平台上提供轻量级集装箱事件处理。像其他亚马逊网络服务一样,Lambda是仅托管的。因此,由Iron.io(2014),Apache OpenWhisk(2016),Fission(2016),Galactic Fog’s Gestalt(2016),OpenLambda(2016)填补的内部替代品市场很快就出现了。

功能平台与应用平台一样运行,除了它们还包括语言特定的框架。因此,开发人员不必编写具有多个端点的应用程序,而只需编写事件处理程序,然后将触发器映射到具有平台API的处理程序。功能平台通常带有或与API网关集成,以处理代理,负载平衡和集中式服务发现。与应用平台不同,功能平台透明地包含基于负载的自动缩放,因为它们控制所有入口点和复用。

与容器平台一样,功能平台也不一定需要基础架构平台,但与容器平台提供的灵活性不同,功能平台的设计目的并不在于支持各种各样的工作负载。所以只运行一个功能平台可能是不明智的或不可能的。您可能还需要较低级别的容器或基础架构平台。一些功能平台甚至被设计为与集装箱平台集成,利用中间层自动化来降低高层的复杂性。

Cloud Platforms, their interfaces, and the scale of abstraction

云平台,它们的接口和抽象的规模

平台抽象

这些平台层中的每一个都提供了自己独特的抽象和API,有些比其他抽象更抽象。一些高层次的平台是全部或没有;他们有自上而下的整合,但只能支持一小部分你想运行的工作负载。您可能会试图选择最高的抽象层来最大限度地提高开发人员的速度,但是您也必须考虑到构建在这些平台上的软件将与平台最紧密地耦合,潜在地需要最多的重新工作来重新平台化,增加你的风险。另一方面,底层平台提供了最大的灵活性,支持最广泛的工作负载,包括Web应用程序,微服务,传统整体,数据管道和数据存储服务。他们允许轻松迁移和简化基础架构操作,但不要让实际开发或运行应用程序,服务或工作更容易。

应用平台和基础设施平台之间的这种冲突是集装箱平台受欢迎的重要原因之一。集装箱平台是双方的妥协。它们允许您根据每个容器来决定您的工作负载是需要自己的环境,还是可以作为二进制运行,从而支持更广泛的工作负载。但是它们也提供声明式配置,生命周期管理,复制和调度,就像应用程序平台一样。如果您还需要更高级别的抽象,则可以轻松地在容器平台上部署更薄的应用程序或功能平台,共享资源和具有较低级别工作负载的计算机。如果您还需要较低的抽象级别,则可以轻松地在基础架构平台上部署容器平台,而不是直接在裸机上部署。

DC/OS Architecture Layers

DC/OS 建筑层

DC/OS – 选择的平台

在Mesosphere,我们的使命是使建立和扩展世界变化的技术变得非常容易。 这意味着我们不仅仅为开发者或运营商提供服务,而且还为这两者服务。 帮助您实现真正的灵活性需要开发人员的速度和操作的灵活性。 开发人员希望减少重复性工作,实现弹性自动化,并建立在强大的平台服务之上。 运营商希望能见度,避免供应商锁定以及控制成本的能力。 所以我们建立了DC / OS来提供一个与云类似的服务和开放的合作伙伴生态系统的基础设施无关的容器平台。 使用DC / OS,您可以获得一个坚实的容器平台,以及更高级别的服务目录:数据库,队列,测试自动化,持续交付管道,日志记录和指标堆栈,自动缩放器,功能平台等。

有关集装箱平台的更多比较,请参阅Container Platform Wars。

来源:https://mesosphere.com/blog/iaas-vs-caas-vs-paas-vs-faas/