今年，随着 AWS Lambda 成立 10 周年，无服务器计算的范围已不仅仅限于功能即服务 (FaaS)。如今的无服务器计算，不需要手动配置，而是提供按需自动扩展，并使用基于消耗来定价的云服务，这种转变是云计算更广泛发展的部分原因。
在这篇文章中，我会重点讨论未来无服务器的发展趋势，看看未来的云服务会变成什么样子，以及这对开发人员和运营团队会产生什么影响。
下面主要以三个主要趋势，看看它们是如何推动这种变化的。、
1．从基础到服务构造
在软件开发中，“模块”或“组件”通常指的是一个自包含的软件单元，执行一系列连贯的操作。这个概念与微服务架构对应，微服务架构通常在长时间运行的计算服务上运行，如虚拟机（VM）或容器服务。AWS EC2是首批广泛可用的云计算服务之一，提供了可扩展的虚拟机。引入这种可扩展、可访问的云资源，为微服务架构提供了必要的基础设施，使其变得实用且广泛。这种转变导致将单一应用程序分解为可独立部署的微服务单元。
那么继续使用软件单元的比喻，函数是一段封装了一系列语句的代码块，执行单个任务并具有明确定义的输入和输出。这个代码单元与FaaS的执行模型相吻合。FaaS执行代码以响应事件的概念在AWS Lambda之前就存在，但缺乏广泛的实现和认可。
FaaS的概念涉及到在无需管理基础设施的情况下，响应事件执行代码。在AWS Lambda将其引入主流之前，像Google App Engine、Azure WebJobs、IronWorker和AWS Elastic Beanstalk这样的服务已经提出了这一概念。作为FaaS的第一个主要商业实现，Lambda通过简化开发人员的部署过程成为了流行的催化剂。这一进步导致了微服务向更小、可独立扩展、事件驱动的操作的转变。
作为服务提供的更小软件单元的演变过程中，有人可能会问我们是否会看到像表达式或语句这样的基本编程元素作为服务（例如int x = a + b，）。然而，这种进展偏离了这条道路。相反，我们见证了函数的最小化和最终被可配置的云构造所取代。在软件开发中，构造包括条件（if-else、switch语句）、循环（for、while）、异常处理（try-catch-finally）或用户定义的数据结构等元素，它们在控制程序流程，或管理复杂数据类型方面发挥着重要作用。在云服务中，构造与分布式应用程序的组合、软件模块（如微服务和函数）之间的互联，以及它们之间的数据流管理等功能完全一致。
云架构取代功能，取代微服务，取代单片应用。虽然以前可能使用函数来过滤、路由、批处理、拆分事件或调用另一个云服务或函数，但现在这些操作和更多操作可以在函数中使用更少的代码完成，或者在许多情况下根本不需要函数代码。它们可以被作为云服务一部分的可配置云构造所取代。让我们来看几个来自AWS的具体示例，以演示从Lambda函数代码到云结构的转换:
请求路由——API Gateway路由可以完成路由，而不是使用Lambda解析请求,并将其路由到正确的后端端点。不仅如此，API Gateway还与其他AWS服务集成，并且可以直接调用它们，从而消除了对函数的需求。
请求验证- API网关可以使用OpenAPI验证正文、查询字符串参数和报头。
数据转换——API Gateway可以使用Apache Velocity模板来转换请求和响应数据，以覆盖负载、参数、标头和状态码，而不需要Lambda。
流式数据库更改——DynamoDB Streams发出所有数据更改。这成为任何数据存储的强制构造，通过将微服务从内到外转换，消除了对应用程序代码和任何数据轮询代码的双重写入需求。
事件触发——AWS事件源映射允许通过从事件源读取并调用Lambda函数来触发Lambda。
事件过滤-事件源映射可以执行事件过滤来控制从流或队列中调用Lambda函数的记录。这消除了在函数中编写过滤逻辑的需要，并大大减少了它的大小和成本。
事件批处理-以类似的方式，事件源映射在将记录发送到函数之前将其批处理到单个有效负载中。不需要在处理之前手动循环聚合事件或拆分事件。
事件转换——EventBridge Pipes可以在将数据发送到目标之前使用JSON路径语法从源转换数据。
事件充实——EventBridge Pipes还可以在进一步处理请求之前调用另一个端点来充实请求。这提供了Content Enricher模式的实现，可以完全声明式地使用。
事件路由——与请求路由类似，EventBridge规则可以执行事件路由，允许您从应用程序代码中卸载此责任并消除Lambda函数。
基于结果的路由——Lambda目的地允许异步调用将执行结果路由到其他AWS服务，用配置代码替换Lambda调用代码。
调用其他服务——StepFunction任务不需要Lambda函数来调用其他服务或外部HTTP端点。有了它，例如，StepFunction任务定义可以执行HTTP调用或读取、更新和删除数据库记录，而不需要Lambda函数。
这些只是应用程序代码构造,成为无服务器云构造的几个例子。与使用if-else逻辑验证函数中的输入值不同，可以通过配置验证输入。与使用case或switch语句路由事件,以及从函数内部调用其他代码不同，可以在函数外部声明性地定义路由逻辑，可以在数据更改、批处理或分割时从数据源触发事件，而无需重复构造，例如for或while循环。
事件可以在没有函数的情况下进行验证、转换、批处理、路由、过滤和丰富。处理失败并将其定向到dlq并返回，而不需要使用try-catch代码，并且将成功完成定向到其他函数和服务端点。将这些构造从应用程序代码移到构造配置中可以减少或删除应用程序代码的大小，从而消除了对安全补丁和任何维护的需要。
编程中的原语和结构具有不同的含义和作用，原语是编程语言固有的基本数据类型，它包含一个基本值，如整数、浮点数、布尔值或字符，不包含其他类型。与这个概念相对应的是，云——就像一个巨大的编程运行时——正在从网络负载平衡器、虚拟机、文件存储和数据库等基础设施原语演变为更精细、更可配置的云结构。
与编程构造一样，这些云构造编排分布式应用程序，交互并管理复杂的数据流。然而，这些构造并不是孤立的云服务，不存在独立的“过滤即服务”或“事件发射器即服务”。不存在“构造即服务”，但它们是核心云原生(如网关、数据存储、消息代理和功能运行时)日益重要的特性。
这种演变降低了应用程序代码的复杂性，并且在许多情况下消除了对自定义函数的需求。从FaaS到NoFaaS的转变才刚刚开始，GitHub上有详细的教程和代码示例。
接下来，我将探讨在垂直多云服务中，出现的构造丰富的云服务。
2.从超大规模到超级专业化
在未来无服务器云时代，仅仅提供高度可扩展的云原生(如容器和函数的计算)、存储服务(如键值存储、事件存储、关系数据库)或网络原生(如负载平衡器)已经不够了。无服务器后的云服务必须包含丰富的开发人员构造，并卸载大量的应用程序管道。这超越了为广泛用户群提供通用云服务的超大规模，它涉及深度专业化和向要求更高的用户公开高级结构。
像AWS、Azure、GCP等超大规模服务提供商，拥有广泛的服务范围和广泛的用户基础，能够很好地识别新的用户需求和结构。然而，提供这些更细粒度的开发人员构造会增加复杂性。每个服务中的每个新结构都需要深度学习曲线，以便有效地利用其细节。因此，在未无服务器时代，我们将看到更多垂直多云服务的兴起，这些服务在一个领域表现出色，这种转变代表了云服务向高度专业化的转变。
以Confluent Cloud为例。虽然所有主流的超大规模服务(AWS、Azure、GCP等)都提供Kafka服务，但没有一个能与Confluent Cloud提供的开发人员体验和结构相匹配。凭借其Kafka代理、众多Kafka连接器、集成的模式注册表、Flink处理、数据治理、跟踪和消息浏览器，Confluent Cloud提供了最丰富的结构和最专业的Kafka服务，超过了超大规模服务器提供的服务。
这种趋势并不是孤立的，很多例子包括MongoDB Atlas versus
DocumentDB, GitLab versus CodeCommit, DataBricks versus EMR, RedisLabs versus ElasticCache等。除了老牌云公司之外，一波新的创业公司正在兴起，他们专注于单一的多云原生(如专门的计算、存储、网络、构建管道、监控等)，并通过开发人员构建来丰富它，以提供独特的价值主张。
以下是一些专注于单一开源技术的云服务，旨在提供丰富的构造体验，并吸引用户远离超大规模:
Vercel:以其卓越的前端开发经验，简化web应用程序部署而闻名。
Railway:以通过简单的部署和扩展管理来增强后端开发人员的体验而闻名。
Supabase: Firebase的开源替代品，提供类似的功能，但更灵活。
Fauna:一种无服务器数据库，以声明性关系查询和强一致事务中的功能业务逻辑而闻名。
Neon:提供最简单的无服务器PostgreSQL，具有数据库分支和最小管理开销等特性。
PlanetScale:以先进的MySQL云服务而闻名，专注于开发友好的功能。
PolyScale:专注于ai驱动的缓存，通过智能缓存优化数据性能。
Upstash:提供了一个完全托管的，低延迟的无服务器Kafka解决方案，适用于事件流。
Diagrid Catalyst:为消息传递、数据和工作流提供无服务器的Dapr api，充当云服务之间的连接组织。
Temporal:提供持久的执行，提供可靠地管理复杂工作流的平台。
下面的生态系统，是建立在超大规模企业提供的核心云原生之上的高度专业化的垂直多云服务。它们通过提供一套全面的可编程结构和增强的开发人员体验来竞争。
无服务器云服务，具有丰富的开发人员结构，高度专业化。一旦这种转变完成，没有丰富结构的裸机云服务，甚至是无服务器的云服务，将看起来像过时的内部部署软件。存储服务必须像DynamoDB那样对更改进行流处理，消息代理应该包含类似eventbridge的构造，用于事件驱动的路由、过滤和带有重试和dlq的端点调用，发布和订阅系统应该提供消息批处理、拆分、过滤、转换和充实功能。
最终，当超大规模企业随着服务的增加而横向扩展时，超专业化企业则垂直增长，提供单一的、一流的、丰富了结构的服务，形成垂直多云服务的生态系统。未来的云服务竞争将从基础设施原生转向核心云原生和以开发人员为中心的结构。
3.从基础设施到组合即代码(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 CDK等工具使开发人员能够使用自己选择的语言来实现功能，并使用相同的语言来组成与云环境的交互，这些工具最适合这个时代。
平台团队仍然可以使用声明性语言(如Terraform)来管理、保护、监视和启用云环境中的团队，但是以开发人员为中心的构造，结合以开发人员为中心的云自动化语言，将改变云构造，使开发人员在云中自助服务成为现实。
从DSL到通用语言的过渡，标志着IaC发展的一个重要里程碑。它承认将应用程序代码转换为云结构，这通常需要开发人员对应用程序需要的资源进行更深入的控制。这种转变代表了IaC工具的成熟，它现在需要迎合更广泛的基础设施编排需求，为更复杂、更高层次的抽象和工具铺平道路。
基础设施管理的旅程将看到从静态配置到更动态的、代码驱动的方法的转变。这种演变并没有止步于基础设施即代码，它正在超越到一个更微妙的领域，即“组合即代码”。这种范式进一步模糊了应用程序代码和基础设施之间的界限，从而产生了更加精简、高效和对开发人员友好的实践。
总结
在总结这些趋势及其强化效果时，我们注意到编程结构越来越多地集成到云服务中。每个计算服务都将集成CI/CD管道，数据库将从边缘提供HTTP访问并发出更改事件，消息代理将通过过滤、路由、等幂、转换、dlq等增强功能。
基础设施服务正在演变为无服务器api、从代码推断的基础设施(IfC)、框架定义的基础设施或由开发人员显式组成的基础设施(CaC)。这种演变导致了更小的功能，有时甚至是NoFaaS模式，为高度专业化、开发人员优先的垂直多云服务铺平了道路。这些服务将以可编程api的形式提供基础设施，使开发人员能够使用他们首选的编程语言无缝地合并他们的应用程序。
使用云服务的应用程序组合将越来越多地与应用程序编程相结合，将微服务从架构风格转变为组织风格。微服务将不再仅仅是单个部署单元或流程边界，而是功能、容器和云构造的组合，所有这些都将由开发人员用一种选择的语言实现和粘合在一起。未来的云将是高度专业化的，专注于开发人员优先的云。
