有关（云）技术锁定的 Virtual Panel 探讨

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

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

主要结论

• 技术锁定不可避免，系统越独特更换成本越高。
• 可以根据备选方案的丰富程度对技术锁定的范围进行量化。
• 组织需要根据能否提供良好的投资回报为依据做出合理的技术决策，而不能以意识形态上的争论为依据。
• 开源不一定能消除锁定，但通常能提供更丰富的备选方案。
• 妥善设计的体系结构能实现单一软件解决方案所不具备的灵活性。

关于技术锁定这个话题从来不缺见解。技术锁定到底在哪些方面让人感觉“很受伤”？面对技术锁定，开源到底是终极的正确答案还只是一种虚假的承诺？InfoQ 邀请下列四位软件行业领袖就这一话题展开了 Virtual Panel 现场讨论：

• Joe Beda是 Accel Partners 的入驻企业家。之前在 Google 就职时，他曾负责一些革新性的服务，例如 Google Compute Engine 和 Kubernetes。
• Simon Crosby是 Bromium 的共同创始人兼 CTO，曾在 Citrix 和 Intel 担任领导职位。
• Krish Subramanian是 CloudMunch 公司产品和战略资深副总裁，长久以来一直活跃在云社区领域。
• Cloud Opinion是一个对云技术有着深入了解的虚构角色。

这些参与者在超过五天的时间里进行了下列现场讨论。

InfoQ：请谈谈你们自己对技术锁定的定义，以及自己认为谁最应该关心这个问题。

Joe：锁定是指任何会对未来的技术自由度产生限制的技术或流程决策。完全避免技术锁定的唯一办法是什么都别用。因此我们关注的重点不应该是如何避免锁定，而是找出并归纳锁定的特征，然后加以应对。

行业标准和开源是缓解锁定的有效措施。这两种方式都提供了不依赖于封闭系统和协议的各种选项。因此锁定更多地发生在对供应商产生长期依赖的情况下。

我觉得可以通过“视距内的锁定（Lock-in event horizon）”这个新称呼代表决策变动的更换成本超出企业承受范围的情况，这种情况下现有决策只能维持不变。也正是因此，很多银行至今还在使用老旧并且昂贵的大型机。

Cloud Opinion：技术锁定是指现有技术使你难以在未来换为使用更好的技术，或更换成本非常高的情况。例如在 2000 年前后，很多组织纠结于到底要选择 JEE 还是.NET。说来也好笑，当时的分析瘫痪（Analysis paralysis）现在看来也没什么大不了的。选择 JEE 或.NET 完全在于你自己，重点是快速选一个然后用起来。

技术锁定还衍生出供应商锁定这种概念。例如在选择 JEE 后，一些组织还需要在 IBM Bluestack 或 Oracle RedStack 中做出选择。无论选择 BlueStack 或 RedStack，这样的组织都已经无法轻易采用其他新技术。他们只能放慢自己的创新节奏，与供应商龟速的创新步调保持一致。这些客户现正在缓慢地迁移至新的 PaaS 方案中（选择.NET 意味着将同时遭遇技术锁定和供应商锁定）。

供应商锁定也是不可避免的，IT 高管必须像对待风险那样对锁定进行评估。但同时也要提防分析瘫痪造成的束手无策。

Krish：我想首先界定一下公众的看法（我个人喜欢将其称之为传统智慧）。按照传统思维方式，以某种程度的锁定（以及相关成本）为代价立刻获得价值（便利性）是没问题的。过去这是一种合理的做法，当时的技术革新非常缓慢，通常多年才能更新一次。相比连续多年持续不断获得的价值，摆脱锁定束缚的成本显得那么微不足道。但现在技术变化的速度以指数形式增长，业务需求迫使 IT 必须不断进化（我个人喜欢用“活跃的 IT（Live IT）”描述这种情况），此时传统思维方式已经不适用了。我们需要重新定义接受一种技术所能获得的价值，需要在各种可以立刻获得的价值基础之上考虑后续革新的灵活度。不考虑灵活度就无法获得最优化的价值。

传统思维的另一个问题在于，提到锁定人们立刻会想到供应商锁定。在我看来，用户完全可以将所有预算花在自己热爱的供应商身上，业务死不了的。但是用户不应该在制定有关体系结构的决策时将 IT 与某种工具、体系结构或流程紧密绑定在一起。这样的锁定比供应商锁定更危险。与技术、体系结构，以及流程的紧密耦合会使得 IT 成为现代化企业中的“老古板”。而 IT 进化的动力注定要避免这样的情况。

