为什么所有主要的云平台都一样

AWS、GCP、Azure和Oracle最初并非如此相似，但它们随着时间的推移而发展并趋于融合。为什么会这样，这对您意味着什么？

译自 Why All the Major Cloud Platforms Are the Same，作者 Rak Siva。

云平台的相似程度远超许多人的认知，它们与自然界的进化过程也比大多数人所知的更为相似。

自然界中，趋同进化描述了不相关的物种如何独立发展出相似的特征来解决共同的问题。最著名的例子之一是鸟类、蝙蝠和昆虫翅膀的进化。尽管它们的起源大相径庭（鸟类是鸟纲动物，蝙蝠是哺乳动物，昆虫是节肢动物），但它们都进化出了翅膀来实现飞行。

这种现象已在众多物种和环境中被观察到。另一个有趣的例子是蝙蝠和海豚回声定位的进化。这两种哺乳动物都发展出了发出声波并解释返回的回声以在低光照条件下导航和狩猎的能力。

好的，但这与云技术有什么关系呢？关键在于，即使是截然不同的实体，在面临相同的挑战或优势时，也会发展出共同的特征。云平台，例如AWS、Google云平台 (GCP)、Microsoft Azure 和 Oracle，非常类似于这些物种。虽然它们最初的起源和理念各不相同，但最终它们都在努力解决类似的问题，因此，它们独立发展出了解决这些共同挑战的通用功能。

虽然许多相似之处可能源于竞争和直接借鉴，但许多其他相似之处则是不经意间由于趋同而产生的。如今，这种趋同和竞争已经持续了足够长的时间，以至于所有主要的云提供商的相似之处多于差异之处。理解这种趋同有助于我们为应用程序开发的未来做出明智的设计决策。

让我们简要回顾一下历史，当时 AWS 在 2006 年推出简单存储服务 (S3) 时处于开拓地位。S3 解决了一个关键挑战：为企业提供可扩展、安全且经济高效的存储，而无需它们管理基础设施。不久之后，Amazon Elastic Compute Cloud (EC2) 彻底改变了对计算能力的访问方式，使组织能够按需部署和扩展应用程序，而无需对物理服务器进行资本投资。

这些创新为 AWS 确立其在云计算领域的领导地位铺平了道路，有效地使各种规模的企业都能访问企业级技术。这种基础设施的民主化使公司能够专注于创新而不是运营开销，为云市场的快速发展定下了基调。

几年后，AWS 在 2009 年推出了 Amazon Relational Database Service (RDS)，解决了对数据库的需求。RDS 提供了托管关系数据库，简化了数据库系统（如 MySQL、PostgreSQL 和 SQL Server）的设置、操作和扩展。这允许开发人员卸载诸如备份、补丁管理和扩展等繁琐的任务，同时仍然可以控制其数据结构和查询。

对于非关系型工作负载，AWS 在 2012 年推出了 Amazon DynamoDB，这是一个完全托管的 NoSQL 数据库，专为低延迟、高规模的应用程序而设计。DynamoDB 针对传统关系数据库效率较低的使用案例，例如实时分析、游戏和物联网。

与 S3 和 EC2 结合使用，这些数据库服务使 AWS 能够为应用程序开发提供强大的基础。S3 处理对象存储，EC2 管理计算需求，RDS/DynamoDB 涵盖数据持久性。这套全面的套件允许企业构建和运行数据驱动型应用程序，而无需管理硬件或数据库基础设施的复杂性。它也为进一步抽象和自动化数据库操作的更高级服务奠定了基础。

随着 AWS 托管服务的成功，Google 和 Azure 等竞争对手认识到市场中类似的挑战，并开发了自己的解决方案来解决这些挑战：

Google Cloud

Google 利用其在搜索、数据处理和分布式系统方面的专业知识，推出了创新的云产品：

• Google App Engine: 早在2008年，Google就凭借App Engine开创了平台即服务（PaaS），允许开发者无需担心底层基础设施即可部署应用程序。这种抽象帮助小型团队专注于代码，而Google则负责扩展和运营。
• Firebase: 为开发者提供了实时数据库解决方案、无服务器后端以及用于移动和Web应用程序开发的集成工具。

