多云不仅仅是一个流行词语，它为IT架构带来了显著的好处。以下是我的愿望清单。
译自 Multicloud Architecture: What I Want to See。作者Robert Sonders已经在戴尔技术公司工作了12多年。在此期间,他一直专注于微软工作负载,无论是本地还是现在的多云,特别是SQL Server生态系统和软件定义存储。在这段旅程中,罗伯特以技术顾问架构师、预售解决方案主管和戴尔的全球微软工作负载专家的身份带领项目团队。
“多云”这个词到底是什么意思呢？它是一个目的地吗？一个操作吗？要怎么才能“做多云”呢？
“多云”一直是一个热门词汇，许多人谈论但很少成功实施。如果你问 10 个人关于多云，你会得到 10 个不同的答案。你是想在多个云中分开工作吗？还是希望相同的工作和基础数据可以跨越多个云存在甚至扩展到多个云？我希望是后者，可以根据需要将合适的数据放在合适的时间和位置。
如果我要执行多云任务，首先我会准备一些常用的工具。我会寻找与当前行业内任何公有云或本地平台无关的流程或产品。多云的首要任务是：不要创建数据孤岛。
我希望用多云做什么呢？我想用 AI 做什么？AI 需要跟随数据，需要大量计算能力来正确训练 AI 模型。数据也需要让 AI 模型训练器可以方便访问。
我希望一个没有刚性架构的多云基础解决方案，这样随着我向上移动技术栈就不会暴露问题。我认为这个基础应该是存储层。存储可以是块或文件，结构化或非结构化，使用任何可用协议；我只需要在任何我想要的地方部署一致的存储目标。
它也不应该受到移动整个技术栈的潜在或实际限制。作为多云架构师，我不想拖带应用程序自带的所有数据仓库、层级和前提条件。我希望存储层是通用的，可以跨内部部署和任何公有云部署。一旦我的数据(由公共存储层驱动)存储在目标位置，就可以被目标位置现有的特定目标技术栈编排快速使用。
由于我的 DevOps 团队已经有了无缝流程，他们会优化访问并频繁刷新数据，因为使用过时的数据不是一个好主意。在我的云之间查看，应该可以直接比较云 A 上的数据与云 B 上的差异。
然后，为了简化我的基础设施即代码(IaC)存储访问实现，我的工具必须有规范的、自记录的自动化，并对我选择的工作流程存储库进行检查和平衡，在整个所需环境中扩展。
我喜欢把这个类比成一条铺设在任何场景中的“存储高速公路”，任何人都可以根据需要在这个存储层上运行。
当我向我的 DevOps 团队传达我的多云基础时，他们会要求此存储具有流动性并支持无阻力的数据流动。我的多云世界将再次以基础的 IaC 和脚本执行为基础，采用以 API 为首要的数据流动性。有了这个，我就可以在正确的时间和地点使用数据。
回到“AI 遵循数据”的概念，我可以最大程度地减少并期望消除任何“Rube Goldberg 式的数据转换”设计，根据需要移动基础存储和卷。有了这个选择，我就可以灵活地只移动我从源到目标所需的数据。这也从多云经济角度来看符合“良好行为”的要求。
存储效率是多云解决方案的关键。我知道公有云服务提供商实际上并不提供存储效率功能，至少不是我可以使用的产品。我想拥有高效存储的功能，包括精简配置和快照。然后，我可以将任何消费该数据的应用程序指向目标位置。我只想在多云目标之间移动我的存储和相关数据。
我对多云的愿望单中重要的部分包括我的朋友 Kubernetes。我的 DevOps 团队每小时都在使用 Kubernetes 构建应用程序，使用临时存储挂钩和作为一个或多个命名空间的一部分的应用程序流动性来构建数据服务。我需要我的多云存储部署来简化 Kubernetes 持久性管理。这个通用存储层将给 CNCF Kubernetes 的大量组件带来某种凝聚力。
可以说，关于多云最重要的讨论是安全性。这包括日志记录和审计、身份和访问管理(IAM)以及通过安全连接网关的入站和出站流量模式。这些都是成功实现多云的基本原则，值得单独撰文探讨。
多云存储基础带来了许多积极结果。即使是影子 IT 操作也可以轻松消失，因为工程师会意识到哪些流程在技术栈的任何部分上执行。可以称之为 IT 生态系统的“单面板玻璃”视图。