正如 Joe 所说，锁定是无法完全避免的。如果有人认为可以通过某种方法彻底避免任何类型的锁定，那他一定是晕了头了。重点在于将锁定的成本降到最低。目前 IT 革新的速度比以往任何时候更快，现在已经没有足够的时间让你赶上技术进步的步伐，因此这样的方法是必不可少的。如果一家组织的 CIO 缺乏这样的全新思维方式，这个组织注定会走上下坡路。关键是弱耦合（Loose Coupling）。

Simon：锁定并不是对自由度的局限，而是一种只与当前情况密切相关的上下文情境。用户只需要在希望换掉已经无法满足需求的技术供应商时对锁定进行了解或评估，但无法进行精确的预测。技术的进步速度太快了，用户根本无法预测任何供应商可能会在未来发布什么产品或技术。

InfoQ：哪些技术存在可能误导用户的锁定以及较高的更换成本？一些技术可能无法让你一开始就发现会造成紧密耦合，但更换成本依然非常高。

Krish：我不想具体说哪些技术可能存在紧密耦合的情况，但我要说的是，整个技术堆栈越上层的内容便利性越高，但同时遇到锁定的可能性也越高。重点在于满足技术进化需求的同时应对这种锁定。上个问题中 Joe 也提到，行业标准和开源能提供不小的帮助。如果使用了某种高层服务（例如某种无服务器计算技术），在这一领域建立相关标准前，至少要确保使用能支持多种云平台的技术。任何能解决实际问题的工具都可以使用，但所选工具一定要能与战略需求一起灵活演化。

Joe：我们有必要将实施的更换和接口的更换区分对待。标准化接口（哪怕仅仅是概念层面上的）可以降低风险，用户无需重写所有程序即可解决问题。有关虚拟机和对象存储的核心概念已经被人们广泛理解，相关的更换成本很低。

与之相反的是，系统在概念层面的独特性越高，更换的难度就越大。不幸的是这些独特功能往往能提供巨大的价值。

一些系统看似是一种“稳妥的赌注”，但最终往往会成为生产环境中的噩梦，这样的情况是用户最不愿意面对的。侧重于开发者的存储系统通常都以这种问题而臭名昭著。这类系统一开始可能非常容易上手，可以提供很不错的使用体验，但随着使用时间的延长，相关应用程序投入运行并开始产生大量流量时，往往会在性能、稳定性，以及可操作性方面产生问题。

很多面向开发者的工具都存在一种趋势：会以投入使用后 5 个月里的开销为代价换取开始使用后前 5 分钟内所提供的良好体验。如果参加开发者大会时看到某些产品以非常易用作为卖点，我会对这样的产品提高警惕。这样的易用性通常需要以缜密的、易于发现的底层体系结构为代价。产品看起来越易用，当你想偏离预设使用模式灵活运用的过程中遇到的障碍就越多。

Simon：我觉得 Joe 已经说的很好了。

谈到锁定造成的“惊喜”，我依然坚信专有数据存储是最难以解决的，例如数据库软件和紧密耦合的配套程序。如果担心过于依赖某个供应商可能导致承受涨价的困扰，并且无法以足够快的速度采用新技术，就有必要坚持使用开源的系统和 API。

但是也要明确，借助类似 AWS Lambda 之类的平台开发那种所谓的“无服务器”应用程序会造成难以置信的依赖。除非彻底重写，否则这些应用根本无法迁移。相比将数据从老旧的存储系统中迁移出来，针对新平台重建应用逻辑的过程可能更难。

Cloud Opinion：很认同 Joe 和 Simon 针对堆栈中不同层面最容易造成技术锁定的看法。从业务角度来看，更换风险最高并且对用户体验影响最大的组件会产生最高的更换成本。例如，很多企业至今依然使用 AS/400 Green Screen 的唯一原因就在于，从这些系统中迁移数据会产生极高的用户体验成本，并可能影响到业务的正常运转。成本还会受到为了更深入理解这些想要替换的技术而寻找所需资源的能力所影响。缓解锁定风险的方法之一是使用对开放式标准提供更好支持的组件。具备完善文档接口的开放式标准能为我们提供很大的帮助。

想要提醒大家注意一点，接口标准化的实现需要时间，早期市场通常会提供使用专有接口的集成式产品，因此若要使用最先进的技术，就不可避免会面临锁定。举例来说，如果你想在等到开放式标准出台后再使用无服务器计算技术，那恐怕还要继续等 3-5 年。

InfoQ：Simon 提到了 AWS Lambda。你觉得当企业在决定如何接纳类似数据库、消息层，或“无服务器”堆栈等专有云服务的过程中应该怎么做？如果这些技术能提供所需业务价值，是否就要立刻全盘接受？是否需要有节制地使用以降低依赖性？还是暂不考虑，等待相关标准的就绪？有没有什么推荐的做法？

