企业在为基于容器的应用程序选择云计算架构时需要了解关键问题和注意事项。
想象一下，走进一家专卖汉堡包的杂货店，里面有各种各样的汉堡包，虽然有很多选择，但只有汉堡包。
如果你是一名汉堡包厨师，可以在店里选择牛肉、鸡肉和其他蛋白质，以及奶酪、面包、蔬菜、调味品以及其他制作汉堡包的食材，甚至还可以选择盛餐的盘子和容器。
如果你没有时间、技能或兴趣自己制作汉堡包，那么可以在店中购买汉堡包。除了传统的选择之外，还有素食汉堡包等。只需按照工具包中的说明进行操作，就可以吃到一个美味的汉堡。
如果汉堡包厨师突然得到通知，需要在午餐前的两个小时内制作300个不同的汉堡包。另外，除了制作汉堡之外，还必须实施一个流程为客户提供服务并获得报酬。那么需要小心，因为有些客户想要特殊订单，而另一些客户会减少订单。
最后，在午餐期间还需要进行健康和安全检查，因此无论做什么，都应更好地遵守规定。而你只能和几个人一起工作，他们在这种操作上经验也很少。
制作云汉堡
在云计算架构中进行选择与这种临时制作汉堡包的操作非常类似，并且在许多方面要复杂得多。在考虑要运行的云计算架构时，开发人员、工程师、架构师和IT领导者需要考虑许多平台、性能、法规和其他考虑因素。
哪种云计算架构将为客户提供更好的体验并提供更高质量的产品?哪个更易于操作并在截止日期前完成?哪条路径可以更好地处理支持、合规性和安全性问题?最后，能否以比较低的成本实施哪种方法?
工程师可以选择容器即服务(CaaS)选项并对应用程序实施容器化，这相当于汉堡包厨师通过创建和操作餐点。如果他们不具备这些专业知识，那么平台即服务(PaaS)选项相当于选择工具套件并遵循使用说明和限制。
容器即服务(CaaS)和平台即服务(PaaS)都不符合需求吗?可以从头开始构建所有内容，(采用基础设施即服务)，也可以将功能部署到无服务器环境(采用功能即服务)。
功能即服务(FaaS)是一种无服务器计算，旨在响应单个任务。例如，功能即服务(FaaS)可用于验证用户身份、对文本体执行拼写检查或执行数学计算。
显然，有许多架构选项可以托管、配置、管理和部署代码到云平台。考虑到不同的产品，事情变得更加复杂。PaaS选项包括Azure应用服务、AWS弹性Beanstalk、Google应用引擎、Red Hat OpenShift和Salesforce的Heroku等等。如果正在探索容器即服务(CaaS)解决方案，那么Azure、Google、AWS公司都有自己的托管Kubernetes服务，它们都有自己的缩写(分别是EKS、GKE和AKS)。另外，还有来自VMware、IBM、Oracle、Rackspace等的其他选项。
当然，还有更多的无服务器选项。Azure Serverless具有无服务器功能，Kubernetes Pod和应用程序环境。AWS云平台当前具有更广泛的无服务器选项，并将其无服务器分为用于计算、存储、数据存储、API代理等的功能类别。Google Cloud对无服务器进行了更广泛的定义，其中包含BigQuery和AutoML等服务。
CaaS、PaaS、FaaS和无服务器的关键注意事项
审查这些不同的云计算架构时，还有一些注意事项。
- 目标受众——平台即服务(PaaS)和功能即服务(FaaS)选项首先通过使解决方案易于配置并与持续集成(CI)/持续交付(CID)管道集成，以进行部署来针对开发人员。容器将操作环境和平台配置参数化，因此这些工具通常针对运营人员和系统管理员。
- 可配置性与敏捷性——通常，容器即服务(CaaS)是最可配置的选项，为操作员提供了更大的灵活性来选择平台和配置进行容器化。平台即服务(PaaS)和功能即服务(FaaS)选项专注于敏捷性，并帮助开发人员更快地部署和测试代码。
- 有些平台即服务(PaaS)解决方案受到束缚——设计时已预先选择了平台即服务(PaaS)和功能即服务(FaaS)解决方案，这意味着已经被其平台选择和配置选项所束缚。这些解决方案是根据设计师对开发人员的需求、优秀实践和目标性能特征的意见而设计的。对于喜欢更大灵活性或更多控制权的运营商而言，采用这样的平台即服务(PaaS)和功能即服务(FaaS)可能会受到影响。
- 技能和学习曲线——公平的概括是，与平台即服务(PaaS)和功能即服务(FaaS)解决方案相比，容器即服务(CaaS)解决方案的学习曲线更陡峭，并且需要更多的技能。
- 供应商锁定——容器即服务(CaaS)解决方案通常在Kubernetes上开发，并且可以在不同的云托管选项之间迁移。尽管平台即服务(PaaS)和功能即服务(FaaS)解决方案能够以Kubernetes为基础进行设计，但它们通常不会向最终用户公开Kubernetes层，而是提供更简化的配置。这些配置是平台即服务(PaaS)和功能即服务(FaaS)解决方案专有的，并且通常设计为仅在一个云平台上运行。一些IT主管发现此问题，并理应担心被锁定在某一个云计算供应商。
指导进行研究和原型制作的问题
当面对如此多的选择时，一些企业将进行最少的研究和原型设计，并选择快捷的路径。其他人将投入大量的时间、精力和费用来研究方案，咨询专家并选择方案以实现可靠的实施。
这两种方法都比使企业因众多选择而瘫痪或者无所适从要好一些。在每个组织都试图获得技术优势的快节奏世界中，过于保守和维持现状只会抑制市场机会。
因此，行业专家提出一些有助于缩小选择范围和竞争范围的关键问题：
(1)企业是只能运行少数应用程序的小型团队吗?在这些情况下，应该考虑使用更简单的PaaS和无服务器选项，从而可以在不花费大量时间和专业知识的情况下预先配置大多数必需的平台。AvidXchange公司平台架构总监DJ Navarrete建议说：“对于可能需要更多变更管理支持才能成功的中小型公司，以及那些希望迅速提高成熟度、稳定性和速度的公司而言，平台即服务(PaaS)之所以具有吸引力是因为它提供更快的实施和效率提升之路。”
(2)企业是否有零星的有效载荷，但仍需要在需要时扩大?作用域可以是微服务或功能，但也可以扩展到完整的应用程序和数据库。这些用例非常适合于无服务器计算，只需为使用的资源支付费用。
(3)企业是否具有合规义务或法规标准，强制报告执行容器、应用程序、数据库、操作系统或基础设施中的特定基础选项或设置?微软公司现代工作场所卓越中心的安全和合规架构师Wayne Anderson说，这是排除无服务器选项的重要原因。法律部门或审核人员通常将PCI法规和其他合规性要求解释为需要计算环境设置的证明。
(4)企业是否在利用许多专用平台或遗留应用程序?在这些情况下，可能很难找到兼容的平台即服务(PaaS)选项。同时，开发容器可以简化部署和依赖性管理。
(5)如果是大型组织或企业，在多个云平台中运营，并且在生产中具有各种应用程序和数据平台，这些组织可能选择对容器进行标准化，因为它在支持多个平台和配置选项方面提供了比较大的灵活性。如果合规性不是一个因素，那么仍然可以考虑无服务器。如果企业具有足够的技能和能力来开发Kubernetes上广泛的选项，则企业可能会避开平台即服务(PaaS)选项。具有足够规模和技术技能的组织(例如Shopify)可以选择以Kubernetes和容器为基础来设计自己的平台即服务(PaaS)。
(6)企业是否正在开发微服务并在基于云计算的微服务架构上进行标准化?Mark Heath建议容器或平台即服务(PaaS)都是不错的选择，在容器中托管功能也是如此。Heath表示，无服务器功能可能更易于配置且支持成本更低，而容器可以简化内部部署开发，并提供更多选项来保护端点。
(7)云计算顾问Sarbjeet Johal指出，无论是构建平台、应用程序还是服务，受众是企业内部的、外部的还是面向客户的，了解应用程序的类型和最终用户的类型有助于企业预测将来的需求。Johal说：“对于外部应用程序，企业想要记录更多的访问控制，数据量可能会意外增长，并且与内部应用程序相比，外部应用程序的使用寿命可能更长。如果服务或平台是机器消耗品，那么可能需要进行计量。”
预测路线图和未来需求应有助于推广某些选择，并排除其他选择。而在缩小选择范围后，优秀实践就是进行概念验证。
