PaaS、CaaS还是FaaS？基于容器的应用程序选择云架构时应当注意哪些关键问题和事项？数据湾给大家介绍一下。

想象一下，走进一家专门经营汉堡包的商店，里面有各式各样的汉堡包。虽然店里只有汉堡包

但是当你想购买汉堡包时，那么这家商店可提供的选择还是很多的。

如果你是汉堡包达人，那么你可以在第一通道自己挑选牛肉、鸡肉、奶酪、面包、蔬菜、调味

品以及其他制作汉堡包可能要用到的配料。你甚至还可以选择用于盛餐的盘子和容器。

如果你没有时间、手艺或兴趣自己制作汉堡包，那么你可去第二通道，并在那里购买一个汉堡

包。除了经典款外，你还可以选择有机汉堡、素汉堡、甚至是生酮keto汉堡。你只需要按照说明进行操作，就可以吃上一个美味的汉堡。

如果你是汉堡包厨师，那么老板可能会打来电话，让你在午餐前的两个小时内制作300个不同类型的汉堡。除了制作汉堡之外，你还必须要招呼客人并负责收款。在这期间，你必须要小心，因为有些人对汉堡包会有一些特殊的要求，还有一些人则会插队并偷走他们的午餐。

最后，在午餐期间你会遇到健康和安全检查，因此无论你做什么都应严格遵守规定。遗憾的是

，和你一起工作的只有几个人，并且他们在这些方面几乎没有什么经验。

 制作“云”汉堡

选择云架构非常类似于上述制作汉堡包的操作，并且在许多方面要更为复杂。在选择使用哪个

云架构时，开发人员、工程师、架构师和IT领导者需要考虑平台、性能、法规和其他因素。

哪种架构可为客户提供更好的体验和更高质量的产品呢？哪个更易于操作并能按期完成呢？哪条路径可以更好地处理支持性、合规性和安全性问题呢？最后，哪种方法是你能够以最低的成本部署的呢？

工程技术人员可以选择“容器即服务”(CaaS)，并对应用程序进行容器化。这相当于厨师通过第一通道自己制作汉堡。如果他们不具备这些专业知识，那么平台即服务(PaaS)相当于在第二通道，他们可以选择套件并遵循使用指导和限制。

那CaaS和PaaS都不符合需求呢？

那也好办，你可以从头开始构建所有内容(基础设施即服务或

IaaS)，也可以将函数部署到无服务器环境(也就是函数即服务或FaaS)。

FaaS是一种无服务器计算，旨在响应单个任务。例如，FaaS可用于验证用户身份，对正文进行拼写检查或进行数学计算。

显然，将代码托管、配置、管理或部署到云端有许多选项。在考虑不同的产品解决方案时，事情往往会变得非常复杂。PaaS选项包括Azure应用服务、AWSElasticBeanstalk、谷歌AppEngine、RedHatOpenShift和Salesforce的Heroku等。如果你正在考虑CaaS解决方案，那么你会发现亚马逊、谷歌和微软都拥有自己的托管Kubernetes服务，它们分别为EKS、GKE和AKS。此外，你还可以选择来自VMware、IBM、甲骨文、Rackspace等厂商的产品。

当然，你还有更多的无服务器选项。AzureServerless拥有无服务器函数、KubernetesPod和应用程序环境。AWS的无服务器选项则较为广泛，并涉及计算、存储、数据仓库、API代理等的功能类别。谷歌Cloud对无服务器进行了广泛的定义，其中包含了BigQuery和AutoML等服务。

 关于CaaS、PaaS、FaaS和无服务器的关键注意事项

在评估不同的云体系结构时，需要注意以下一些事项。

目标受众——PaaS和FaaS选项的优先目标是开发人员，他们使得解决方案更易于配置且可与

CI/CD(持续集成/持续交付)管道整合在一起进行部署。容器参数化了操作环境和平台配置，因此这些工具的目标通常是操作人员和系统管理员。

可配置性vs敏捷性——通常，CaaS的可配置性最高。在容器化方面，CaaS在平台和配置的选择上赋予了操作人员极大的灵活性。PaaS和FaaS则更专注于敏捷性，能够帮助开发人员更快地部署和测试代码。

已经过优化的PaaS解决方案——如果PaaS和FaaS解决方案经过了预先优化，那么这意味着