Joe：从锁定的角度来看，Lambda 和无服务器技术也没什么新颖之处，企业可以像对待其他任何技术决策那样对待它们。也就是说，需要在锁定以及锁定造成的风险（自己有可能摆脱哪些因素的束缚）与技术所能提供的价值之间进行权衡。任何公司面对任何产品都很难做出这样的抉择。例如一家初创公司没什么需要保护的投资，因此相关风险很低，而通常所能获得的价值很高。如果锁定已经开始成为一种问题（例如无法缩放的 PaaS），这种“成功灾难（Success disaster）”总好过始终与成功失之交臂。

然而危险之处在于不进行任何分析就一头扎进锁定的环境中。我认为，类似 Lambda（也就是数据库中的存储过程）这样的系统很容易造成这种情况。用户可能一开始使用 Lambda 开发了少量依赖 Lambda 的程序，但很快发现自己所编写的很多代码都与 AWS 紧密耦合。考虑到 Lambda 并非自成一派的体系，而是需要用到 AWS 平台的很多事件和服务，这种情况更为严峻，Lambda 根本无可替代只能全盘使用 AWS。

我很乐于看到面向开发者的文档中开始提及锁定这个问题。我觉得可以按照 Google“数据解放阵线（Data Liberation Front）”的倡议将这种行为叫做“代码解放阵线”。对于每种系统和 API，我们可以打出相应的分数（下列评分可以作为一种范例）：

• CLF 0：完全专有。如果试图克隆这种系统（例如 Oracle Java API）很可能招致法律诉讼。
• CLF 1：开放式 API 规范。开发这种 API 的公司承诺不因为你对这种 API 创建一个独立的版本而起诉你，例如 Slack。
• CLF 2：只有单一的备选实现。这种接口可以包含开放式实现或独立实现。
  – CLF 2.1：由社区开发的备选实现（例如基于 GAE 实现的 AppScale）。
  –CLF 2.2：由供应商提供支持的备选实现。
• CLF 3：有多种备选实现。
• CLF 4：所有代码均已开源并由社区驱动。

只针对系统整体应用这样的标签是不够的，因为随着新功能的陆续加入，独立支持可能也会产生变化。我很希望看到这样的体系也能包含在开发者文档中。理想情况下，你应该可以通过“Lock-in lint”工具对所要承担的风险和希望实现的自由程度进行打分。

Simon：虽然喜欢 Joe 的想法，但我觉得需要补充一点：“代码解放阵线（Code Liberation Front）”很有可能跑偏并最终变成“解放代码的阵线（Liberation Front for Code）”，以“伟大”的目标、标准或接口作为不屑努力的方向，但最终获得的却是一个不兼容的生态系统。这种情况随处可见，例如 VMware“Open vSwitch”和 Open Daylight Foundation；Red Hat Linux 和 Oracle Unbreakable Linux；Ubuntu 和 Debian。这样的情况数不胜数。为什么呢？尽管“开放和自由”的争议能够为客户提供灵活性和丰富的选择，但并没有考虑到供应商的利益。目前还没有什么足够得体的开源业务模式，如果供应商为了抢夺市场份额“斗争到底”，客户最终只能退而求其次选择供应商“斗争”的产物。如果这样的平台 / 产品自身不具备商业可行性，客户将面临另一种类型的锁定：自己将自己锁入牢笼，扔掉钥匙，别人毫不关心也完全无法提供任何帮助。

这种极端的情况十分危险：单个“专有实现”和“一切均开源”，需要在这其中做出合理的选择。鉴于规模非常大的供应商会产生极大的影响力，他们可能会受制于各种制度的监管（例如 Microsoft 的合意判决（Consent Decree））。AWS、Azure，甚至 Google Cloud 都面临这种情况，为了像土匪一般攫取大量利润，他们有可能在相当长的一段时间里针对功能 / 服务提供更大程度的通用性。

用户对每个企业应用程序最终都会期待获得投资回报。如果能对初始投资和回报进行妥善的权衡，企业就可以制定出合理的，以业务为中心的决策。然而还有必要对应用程序所需产品（计算、存储、更复杂的服务 / 产品等）定价方式的根本性改变有充分的了解。基础技术变动导致的大规模断层所造成的锁定可能会使得一些在传统业务情境中能提供巨大价值的解决方案成为昂贵无用的累赘，但这就是技术行业的行事方式：选择要驾驭的技术，并祈祷自己做出了正确的选择。

