几年前，我们遇到过一个有趣的问题。我们是一家完全远程的公司，所有软件都在云端。而且我们有一套使用 “基础设施即代码” 在容器上运行的 Spring Boot 应用程序。但我们需要业务灵活性。全球就业市场发展迅速，对新产品的需求始终存在。我们必须想办法保持我们在整个行业的领先地位。
我们是一家拥有大胆战略的科技公司
在2022 中，我们创建了一个 ADR（架构决策记录），其中写道："serverless-first 和 containers-as-needed。"并引发了近 40 工程团队的辩论。
先解释一下术语
无服务器优先不仅是功能即服务。它还是一组由云提供商提供的托管服务，这些服务包括
- 无需管理基础设施，从而降低运营开销
- 根据需要进行缩放，包括缩放至零，使其完全具有弹性
- 弹性定价（用多少付多少）
在 G-P，无服务器优先是指我们对 AWS Lambda、EventBridge、Step Functions、Fargate、SQS、SNS、API Gateway、S 3、DynamoDB 等的使用。
无服务器优先意味着当我们为计算、存储、消息传递或类似解决方案选择解决方案时，我们希望团队从无服务器选项开始。重要注意事项：如果无服务器服务无法满足需求，团队应改用更重的服务，即需要更多运营投资的服务。
“按需容器”明确指出，无服务器优先并不意味着只有无服务器。有些时候我们需要容器（例如，安装COTS 软件产品） ——这没问题。
优先考虑客户的技术策略
我们以灵活的步伐来满足客户和用户的需求。Lambda、S3 和 DynamoBD 等服务具有令人难以置信的弹性和速度。通过卸载无差别的繁重工作，我们可以将更多时间用于为用户构建功能，而不是处理通用的基础设施配置。
G-P 的一个关键原则是：" 你建造它，你运行它。"我们的团队拥有他们的软件。因此，我们不只是将软件丢给开发运营团队。
无服务器优先 "的优势
无服务器本质上是事件驱动的。
我们的架构完全由事件驱动。通过使用 EDA（事件驱动架构），我们可以扩展我们的组织和软件。无服务器迫使我们保持较小的爆炸半径，并通过事件以完全云原生的方式进行通信。
有利的制约因素
作为全球雇佣平台，我们非常重视合规性。 我们的云基础设施架构完善，我们采用多账户策略来分离工作负载并实现云合规性自动化。Serverless 无服务器架构通过控制云资源的配置方式，帮助我们实施高标准。
卸载工作
我们的云提供商负责管理我们的无服务器服务。由AWS集成、安全、调整、启用和维护的单一构建模块使我们能够腾出精力为客户提供更高的价值链。
架构良好的工作负载
我们创建的每个工作负载都要使用 AWS 架构完善的框架进行审查。我们专注于规模、安全性、可靠性和成本优化，以确保我们不仅满足而且超越我们的 SLA（服务水平协议）。随着我们与云环境的不断发展，这为我们的工程团队提供了支持。
关于我们的团队
我们的技术战略雄心勃勃，这使其具有挑战性。许多工程师都没有在无服务器架构（或分布式架构）中工作过。向无服务器架构的过渡并不容易，我们寻找的工程师要善于学习、善于思考、步调一致。
一些工程师对无服务器（是的，我们知道有服务器）一词并不确定，因为这种方法不仅仅是在函数中编写代码。我们的战略要求对经典的云原生原则采取整体方法。
结果
两年内我们取得了非凡的进步。现代化有很多好处（请参阅我们关于年度工资补充/云现代化的已知商业价值的文章）。 具体而言，我们观察到以下情况：
1 。速度：我们拆分系统的方式使得团队和产品能够独立创新和发展。这将对业务敏捷性产生巨大影响。
2 。合规性：我们使用年度工资补充架构完善的框架来审查所有工作负载。 因为我们使用了许多年度工资补充管理服务，我们可以依靠他们的卓越运营，并从高质量开始。
3 。系统思维：我们必须将许多流程标准化，以便我们能够对系统、可靠性和商业价值进行推理。我们不会把时间浪费在低价值的组件上。
4 。创新：无服务器意味着一切都是应用程序编程界面。 这种强制约束需要应用程序界面优先的方法。 当我们把自己视为一个平台时，我们可以通过 API 轻松连接系统，例如将G-P Gia™插入新的知识库，从而达到新的创新水平。
5 。所有权：年度工资补充拥有我们的基础设施，但我们拥有我们的业务领域。 采用无服务器优先和领域驱动设计迫使我们专注于业务问题。这使得能力的范围保持清晰。
无服务器优先并不总是更快，但却更有益。我们更愿意优化系统速度，而不是单个开发人员的速度。无服务器优先与使用函数的关系不大，更多的是考虑 "代码是一种负担"。系统就是资产"。我们需要编写的代码越少，就越能考虑和塑造我们正在构建的业务系统。
随着我们分享自己的故事，我们的工作速度将变得显而易见，这也是无服务器优先的直接结果。敬请期待。
