顾问对锁定问题的看法：Nicki Watt采访记录-InfoQ

随着云计算技术日新月异的飞速发展（不同的服务和供应商你方唱罢我登场），用户开始关心云技术锁定的问题。技术锁定意味着什么？如何确保在照顾到“可移植性”的同时通过云计算方面的投入获得最大化收益。

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

主要结论

为了充分利用云的能力，使用自有软件栈可以提高可移植性，但也可能意味着相比使用原生服务开发工作将要花费更长时间。

在解决方案堆栈的某些方面使用自有技术是合理的，例如 VPN 访问。

在云基础结构的基础上打造模块化程度更高的体系结构可以提高可移植性。

在采用所谓的“全能型”工具时一定要当心。例如在构建云基础结构时，请分别为供应和配置等任务使用不同工具。这样当日后需要为了解决某些方面的能力问题而要更换服务时可以获得更高灵活性。

交付软件的过程中会产生很多成本，不仅需要考虑实施成本，而且要考虑自定义解决方案的维护成本和后端支持成本。

在帮助企业交付软件的过程中，顾问扮演了重要角色。顾问是如何看待“锁定”问题并构建可移植解决方案的？OpenCredo 公司的 Nicki Watt 接受本次采访探讨了这个话题。

InfoQ：规划解决方案时，您的客户谈到“锁定”这个话题的频率有多高？主要在什么情况下谈及？

Nicki：“锁定”通常表现为几方面，例如软件或产品锁定，以及供应商锁定。对于比较大的项目和客户，例如倾向于从长远角度进行变革并选择解决方案的大企业或政府机构，确实多次提到过“锁定”这个话题。通常这是因为客户曾经经历过，或正在经历这样那样糟糕的锁定，因此非常渴望摆脱这种情况。

InfoQ：在构建托管于公有云中的系统时，如何决定是要使用云平台原生提供的服务，还是引入外部的（开源）软件栈？

Nicki：这个问题没有简单直接的答案，虽然我挺希望有的！有些客户很乐于接受某个特定云供应商的服务，在时间和预算等约束条件下，甚至愿意在使用某个特定云供应商的特定服务时承受某种程度的“锁定”，以此为代价换来速度更快、集成度更高的开发周期，以及使用更多集成式云服务产品的能力。然而有些企业并非如此，他们认为“自带软件栈”通常意味着开发过程需要更长时间和更大工作量，但是又很想获得这样做所实现的长期灵活性。“锁定”这件事在过去一直是个切实的痛点，关键在于需要对客户真正希望维持控制的核心领域进行评估。例如，通过一致的方式用 VPN 连接至不同的云供应商（使用客户自己的 VPN 解决方案，而非使用云供应商提供的方案），这意味着客户能够在这方面获得完整控制力，甚至完全无需考虑云供应商是否提供了相应服务。取决于问题的影响范围，其他方面可能并不那么重要。举例来说，如果某个解决方案要求与一个“关系型数据库”进行某种形式的交互，但并不强调具体细节，通过（云供应商）“即服务”产品使用这个解决方案，或者构建并自带自己的一套方法，两种做法虽然方式不同，但可以实现相同的业务成果。然而关键在于，只要用户依然仅仅是通过“即服务”产品使用最基本的关系型数据库功能，那么在有必要时换为使用需要提供“自带”方法的供应商，这种做法依然是可行并且无痛的。所有情况下，任何此类决策都需要与客户协商进行，并要向客户解释从一种方法换为另一种方法的可行选项，让客户决定在自己的实际情况下哪种方法对业务而言是最合理的。

InfoQ：最近您参与过多个云解决方案的相关工作，这样做的主要动力是什么，如何将技术之间的耦合降到最低，以便不需要为每个供应商的产品维持一套专用的配置？

Nicki：正如上文所说，动力通常在于客户过去已经被绑定到某个或某些特定的供应商，但现在不想继续把所有鸡蛋放在同一个篮子里。只要真正具备更换供应商的能力，就可以增强客户在这些方面的谈判立场，而有竞争总是好事！“价格”通常被看作首要促进因素，不过可能也存在管控方面的原因，例如要求某些类型的数据只能位于特定地理区域内，而这一点并不是所有供应商都能满足的。较大规模的客户首先会接受云计算，并且通常会非常习惯于将开发和测试工作负载跑在公有云中，但与此同时依然会将某些核心生产工作负载放在更专业的内部云或数据中心里运行。