Cloud Opinion：这主要取决于具体业务。将 IT 用作战略投资参与市场竞争，这一点对你到底有多重要？为业务提供价值，比陷入意识形态争议的锁定更为重要。通常来说，相比等待技术逐渐成熟并催生出开放的标准，第一时间采用前沿技术可以帮助你的组织在市场竞争中获胜。为了在激烈的市场竞争中保持竞争力，锁定可能是一种必须承担的代价。然而依然需要对业务价值和潜在的锁定成本进行权衡，你对于其他类型的风险不也是这样做的吗。

具体来说，目前 AWS Lambda 可能还不适合广泛使用，并不是因为担心被锁定，而是因为相关工具还需要进一步完善才能为开发者提供所需的生产力。

Krish：我不能说不应该使用专有工具，而是应该慎重研究这类工具的使用时机和方法。等待标准的出台是一种徒劳无功的做法，然而目前通过开源和标准化技术推进企业对 OSS 的接受速度，情况正在好转。

在决定到底使用专有数据库服务，还是选择无服务器计算这种高端服务时，你需要：

1. 从业务价值寿命的角度考虑锁定成本。在感受到压力需要革新之前，这种技术能否为我提供足够长期的收益？如果不能，市面上是否有什么无需付出太多成本或时间的情况下就能顺利实施的备选方案？
2. 为了不对 IT 技术的演化产生影响，问问自己能否将使用专有技术的服务应用在尽可能小的范围内（换句话说，是否能确保这类技术不会影响自己参与市场竞争的能力）。

此外，类似数据库服务这种应用程序依赖性的锁定和类似无服务器计算这种运营层面的锁定是两回事。用户必须了解这两者的差异，评估不同形式的锁定对快速演化能力可能造成的后果，随后在全面采用这类技术前对体系结构进行细致的划分。在我看来，仅仅因为“有着光明的前景”就不假思索立刻拥抱新技术，这是一种自杀式做法。

面对反复出现的风险，在缺乏标准的情况下，多个云平台的弱耦合可能会成为任何现代化 IT 战略的核心元素。

Simon：关于 OSS 我想强调一点：OSS 本身不是一项标准，也无法帮助用户摆脱锁定。OSS 也是别人开发的代码，并且你无从加以控制。无论来自 GitHub 或其他来源，任何 OSS 依然有可能让你面临锁定，因为别人根本不关注你自己环境中的烂摊子。OSS 并非解决锁定问题的答案。OSS 是开发者为了重用代码所采取的一种方法，这里的风险在于，用户可能会通过一些小型项目选择未能妥善维护的程序包，这样的程序包中很可能存在 Bug、安全隐患，或其他问题。商用供应商所支持的 OSS（例如类似 Amazon Linux 的某种服务，或 Docker 这样的商用产品）也许可以提供更为安全的中间立场，但这依然缺乏保障。

Krish：我想接着谈谈 Simon 提到的 OSS。虽不是标准，但在当今世界里 OSS 对标准化的促进速度远远超过专有软件。

此外，通过 GitHub 获取任何版本的 OSS，这种做法危险程度与从网上随意下载各种软件的危险程度相当。没错，风险确实有，但并不只是从 GitHub 下载软件有风险，从网上下载任何软件，无论 OSS 或专有软件，都存在着风险。对于 OSS，如果有足够的知识和时间，你大可仔细检查软件本身的质量，但对专有软件就没法这样做了。

一般来说，建议无论专有软件或 OSS，都需要进行尽职调查。从陌生供应商处得到的专有软件也许缺乏透明度或保证，但 OSS 通过一种更好的方式为你提供了尽职调查所需的能力，不仅可以获得软件源代码，还能通过 GitHub 之类的网站得到来自社区的帮助（评分、表单数据、Pull 请求等）。

Simon：OSS 真能比专有软件更快速地促进标准化的实现吗？未必！Linux 没有“标准”，只是为你通常所依赖的内容设立了一组“共同特性”。

同时任何认为 OSS 用户具备审查软件安全性和功能所需的技能、时间或经验的说法都没有确切的根据。想当然地认为网上获取的软件就是可用的或者安全的，这种想法本身就会给你带来不小的挑战。对于正在积极维护和推广的项目，也许可以这样认为，但依然没有任何保证。更重要的是，随便选择的 OSS 软件在无法满足预期的情况下，无法为用户提供任何担保或补救措施。专有软件供应商所提供的程序包和支持的 OSS 项目可以包含 SLA，如果你希望避免锁定，这应该是最基本的要求。

