一切均被“锁定”：谈谈更换的成本

随着云计算技术日新月异的飞速发展（不同的服务和供应商，你方唱罢我登场），技术锁定依然是很多用户接受云计算过程中的主要障碍。技术锁定意味着什么？如何确保在照顾到“可移植性”的同时通过云计算方面的投入获得最大化收益？

本篇 InfoQ 文章是“云和技术锁定”系列文章的一部分。你可以在订阅后通过 RSS 获得内容更新通知。

主要结论

• “财务锁定”是最难解决的问题之一，但也别忘了考虑其他方面的问题，例如对生态系统的依赖。
• 任何产品都不能完全避免“锁定”，最理想的情况下，我们只能通过某种产品减少架构中某一层面可能遇到的锁定。
• 出于很多原因我们可能愿意拥抱锁定，例如这样的技术能为我们提供极大的价值，或者能让我们继续专注于更有价值的活动。
• 如果所用的某种技术导致无法实现目标，此时必须为技术更换付出相应的成本。
• 微服务、开源，以及提供了 API 的技术可以帮助我们改善可移植性。

用 Java 写代码，购买 SAP，部署 OpenStack，使用 Amazon Web Services：每种行为都会产生一种类型的技术“锁定”。按照维基百科的定义，“锁定”是指“客户被迫只能持续依赖某一供应商的产品和服务”，这个话题总是能在技术社区引发热烈的讨论。很多不看好供应商锁定的学者希望能通过某种技术“彻底解决”此类问题。在意识到云服务也无法针对技术锁定风险获得“免疫力”之后， CIO 们开始不抱任何希望。为了尝试消除供应商技术锁定，沃尔玛曾打造了自己专有的云管理平台，然而无论如何努力，都会不可避免地遇到某种形式的技术锁定。此时更重要的是充分理解技术锁定的不同层面，并考虑评估和降低更换成本的方法。

在一系列才华横溢的文章中，Battery Venture 公司的 Adrian Cockcroft 在探讨有关技术锁定的话题时提出了一个很贴切的比喻。

和婚姻类似，企业会面临 IT 技术锁定（也就是说在某些关键功能方面只能使用某一供应商的产品，例如外包的云计算服务），如果能妥善应对实现互惠互利的效果，这其实是一种好事。但如果遇到问题需要“离婚”，结果就会很不堪，甚至需要付出不菲的代价。

本文中我们将一起看看你是如何在一开始就被锁定的，如果更换技术需要付出怎样的成本。同时我们会介绍不同层面的锁定，什么时候可以放心拥抱技术锁定，需要立刻付出额外成本进行更换的原因，以及从长远角度来看如何降低更换技术所产生的成本。

技术锁定是如何产生的，更换成本有多高？

技术锁定的形式多种多样，每种形式的更换成本都可能非常高。

财务的角度

商用软件通常需要通过每服务器或每席位的方式获得许可，购买支持协议，并会产生与顾问服务有关的“上岗”成本。这些费用中有些是一次性的，但很多公司可能需要定期反复收费。硬件成本通常会产生极高的资本支出，而其价值会逐年贬值。别忘了还有基础结构的托管成本，数据中心的建设成本，以及使用共置 / 托管服务的成本，这些做法都需要做出大量财务承诺。

所有这些成本都属于某种形式的技术锁定。企业在技术方面投入巨资，自然希望能够从投资中获得价值。当花费上千万美元部署了一套 ERP 系统后，很少有企业会愿意放弃这套系统转为使用其他厂商的产品！在购买新系统取代老系统之前，CFO 都希望能榨干老系统的最后一滴油水。云服务也无法针对财务锁定获得“免疫力”。虽然我们都认为云计算具有独一无二的“现用现付”模式，但只要你能按月或按年做出承诺，很多供应商都会在报价方面提供折扣。这样的承诺虽然能节约成本，但也会让你无法轻易停用相关的服务。

对供应商做出重要的财务承诺，这也意味着更换供应商的过程会变得更加痛苦。提前解约可能需要支付费用，甚至可能需要偿还前期获得的折扣。任何彻底更换供应商的做法都无异于一种庞大的项目，需要组建团队并花费大量时间进行迁移，甚至会影响到本职工作。此外还会面临一些可能影响到底线的后续更换成本：为员工提供新的培训，如果新技术与原有模式不兼容则需要更换托管或支持服务的供应商，甚至可能需要为新资产的管理购买新的工具。

使用模式的角度

