[关闭]
@liuhui0803 2016-06-11T13:50:04.000000Z 字数 6995 阅读 2232

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

设计和架构 DevOps 开发 IaaS 云计算


摘要:
用Java写代码,购买SAP,部署OpenStack,使用Amazon Web Services:每种行为都会产生一种类型的技术“锁定”。然而无论如何努力,技术锁定都是不可避免的。此时更重要的是充分理解技术锁定的不同层面,并考虑评估和降低更换成本的方法。

正文:

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

本篇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使用。这就使得迁移工作更加难以实现!

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

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

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

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

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

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

总结

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

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

关于作者

此处输入图片的描述

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

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

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

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注