我不赞同让企业进行“尽职调查”的做法。我们谈论的是软件的企业用户，直接断言 OSS 软件包的用户就具备尽职调查所需的资源、洞察力和技能，这种想法有些天真。如果不想被别人开发的糟糕 / 不安全的软件绑定，可以选择商用供应商提供支持，并且在技术支持方面提供 SLA 的（OSS 或商用）软件。

Krish：Linux 不是唯一的 OSS 软件，如果你仔细看我说的话会发现，我强调的是，目前 OSS 能比专有软件更快速促进标准化的实现，Docker 就是个很好的例子。

另外关于检查 OSS 软件需要花费时间，这个说法其实曲解了我的本意。仔细阅读就知道，我刚才说的是 OSS 为这样的尽职调查提供了可能性。

我不赞同企业客户缺乏深入了解 OSS 软件所需的资源或技能这种说法。诸如 Expedia、Capital One 这样的公司正在主动将越来越多自己内部开发的软件以 OSS 软件的形式发布。企业用户缺乏对 OSS 的了解？这种结论已经站不住脚了。

Joe：我想进一步完善一下刚才针对 Simon 的观点提出的看法。

首先，OSS 虽然意义重大但并不是万能的。开源提供了一种无法通过其他方式获得的选项：你可以创建分支并自行维护。虽然这样做的成本很高，但考虑到为业务带来的价值，这样做依然是可以接受的。很明显，小规模初创公司创建的项目分支无法提供什么投资回报，但是对大型企业来说，开源提供了闭源解决方案永远无法具备的丰富选项。

对于我之前提出的“代码解放阵线”这个想法，之前可能说的不够清楚。这并不是指某种生态系统，而是一种对特定 API 所造成的锁定程度进行归纳描述和评价的方法，借此可以评估使用某种 API 时在自由度方面可能需要承受的风险。一种技术没有开源并不意味着这样的技术没价值、没用处，或者不是一种好的选项。但是通常来说专有技术的锁定风险会远远高过开源技术。

我认为从几个方面来说我们都处在一种暴力共识（Violent agreement）的情况下。首先，锁定是不可避免的，同时也是必要的。其次，如果锁定带来的回报胜过需要付出的成本，对业务来说采取这些可能产生锁定的技术就很合理了。最后，在对任何想要使用的技术（或技术中的某种功能）进行评估时，都需要清楚地认识到你会在哪些方面被锁定，锁定的风险又是什么。

Simon：一旦创建分支，就必须自行搞定一切工作。嗯，这种做法其实可以叫做企业专有解决方案，也就是作茧自缚。企业很少（就算有的话）具备维护自己专有项目分支所需的资源，或者只能重新并入原本的主线。OSS 的价值在于来自社区的持续贡献，快速演化，更好的安全性和功能。但是对于担心被锁定的企业平台，选择一两家能为 OSS 软件提供支持的商业合作伙伴难道不是更合适的做法吗？

Joe：对于“那种可以通过多个供应商获得商业支持的项目”，我觉得这是一个有必要强调的重点。并非所有 OSS 软件都生来平等。理想情况下，健康的 OSS 生态系统可以得到来自多个供应商的支持。企业可能无法维持自己的分支，但这些任务可以交给新出现的供应商，例如 MariaDB 就是这样做的。

InfoQ：Randy Bias最近撰文说 OSS 有助于革新供应商的权力力度（Power dynamic）并能降低更换成本。然而正如 Simon 所说，OSS 自身也存在某种形式的锁定，远远无法借此避免锁定。在你有关锁定的决策中，开源扮演了什么角色？“标准”能否缓解自身造成的这种锁定？或者说，这个问题重点在于体系结构而非软件本身吗？

Simon：我认为 Randy 的观点实际上就是“Randy 的偏见（Bias）”:)。OSS 确实可以改变权力力度，但毕竟我们谈的是锁定，我们探讨的是企业因为某种原因被局限在某一特定供应商的平台中。我们是要探寻这背后的原因。OSS 从任何意义上来说都不是这个问题的答案，除非客户已经准备好通过 OSS 软件实施自己的平台，并愿意放弃原本可以获得的支持和 SLA。对几乎任何大企业来说，通常都不会考虑这样做。OSS 的有趣之处在于，它已经成为一种方法，可以吸引开发者快速创建能为很多使用场景提供价值的平台或组件，服务提供商或供应商应该能为这种方法提供支持。

Cloud Opinion：我认为有必要将“开放式标准”和“开源”区分对待。虽然营销人员喜欢将这两者混为一谈以促进自己产品的销售，但其实还是有差别的。

开放式标准有助于降低锁定风险。开源无法直接起到这类作用，但通过让用户更容易找到胜任相关组件 / 产品的人才，可以间接提供帮助。可开源社区的思想领袖会争论说，OSS 对锁定风险的降低，在他们看来如同专业营销人员伪装的技术顾问。

