阅读量:16
作者 | Bilgin Ibryam
译者 | 马可薇
策划 | Tina
摘要
注：文中观点与预测仅代表作者本人，与 InfoQ 无关
随着 AWS Lambda 即将于今年迎来十周年，无服务器计算已不再局限于功能即服务（FaaS）。如今，无服务器是指无需手动配置、按需自动提供扩展，以及采用按用量计费的云服务。这种转变只是云计算广阔发展的一部分，而无服务器技术也在不断变革。本文中关注无服务器技术之外的未来，探索云计算的格局将如何超越目前的超大规模模式，以及其对开发者和运营团队的影响。作者将探讨这一演变下的三大趋势。
从基元到结构即服务
在软件开发中，“模块”或“组件”通常是指执行一系列相关联操作的自包含软件单元。这一概念是对微服务架构很好的映射，后者通常运行在虚拟机或容器服务等长期运行的计算服务中。作为最早被广泛使用的云服务之一，AWS 的 EC2 提供了可扩展的虚拟机，而这种可扩展、可访问云资源的引入为微服务架构的实用性和普及化提供了必要的基础设施，也导致了单体应用分解至可独立部署的微服务单元。
让我们回到对软件单元的类比。函数是封装了一系列执行单一任务、定义输入输出语句的代码块，这种代码单元与 FaaS 的执行模式十分吻合。在 AWS Lambda 出现之前，FaaS 无需管理基础设施便可根据事件执行代码的概念就已经存在了，不过是缺乏广泛的实施和认可。
在 AWS Lambda 将无需管理基础设施，即可根据事件执行代码的概念引入主流视线之前，谷歌应用引擎（App Engine）、Azure WebJobs、IronWorker 及 AWS Elastic Beanstalk 等服务早已提出 FaaS 的概念。Lambda 作为 FaaS 的首个主要商业实施，通过简化开发者的部署流程催化了 FaaS 的流行，促使微服务转变为更小化、可独立扩展、以事件为驱动的操作。
随着服务的提供在向着更小的软件单元演进，人们可能会好奇表达式或语句等基本的变成元素是否也会成为服务的一种（如 int x = a + b;）。然而，演变的方向却有所偏折。我们正在见证函数逐渐缩小并最终被可配置的云结构所取代。软件开发中的构造包含条件（if-else、switch 语句）、循环（for、while）、异常处理（try-catch-finally），以及用户定义的数据结构等元素，这些在控制程序流程或管理复杂数据类型方面发挥着重要的作用。在云服务中，实现分布式应用程序的组成、微服务及函数等软件模块的相互连接，以及管理其间的数据流，构造与上述这些功能相一致。
云构造取代函数、取代微服务、取代单体程
开发者曾经或许要通过函数才能进行筛选、路由、批处理、拆分事件或调用其他云服务或函数，但现在这些操作等等都能都能通过更少的函数代码，多数情况下甚至不需要函数代码就能完成；它们可以被可配置的云构造，以云服务一部分的形式取而代之。下面作者将通过 AWS 的几个具体示例，展示从 Lambda 函数代码到云构造的过渡：
以上只是应用程序代码结构转变为无服务器云结构的几个例子。与其在函数中通过 if-else 逻辑验证输入，不如通过配置进行输入验证；与其用 case 或 switch 语句调用函数中其他代码将事件路由，不如在函数外声明式定义路由逻辑。无需 for 或 while 循环等重复结构，数据源的数据变化、批处理或拆分即可触发事件。
无需函数，便可验证、转换、批处理、路由和富集事件；无需 try-catch 代码，错误即可通过死信队列（DLQ）重启，成功的则被引导至其他函数和服务端点。将这些构造从应用程序中转移至构造配置，可消减应用程序代码数量，从而减少安全修复和各类维护的需求。
程序设计中的“基元（primitive ）”和“构造（construct）”有不同的含义和作用。基元是编程语言中固有的基本数据类型，包含一个基本值（如整数、浮点、布尔或字符）且不包含其他类型。与此概念相类似，云也就像是个巨大的程序运行时，正在从网络负载平衡器、虚拟机、文件存储和数据库等基础架构基元向更精细且可配置的云结构演进。
与编程结构一样，云结构协调分布式应用程序的交互和复杂数据流的管理，不过这些结构并不是孤立的云服务，不存在单独的“过滤即服务”或“事件发射器即服务”。虽说“结构即服务”也不存在，但它正逐渐成为网关、数据存储、消息代理和函数运行时等核心云基元的必备功能。
这种演变缩减了应用程序代码复杂性，在多数情况下还可免除对自定义函数的需求。随着许多颇具见地的演讲和 GitHub 代码示例的出现，这种从 FaaS 到 NoFaaS（no fuss 谐音，意味着简单）的演变只是个开始。接下来作者将对垂直多云服务中出现的构造丰富的云服务进行更多探讨。
从超大规模到超专业化
在后无服务器云时代，仅仅提供容器和函数的计算等高度可扩展的云基元，或是键值存储、事件存储、关系数据库之类的存储服务，又或者是负载均衡器等网络基元已经不够了。后无服务器云服务必须拥有丰富的开发人员构成，且能拆除大部分应用管道。这不再局限于为广大用户提供超大规模云服务，而是为高要求用户提供深度专业化的高级构造。
AWS、Azure、GCP 等超大规模云服务商坐拥大量服务类型和广泛用户群体，是有能力识别新用户的需求和构造。话虽如此，提供这些更为细化的开发者构造会导致复杂性上升，所有服务中的每一项新构造都需要对其具体细节深入学习，才能有效地加以利用。因此，在后无服务器时代，我们将会观测到精通某个领域的垂直多云服务兴起，这种转变将会代表云服务向着超专业化的方向发展。
以 Confluent Cloud 为例，虽然所有主流超大规模云供应商如 AWS、Azure、GCP 等等都提供卡夫卡服务，但没有哪家提供的开发者体验和构造能与 Confluent Cloud 相媲美。Confluent Cloud 的卡夫卡 broker 联合众多卡夫卡连接器、集成模式注册表、Flink 处理、数据治理、追踪、信息浏览，提供构造最为丰富也最为专业的卡夫卡服务，是超越了超大规模云供应商所能提供的服务。
这种趋势无独有偶，其他例子还包括 MongoDB Atlas 和 DocumentDB、GitLab 和 CodeCommit、DataBricks 和 EMR、RedisLabs 和 ElasticCache 等等。除了老牌云公司之外，专注于单一云基元（如专业计算、存储、网络、管道搭建、监控等）的初创公司也有了新的一波崛起浪潮，他们通过开发者构造将其丰富化，从而提供独特的价值主张。以下是一些提供专业化单一开源技术的云服务，意在提供构造丰富的体验，并从超大规模云供应商处吸引用户：
这里只列出了在超专业化垂直多云服务这一不断增长的生态系统中的冰山一角，这些多云服务是建立在超大规模企业所提供的核心基元之上，通过一套全面可编程结构及增强的开发者体验展现其竞争力。
无服务器云服务通过丰富的开发者构造在单一领域超专业化发展
实现了这项转变之后，那些没有丰富构造的白板云服务，就算是无服务器的版本，也会显得像是过时的内部软件。存储服务必须能像 DynamoDB 一样实现流式变更；消息代理得有类似 EventBridge 的结构来实现事件驱动的路由选择、过滤，以及具备重试和死信队列功能的端点调用；发布订阅系统应提供消息的批处理、拆分、过滤、转换和富集功能。
最终， 超大规模云供应商通过不断增加服务器数量横向发展，超专业化企业则是纵向发展，提供专一领域内构造丰富的最强服务，从而形成一个纵向多云服务生态系统。未来云服务的竞争将从基础设施基元转向核心云基元和以开发者为中心的二元结构。
从基础设施到复合即代码（CaC）
云构造逐渐模糊了应用程序与基础设施责任之间的界限，而下一轮的发展则是云自动化、应用程序继承和自动化代码工具及责任的“左移”，让我们来看看这一转变是如何展开的。
第一代云基础设施管理是由基础设施即代码（IaC）定义，这种模式的出现是为简化基础设施的配置和管理，是建立在云计算虚拟化商品化的趋势之上。
最初的 IaC 工具引入了全新的领域特定语言（DSL），以可重复的方式创建、配置和管理云资源。在这阶段的主流工具有 Chef、Ansible、Puppet 以及 Terraform。这些工具利用声明式语言，允许运营团队在代码中定义基础设施所需的状态，从而抽象出底层的复杂性。
然而，随着云技术从从底层粗粒度基础设施过渡到更多以开发者为中心的细粒度结构，这种向着使用已有通用编程语言定义结构的趋势正在逐渐成型。像是 Pulumi 和 AWS 云开发者指南（CDK）这类新工具是站在了这股浪潮的前沿，支持 TypeScript、Python、C#、Go 和 Java 的编程语言。
驱使这股趋势向通用语言转变的是克服声明式语言局限性（声明式语言缺乏编程式定义云结构的表现力和灵活性）以及将配置云结构责任从运营左移到开发者的需求。与声明式语言适用于低级静态基础设施的静态性质不同，通用语言允许开发则定义动态和逻辑驱动的云构造，从而实现与应用代码更为紧密的结合。
将应用程序的组成从基础设施左移到开发者团队
后无服务器时代的云开发者需要通过编写函数和微服务来实现业务逻辑的同时，还要用可编程的云结构将其组合在一起。这样一来就需要开发者为开发和拼装云应用程序承担更为广泛的责任，举例来说，Lambda 函数内代码实现的业务逻辑同样需要在 API Gateway 中路由、过滤和配置转换请求。
其他的 Lambda 函数可能会需要 DynamoDB 流配置去流式处理特定的数据变化、EventBridge 路由、过滤和富集配置。
还有的应用程序可能会将大部分协调逻辑以 StepFunction 形式表示，而 Lambda 代码只是其中的一个小任务。开发者而不是平台工程师或运营，可以将这些代码单元组合在一起。Pulumi、AWS SDK 等工具让开发者可以选择语言实现函数， 再用同一种语言完成函数与云环境的交互，这些工具是最适合这个时代的。
平台团队还是可以用 Terraform 等声明式语言管理、保护、监控和赋能云环境中的团队。但让开发者为中心的构建和开发者为中心的云自动化语言相结合，将会左移云构造并让开发者在云上的自助服务成为现实。
从 DSL 到通用语言的发展，标志着 IaC 演进过程的一个重要里程碑。它承认了应用代码向云构造的过渡，后者往往需要开发者对应用程序需求的资源有更为深入的掌控；这种转变也代表着 IaC 工具的程序，可以满足更广泛的基础设施协调需求，为更复杂也更高级的抽象和工具铺平道路。
基础设施的管理将会从静态配置转向更为动态的代码驱动方式，这种转变不会局限于基础设施即代码，而是向着“复合即代码”这一颗粒度更细的领域过渡。这种模式进一步模糊了应用程序与基础设施之间的界限，从而实现更精简、更高效也更利好开发者的实践。
总 结
在总结趋势和其所带来的组合效应时，我们会注意到编程结构和云服务之间的集成度越来越高，每项服务都将集成 CI/CD 管道，数据库将从边缘提供 HTTP 访问并发出变更实践，消息代理将通过过滤、路由、幂等性、转换、DLQ 等对功能进行增强。
基础设施服务正在转变为无服务器 API、代码推断基础设施（IfC）、框架定义基础设施，或是仅由开发者组成的基础设施（CaC）。这种变化会导致函数缩水和偶尔的 NoFaaS 模式，为超专业化和开发者优先的垂直多云服务铺平道路。这些服务将提供 基础设施即可编程 APIs，允许开发者使用自选的编程语言无缝合并自己的应用程序。
通过云服务将应用程序的组成左移，会使其与应用程序编程更多地相结合，让微服务从架构风格转变为组织风格。微服务将不再是单一的部署单元或流程边界，而是功能、容器，以及云结构的组合，所有这些都会通过开发者所选的编程语言实现并黏合在一起。未来的云计算将会更加专业化，也更以开发者为优先。
查看英文原文：
Cloud-Computing in the Post-Serverless Era: Current Trends and Beyond
