避免不完全的云原生

本文最初发布于 The Startup 博客，经原作者授权由 InfoQ 中文站翻译并分享。

在我的工作中，最令人沮丧的一部分是对失败的云采用项目进行事后分析。这种情况经常发生；我们被叫到客户那里，帮助他们弄清楚，为什么他们采取了上云的步骤却没有达到预期。在这种情况下，我能做的最重要的事情就是保持冷静，帮助客户根据事实而不是臆测得出结论。我经常会看到，导致这些失败的一个最常见的问题是，团队并没有实现完全的云原生转型，他们只是走了这个过程中的一段路，并且在到达那里之前就停下了。

可以这样说，云原生并不像一个架构的描述（虽然肯定有云原生和非云原生架构），因为作为一个整体，它既描述了一组架构决策，也描述了支持这种架构所需的流程和组织决策。技术决策是必要的，但对于团队来说，要成功地构建、特别是管理和维护云原生系统，仅有技术决策是不够的。为了取得成功，你需要协调以下三类决策。

技术——这些（相对而言）是比较容易做出的决策，包括采用微服务方法、编写组件，以便实现水平扩展，充分利用开源技术，从而从社区的成果获益。但是，每一项决策都伴随着相应的流程和组织决策，它们是技术决策的基础。

团队组织——微服务意味着你在小型自治团队中构建服务。这是康威法则的简单应用——如果你希望系统是由小的、解耦的组件组成，那么你就要保证团队也很小，而且不与其他团队紧密耦合——与团队之间的松散关系相呼应的架构方法，只允许正式进程间通过 API 通信。

流程——微服务意味着你正在将 DevOps 原则应用到开发流程中，比如持续集成和持续交付。但这本身需要你采用其他专门的技术流程，如自动化测试，并把你导向基于主干的开发。事实上，如果你首先采用像测试驱动开发和结对编程这样的开发实践，那么采用那些实践将变得容易很多。

当一家公司试图越过其中的一项时，问题就来了——如果你敲掉凳子的一条腿，整个凳子就会倒下来。例如，当公司告诉我们，他们正在构建多个“微服务”，同时他们也在运用 SaFE 方法来管理结果系统的的多个发布序列的异常复杂的交互时，如果我们看到一个常见问题，就表明有一个更大的问题。你无法两者兼得；这会弄巧成拙。

如果你的设计需要多个复杂的发布序列，那么你可能违背了微服务的其中一项关键原则，即每个微服务的 DevOps 管道应该保持彼此独立（或者至少尽可能地独立）。此外，这种协调还表明，你的系统耦合性超出了正常水平，所以你才需要这种程度的协调。更重要的是，需要这种协调意味着你的团队并不是真正自治的——你可能只是把一个大团队任意分成小块，而没有给予他们真正的自治。

对于这方面的考虑，我们通常还可以追溯到 IT 和业务之间的互动。这从下图中可以看到：

图 1：云原生方法需要技术、组织和流程的变革

采用云原生开发方法（如微服务）的唯一原因是，团队能够以增量的方式交付可度量的业务价值单元。但是，如果你的业务不能这样做——不能从小型业务价值单元（可以在一段时间内独立交付）的角度来考虑，那么事实上，微服务架构以及其余大部分云原生方法，都不会有太多的价值。

因此，每当我看到不完全的转型时，我的第一个想法就是与业务和 IT 负责人一起坐下来，问问他们对采用云有什么期望。通常你会发现，人们的期望差别很大。例如，在“IT 主导”的转型工作中，你有时会看到业务被排除在转型工作之外——事实上，他们不仅应该有一席之地，而且应该主导这项工作。其中一个征兆出现在我问敏捷团队产品负责人向谁汇报时——如果是 IT 部门的人，那么我们可能会有问题，因为业务并没有像他们应该做的那样深入地参与进来。但这并不是转型不完全的唯一征兆。下面是其他一些征兆：

1. 如果你仍然有一个架构委员会审批设计，或者一个变更控制委员会审批所有发布，那么你并没有真正授予团队完全的自主权。你应该制定指导方针，然后确保团队遵照指导方针开展工作。

2. 如果不能快速构想和测试你的业务假设（通过 A/B 测试），那么你就不能获得云计算承诺的潜在业务成果。这一切都取决于业务和 IT 之间紧密的互动循环。

还有许多其他的例子可以说明，团队可能会因为不完全的转型而失败；太多了，我就不列举了。我要向托尔斯泰道歉，“所有成功的转型是相似的；所有失败的转型各有各的失败。“你只需要坚持基本原则，保证做好这三个方面的工作，并与业务保持一致，但要做到这一点并不容易。为了实现完全的转型，你必须在每个阶段不断地回顾这些基本原则。

那么，你能采取哪些积极的行动来确保自己彻底地完成转型，而不是中途停下来呢？回到这些基本原则到底意味着什么？

1. 在组织方面，第一步也是最大的一步是建立小型团队（例如双披萨团队），并授予他们自主权，让他们自己做出技术决策，并确保他们有一个专门的产品负责人，他可以自己做出业务决策。这些决策应该在一定范围内做出，但这是最大的一步。许多团队（包括我们的团队）发现，像 Spotify 模式这样的框架也能帮助更大的团队（如多组双披萨团队）通过协作组织（如分会、协会和部落）定义这些限制，并在小型团队之间进行协调。

2. 在技术方面，确保团队在做架构选择时能减少跨服务耦合、增加组件内聚性，并确保能够快速轻松地添加特性。这涉及到采用容器或无服务器，并且要保证，在使用像微服务这样的技术时不会通过共享数据库引入“隐式”耦合，并利用所有可以让我们从中获益的架构选项服务，例如，使用同步和异步调用路径。

3. 在流程方面，最重要的步骤是采用敏捷开发方法的技术实践，如Forssgren等人提出的极限编程，这被认为是成功的秘诀。这不仅包括每个服务的 CI/CD，还包括测试驱动开发、结对编程，最重要的是，让团队推动他们自己的敏捷转型。从上至下的敏捷原则和方法训练很好，但是，如果团队是流程所有者，他们的表现会最好。

原文链接：

Avoiding Incomplete Cloud Native Adoption