然而，云应用程序的常见需求以及AWS既有功能意味着还需要其他服务，例如Google Cloud Storage（2010），以提供类似于AWS S3的可扩展、持久性对象存储。

Microsoft Azure

Azure利用其既定的企业客户群和与现有Microsoft工具的深度集成，但同样的常见需求也导致了类似的产品：

• Azure Blob Storage: Microsoft的S3对应产品Blob Storage于2008年推出，为非结构化数据提供可扩展的对象存储。
• SQL Azure: 认识到对数据库解决方案的需求，Azure在2010年推出了SQL Azure（现为Azure SQL Database），这是一种基于Microsoft SQL Server技术的托管关系数据库服务。它面向已经熟悉SQL Server的企业，降低了云采用的门槛。
• Azure Cosmos DB: Cosmos DB于2017年推出，满足了对全球分布式、多模型数据库日益增长的需求，类似于AWS DynamoDB，但支持更广泛的数据库范例。

云提供商在一个共享的开发者期望和业务需求生态系统中运营。在早期阶段，云平台的共同点较少，导致人们认为存在重大的能力差距。AWS在Lambda、DynamoDB、EC2和S3等服务中的早期主导地位强化了其他提供商不完整的观念。然而，随着这些技术的演变，平台之间的差异缩小了。如今，AWS、GCP、Azure和Oracle提供的托管服务与其说是不同，不如说是更相似。

下面，我们研究以下需求是如何塑造无服务器计算的：

1. 简化的基础设施管理— 团队希望专注于构建应用程序，而不是配置、扩展和维护服务器。
2. 事件驱动架构— 微服务/宏服务的兴起以及事件驱动的流程，产生了对可以响应特定触发器执行功能的需求。
3. 成本效率— 组织寻求通过仅为使用期间消耗的资源付费来最大限度地降低成本（为服务处理请求所花费的时间付费）。

回应：

• AWS Lambda: 这是第一个广为人知的解决方案，它满足了这种需求，引入了短暂的、事件驱动的代码执行，无需传统的服务器。它专注于可扩展性和与AWS不断发展的生态系统的无缝集成。
• Azure Functions: 演变为优先考虑与企业工具和工作流程的深度集成，响应Microsoft客户对有状态工作流程和企业级监控的需求。
• GCP Cloud Functions: 专为使用Google数据和AI服务的组织量身定制，满足了对易于与BigQuery和Vertex AI等工具集成的功能的需求。

每个提供商都带来了独特的优势和战略重点，最初创造了差异化，但最终趋于一致的功能基线。我们现在有了像Oracle这样的后来者，尽管它进入较晚，并且额外受益于观察其他云提供商的成功经验，但Oracle Cloud提供了非常类似的功能。

这种标准化反映了全球开发者和企业的共同期望，并已形成一套全面的服务，支撑着云原生应用程序。

以下是这种标准化如何提供关键的基础功能：

1. 存储: 所有主要的云提供商都提供可扩展、安全且高可用的存储解决方案，以满足对象存储或块存储等高性能需求。
2. 计算: 从虚拟机到无服务器计算和容器编排，计算服务已经发展到满足不同的需求，包括按使用付费模式（例如 AWS Lambda 和 GCP Cloud Run）和用于传统工作负载的强大虚拟机实例。
3. 数据库: 提供商现在提供托管关系数据库、NoSQL 解决方案和分布式数据库，消除了开发人员的操作开销，同时确保可扩展性和高可用性。
4. WebSockets: 实时通信已成为现代应用程序的关键功能。提供商现在提供托管 WebSocket 解决方案，实现无缝的双向通信。
5. 高性能计算 (批处理): 对 HPC 工作负载的需求推动了针对 AI、机器学习 (ML) 和科学研究而定制的批处理解决方案的开发。
6. 队列: 托管消息队列确保应用程序组件之间可靠的解耦通信，降低了分布式系统的复杂性。
7. 主题/订阅: 发布/订阅模型已成为事件驱动架构不可或缺的一部分，能够将消息可扩展且高效地广播到多个使用者。
8. 计划任务: 提供商已标准化任务调度，以便在指定的时间或间隔触发作业，从而实现重复性任务的自动化。

