多云的定义之——数据可移植性
世界正在走向多云。“多云”这个词的含义不能以单一的方式进行理解，而应该通过多方面的讨论来了解哪些类型的多云功能值得追求。
1、多云的四个定义
多云的不同用例并不总是相互排斥，这意味着企业可以将多个用例应用于其系统。本系列文章将涵盖四个多云定义：
在本文中，我们将讨论数据可移植性。
2、数据可移植性
多云数据可移植性意味着能够将数据从一个云提供商移动到另一个云提供商。其中的一个重要目的是了解停机、市场状况、价格变化或供应商关系变化。另一个目的是收集和移动合适的数据。
大规模数据可移植性的最大障碍是速度和带宽成本。带宽和延迟永远是计算中的大瓶颈。网络出口费用往往相对较高，因此云架构师倾向于将工作负载及其数据放在同一个云上，以最大限度地降低这些成本并减少延迟。
这个概念称为数据引力。将大量数据通过网络移动到另一个云需要花费大量金钱和时间。
3、Break-Glass与连续
用户可以通过两种方式构建数据可移植性：
Break-Glass的便携性：用户希望选择将数据作为逃生口或潜在的业务决策移动。
持续复制：用户希望其数据在多个云区域中持续可用。
许多企业在早期没有选择连续复制，因此对于这些企业，他们只能更改使用新数据系统的操作。
刚开始进行数据存储的企业有两种截然不同的选择，但业务成本却截然不同。企业需要根据其选择做出架构来支持它。
1、费用
连续式：成本是恒定的。企业会主动支付跨多个站点复制数据的成本。随着每条附加记录的出现，企业将为此支付增量成本。
Break-Glass：费用发生一次。企业可能在一个巨大的数据湖中的一个位置累积数据，然后当企业想要行使移动所有数据的选项时，其账单要大得多。
随着时间的推移数据迁移的粗略成本
如果企业没有在一致的、更小的基础上复制数据，这张图显示了一次性数据移动的成本(蓝色的“选项”线)如何随时间增长。在大多数情况下，数据呈指数增长，这将使期权线成为向上曲线，而连续线则成为上升线。根据工作负载的不同，任何数据可移植性的成本都会非常高。
初始成本：对于这两种类型，初始成本都很低，因为企业暂时还没有太多数据。
持续成本：对于Break-Glass的可移植性，持续的数据可移植性成本基本上为零，但对于持续移动的数据，通过将每个新数据记录复制到多个位置，可以逐渐降低数据可移植性的成本。
延迟成本：Break-Glass可移植性的延迟成本非常高，因为如果需要移动和复制所有数据，则费用会很高。通过连续复制，企业已经为每次创建新记录时的数据移动提前支付了费用。
一个很好的类比是股票期权与保险。Break-Glass的便携性就像一个股票期权——企业预先支付少量的费用来选择行使权利，但如果你选择行使它，就会付出昂贵代价。持续复制就像保险一样，企业每个月都需要支付账单。它可能不会一直对您有用，但是当确实需要它时，它不会使企业付出极为昂贵的成本。
2、速度、可扩展性、弹性、可观察性、可管理性
速度、可扩展性、弹性、可观察性和可管理性等其他因素通常有利于连续复制路径。在一次性可移植性场景中，从 GB 到低 TB 的少量数据集合是可管理的、有弹性的、可观察的并且快速地移动，但是随着事务数量和数据大小的增加，这些传输将会变得不那么实用。
小型数据系统和某些用例可能一开始就不需要连续复制——在这些情况下，连续复制的速度或可靠性是无关紧要的。持续复制真正重要的地方是在想要利用动态、云原生应用程序的系统中，其中大部分数据需要能够立即可用并在全球范围内分发到云供应商。
4、第三选择：即插即用的专有架构
还有一个方向，既不提供Break-Glass的便携性也不提供持续复制——云专有解决方案。如果企业选择专有的云数据库服务，例如 AWS DynamoDB、Azure CosmoDB、GCP Spanner 等，那么企业就会被该云供应商锁定。
如果企业开始使用其他技术，那么数据将很难移动。企业固然可以获得商业支持的解决方案的所有常见好处，并且该供应商的解决方案之间的可移植性可能会相当顺利，但是根据企业的需求和领域将自己锁定在一个云数据库服务中会是一个巨大的风险。
5、实现Break-Glass的便携性
对于Break-Glass的路线，需要对每个数据区域都有一个通用接口。这意味着企业需要使用广泛可用的开源数据库或专有解决方案。MySQL、PostgreSQL 和其他开源数据库的托管版本可以正常工作。在应用程序使用相同 API 的情况下，拥有一个兼容的接口更为重要。
例如，企业可以使用 AWS Aurora，但由于有一个通用 API，仍然会与MySQL有应用程序级别的兼容性。企业的数据系统还需要具有导入/导出功能，这样就可以轻松地将数据从一个位置移到另一个位置。
企业不需要实时执行此操作，因为这些是仅按需执行的批处理作业。但是，企业可能必须暂时关闭站点才能进行此数据迁移，具体取决于企业的数据存储以及它是否支持增量导出/导入。
6、启用连续复制
对于连续路由，企业需要支持实时复制的系统。有几个数据系统更关注这种云原生用例，包括 CockroachDB、Cassandra 等。这些系统提供跨区域数据的持续可用性。
许多传统的数据库系统通常也支持实时流和复制，但可能具有更复杂的故障模式，或者只支持主动/被动配置。连续复制也需要一个兼容的接口，就像Break-Glass的可移植性一样，除此之外，它还需要一个兼容的实现。
借助Break-Glass的可移植性，我们正在进行导出和导入，因此实现可能会有所不同。对于连续复制，应用程序必须支持在事务级别复制数据。这意味着企业不能混合实现（例如 AWS Aurora 和标准 MySQL）来设置连续复制。
7、在选择前清晰了解自身需求
利用多云数据可移植性的关键是尽早清楚地了解自身系统需求。当然，企业也面临着多种选择，可能企业会决定未来不再需要数据可移植性，使用云专有技术即可。也可能会设计一个具有在紧急情况下进行大型数据迁移选项的系统。或者，企业可以选择设计一个连续的数据复制系统，这样就不会产生大量的后续费用。
无论企业做出何种选择，每个决策都需要预先考虑系统设计和业务成本概况分析。还需要注意的是，这两种选择之间的成本可能会根据系统中使用的工作负载类型而有很大差异。企业的系统域和拥有的数据量也是选择路径的主要因素。