企业需要根据特定资产的使用方式构建相关流程和系统。此时很容易（无意中）让所构建的流程和系统与供应商提供的 API、软件系统，或硬件设备紧密耦合。一旦遇到这种情况，要想在不对无穷无尽的已知（和未知！）依存项目造成重大影响的情况下让紧密集成的系统实现去耦合，此时更显得困难重重。

很多企业为新技术的规划和采购制定了集中化的流程。如果已经被这种使用模式锁定，此时就很难重新采用其他按需供应的技术，甚至更糟糕的情况下可能面临“影子 IT”的局面。与此相关的是，很多企业已经围绕外包和 IT 支持服务建立了复杂的合作关系。在这种环境中，需要按照预定义的协议购买和使用技术。希望使用这些托管技术的团队会被锁定为只能使用流程所规定的技术。这些团队也许希望通过自助服务获得更大的灵活性，但依然受到现有投资的掣肘。

业务数据 / 逻辑的角度

你的大部分知识产权也开始与运营业务所需的各种类型的系统相互融合：算法、客户记录、历史报表、业务战略，所有这一切都通过代码保存在数据库中存储的过程内，构建在使用各种“获得批准”的编程语言编写的组件中，存储在数据仓库或隐匿在内容管理系统里。另外也别忘了在你的权限模型、防火墙规则，甚至文档变更历史中还隐含着业务所需的各种元数据。

取决于这些数据或业务逻辑所处的位置，你可能面临专有应用程序、提供“标准”接口的开源数据库，或不允许执行提取操作的第三方程序所造成的锁定。这一切使得你只能继续使用存储这些信息的记录系统或管理系统而无法轻易更换。

更换需要付出极大的代价，有时除非完全从头开始，否则根本无法实现。举例来说，如果一个组织使用 Salesforce.com 的 Apex 语言编写了大量业务处理逻辑，这些逻辑将完全无法使用其他技术运行。此时若要更换就只能使用其他环境可以支持的语言重新编写所有逻辑。原本一直使用关系型数据库的企业无法，除非付出极大精力，否则完全无法迁移至 NoSQL 数据存储系统。很多商用软件和硬件设备根本不提供用于提取数据所需的 API。这种情况下只能重建所有数据，或通过某种形式从原生的二进制格式重新解析。业务逻辑和数据是企业日常运作的关键，此时更换供应商的过程很少能通过简单的方式顺利实现。

生态系统的角度

毫无疑问，当一家公司购买技术时，他们同时也步入了围绕该技术所建立的生态系统。多样化的技术生态系统是一种健康发展的象征，然而在培训、人才、支持，以及工具方面对生态系统的依赖也是一种被低估了的“锁定”。围绕 Mulesoft 建立的生态系统，与围绕 Microsoft BizTalk Server 建立的生态系统，这两者肯定是没有交集的！

生态系统会对总体拥有成本产生影响，因此技术更换也会对新生态系统的成本评估工作产生重大影响。顾问服务是否更加昂贵？是否有什么现成的实用工具，还是需要投入人力物力自行开发？是否有自学培训材料，还是只能参加某些线下培训课程？这些问题的答案可能决定了你被生态系统锁定的程度到底有多深。

需要考虑的角度还有很多。如果想要更具体了解这方面信息，可以参阅上文提到的博客文章，文章作者 Adrian Cockcroft 从业务、技术，以及数据锁定等多个角度进行了详细的介绍。

技术锁定的不同层面

对于这个问题，最理想的结果可能只是消除了特定技术层中存在的锁定。例如可以通过 OpenStack 消除基础结构层存在的锁定。客户可以跨越公有或私有云运营自己的基础结构管理平台，此时可在无需额外付出大量更换成本的情况下更改所用的底层技术供应商。然而这种做法会导致客户只能使用 OpenStack 以及该技术所需的工作模式。用户将自己锁定到整个堆栈的不同层面，通常只是为了获得额外的灵活性。

“锁定”通常会发生在哪些技术层面？简单来说可以分为下列几层。

基础结构层

物理资产（包括数据中心、服务器、交换机、电话等设备）是我们创建和使用的所有服务的基础。举例来说，当一家公司选择托管服务供应商时，他们实际上做出了一个重大承诺，会将自己锁定在该供应商的能力和战略范围内。基础结构虚拟化是一种能将锁定范围缩减至特定物理宿主机的机制，但代价是用户只能使用特定虚拟化技术供应商的产品。

云基础结构也存在这种锁定。在选择一家公有云服务后，企业需要迁移自己的数据，针对每种云平台设置网络拓扑，并制定财务和人员方面的承诺。

