云原生：运用容器、函数计算和数据构建下一代应用

186

｜

第

7

章

•

利用另一个云服务商提供的新功能或者快速地移动工作负荷以节约成本。

有些应用实现可移植性仅仅是出于担心供应商锁定。当应用程序依赖于只能从特定云服

务商处获得的服务或 API 时，就会发生供应商锁定。若不对其进行重构并重写用于管

理该程序的部分应用程序和工具，则很难迁移应用程序。一些团队会投入大量资源来使

应用程序可移植，却不会考虑这样做的成本。然而，当需要可移植性时，权衡取舍很重

要。利益相关者有时会要求应用程序具有可移植性，却忽视了潜在的风险，如可能影响

产品上市时间、功能、工程成本，同时常常会导致运营成本增加。

有时，即使没有明确需求，工程团队也会不必要地使应用程序具备可移植性。这通常是

出于对决定使用某一特定云服务商所产生的担忧。如果其他云服务商的服务变得更便

宜、增加了新功能或变得越来越流行，那该怎么办？这种对供应商锁定的担心可能会导

致项目开始时间的延后，因为团队花费大量的时间来评估平台及其技术。

7.2 可移植性的代价

追求应用的可移植性往往是要付出代价的，如果是一个大型的应用程序，那这个代价还

不小。使应用具有可移植性，即应用具备部署在多平台或私有数据中心内的能力可能是

需求的一部分。如果真的如此，那么了解对应的代价和潜在的牺牲就很重要了。业务团

队需要考虑到这些代价，并且能够将可移植性和其他功能放在一起排列优先级，然后决

定是否值得付出这样的代价。如果业务团队还是觉得真的需要可移植性，那么就一定要

明确知道这样做对运营成本和产品上市时间的影响。很可能可移植性的需求跟需要额外 ...