毫无疑问，组织因可能会被他们的云服务供应商锁定而倍感担忧。毕竟纵览 IT 历史，供应商倚仗高昂的转换成本实施限制性许可条款并提高价格的例子屡见不鲜。但是我认为云计算是不同的——事实上，它正在使软件、硬件和 IT 服务供应商越来越难以利用他们过去所拥有的优势。
这是一个敏感的话题，作为一名 AWS 的员工，我认为很多关于供应商锁定的讨论都偏离了主题。因此我希望能够通过阐述我在加入 AWS 之前担任 CIO 时的感触，来引发大家对这一话题的重新思考。
为什么上云？
首先，我非常清楚自己为什么要向云计算迁移——无疑是为了提升速度。我们研发新 IT 功能的时间过于漫长，转型不仅是要向云计算迁移，同时还将通过 DevOps、通过简化治理和监督流程、创建可重复使用且能快速重组以开发新功能的微服务来缩短前置时间。作为美国公民及移民服务局（USCIS）的 CIO，我知道移民政策随时可能发生重大变化，而当这些变化发生时，漫长的研发时间将是不被接受的。我们有理由相信云计算将显着降低我们的成本（最终削减了 75% 的基础架构成本），但速度是我首先考虑的要素。
我面临的难题
员工技能组合是当时面临的巨大障碍之一。他们中的大多数人从来没有在云环境中工作过，而且在 DevOps 和微服务方面也是新手。
第二个障碍则是我们的采购流程——在完成所有法务工作和供应商选择流程的情况下，采购一项服务需要耗费我们 6 个月到 3 年的时间。
另外，还有一个文化上的障碍 （实际上还有很多），那就是我们的“例外主义文化” （culture of exceptionalism）——我们政府的 IT 需求十分特殊，因而我们不得不采取与行业公认首选实践不同的做法。
为什么放弃多云？
当我考虑为基础架构和平台使用多个云供应商时，我很快就放弃了这个想法。我担心这会减缓我们的转型速度，而速度对我来说是首要的因素。构建部署到多云的系统将会耗费我们的时间，即使是使用容器和与云无关的工具。由于我一直在督促我的团队学习如何用基础架构作为代码，我不希望在不同云中管理基础架构的复杂性会降低他们的速度。
使用多云方法还使我无法使用特定于某个云供应商的服务，而这些服务原本可能会加快我们的速度。
另外，技能也是一个问题，我不希望员工花时间去学习不同的云平台和跨云兼容性。
最后，为了克服我们的“特殊需求”文化，我希望我的员工从其他组织所使用的简单且直接的方法开始。
综合所有这些原因，我知道投注于多个云供应商将在我实现目标的过程中产生巨大成本。接下来，我要考虑的是选择单一云供应商的风险，以及找到减轻这些风险的方法。
从 “锁定” 到转换成本
我的思路是这样的：“锁定”这个词具有误导性，我们真正讨论的应该是转换成本。转换成本一直存在于整个 IT 历史中。一旦您开始采用某个平台或供应商，那么当您之后决定更改时就会产生转换成本。
如果选择 Java，然后迁移到 Node.js，那么您将面临成本问题；如果选择 Maven，然后迁移到 Gradle，同样也将面临成本问题；如果您决定使用大型机，然后迁移至水平可扩展的商用硬件，那么您也需要面临一定的成本。在这些情况下，您实际上并没有被“锁定”——只是产生了转换成本。它有可能是大成本，也可能是小成本，这都取决于具体情况。
当我们在做决定的时候，总是把这些成本考虑进去，至少是隐含在内的。比如，我们通常不会在两个不同的云平台上构建同样的应用来避免被某个供应商锁定，因为我们相信为同一个应用采用两个可替代的数据库将导致成本超过风险管理带来的好处。
因此我问自己：
1. 如果我需要退出 AWS，转换成本会是多少？
2. 发生这种情况的可能性有多大？
3. 如何在符合成本效益的情况下降低风险？
使用云服务，您可以按需付费 （只有少数例外，比如预留实例），所以当您决定更换供应商时不会产生遗留费用。我认为在我们的情况下，做一些使应用多云化的前期工作是没有意义的；正如我之前所说，这将产生非常巨大的成本，并且我认为自己离开 AWS 的可能性并不高。相反，如果因为某种原因我们决定离开 AWS，我会接受随之产生的转换成本，并努力减轻它。
降低高额转换成本风险
我们考虑降低高额转换成本风险的第一个领域是架构。我们曾使用 Docker 容器以期它可以部署在任何地方，也曾构建微服务，其中一部分原因是希望由此能将一些服务放在一个平台上，并将其他服务放在另外的平台上。我们还知道，可以将因变化而产生的“波及范围”减小到单个微服务，并且在我们需要大规模变化时对每个变更进行单独测试。我们积极地将服务进行松散耦合，特别是在使用 AWS 特有的服务时——事实上，我们为每个 AWS 服务构建了一个外观模式以便我们尽可能透明地对其进行更换。
有一件事虽然我们还没有做，但您或许可以进行考虑——制定一个撤销计划或“可逆性”计划。根据您所感知到的风险级别，您可以或多或少地制定计划细节。在这个计划中，您可以详细地列出离开 AWS 而产生的主要转换成本是什么，以及您将采取哪些步骤来管理这些成本。您还可以为如何进行这项工作制定一个高级项目计划，并估算成本。有了这样的计划，您就可以在使用一个供应商时对所面临的风险做出明智决策。
正如我所提到的，云计算、DevOps 和其他现代化开发正在瓦解传统供应商对您的控制。如果您正在做我所描述的事情——松散耦合、创建外观、使用容器等等，那么您不仅能更轻松地更换云供应商，还能轻松更换任何类型平台的供应商。当您考量开源的影响、由开发自定义解决方案而产生的成本降低，以及更重要的一点——基于“按需付费”可被替代的 AWS 产品 （例如 Amazon Relational Database Service、Amazon DynamoDB 和 Amazon Aurora），您所面临的风险 （也就是说，您的潜在转换成本以及您想要进行转换的可能性）会迅速下降。而这不仅仅关乎于风险，由于供应商不得不围绕您的业务展开竞争，您也将从其带来的创新中受益。
别忘了，我还是 AWS 企业战略专家
抛开作为 CIO 的决策过程，接下来我们从 AWS 企业战略专家的角度谈一谈。
当您评估使用 AWS 的风险时，请考虑到我们正有意地基于 Xen、SQL 和 Linux 等开放标准来构建我们的云平台，同时我们加入到了越来越多的开源项目中。目前，我们已经降价 67 次，主要是因为不存在竞争压力。
我们帮助您迁移到 AWS 的工具也可以反过来帮助您从 AWS 中迁移出来。如果您选择离开 AWS，我们已经尽力使该过程尽可能简单。坦率地说，从商业角度来看这是有道理的，因为降低与我们合作的风险也符合我们的利益。
我们的创新步伐应该会让您感到放心，因为我们打算继续赢得您的业务，与此同时还清楚地认识到，只要您愿意，您便可以转移到另一个云供应商。我们 90% 到 95% 的路线图都是由客户期待来驱动的。AWS 开创了云计算，也将继续推动云计算的发展。
我的一些建议
最后，作为一名企业战略专家，我想提出以下建议。
首先，如果您认为使用单个供应商的风险大于使用多个供应商的成本，那么一定要与多个供应商合作。在这种情况下，我建议您通过将一些工作负载放在一个云中，将其他工作负载放在另外的云中来降低决策成本，而不是试图将单个工作负载部署到多个云中。
如果您同意我的理论并决定使用单个供应商，我建议您通过良好的架构、标准部署实践和些许预先计划来降低潜在的转换成本。
当您较之一个平台选择了另一个平台时，就会产生转换成本，而这种情况一直都有。其实并没有所谓的“锁定”，除非您签署了同意合同。但转换成本可能高昂，也可能低廉。通过良好的设计和一些先进的思想，您可以降低转换成本 （通过传统软件或云供应商）。比起通过承担速度减缓和更高的成本 （转向多云）来预先支付这些转换成本，您也许更希望降低潜在的转换成本，并看看您的供应商是否能继续为您提供良好的服务。
CIO介绍
Mark Schwartz
Mark Schwartz 是 AWS 企业战略专家，前美国公民及移民服务局 CIO，玩世不恭的创意制造者，深谙世情的散文作家，同时也是大大小小的公共、私人和非营利性组织的 IT 领导者。
（原标题：CIO 必看！一个 AWS 企业战略专家的“肺腑之言”）
