共计 2943 个字符，预计需要花费 8 分钟才能阅读完成。
为了帮忙大家更加具体地理解哪些类型的多云性能值得谋求，本文持续从工作流可移植性的视角钻研多云。
多云工作流可移植性意味着领有跨多个 IT 环境（无论是云环境还是本地环境）兼容的开发和经营工作流。作为这些可移植工作流的用户，企业大多心愿可能应用一个工具链、流程和常识集来治理在 Google Cloud、AWS、Azure 和本地数据中心上运行的应用程序的操作。一言以蔽之——一个工作流程，能够在任何中央运行。
1、工作流可移植性
事实上，工作流可移植性曾经存在于大家相熟的部署前和部署后工具类别中。
- 版本控制：GitHub、GitLab
- CI：Jenkins，CircleCI
- 包治理：JFrog Artifactory、Sonatype Nexus
- 利用部署（编排、调度）：Kubernetes、HashiCorp Nomad
- 可察看性和警报：Datadog、PagerDuty
- 平安和秘密治理：HashiCorp Vault、AWS Secrets Manager
- 基础设施供给：HashiCorp Terraform、Red Hat Ansible
当企业的 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、启用工作流可移植性
工作流可移植性是多云可移植性中最容易实现的，也是最值得谋求的多云可移植性实现。
启用工作流可移植性意味着抉择与多云兼容的工具。即便作为一家较小的单云公司，如果不事后优化工作流可移植性，当前的工作会面临重重困难。来自云供应商的工具和服务能够将企业锁定在仅实用于其平台的工作流中。所以，立刻进行工作流程的优化是十分必要的。