不到5年的时间，无服务器计算已经成熟，并以惊人的速度被采用。AWS最初提供的无服务器服务，现在已经涵盖了几十个竞争对手的平台，有两种主要的方法：功能即服务（FaaS）和基于容器的服务。可以肯定的是，无服务器超越了功能，已经成熟为云原生架构模式。因此，我们更喜欢术语Serviceful而不是serverless。
越来越多的选择和无服务器固有的抽象结合在一起，为企业架构师带来了希望和风险。
众所周知的承诺是更低的成本、更大的灵活性和更好的客户响应能力，因为企业使用无服务器技术将事件驱动架构（EDA）扩展到更多的系统。
很少有人讨论风险。随着现代化和向云转移的压力越来越大，一个时不时被忽视的风险是将非标准和/或理解不足的云技术置于企业架构的中心——这可以称之为速度陷阱。我们认为像Kubernetes这样的开源方法，以及它的无服务器分支Knative，可以成为企业架构师管理这种风险的关键。
了解支持多云EDAs（Event-driven Architecture）的公共底层的架构师可以做出更明智、更灵活的选择。我们看看两个截然不同的平台公司，谷歌和SAP提供的基于Knative的无服务器托管产品。
Google Cloud Run for Anthos
Google Anthos是一个应用程序管理平台，它为云和内部环境提供一致的开发和运维体验。
Google Cloud Run for Anthos是它的无服务器产品，允许你在完全托管的无服务器平台上开发和部署高度可伸缩的容器化应用程序。Cloud Run基于Knative，这意味着API规范是标准的Kubernetes定制资源。这一点很重要，因为这意味着你在构建系统时投入的设计工作对于任何其他基于Kubernetes的平台都是高度可移植的。
Cloud Run for Anthos为事件驱动架构（EDA）奠定了坚实的基础。
Cloud Run for Anthos提供了对许多Google源、Pub/Sub、Cloud Scheduler和定制事件的支持。当与TriggerMesh结合使用时，你可以从任何地方的事件触发Cloud Run的无服务器工作负载，甚至是内部遗留应用程序。
SAP云平台，Kyma运行时
SAP从一个与谷歌截然不同的地方进入无服务器领域，但它的技术水平却相差无几。谷歌吸引新应用程序的开发人员，SAP则以拥有庞大的复杂内部企业应用程序安装群而自豪。确保这些客户能够经济高效地使用无服务器和事件驱动功能更新这些应用程序是SAP的主要目标。
Kyma允许你通过使用微服务和无服务器功能构建扩展，因此开发人员可以扩展SAP解决方案，还可以结合现有IT解决方案来创建新功能。就像
Cloud Run for Anthos一样，Knative锚定了Kyma的无服务器功能。Knative支持这两个用例的无服务器需求的能力，说明了它的多功能性。
开源和开放标准降低了平台选择的风险，它们不仅提供了更大的应用程序可移植性，也降低了重新学习的需要——你可以在多个基于Kubernetes的环境中使用相同的技术、模型，在许多情况下使用完全相同的YAML。
原文链接：
https://thenewstack.io/avoid-the-serverless-speed-trap/
