本文作者：
张沙沙云解决方案专家级咨询师
王妮中国区欧洲事业线技术负责人
在上一篇文章（跨国企业云迁移：不止于技术）当中，我们论述了对于跨国企业来说，频繁被提及的“云迁移”不是一个技术问题，它起源于快速启动阶段的可用性问题，落地于更深层次的数字化能力本土化，旨在帮助跨国企业适应国际及中国大环境，从而保证其在华业务的连续性；因此，从本质上讲，云迁移是一个更大在华战略的技术体现，那么此时作为技术人员，该如何定义技术侧的策略目标呢？我们认为答案是平台中立。
平台中立
站在技术角度，跨国企业想要适应国际及中国大环境需要做到以下几点：
- 业务系统能够被部署到不同的环境当中，这里的环境既包括云服务环境，也包括各式各样的 on-prem 环境。因为结合中国国情，仍然有相当一部分商业软件因法律或安全问题需要被部署到 on-prem 环境当中。
- 业务系统能够快速并有效地向中国模式扩展。中国模式包含外在用户体验、中层商业模式、里层运营模式。此时就需要承载企业核心竞争力的业务系统有足够的适应性，一方面是为了符合国内用户的使用习惯，带来更好的用户体验，另一方面也是为了打通其在中国的商业和运营模式。
- 业务系统所依赖的外部组件要能够以较低的成本被替换，这样才能更好的支撑上面两项能力。
这三项能力最终指向的是系统的可移植性(Portability)，即可安装性(Installability)、适应性(Adaptability)、可替换性(Replaceability)。因此平台中立实际上是：通过提高系统可移植性以帮助跨国企业在不牺牲用户体验和业务能力的前提下快速将业务系统扩展至一个全新的技术和商业环境当中。
我们认为平台中立的实现包括三个方面：架构中立、平台工程、跨地区运营。上篇文章中我们对跨地区运营的必要性进行了简单的阐述，考虑到该问题的复杂性我们将在后续文章中单独阐述其解决思路，本文将重点介绍架构中立和平台工程。
架构中立
《Enterprise Architecture as Strategy》对企业 IT 的经营模式进行了分析，发现它存在两个维度：标准化（Standardization）和整合（Integration），并由此分析得出四类不同的 IT 经营模式：复制（Replication），差异（Diversification），协作（Coordination），统一（Unification）。
跨国企业扩展中国业务的过程追求速度和敏捷度，这对标准化提出了较高要求，同时根据国内业务独立性的不同，也会对数据整合提出要求，因此根据跨国企业在华业务的独立性不同，其 IT 经营模式一般会向复制和统一两个方向演进，即加强标准化并视情况完成数据整合。
图片来源网络
因此架构中立侧重于技术选型、基础设施、技术架构、数据、业务流程的标准化，以支撑企业 IT 运营模式的转型。这里我们以云服务的选型为例，说明实现架构中立的思路：成本左移、标准化指引、小成本架构改造优先。
成本左移
可移植性的另一面是“退出成本”，而在各类技术和平台唾手可及的当下，很少有人会在前期考虑退出成本。想要提高可移植性，需要将成本左移，通过增加设计成本来降低退出成本。就云选型来说，云厂商提供的服务集有三类：
- IaaS（基础设施即服务）：提供计算、存储和网络资源，用户可以根据需要租用资源，以搭建和管理自己的应用和服务。
- PaaS（平台即服务）：提供开发环境和运行环境，用户可以在其上快速构建应用，而无需关注底层基础设施；
- SaaS（软件即服务）：提供完整的应用程序，用户可以直接使用，无需安装、配置；
其中 IaaS 层的通用性最高，越往上云厂商特色化差异越大，对于架构中立的实现越有挑战。因此从提升可移植性角度出发的建议是：广泛采用 IaaS，灵活使用 PaaS，谨慎使用 SaaS，以使架构保持足够中立。
需要注意的是，成本左移并不是通用的（一些期望快速实现业务验证、市场证明的场景中，速度至上，成本并不是重要的考量因素），因为它有一个前置条件：系统将会面临退出现有技术选型的问题，并且其退出成本大于前期快速启动的收益。再回到云选型，更为有效的提升可移植性的建议是：从退出成本、业务重要程度两个角度考虑，避免“业务重要程度高”+“云能力退出成本高”和“业务重要程度低”+“云能力退出成本低”的情况出现。
标准化指引
架构方案的执行不是一锤子买卖，站在治理的角度，构建标准化指引，并文档化显得非常重要。套用技术雷达的方法，拿云选型来举例
- 将具备更通用能力、能够以较小退出成本迁出的云服务标识为“采纳”，团队可直接采用该服务；
- 将通用性较弱、需要一定成本迁出的云服务标识为“谨慎”，团队在选型时需要经过架构组讨论，从业务重要程度和迁出成本间的平衡来论证采用该服务的必要性；
- 将通用性差、迁出成本很高的云服务标识为“不推荐”，一般情况下团队不得采用该服务。
小成本架构改造优先
架构中立并不建议企业大刀阔斧的改造现有系统架构，对于既有系统，总体原则是结合企业实际情况，以小成本架构改造优先的方法逐步完成架构迁移。这里以云服务适配为例，说明两类程度不同的改造方式。
基于 Translator 的架构中立改造方式
以系统原有云厂商的依赖为主，基于新的系统运行环境提供适配。举例来说，原有数字化系统构建于 GCP 上，依赖了 firebase 这样的 PaaS 服务，既可以提供 NoSQL 式的数据存储、也可以基于 stream 的方式对前端进行通知推送，在中国市场，原有数字化系统需要构建在阿里云上，在 Translator 的模式下，以原有 GCP SDK 中定义的接口为标准实现，基于阿里云的 PaaS 能力对相应实现进行翻译，从而提供功能。
此种模式成本较小，但稳定性较低，对于系统复杂度较低、需要快速迁移的系统可以优先选择。
Generic wrapper 的架构中立改造方式
以构建企业自身标准化能力为主，无论是消息中间件、数据库、通知、认证等基于业务诉求抽象标准能力接口，借助公有云提供商提供的能力对接口进行实现。
此种模式成本较高，改动较大，对于无法采用 translator 方式的系统可以考虑采用该模式。此类模式的优势也很明显，稳定性高，一次性提成系统整体可移植性，从根本上降低了系统的迁出成本。
平台工程
为什么需要平台工程？
架构中立可以提高系统可移植性，帮助有效完成系统迁移，但想要保障系统迁移的效率，平台工程不可避免，因为跨国部署和运营为团队带来了很大的挑战。
可互操作性降低，架构复杂度直线上升
云服务提供商是期望实现供应商锁定的，为此他们在看待技术趋势，解决问题的思路等方面都有很大的差异。不同云服务提供商之间没有产品构建的共同标准，这使得它们的可互操作性很低，这种差异可能是相同类型不同产品之间的差异，也可能是同种产品之间的差异。
以消息队列为例，GCP 的 PubSub 继承了 Kafka 的水平扩展能力和 ActiveMQ/ RabbitMQ 这类传统消息队列的功能特性，而同样的选型在阿里云上没有1:1 的替代品，在消息的推送模式、消息超时时间、超时处理机制方面也有所差异。即便是同样的 RabbitMQ 产品，阿里云版本与开源版本也有功能层面比较大的差异1。
研发团队在进行数字化系统架构设计时，不仅要考虑技术组建如何更好得支撑业务场景，也要将技术组建本身的差异作为约束考虑进去。
云原生开发技术让团队的认知成本增加
云原生研发过程中，研发团队从业务功能研发到部署上线需要掌握的知识很多。
- 云原生时代，微服务架构变成了企业的常用架构。研发团队既要掌握 Golang/Java 这样的主流开发语言，又要熟悉领域驱动设计这样的方法论，让代码处于简单、易维护的状态，还要明白不同云产品的特性以及正确使用的方法;
- 代码写完之后，需要经过流水线的层层检测，最终变为标准制成品。这一路既要掌握不同的测试策略、测试方法，也要掌握 pipeline as code 这样的实践，设计并合理实现能够保证交付质量的持续集成流水线;
- 制成品产出之后，需要部署到不同的研发环境中。研发环境通常会使用 terraform 这样基础设施即代码的管理工具进行初始化和变更，也会需要 k8s 这样的容器编排工具来实现不同的部署策略、支撑不同的非功能性诉求;
- 产品上线之后并不是一切的终结，线上监控、预警，系统稳定性、安全性的提升……
上面的内容只是研发团队需要关注内容的冰山一⻆，要完成高质量数字化系统的构建，做到这些只是基线。这样高的认知负载，久而久之让研发团队的动作变形，雪花服务器、临时变更处处皆是，产生了很多隐性知识和上下文。于是，团队中初级开发人员忙于功能开发，高级开发人员忙于帮助初级开发人员解决构建、部署的问题，bug 层出不穷，团队手忙脚乱。
多云治理(安全与成本)
云治理本身就是一个复杂范畴，使用云计算对于很多企业而言，投入、产出比本身就是一个难题，大多数企业是奔着节约成本的目的开启云征程的，但在完成云迁移之后却往往发现成本不降反增。使用多云之后，治理就更加复杂，不同云服务提供商建模方式不同，很难给企业提供统一视图。
平台工程的实施原则
平台工程是设计和构建工具链和工作流的学科，由内部平台团队主要负责，通过自服务的平台的建设为交付团队提供便利。企业在实施自己的平台工程，应当遵循以下原则。
固化知识，增加不同云服务提供商的可互操作性
- 以应用为核心，为来自不同云厂商的云产品抽象标准能力层，让云产品本身的差异化对研发团队透明，参考 OAM 这样的标准；
- 打造自服务的 API，封装底层 CI/CD 技术细节的同时给研发团队提供最大程度的操作空间；通过封装底层 CI/CD 技术细节，降低研发团队学习成本；而自服务的 API 则可以赋予研发团队最大程度创建和配置资源的能力，避免基于保修单运维过程中带来的延迟和摩擦；
- 提供更健壮的跨功能性特性2，如可观测行、高可用、高性能等等，通过架构适应度函数的方式帮助研发团队更好得提升产品的质量，让研发团队更加专注于业务价值的塑造;
设立专有且目标清晰的平台团队推进平台工程，避免强度高但是优先级不明确的混杂平台团队3
平台团队应当以“服务”的方式与流动式团队协作，使研发团队能够以高度自治的方式交付工作为主要目的。研发团队在生产环境中拥有构建、运维、修复应用的所有权限。平台团队提供内部服务使得研发团队无须关注底层服务。
将产品思维融入平台工程
- 将研发团队的开发者体验作为首要考虑目标，与研发团队密切协作，理解研发团队的需求，而非一味盲目追求技术先进性；
- 依赖于快速原型技术，尽早引入研发团队成员以获得快速反馈，了解哪些有效哪些无效；按创新扩张曲线的过程将新服务逐步引入到流动式团队中去；
- 关注企业内部实质性问题，避免过分在工具链选择上投入精力；
小结
无论是架构中立、平台工程，还是我们尚未谈及的跨地区运营，它们都是帮助企业适应并深耕中国市场的技术支撑。根据我们的经验，不同的业务目标和实际情况，实施重点和深度会有不同，但这三者相辅相成、缺一不可。本文以最常被提及的云迁移和多云为例，阐述了架构中立和平台工程的实施原则，我们将会在后续的文章中分享更多的场景和案例。
1 阿里云版本 RabbitMQ 与开源版本 RabbitMQ 功能对比，https://help.aliyun.com/document_detail/188208.html
2 跨功能性特性 https://en.wikipedia.org/wiki/Non-functional_requirement
3 混杂平台团队 https://www.thoughtworks.com/zh-cn/radar/techniques/miscellaneous-plat-form-teams