更换数据中心设施、防火墙设备，或云 IaaS 供应商，这些也是一种重大的承诺。基础结构中不同领域的配置元数据很少能直接移植至其他类似的解决方案中使用。组织该如何降低自己在基础结构层面上的耦合进而锁定到其他层面？此时通常会选择平台层面的锁定。

平台层

不同的人对“平台”有着不同的看法。我们首先来了解一下人们是如何以平台为基础构建新服务的。平台通常是从基础结构组件之上抽象而来的，能够为用户提供统一的接口。借助这种广义的定义，类似 SAP、OpenStack、Microsoft SQL Server、NGNIX、RabbitMQ、Kubernetes，以及 Amazon Lambda 等技术才能称之为平台。

平台技术经常会跨越不同的基础结构层进行移植。这也是 OpenStack 等技术的一种承诺，借助这样的方式，此类技术才能通过创建与基础结构无无关的管理层作为消除技术锁定的卖点。Amazon Lambda 是一种“无服务器”框架，可以让开发者彻底忽略存储、网络，或计算等概念。这种方式的意图在于，平台可以让开发者不再需要考虑底层宿主机，可以将更多时间用于服务本身的构建。

然而平台锁定也有一定的复杂问题。虽然平台技术通常可以在不同基础结构宿主机之间移植，但平台本身难以更换。例如，更换 ERP 系统或消息引擎通常需要从头再来。来自一个系统的业务逻辑和配置数据通常无法转换至另一个系统中使用。当然，有些平台可以使用“标准的”API 或某些通用的基础元素，这样可以确保哪怕更换成本很高，但至少是可行的。

应用程序层

在堆栈的应用程序层，运行着自行开发的、开源的，以及商用的软件。这些软件通常代表着企业的应用系统和记录系统。这些应用程序可能是针对特定平台专门开发的，或直接在基础结构层面上运行。

这些应用程序本身也存在自己的技术锁定。对于针对具体行业的应用程序，也许只能从有限的供应商中进行选择。而客户还需要感激这些供应商，因为如果不使用他们的产品，就只能由客户自行开发自定义解决方案，而这种做法并不适合每个客户。这些应用程序中的数据可能以专有格式存储，或无法通过 API 使用。这就使得迁移工作更加难以实现！

什么时候适合接受技术锁定

技术锁定真的是一种很糟糕的情况吗？不一定。很多情况下企业反而应当认可并接受技术锁定。

• 维持现状可获得巨大的业务价值。首先，如果目前选择的技术可以满足业务需求并且没什么太大的不足，用户就能从中获得足够的价值。没错，很多 AWS 或 Google 云服务是专有的，但如果你的业务能从中获得巨大的竞争优势，这一点真的还很重要吗？重点在于你可以（更明智地）运用这些技术，而非整日担心自己会变得过度依赖这些技术！
• 技术可满足多年内的需求。一些技术可能会变为整个系统的基础，或者并不需要频繁改动。这种情况下，锁定对业务产生不利影响的风险实际上被降低了。当今软件的“保质期”似乎都缩短了，但类似 Ubuntu 这样的“基础技术”还是可以让人安心使用的！
• 生态系统和供应商带来持续不断的售后价值。如果能形成有活力的社区，企业对技术锁定的担忧也会减轻。你在买手机时可能需要签订持续多年的合约，但只要手机的操作系统能定期更新，市面上会持续不断出现针对该手机的各种新应用，这样总的感觉也不会太糟糕。
• 现有技能方面进行了大量投入。如果公司从 Java 技术迁移至.NET 之后能持续不断获得大量收益，你会动心吗？这样做是否值得？有时候继续沿用现有技术产品或堆栈可能是更明智的做法，因为员工对于这些技术已经积累了大量知识和经验。
• 与特定供应商合作所获得的战略价值。看看 Microsoft 吧，这家公司的不同产品是否就真的是市面上最棒的？当然不是。但只要能尽可能多地使用 Microsoft 产品，依然可以获得巨大的价值，因为选择单一供应商，通常在财务和战略方面往往能获得更大的收益。

什么时候值得为“更换”付出成本

有些时候企业也有必要打破束缚更换所用的技术。哪怕更换成本很高，从长期和短期来看依然值得一试。