云生态系统已经发展到提供惊人相似的服务，跨提供商，但其中的旅程仍然复杂且支离破碎。认识到云服务的趋同进化使企业能够根据当前的现实情况而非历史印象做出决策。

随着云服务在功能和标准方面趋于一致，组织能够创建可跨平台无缝迁移的可移植解决方案，从而降低与供应商锁定相关的风险和成本。这种融合还使开发人员能够利用更高层次的抽象，使他们能够更多地关注通过业务逻辑交付价值，而不是陷入底层基础设施的复杂性。

我们最初构建 Nitric 的目的是利用这种融合，提供一个开发人员可以用来部署真正可移植的云应用程序的框架。但是，到目前为止，大多数用户发现即使他们只针对单个云，它也能带来价值。通过抽象化表面的差异，Nitric 通过直观的、与提供商无关的 API 解锁通用功能。这种方法简化了开发，并重新定义了团队与云资源交互的方式。例如，假设我们要按节奏执行流程（计划任务）。

例如，在使用计划任务时，开发人员必须配置应用程序以适当地处理计划事件。这包括：

1. 集成特定于云的 SDK:

• AWS: 使用 AWS SDK 解析 EventBridge 有效负载。
• GCP: 处理由 Cloud Scheduler 触发的发布/订阅消息。
• Azure: 利用 Dapr 绑定进行 cron 作业。

2. 依赖项管理:

• 确保云 SDK是最新的，并且与运行时兼容。
• 添加用于 JSON 解析、日志记录和计划事件监控的其他库。

3. 代码耦合:

• 应用程序逻辑通常与云提供商的 API 紧密耦合，即使是在同一云提供商的不同服务之间，也限制了可移植性。
• 处理计划事件的代码在不部署到实时云环境的情况下难以测试。

4. 错误处理:

• 为计划任务失败时开发强大的重试逻辑。
• 设置适当的日志记录和警报以监控运行时问题。

为计划任务配置基础设施通常需要处理多层特定于云的配置。

特定于云的资源:

AWS EventBridge:

• 创建一个规则，指定计划（例如，cron 表达式）和目标（Lambda 函数、SQS 队列）。
• 配置身份和访问管理 (IAM) 角色和策略，以允许 EventBridge 调用目标资源。

GCP Cloud Scheduler:

• 使用计划和目标类型（HTTP 端点、发布/订阅主题）定义作业。
• 确保目标具有正确的 IAM 权限以接受调度程序调用。

Azure Logic Apps:

• 使用计时器触发器构建 Logic App 工作流，并配置连接器到下游服务。
• 管理 API 连接，包括身份验证和权限。

环境配置:

• 为调度程序与应用程序通信设置环境变量或密钥。
• 确保基础设施更改能够在暂存、测试和生产环境中无缝传播。

错误可见性和恢复

• 实施手动检查或自定义脚本以识别配置错误的计划或权限。
• 如果云提供商的原生调度服务出现停机，则开发回退机制。

资源抽象使我们能够避免直接与特定于云的 API 交互。以下是在 Nitric 中执行此操作的方法：

from nitric.resources import schedule
from nitric.resources import Nitric
 
# Run every 5 minutes
@schedule("process-transactions").every("5 minutes")
async def process_transactions(ctx):
  print("processing transaction")
 
 
# Run at 22:00 Monday through Friday.
@schedule("send-reminder").cron("0 22 * * 1-5")
async def send_reminder(ctx):
  print("sending reminder")
 
Nitric.run()

开发人员使用 Nitric 的高级 SDK 声明性地定义计划：

• 自动映射：Nitric 在后台将计划映射到相应的云服务，自动管理 cron 语法或权限等差异。
• 无缝可移植性：由于计划配置与云无关，因此在提供商（AWS、GCP、Azure）之间切换无需更改应用程序代码。
• 项目间的一致性：所有项目都以相同的方式运行，以相同的方式实现计划任务，这意味着需要在不同的实现中修复更少的安全漏洞。

改变开发人员和业务成果

通过专注于可移植性、抽象和自动化，Nitric 创建了一种开发范例，重点关注最重要的事情，即交付有影响力的应用程序。结果不仅是更快的交付周期，而且还有信心进行创新，而不会受到平台外观差异或限制的约束。