软件栈的商品化：应用程序为先的云服务如何改变游戏规则-51CTO.COM

今天读到这篇文章，觉得不错就翻译一下。文章是翻译自 Steef-Jan Wiggers The Commoditization of the Software Stack:How Application-first Cloud Services are Changing the Game[1]，内容来自 Bilgin Ibryam 在 QCon London 上的演讲。Ibryam 在分享中从应用开发和运维两个不同的维度来讨论架构的演进：内部架构和外部架构。二者从单体应用时期的明显的界限，到如今界限愈来愈模糊。

我认为随着架构的演进，应用程序发生着巨大的变化，能力从应用中分离出来，下沉到基础设施中，甚至变成新的基础设施。基础设施，也从狭义上的物理设施、计算资源演变为软件定义的能力，这些能力不断地被产品化、商品化。新生代的基础设施，以各种运行时的方式游离在应用程序之外，二者仍保持着一定的联系：API。

以下是原文的翻译。

云服务正在不断演进，这影响着开发者构建分布式应用程序的方式。在 QCon London 大会上，来自 Diagrid[2] 的产品经理 Bilgin Ibryam[3] 探讨了云原生技术（如 Dapr[4]）与面向开发者的云服务的交集。

Ibryam 首先介绍了如何看待从单体应用程序[5] 到微服务[6] 的转变，以及接下来会出现什么。此外，他还谈到了云服务以及它正在以什么样的形式塑造架构的演变。

演讲期间，Ibryam 讲述了在云之前或云早期构建应用程序的不同阶段（时间线），从基础设施和应用程序趋势的角度探讨了计算为先的云、以及应用程序为先的云时代。

Ibryam 从云之前或云早期开始讨论，这意味着应用程序是单体 x 的。这个时代是在云计算成为主流之前，而且还没有微服务。相反，开发人员必须使用围绕业务逻辑的所有内容，从异步交互（如消息传递）到打包和缓存。此外，由两个团队（开发人员和运维人员）管理的应用程序层和基础设施之间也存在区别。

接下来，Ibryam 讨论了云计算时代早期的内部架构。2010 年后，应用开发复兴并重新得到关注，还出现了一些重要且至今仍具有影响力的软件开发趋势。通过使用 C4模型[7] 或 4+1架构模型视图[8] 对架构进行可视化和描述，可以从不同角度来观察架构。Ibryam 采用了更为直接的方法，将其分为两个层次：内部架构和外部架构。内部应用程序架构是开发人员创建并完全掌控的所有内容，例如应用程序中的不同层，或者如他所说，所有放入容器镜像中的内容。从运维（Ops）视图来看，这是一个黑盒。外部应用程序架构是应用程序与之交互的所有内容的集合，例如消息代理、数据库甚至云服务。Ops 使其可靠、可观测等。基于此，他讨论了一些影响单体应用程序开发的架构设计方法，例如领域驱动设计[9]、[六边形架构](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software "六边形架构"))、洋葱架构[10] 和清洁架构[11]。12要素应用程序[12] 和微服务[13] 原则遵循这些方法，导致单体应用程序几乎成为反模式。

在云之前和云早期之后，计算优先的云应运而生，从单体应用程序向微服务转变。内部应用程序架构的变化和云的出现导致应用程序与其基础设施之间出现了分离的集成。

在谈到计算优先时，Ibryam 详细讨论了应用程序的内部架构以及云提供的计算。它是应用程序和计算机之间的一个协议（集成绑定），无论是容器、函数还是无服务器应用程序。它发生在两端的 API 之间（操作调用，如资源需求、部署、配置和指标）。通常由运维团队负责。

接下来，Ibryam 讨论了随着云的出现，应用程序的外部架构如何再次发生变化。再次讨论了应用程序绑定的概念；然而，现在是以云服务作为应用程序的顶部，而不是作为基础设施在其下，这是开发人员的责任。

向云服务的集成绑定可以移动到另一个层面，例如分布式应用运行时（Dapr）[14]。为了在这方面与 Dapr 进行比较，Ibryam 提到了 Google Cloud Event Arc[15]、AWS EventBridge[16] 和 Azure Event Grid[17] 作为云特定的服务，以及 Camel[18] 作为语言无关的服务。而 Dapr 则是两者兼备的。

最后，Ibryam 谈到了以应用优先的云，例如，网络服务变得更加以应用为中心，并且集成云的诞生：首先是为开发人员创建的一系列管理服务。

应用程序优先的生态系统将与事件处理服务（例如 Azure Eventgrid）、与服务（例如 AWS Step Functions[19]）的状态绑定、与服务（例如 Vercel Edge Middleware[20]）的同步绑定以及与计算服务（例如 AWS ECS[21]、Azure Container Apps[22] 和 Google Cloud Run[23]）的计算绑定具有异步绑定。通信将通过遵循 OpenAPI 规范[24] 的 API 进行。最后，Ibryam 从他的讲话中提出了以下主要观点：

专注于区分业务逻辑并重用未区分的商品化能力。
使用基于事实标准的开放计算和开放集成绑定，实现可移植性。
可移植性不是关于应用程序，而是关于模式、实践、工具和人员。

关于作者

Steef-Jan Wiggers 是 InfoQ 的高级云编辑之一，目前在荷兰的 HSO 担任技术集成架构师。他目前的技术专长集中在集成平台实施、Azure DevOps 和 Azure 平台解决方案架构上。Steef-Jan 是荷兰 Azure 用户组的董事会成员，经常在会议和用户组中发言，为 InfoQ 和 Serverless Notes 撰写文章。此外，微软已经连续 11 年认可他为 Microsoft Azure MVP。

参考资料

[1] The Commoditization of the Software Stack:How Application-first Cloud Services are Changing the Game: https://www.infoq.com/news/2023/03/application-first-cloud-services/

[2] Diagrid: https://www.diagrid.io/

[3] Bilgin Ibryam: https://qconlondon.com/speakers/bilginibryam

[4] Dapr: https://dapr.io/

[5] 单体应用程序: https://en.wikipedia.org/wiki/Monolithic_application

[6] 微服务: https://en.wikipedia.org/wiki/Microservices

[7] C4模型: https://en.wikipedia.org/wiki/C4_model

[8] 4+1架构模型视图: https://en.wikipedia.org/wiki/4%2B1_architectural_view_model

[9] 领域驱动设计: https://en.wikipedia.org/wiki/Domain-driven_design

[10] 洋葱架构: https://www.codeguru.com/csharp/understanding-onion-architecture/

[11] 清洁架构: https://betterprogramming.pub/the-clean-architecture-beginners-guide-e4b7058c1165

[12] 12要素应用程序: https://en.wikipedia.org/wiki/Twelve-Factor_App_methodologyhttps://en.wikipedia.org/wiki/Twelve-Factor_App_methodology

[13] 微服务: https://en.wikipedia.org/wiki/Microservices