我想列举一个和 Joe 从事的领域非常紧密的例子。如果想要在不同产品之间实施联合身份验证，使用 SAML 之类的开放式标准可以降低技术锁定的风险。如果使用某个供应商提供的 API，随后就会遇到锁定风险，如果要更换所用产品，无论该产品的 API 和范例代码是否发布到 GitHub，你都需要付出更多成本。

接着再列举一个和 Krish 从事的领域非常接近的例子。如果要搭建自己的“云”，你可以选择使用 OpenStack 这样的开源软件。OpenStack 是一种开源技术，而非开放式标准。RedHat 提供的 Open Stack 发行版和 IBM 提供的 OpenStack 发行版当然有所差异。如果你选择了某个供应商提供的特定 OpenStack 发行版，恭喜你，你自己造成了锁定（但锁定可能不是你需要面对的最大问题，人才的维系才是）。

Joe：我完全同意 OSS 和标准是两个截然不同的概念。

但我们还是对 OpenStack 的这个场景发散思考一下。虽然无法在不同 OpenStack 发行版之间无缝切换，但切换成本至少要比完全迁移到截然不同的技术平台要低。因此 OSS 其实也可以降低锁定成本。虽然“标准”的目标是消除锁定风险，但 OSS 至少可以降低这样的风险。

对于身份验证那个例子，如果所用 API 是开放的，他人可以借此提供不同的实现（例如供应商不会起诉），那么其他供应商就可以实现这种 API，而这个 API 就成了约定俗成的标准。S3 的核心正在发生着这样的情况。在使用 Google Cloud Storage 构建应用时，我们知道在工具和 API 方面也存在“先有鸡还是先有蛋”的问题。S3 API 已经足够简单，我们已经可以（至少针对核心部件）开发出 API 兼容，能够顺利沿用现有工具的实现。也正是通过这种方式，才能通过适用于 AWS 的知名 Python 库 boto 开发命令行工具 GCS（ gsutil ）。

我提议进行一次思维实验。在我看来，Windows 和 Win32（见下方注解 1）是锁定的终极范例，这样的锁定需要通过（Web 和移动）技术的革命来消除。如果 Windows 是开源的结果会有什么不同？我猜测 Microsoft 会受到抑制而全世界可以进行一次软着陆。

注解 1：Win32 是 API 过于晦涩难懂而无视标准化的完美范例。就算 Microsoft 自己也不具备干净实现（Clean implementation）所需的足够好的规范。代码本身即规范。

Krish：我在锁定风险那个问题中说的就是这个意思。OSS 有助于促进标准化，一些营销人员可能会将 OSS 与标准混为一谈，但不可否认的是，OSS 是大部分标准化工作的最前线。

人们有关 OSS 的 FUD（惧、惑、疑）最主要的问题在于，他们会选择性地挑选能应对自己主张的例子。服务的世界里开放式协议是关键，任何参加过与服务有关的基础入门课程的人都会得出这样的结论。然而仅有开放式协议还不够。看看 AWS API（与 Cloud Opinion 的想法非常吻合）吧，尽管 AWS 已经成为市场领导者，但我们依然无法让其实现标准化。他们是有多偏好 Eucalyptus 而嫌弃 CloudStack？考虑到这套 API 背后的专有堆栈，供应商利益和客户利益之间存在着巨大的风险。虽然 OpenStack 可能还有其他问题，但它的 API 是供应商无关的，无论供应商态度如何你都可以采纳并使用。

任何掌握软件开发技术并开始入门服务领域的人都能轻松地发现，以 OSS 堆栈作为后盾的开放式 API 才是最安全的做法。在互操作性方面能提供保证吗？没门！相比专有堆栈，开放式 API 能降低风险并提高使其成为标准的潜力吗？当然可以。

看名字，Randy Bias 这人可能有偏见（Bias），但他以前发布的一篇文章针对开放式 API 为什么还不够，以及为什么说 API 背后的体系结构至关重要进行了非常精彩的阐述。强烈建议大家读读 Randy 的这篇文章。考虑到 API 背后体系结构的重要性，开放式 API 背后的开源技术所提供的价值就更加显而易见了。

在我看来，只有营销人员才会说 OSS 不重要，只有开放式协议最重要。

另外，如果 Amazon 在构建 AWS 时说服了湖区的其他公司更改许可条款，谁还会压赌在他们身上？OSS 许可方式的灵活性让 AWS 获益，这样的灵活性还可进一步加速创新。前一句话里的关键字正是“加速”。