你已被平台和配置选项所锁定。这些解决方案是根据设计师的意见开发的，这些设计师决定了开发人员的需求、最佳实践和目标性能特征。对于那些喜欢更高的灵活性或更多控制权的操作人员而言，这种自以为是的PaaS或FaaS会让他们感到束手束脚。

技能和学习曲线一—通常情况下，与PaaS和FaaS解决方案相比，CaaS解决方案的学习曲线更加陡峭，并且需要更多的技能。厂商锁定——CaaS解决方案通常都是基于Kubernetes开发的，并且可以在不同的云托管服务商之间迁移。尽管PaaS和FaaS解决方案也可以Kubernetes为基础进行设计，但是他们一般不会向最终用户开放Kubernetes层，取而代之的是提供更为简洁的配置。这些配置为PaaS和FaaS解决方案所专有，并且通常被设计为仅在某个云端上运行。一些IT主管发现了这个问题，并担心会被云服务提供商锁定。

 一些关于研究和原型制作的问题

当面对如此多的选择时，一些企业几乎不再进行研究和原型制作，而是选择走捷径。还有一些

企业依然投入大量的时间、精力和资金来研究可供选择的选项，咨询专家意见，然后再选择可以实现可靠部署的选项。

当面临太多选择时，企业往往会变得不知所措，相比之下，这两种做法反而效果更好。在当今的

快节奏世界中，所有的企业都在试图获取技术优势，过于保守和维持现状只会抑制企业的发展机

会。

因此，我咨询了许多专家并找出了一些关键问题。这些问题可以帮助企业缩小选择范围：

 1.你是否有一支只负责少量应用程序的小型团队？

在这种情况下，你应该考虑使用更为简单的PaaS和无服务器。优点是，用户无需投入大量的时间和专业知识就可以获得大多数自己所需要的且经过预配置过的平台。AvidXchange平台架构总监DJNavarrete建议：“对于那些需要调整大量管理措施提供支持的中小型企业，以及那些希望迅速提高成熟度、稳定性和速度的企业而言，PaaS之所以具有吸引力是因为它们为部署和提高效率提供了一条更为快捷的途径。”

 2.你是否有一些在有需求时才需扩展的暂时性负载？

如果答案是肯定的，那么除了完整的应用程序和数据库外，你还可以选择使用微服务或函数。这些用例非常适合无服务器计算，你只需为所需的使用量付费即可。

 3.你是否有合规义务或是受到一些法规标准的约束，强制你要对执行容器、应用程序、数据库、操作系统或基础设施中的某些特定的基础性选项或设置进行报告？

微软ModernWorkplace卓越中心的安全与合规架构师WayneAnderson指出，这是排除无服务器选项的一个重要原因。PCI和其他合规性要求通常被法律部门或审核人员理解为需要计算环境设置的证明。

 4.你是否正在使用许多专用平台或旧版应用程序？

在这些情况下，你可能很难找到兼容的商用PaaS选项。与此同时，容器的开发可以简化部署和依赖性管理。

 5.你的企业是否是一家使用着多个云服务，并在生产中使用各种应用程序和数据平台的大型公司或企业？

这些公司可选择对容器进行标准化，因为它们在支持多个平台和配置选项方面能够提供最大程度的灵活性。如果合规性不是一个因素，那么你可以考虑无服务器。如果企业具有足够的技术实力，且能够基于Kubernetes开发出更多的选项，那么企业要避免PaaS。拥有足够规模和技术实力的企业(例如Shopify)可以选择以Kubernetes和容器为基础设计自己的PaaS。

 6.你是否正在开发微服务并在基于云的微服务架构上进行标准化？

MarkHeath认为，在这种情况下，容器或FaaS都是不错的选择，在容器中托管函数也是如此。

Heath表示，无服务器函数更容易配置且支持成本更低，而容器则可以简化本地开发并为保护端点提供更多选项。

 7.云服务顾问SarbjeetJohal想知道，你是正在构建平台，应用程序还是服务，以及受众是企业内部的，外部的，还是面向客户的，亦或是机器消耗品？

了解应用程序的类型和最终用户的类型有助于预测未来的需求。Johal举例说：“对于外部应用程序，你想要记录更多的访问控制，那么数据量可能会出现意外增长，与内部应用程序相比，该应用程序的寿命可能会更长。如果一个服务或平台是机器消耗品，那么你可能需要计量。”对路线图和未来需求进行预测可以帮助选择某些选项，并排除其他的选项。

一旦缩小了选择的范围，最佳实践将是进行概念验证。就如同在不确认订单的情况下，你是不

会制作300个汉堡包的。