• 缺乏足够的人才。如果你的公司中某个重要技术领域只有“一位专家”，这时候也许需要考虑更换自己使用的技术了，尤其是涉及到一些非常特殊的技能时。如果无法非常确信在关键技术领域具备足够的开发和支持人员，这可能会对业务造成不小的风险。
• 供应商导致创新步伐缓慢。技术本身是一种竞争优势。如果公司目前的投资无法跟上行业领袖的步伐，最终可能会伤害到这家公司的底线。任何技术层面的锁定都会造成这样的问题。如果你的防火墙设备供应商非常落伍，云服务供应商无法跟上技术进步的步伐，或应用程序平台无法适应贵公司在移动互联网领域的长远目标，还是考虑更换技术吧。
• 无以为继的成本模型。取决于你的目标，借助现有技术对业务进行缩放的做法可能无法很好地实现。你是否真的可以在所有最前沿的数据处理位置使用那些昂贵的企业服务？市面上有那么多开源方案，你是否真的还愿意为关系型数据库支付“每服务器内核”的许可费用？Randy Bias 最近通过一些非常绝妙的观点介绍了技术锁定，以及开源技术如何帮助企业从供应商手中夺回自己的权力。这里的一些概念也适用于本文谈到的情况。只要企业在花费预算的过程中能更加明智，通常就更倾向于将更多成本投入于人，而非商用软件。

改善可移植性，降低更换成本

如何能在充分利用技术投资的同时确保自己有丰富的选项，可以在未来随时更换所用技术？InfoQ 这一系列文章中的其他几篇会进一步进行介绍，这里提供几个建议：

• 避免与供应商签署长期合约。财务锁定是最难解决的，因为你需要花费大量时间和精力对抗“沉没成本谬误（Sunk cost fallacy）”。做出重大长期投资的企业在期限结束前通常会以非常谨慎的态度对待技术更换。
• 提防融合系统。通过捆绑销售的系统获得统一的接口和专门耦合在一起的内部组件，使用过程中确实很方便。然而这样的便利也使得你更加难以单独更换某个技术层，并迫使你在战略产生变化后只能更换整个系统。
• 不要使用任何不提供 API 的技术。无论硬件或软件，请尽量避免购买任何无法通过 API 操作的技术。无论存储设备或 CRM 系统，务必确保你所选择的技术可以通过自动化的方式加载 / 提取数据。
• 考虑微服务模式。你所使用的集中拥有的共享式资产越多，更换的难度就越大。不要只使用两个关键数据库，也许你可以使用三百个，为每个需要数据库的服务使用一个专门的数据库！当然，这种做法需要投入极大的精力和成本，但如果能将堆栈的控制权下放给每个需要这些堆栈的服务，更换技术的成本也将大幅降低。我们需要的是专为跨越宿主机或运行时进行移植而生的，规模更小的服务。
• 拥抱抽象技术。诸如 Ansible 和 Terraform 等技术可以帮助团队使用“插件”的方式跨越不同技术协同工作，而无需使用每个系统的原生 API。如果公司里所有虚拟服务器都使用 Terraform 创建，更换供应商的过程将变得更简单。同理，在不同系统之间使用轻量级消息总线，而不要使用紧密耦合的数据库或 API，就可以在无需更换整个集成式系统的前提下随意更换端点。
• 充分利用开源软件。开源并不一定意味着可以消除技术锁定。但正如 Bias 所说，开源可以改变权力结构并降低更换技术的成本。企业在使用 OSS 时可以获得更多控制权，但在支持合约或贡献人的发布计划方面依然会面临锁定的状况。

总结

无论你是打算结婚或者购买一台 Dell 的服务器，都会面临锁定。这本没什么。关键在于不能因为担心被锁定而变得麻木，以至于错失技术投资带给你的强大收益。不过一定要明确你所面临的锁定位于哪个技术层面，并密切关注在什么情况下需要做出改变。此外还要考虑如果出现这种情况，技术和业务做出的选择是否能够降低更换所产生的成本。

赞同还是反对？是否有其他原因需要接受锁定，或有什么策略可以降低更换成本？希望能在评论区看到你的反馈。

关于作者

Richard Seroter是 Pivotal 公司的资深产品总监，九届 Microsoft MVP，Pluralsight 公司培训讲师，演说家，多本有关应用程序集成战略的图书作者。Richard 通过一个定期更新的博客探讨有关架构和解决方案设计的话题，你也可以通过Twitter 关注 @rseroter 。

随着云计算技术日新月异的飞速发展（不同的服务和供应商，你方唱罢我登场），技术锁定依然是很多用户接受云计算过程中的主要障碍。技术锁定意味着什么？如何确保在照顾到“可移植性”的同时通过云计算方面的投入获得最大化收益？

本篇 InfoQ 文章是“云和技术锁定”系列文章的一部分。你可以在订阅后通过RSS 获得内容更新通知。

查看英文原文： Everything is “Lock-in”: Focus on Switching Costs