利用数据引力：战略云架构决策
如果您从事基础设施工作，您就会感受到数据引力的作用。你规划并建造了一个田园诗般的、原始的、灵活的建筑，然后站在后面短暂地惊叹它。接下来，添加数据 - 然后数据就会增长！突然之间，工作负载聚集在它周围，服务部署在数据所在的地方，您的架构决策悄悄地由存储位置而不是业务优先级决定。
起初，这很微妙，这里有几毫秒的延迟，那里有一小笔出口费用。但快进后，您正在管理一个系统，其中移动工作负载不是战略选择，而是一项艰巨的工作。这才是真正的危险。并不是说你不能搬迁，而是它变得如此昂贵、具有破坏性且政治上困难，以至于你根本不会搬迁。
踢球者？万有引力并不关心你所处的环境是否仍然适合你。
什么是数据引力？
你知道这个类比——质量吸引质量。在科技领域，数据集就是质量。它们越大，它们的吸引力就越强。计算、应用程序、分析和人工智能模型向数据迁移，以减少延迟并简化访问。
这种拉力在短期内可能会有所帮助。将所有内容保持在一起可以减少数据移动、提高性能并最大限度地降低复杂性（至少在最初是这样）。但随着时间的推移，它就会成为一种限制。数据集和周边服务越大、越紧密，在不造成重大干扰的情况下重新定位它们就越困难。
另请参阅： 自动化数据治理：利用人工智能作为您的数字门卫
对云战略的现实影响
1.迁移挑战
PB 级迁移并不是“直接迁移”。它们是分阶段的操作，具有内置的切换窗口、增量同步策略、数据验证和风险管理。即使有最好的规划，您也可能面临：
- 出口费用让人感觉旨在阻止离开
- 提供商方面的带宽限制
- 切换期间运营停机或服务质量下降
- 合规性审核可阻止迁移中途
可行的提示： 不要等到搬家时才考虑便携性。从一开始就将其构建到您的架构中 - 通过开放标准、容器化工作负载和抽象来减少对专有服务的依赖。
2.绩效惩罚
您已经知道邻近很重要。但在多区域或多云设置中，数据和计算很容易随着时间的推移而发生偏离。
发生这种情况时，您需要支付两次费用：一次是延迟（影响用户体验、分析 SLA 和批处理时间），另一次是区域间或跨云传输成本。
可行的提示： 持续监控相对于数据位置的工作负载放置——而不仅仅是在部署时。使用自动保持计算和存储同步的工具或策略，除非有故意将它们分开。
3.默认情况下供应商锁定
锁定很少发生在一项重大决策中。它发生得很慢——这里是一个 API，那里是一个托管数据库——直到您的工作负载与单个提供商的服务深深地交织在一起。到那时，“迁移”就更接近于重写，而不是搬迁。
可行的提示： 跟踪架构中特定于提供者的依赖关系，就像跟踪技术债务一样。每季度进行一次审查，以决定哪些是您可以容忍的（因为它们提供独特的价值），以及哪些是您将在它们成为关键路径之前开始放松的。
另请参阅： 位置、位置、位置与数据也很重要
减轻数据引力
以下是如何防止拉力成为陷阱：
默认采用混合云和多云
不要将混合视为“以后”的策略。这是起点。将工作负载放置在性能最佳的地方，而不是主要提供商恰好有容量的地方。让多个提供商参与进来，以保持谈判筹码和部署灵活性。
将计算推向边缘
对于延迟敏感的工作负载（人工智能推理、工业遥测、视频流），在源处或源附近处理数据。仅将精炼或聚合的数据推送回核心基础设施，以减少移动和成本。
积极进行数据生命周期管理
并非所有数据都值得高级存储或立即访问。热/暖/冷分层应该是标准做法。积极归档。删除没有运营、业务、法律或合规价值的内容。您削减的每 TB 都会减少引力。
展望未来
新兴技术正在开始改变微积分。去中心化存储、人工智能驱动的编排以及与提供商无关的数据结构可以帮助移动性再次成为真正的选择。但它们不是灵丹妙药。如果没有有意的架构，这些工具只会在已经不可移动的质量周围增加另一层复杂性。
数据引力是不可避免的。错误在于将其视为纯粹的技术问题，而实际上它也是一个财务和战略问题。数据所在位置决定的不仅仅是延迟。它将定义您的成本结构、灵活性以及当机会或威胁出现时您可以多快地进行调整。
您开始使用的超大规模计算程序可能是某些工作负载的正确选择，但永远不要认为它永远是所有工作负载的正确选择。
现在开始的行动项目：
- 清点您的数据位置和工作负载 - 识别任何与某个提供商“紧密相连”的数据位置和工作负载。
- 在需要之前对迁移成本进行建模 - 了解您的逃逸速度（以美元、时间和风险为单位）。
- 构建可移植性 — 开放标准、容器化和最小化专有依赖性。
- 每季度审查一次放置情况 - 尽可能保持计算和存储的一致性。
- 维持多个提供商的关系 - 即使目前其中一个占据主导地位。
在云中，移动性并不是可有可无的。这是您应对成本攀升、性能下降和创新放缓的保险政策。按照您期望的移动方式构建您的架构，只有当它真正有意义时您才能自由地留下来。
云计算