云联壹云：多云的定义之——工作流可移植性
为了帮助大家更加详细地了解哪些类型的多云功能值得追求，本文继续从工作流可移植性的视角研究多云。
多云工作流可移植性意味着拥有跨多个 IT 环境（无论是云环境还是本地环境）兼容的开发和运营工作流。作为这些可移植工作流的用户，企业大多希望能够使用一个工具链、流程和知识集来管理在 Google Cloud、AWS、Azure 和本地数据中心上运行的应用程序的操作。一言以蔽之——一个工作流程，可以在任何地方运行。
1、工作流可移植性
事实上，工作流可移植性已经存在于大家熟悉的部署前和部署后工具类别中。
当企业的 IT 堆栈开始分裂为多个异构环境时，有两种可能的解决方案来修复这种碎片。构建可移植的工作流程就是其中之一。另一种解决方案是迁移到一个单一的技术堆栈，这也意味着将会锁定在一个云供应商。
2、多云与单云
对于预生产工作流程，工作流可移植性是常态。GitHub 或其他版本控制和 CI/CD 系统是当今大多数软件开发的中心系统和通用工作流程——在这里几乎可以与任何东西集成。现在的大多数挑战是由于随后在部署和生产空间中出现的工作流程碎片化。
解决这种碎片化的一种方法是使用单云原生技术堆栈——这不能使工作流程具有可移植性。只要企业不使用其他云作为基础架构，也就不需要可移植性。另一种方法是使用跨多个云工作的工具。
1）单云即可满足需求
单云通常是小型公司或大型公司在云中刚刚开始项目的正确选择。在部署期间，平台原生服务产品应该彼此无缝协作。
如果企业有发展壮大的愿景，则应该尽早选择具有跨云兼容性的技术，因为多云必然会成为企业未来的选择。
2）当多云不可避免时
对于像全球 2000 强企业这样的大公司来说，多云已经成为最现实的选择。
3）遗留系统
构成我们世界经济支柱的大多数公司（银行、保险公司、能源、医疗保健和生物技术）在云出现之前就已经存在。可以想象一个 IT 组织就像一棵成熟的树，每一代技术都增加了一个新的“年轮”。每一代技术都还在，就像一棵树的内环一样。
这意味着他们拥有广泛的物理足迹，会有多个数据中心。许多公司并不会放弃这些投资，部分公司甚至进一步投资本地系统。
4）收购
收购是大型企业发展战略的关键。潜在的收购不会仅仅因为这两个实体没有使用同一个云而停止。对于收购的任何一方而言，工程师们都可能在一个不同的云平台上推出新的应用程序和基础设施。
5）折扣
大公司通常会有数百万美元的云预算。当云供应商争夺该预算时，通常会提供有吸引力的折扣或积分。这些也为在多个提供商之间分配工作负载提供了经济助力。
6）优化
有部分观点认为，将应用程序优化作为使用多云的理由是矫枉过正。如果优化是唯一的原因，这种观点是对的，但通常情况并非如此。
3、为什么单一云通常不适用于大公司
由于大公司的遗留系统、收购和技术多样化，将所有东西迁移到一个云通常是不可能的。最主要的原因是成本问题。
1）成本
将所有工作负载迁移到云所需的时间和精力成本很高，至于遗留系统和公司数据中心，虽然继续使用该基础设施会更便宜、更安全。但是维护这些遗留系统并将其集成到新系统中也具有成本和复杂性。
2）速度
虽然遗留系统和多云集成会降低应用程序和交付的速度，但也有一些提高速度的策略。然而，与将所有内容迁移到单个云所需的时间相比，集成速度可能大不相同。与完全迁移到新云相比，使用一致的、可移植的工作流集成系统可以为公司的新收购带来更快的价值实现时间。
3）可扩展性、弹性、可观察性、可管理性
有一些工作流可移植性解决方案可以在部署后的工作流中提供与企业在单栈设置中使用的云原生等价的可扩展性、弹性、可观察性和可管理性。
4、工作流可移植性与碎片化
企业不将所有内容迁移到一个云的原因有很多。企业可以为为每个云配置本地工具，帮助团队熟悉团队环境中独特的服务、工具和语法。
这就是所谓的碎片化方法，它涉及每个云部署的分支工作流。
1）碎片化的内在缺陷
碎片化的方法很快会变得复杂起来。这种方法必须为两到三个不同的云构建专家团队，然后为配置、基于服务的网络、凭证和密钥管理安全以及部署编排/调度任务提供不同的工作流程。这些复杂性的成本通常会超过专业化可能带来的小优势。
下图很好地说明了云工具的碎片化。从左侧的静态专用基础架构和右侧的动态云和本地基础架构开始，配置等领域是非常特定于云的。每个云平台都有自己的配置工具——例如 AWS 的 CloudFormation、Azure 资源管理器和 GCP 云部署管理器——它们只与各自的平台兼容。这意味着使用这些工具的多云公司不具备工作流可移植性。
但是，其中一些工具可以跨不同的云工作。例如HashiCorp Terraform属于私有云领域（许多其他工具也可以进入私有云领域），但它也以能够跨所有主要公共云进行配置而闻名。它与云无关，可以作为每个云平台的单一供应平台。这是支持多云工作流可移植性的工具的一个很好的例子——特别是对于预置工作流。
2）工作流可移植性的比较优势
如果企业使用单一、可移植的工作流程处理图表的每个类别，则单一工作流程解决方案只需要一个团队。与云原生工作流程相比，这也有助于更轻松地将本地基础设施和遗留系统囊括到混合云工作流程中。
再次以 Terraform 为例，开发人员可以使用一种通用的方法编写基础设施代码来定义资源（例如服务器、数据库和负载平衡器）的通用方法。然后，他们可以为云或本地设置配置和提供这些资源。
开源是有助于工作流可移植性的关键组成部分。在 Terraform 的案例中，它使第三方开发人员和公司能够创建插件，以便 Terraform 提供其独特的技术。
总体而言，将单一工作流方法与分散的多团队的方法进行比较时，成本、速度、可扩展性、可观察性和可管理性因素都有利于工作流可移植性。
工作流程应该是可移植的，但应用程序不必是可移植的。
多云的优势在于能够运行非常适合一种云的应用程序，而不必放弃适合另一种云的应用程序。
企业不需要数据可移植性和应用程序可移植性来获得工作流可移植性。
例如，如果企业想构建一个利用 AWS 中的数据库的应用程序和另一个利用 Google BigQuery 分析的应用程序，则使用 Terraform 的配置工作流可以从同一接口部署到这两个服务。在这里，我们将交付过程与运行时依赖项分开。企业不需要构建或管理所有的数据库、缓存等，但要意识到这些服务可以将应用程序固定到该环境。
5、启用工作流可移植性
工作流可移植性是多云可移植性中最容易实现的，也是最值得追求的多云可移植性实现。
启用工作流可移植性意味着选择与多云兼容的工具。即使作为一家较小的单云公司，如果不预先优化工作流可移植性，以后的工作会面临重重困难。来自云供应商的工具和服务可以将企业锁定在仅适用于其平台的工作流中。所以，立即进行工作流程的优化是十分必要的。