Cloud Opinion：OSS 挺好，令人惊叹，但真能直接降低锁定风险吗？

Joe：可以，再次建议大家看看 MariaDB 吧，实际上在被 Oracle 收购之前，MySQL 一直以 OSS 作为自己的发展战略。

Krish：可以，OSS 降低锁定的可能性远远高过专有软件。

调整一下措辞：如果问题是“OSS 是否等同于不锁定”，答案是：未必。

但如果问题是“相比专有软件，开源能否降低锁定”，答案是：绝对可以。

InfoQ：如果有公司着手在自己的环境中增加或更换关键技术，你们有什么建议？需要考虑哪些方面的问题？体系结构方面是否有什么重要的注意事项？有哪些问题是无需担心的？

Cloud Opinion：我觉得这个决策首先应该由业务和技术原因驱动。一旦有正当的业务或技术理由（例如降低技术负担），就需要理解相关的成本。例如可以考虑：

• 团队中是否有必要的人才？或者能否通过培训或招聘等方式获得所需人才？
• 预计这项技术在多久后能够为业务提供价值？
• 是否存在“被迫”更换这项技术的风险？例如提供技术的公司停业了，许可方式有变化，定价有变化，技术管理成本越来越高，人才短缺，性能退化等。
• 这项技术是否会迫使你将来只能从一家供应商处购买需要的其他所有技术？如果会，这家供应商是否你“首选”的供应商？你是否对这家供应商进行过详细的尽职调查？与该供应商是否签署了什么商议协定？

有些事则不必担心，因为业内人士说了，一些特定的技术确实会造成锁定。你需要自己思考，毕竟每一行都有不同的特点。思考的过程可不能外包给其他公司。

Simon：我们正身处在一个前所未有的技术创新时代，每种创新都影响到我们以往针对 IT 或应用程序交付所做的各种假设，甚至影响到我们对相关技术和供应商的选择。谁能做出准确的预言呢？仅仅在 3 年前，所谓的 DevOps 活动与 Docker 这样的容器技术相结合，就对下一代应用程序体系结构的规划，云平台的选择，以及 AWS 和 VMware 等相关供应商的选择产生了深远的影响。谁能预见到 Mac 在消费者群体中的人气和 iPhone 的支配地位会彻底改变消费者使用各种应用的方式？诸如物联网等下一代技术用例又会再一次对业界产生怎样的影响？

层出不穷的创新对传统企业 IT 和应用程序交付团队产生的影响是巨大的：

• 员工会因为或多或少落后于趋势变化而需要迎头赶上，或在“便利性”产生变化后缺乏发现“更长寿”技术变迁的能力。例如，公有云和容器都得 Linux 发行版的选择无足轻重，类似的，采用 SaaS 应用程序后虚拟化技术将变得无足轻重。
• 供应商也或多或少有些落后，因此更倾向于在技术选项的适用性方面误导客户。
• 难以找到并维系在当前热门技术（VMware、AWS、Docker）方面具备技能的员工。

上述任何一种人都可能导致企业在为关键应用选择供应商或技术的过程中做出糟糕的决策，并在未来面对不那么愉快的锁定。

鉴于技术甚至供应商都在飞速发生着变化，继续出于合理原因采购供应商产品（指企业拥有或在本地运行的产品，而非目前的“即服务”产品）的唯一方法是发现并详细记录现有平台可能导致锁定的局限，并从业务角度将其与“下一代”方法所提供的机会和获取成本进行对比，与此同时要确保远景规划所涉及的时间尽可能短。“更新更好的技术”会以更高频率层出不穷，因此很多选择也需要由战术来驱动。

很多传统的本地部署、拥有 / 许可的 IT 能力和企业应用程序都在迁往 SaaS。SaaS 供应商的采纳是一种战略性的，长期的，有粘性的解决方案，换句话说这里面蕴含了极大的锁定风险。虽然 SaaS 提供了很多收益，但也要注意任何 SaaS 应用只要使用一段时间就会在其中产生大量企业数据，这时候再想停用就很难了。用户需要针对可以立即获得的收益，以及潜在的长期成本对此类应用进行评估。

Joe：我也不确定要对之前的回答补充些什么。

我同意，我们正身处技术更新的过程中。人们很容说，只要等一等，最终的赢家终究会出现，到时候就不需要左右为难了。但这些人对“迁移至云”就是这么想的，时至今日云迁移还没有全面完成，但是各种新的想法又出现了。

我（作为一个主要开发，而非使用这些平台的人）的建议是，务必要对目前所选择的技术感到满意。以后还会出现更多让人激动的东西，但其中很多可能只适合那些有耐心，有驾驭这些新技术的人员的早期采用者。请根据对所具备能力的清醒认识和各种技术目前所处的状态来做决策。

