在云用户中，对“混合云”和“多云”这两个术语评价的两极分化程度较为严重。从之前的情况来看，混合云的使用表明工作负载正在从私有数据中心转移到公共云。现在，它意味着本地应用程序与云中的服务之间的集成。
多云的起源情况类似——最初是工作负载根据价格和性能等情况从一个云迁移到另一个云。然而，这些用例却难以被发现。现在，多云只是意味着用户正在使用多个云平台。
在大多数企业中，公司都在使用来自多个云的服务。只要有一种方法可以集成服务并在没有过多工具的情况下管理它们，工作负载在哪里运行就变得几乎无关紧要。
高质量云服务的普及使用户能够使用来自最佳提供商的服务来满足其特定需求。它可能是来自亚马逊的对象存储、来自谷歌的计算、来自 Salesforce 的 CRM 以及来自 Splunk 和 Datadog 的管理服务。松散耦合的服务创建的应用程序是云服务的融合，通过网络组合，成为云原生应用程序。
该设计模式与90 年代后期倡导的面向服务的架构 (SOA) 非常相似。尽管它们变成事件驱动，而不仅仅是 API 驱动的。
当互联网的使用在 20世纪90 年代首次出现快速增长时，大多数用户的带宽极低，人们在电子邮件和网络之外使用的服务数量也很少。当时间来到 2022 年，现在我们拥有速度极快的互联网、无数的云服务、智能设备，以及对最新信息的不断追求。
API 与事件驱动架构
云中有两种流行的交互模型。第一个是 REST API（或 RESTful API）。REST 部分代表具象状态转换，API 代表应用程序编程接口。RESTful API 是系统相互交互的一种方式，就像对话一样。在 RESTful 架构中，有请求和响应并反复进行，一直持续到确定信息为止，这需要同步通信。
相比之下，事件驱动的架构就像从水龙中喝水——其中事件是异步流式传输的，用户基于发布/订阅模型（称为 Pub/Sub）消费主题。
事件驱动架构可以采用多种形式，但最常见的两种是 Webhook 和流式传输。在事件驱动的架构中，数据是实时提供的，而不是作为对查询的响应（与 API 方法一样）。
例如，在 Webhook 的情况下，我们要求事件的生产者告诉我们工作何时完成，然后我们会在事件发生时收到通知，这就是异步通信。
在流式传输的情况下，我们会随着状态的变化接收事件。这些事件可能是对数据库的更改、将文件上传到存储 blob 或完成无服务器功能。
事件驱动架构的兴起
为什么事件驱动很重要？因为这些事件用于触发和通信解耦的服务。事件只是系统中状态的变化，它可以携带状态或标识符。这些事件可用于触发工作流。云之间的这些工作流打破了孤岛，提供数据同步或复杂任务的完成。
云中的事件驱动架构
现在，云的结构已经变成了 Kubernetes。它无处不在，并允许在容器中运行的应用程序的可移植性。用户通常在容器或无服务器功能中部署全时运行的微服务。这些函数能够使用事件相互通信。有许多事件流技术，一些可以跨越多个云，而另一些则特定于每个云。
Amazon Kinesis提供了一种在 AWS 中管理事件流的方法。Eventarc是 Google Cloud 的解决方案，用于将事件从 Google 服务发送到可以从 Pub/Sub 主题接收消息的目标或服务。Microsoft Azure 的事件网格在 Azure 云中管理从源到目的地的事件路由。这些解决方案是单一云事件流解决方案的示例。
如果想做多云应该怎么办？Apache Kafka是一个开源的分布式事件流平台。如今，它广泛用于流式传输本地事件或来自云基础设施。
从多云/混合云到集成
云用户需要在所有云中都一致的工具，尽管管理无服务器功能的部署相当容易，但是提供云服务之间通信的一致方式并不容易。
通过与云服务的用户持续交流，我们得出的结论是云架构师正在努力解决的问题是，不仅要在云服务之间进行通信，还要知道如何路由事件流——有时甚至可以将这些事件从一种格式转换给另一个。
例如有大型银行希望过滤从 Azure 到 Splunk 的事件，以降低存储成本。这些希望通过 Apache Kafka 服务的事件流集成 Salesforce 及其现有 ERP 系统的人表示，像甲骨文这样的云计算工具比三大云提供商少。他们需要将云指标流式传输到 Datadog。所有这些问题都是集成问题，源和目标位于云端和本地。
通过一系列的整合工作，现在，我们认为HashiCorp的Terraform基础设施即代码之类的工具（用于部署云基础设施）需要为集成而存在（我们称之为集成即代码），这就是为什么服务存在于哪里并不重要，因为它只需要易于集成。