最后，所有云供应商并不是生来平等的！如果你只选择为最低层次的需求提供支持，有时候可能会错失云供应商提供的很多其他附加值。因此尝试彻底免除客户进行配置或选择不同选项的做法并不一定可行。尽管如此，我用来降低耦合的方法更多围绕在解决方案的设计和方法方面，会尽量尝试充分利用一系列模块化、API 驱动的工具和产品，而不是为所有类型的解决方案使用同一种“均码”的工具。我觉得通过将这种方法与一些需要坚守的原则，例如始终将配置数据和代码分开，尽量让一切自动实现等相结合，将能获得一个难得的机会，根据需要更换解决方案中的不同组件，随时拥抱云领域日新月异的变化。

InfoQ：对于这种模块化方法的运用，能否举个例子？

Nicki：我最近参与的某个项目其主要目标之一是通过不同云供应商的服务逐渐实现彻底自动化、自包含的安全环境。这就需要通过执行自动化代码在供应商平台上供应所需基础结构，并在此基础上应用配置管理技术安装并配置以后需要的其他软件。这个项目中并没有选择将供应和配置管理功能结合在一起的工具，而是统一使用一个工具（Terraform）执行所需基础结构供应任务，并使用 Cloud-init 作为桥接机制，通过虚拟机中运行的专用配置管理工具执行最终的软件安装和配置任务。这样就可以在不影响供应基础结构所用代码库的情况下更换配置管理解决方案（Ansible <–> Puppet）。如果最初通过一个工具承担所有角色，这个过程无疑会困难很多。

InfoQ：您提到说价格是这些解决方案的一个考虑因素，在考虑这种类型的体系结构时，您是如何对此展开讨论的？不使用某一供应商内置的服务，可能会导致实施和运行成本增加，但随后的更换成本可能会低一些。如果要使用更为模块化的体系结构，而非传统的单层（Monolithic）体系结构，需要弄清楚哪些成本组件？

Nicki：“没有免费的午餐”，这种说法无论在软件开发领域或其他领域都是真理。我在自己参与的大部分讨论中都想融入这个说法背后蕴含的道理。成本有显性的，还有更多是隐性的。根据供应商服务的用量实际支付的价格，这种显性成本更容易理解和解释。但不那么有形的成本，例如开发者有时候为了参加培训、实施、定制，以及维护“自带技术”解决方案所付出的时间和精力都需要更具体地罗列出来，并将其作为整体成本效益决策的一部分加以考虑。另外还要注意，更换供应商的过程中也会不可避免产生成本，哪怕整个过程可以全自动实现也是如此。通常向供应商提供的服务中导入数据很容易，但想导出往往很难，如果有大量数据要处理这一点也需要考虑到。另外一些单层式解决方案可能会在自己的单一成本模型中引入或包含多种支持和许可成本。有时候客户可能希望改为使用更为模块化的体系结构，以获得灵活性，同时依然出于各种原因继续使用某些软件产品。需要向客户强调在新的模块化（通常是云原生体系结构）平台上运行老式产品可能会产生非常高的成本，这样客户才能选择最恰当的软件。

InfoQ：在 InfoQ 的另一篇文章中谈到了“更换成本”可能是比“避免锁定”更值得客户考虑的。您觉得哪些组件的更换成本最高，（如果关心的话！）又该如何缓解这一问题？

Nicki：非自动化组件：无法以自动化方式部署和 / 或测试的组件或解决方案，无论是否使用了具体供应商提供的此类组件，若要更换可能需要付出极高的时间和金钱成本。这种情况下通常需要找到“一个知道该怎么做的人”，由他来解释相关的情况和依赖性等问题，才能推动项目继续执行。为了缓解这种问题，需要一切都能自动化实现！！！

特定专业化供应商的产品：如果解决方案中包含特定供应商的独家功能，取决于这些功能的不可替代性，可能需要通过大量二次开发工作针对新解决方案进行定制。此时最有效的缓解方式是，如果可行或可取一开始就尽量不要使用这种定制功能。如果做不到这一点，做决策时就要注意至少要尝试降低或限制这种功能在解决方案中的使用范围，在我看来这是最佳的备选做法。因此我的首选是使用模块化、API 驱动的体系结构，这种结构中可以轻松地随时更换解决方案的某个组成部分，为不需要整体更换！

关于被采访人

Nicki Watt在 OpenCredo 担任销售顾问的职位。虽是技术人员，但她的个人座右铭是“尽可能追求简单，否则至少也要务实”。Nicki 参与过多种与开发和体系结构有关的项目，目前致力于云技术、持续集成，以及交付等领域。Nicki 还是《Neo4j In Action》的合作者，这本书全面介绍了图形数据库 Neo4j。