关于锁定需要考虑：(a) 你将来弃用某一技术或供应商的可能性有多大，以及 (b) 更换的成本有多高。请将这些风险与决策所能带来的价值放在一起进行权衡。很明显，这些都取决于公司业务的约束以及针对未来情况的合理猜测。

我觉得很多出色的技术领袖在做决策时都会采取这种直观的做法。我也很希望以后能用更好的决策框架和专门的术语来探讨这里面的风险，这样才能用更为系统性的方法做出决策。换句话说，这次的对话还远未结束。

Krish：技术演进的过程中不要过于重视便利性而忽略了灵活性。这种做法在传统环境中很有效，当时可能十几年才会进行一两次技术更新，但今时不同往日。目前的 IT 更像是一种随时在演化的“活跃的 IT”，当今我们的 IT 战略一定要明智。

一些结论

1. IT 环境应该是一种弱耦合的系统。不仅应用程序组件要弱耦合，基础结构和所部署的平台也要如此。举例来说，如果要在某个平台上部署应用程序，使用该平台自带的数据库服务固然方便，但数据带来的沉重压力可能会成为你的拖累，让你无法在当今快节奏变化的世界中以足够快的速度对 IT 进行革新，以满足不断变化的需求。请务必制定好相关规划，让类似数据这种应用程序关键组件能够移植。如果紧密耦合无法避免，至少要确保你的应用能够支持不同的云平台。
2. 在应用程序端，请在可行的情况下尽量采用微服务体系结构。面对快速演化，微服务比单层系统（Monoliths）提供了更高灵活性。虽然无法同时将所有东西迁移至面向微服务的体系结构，但至少应该开始对某些组件进行迁移了。
3. 确保通过抽象避免流程的紧密耦合。例如，你不会因为仅仅想要拥抱 DevOps 就选择某种具体的部署平台或工具。你可以通过多种方法在无需承受高昂的成本或锁定压力的前提下对过程进行抽象。
4. 避免锁定，还需要企业文化上的改变，需要对侧重于便利性而忽略锁定风险这种传统思维进行转变。决策者必须了解 IT 的流动性会越来越高，面对压力必须能进行持续不断的演进。同时决策者也必须了解这些变化。企业高管需要懂得放弃短浅的眼光全面拥抱“活跃的 IT”这种模式。

当然，维持演进所需的灵活性需要付出代价（但不像过去那么高），但缺乏这样的灵活性必然也要在不远的将来付出代价。应对这些需求时一定要足够明智。

讨论者简介

Joe Beda是 Accel Partners 的入驻企业家，目前正在寻求下一份工作，同时他也是 CoreOS 和 Shippable 的顾问。过去 18 年来，他曾是一名专业的软件工程师。在 Google 和 Microsoft 任职过程中，他开发过浏览器，设计过图形 API，建立过电话系统，还参与过广告优化的工作。过去六年里，他创立、管理并发布了 Google Compute Engine，并对 Kubernetes 项目的建立、推动和发布提供过帮助。Joe 目前正在进行一个旨在借助开源项目 SPIFFE 保护服务之间的通信的个人项目。Joe 在美国加州克莱尔蒙特的哈维姆德学院获得学士学位，目前他与作为医生的妻子，以及两个孩子一起居住在西雅图。

Krish Subramanian目前是 CloudMunch 公司产品和战略资深副总裁。同时他也是云计算和大数据领域初创公司的顾问。他是坚定的现代化企业模式拥护者，致力于帮助不同组织提升灵活性。

Simon Crosby是 Bromium 的共同创始人兼 CTO。在这之前他是 XenSource 的共同创始人兼 CTO，该公司被 Citrix 收购后他曾担任 Citrix 虚拟化和管理部门的 CTO。更早前 Simon 曾是 Intel 的首席工程师，主要领导分布式自主计算、平台安全性和可信度的战略研究工作。另外他还是网络优化软件供应商 Cplane 的创始人。在成立 Cplane 之前，Simon 是剑桥大学的终身制教授，他在那里主要负责网络性能和控制，以及多媒体操作系统的研究工作。2007 年，Simon 被 InfoWorld 授予 Top 25 CTO 称号。

Cloud Opinion是一个对软件行业有着深入了解的虚构角色，你可以关注 Cloud Opinion 的 Twitter 并访问他的博客。

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

这篇InfoQ 文章是“云和技术锁定”系列文章的一部分。你可以在订阅后通过RSS 获得内容更新通知。查看英文原文： Virtual Panel on (Cloud) Lock-In