将你的团队迁移到微服务架构的 3 个技巧

微服务越来越受欢迎，并为科技公司改进终端用户服务提供了新的方法。但是，向微服务转变对团队文化和士气有什么影响？当最佳技术选择是转向微服务时，CTO、开发人员和项目经理应该考虑哪些问题？

在下面，您将找到来自 CTO 和项目主管的关键建议和见解，他们反思了他们在团队文化和微服务方面的经验。

没有成功的团队文化，你就无法构建成功的微服务

当我和 Java 开发人员一起工作时，阵营内部对谁可以从事最新和最重要的功能存在紧张关系。我们的工程领导层决定，我们将专门使用 Java 构建所有新的微服务。

这个决定有很好的理由，但正如我稍后将解释的那样，这样一个限制性的决定会带来一些影响。沟通技术决策的“原因”可以大大有助于创建一个人们感到被包容和知情的文化。

当您围绕微服务组织和管理团队时，平衡情绪、士气和整体文化始终具有挑战性。在大多数情况下，领导层需要平衡团队成员使用新技术的风险与客户和企业自身的需求。

这种困境以及许多其他类似困境导致 CTO 自问以下问题：在采用新技术方面，我应该给我的团队多少自由？也许更重要的是，我如何管理我阵营内的总体文化？

给每个团队成员一个蓬勃发展的机会

当上面示例中的工程领导者决定 Java 是构建微服务的最佳技术时，该决定对公司来说是最好的：Java 性能良好，并且团队中的许多资深人士都精通它。但是，并非团队中的每个人都有 Java 经验。

问题是，我们的团队分为两个阵营：Java 阵营和 JavaScript 阵营。随着时间的推移，令人兴奋的新项目不断涌现，我们总是会求助于 Java 来完成工作。不久之后，JavaScript 阵营中出现了一些恼火情绪：“为什么 Java 伙计总是能从事令人兴奋的新项目，而我们却只能做像实施第三方分析工具这样的平凡的前端任务？我们也想从事一个大型的、令人兴奋的项目！”

像大多数裂痕一样，它开始时很小，但随着时间的推移变得更糟。

我从那次经历中学到的教训是，在为你的微服务选择事实上的技术栈以及调整团队选择工具的自由程度时，要考虑团队的专业知识和偏好的技术。

当然，你需要一些结构，但是如果你过于限制——或者更糟，对团队成员使用不同技术进行创新的愿望视而不见——你可能会有自己的裂痕需要管理。

因此，密切评估你的团队，并制定一项授权所有人的计划。这样，你团队的每个部门都可以参与到重大项目中，没有人会觉得自己被冷落了。

技术选择：稳定 vs. 灵活性

假设你聘请了一位新的初级开发人员，他对一些全新的、刚发布的 JavaScript 框架感到兴奋。

该框架虽然具有一些技术突破，但可能尚未在生产环境中证明自己，并且可能没有很好的支持。CTO 必须做出艰难的选择：为了团队的士气而批准该举动，还是为了保护公司及其底线并在截止日期临近时保持项目稳定而拒绝它。

答案取决于许多不同的因素（这也意味着没有唯一的正确答案）。

技术自由

“我们在考虑技术选择时给予我们的团队和我们自己 100% 的自由。我们最终确定了最终不使用的两到三种技术，主要是因为不想使我们的部署故事复杂化，”Benjamin Curtis，Honeybadger 的联合创始人说。

“换句话说，我们考虑在创建微服务时将新语言和新方法引入我们的技术栈，并且我们实际上确实在一个不同的栈上部署了一个生产微服务。[虽然我们通常]坚持我们知道的技术以简化我们的运维栈，但我们会定期重新审视该决定，看看采用新技术是否会获得潜在的性能或可靠性优势，但到目前为止我们还没有做出改变，”Curtis 继续说道。

当我与 Stephen Blum，PubNub 的 CTO 交谈时，他表达了类似的观点，欢迎几乎任何能胜任的技术：“我们对此完全开放。我们希望继续推进可用的新开源技术，我们对团队只有几个非常公平的约束：[它]必须在容器环境中运行，并且必须具有成本效益。”

高度自由，高度责任

Sumo Logic CTO Christian Beedgen 和首席架构师 Stefan Zier 扩展了这个话题，他们都认为，如果你要给予开发人员选择技术的自由，那么它必须附带高度的责任。“[构建软件的人]对它承担全部所有权非常重要。换句话说，他们不仅构建软件，而且还运行软件并对整个生命周期负责。”

Beedgen 和 Zier 建议实施一个类似于联邦政府系统的系统，通过提高责任感来控制这些自由：“[你需要]一种联邦文化，真的。你必须有一个系统，多个独立的团队可以为了更大的目标走到一起。这在一定程度上限制了单位的独立性，因为他们必须同意可能存在某种形式的联邦政府。但是在这些较小的群体中，他们可以在更高层次上建立的指导方针内自行做出尽可能多的决定。”

分散式、联邦式，或者无论你如何定义它，这种构建微服务团队的方法都赋予了每个团队和每个团队成员他们想要的自由，而不会使任何人将项目拆散。

但是，并非所有人都同意。

限制技术以简化事情

Darby Frey，Lead Honestly 的联合创始人，对技术选择采取了更严格的方法。

“在我上一家公司，我们有很多服务和一个相当小的团队，使其能够运行的主要因素之一，特别是对于我们拥有的团队规模而言，是每个应用程序都是相同的。每个后端服务都是一个 Ruby 应用程序，”他解释说。

Frey 解释说，这有助于简化他的团队成员的生活：“[每个服务都有]相同的测试框架、相同的数据库后端、相同的后台作业处理工具等等。一切都一样。

“这意味着当工程师在应用程序之间跳转时，他们不必每次都学习新的模式或学习不同的语言，”Frey 继续说道，“因此我们非常清楚并且非常严格地保持这种通用性。”

虽然 Frey 同情想要引入新语言的开发人员，承认他“喜欢尝试新事物的想法”，但他认为缺点仍然大于优点。

“拥有多语言架构可能会增加开发和维护成本。如果一切都相同，你可以专注于业务价值和业务功能，而不必在服务运营方式上过于孤立。我不认为每个人都喜欢这个决定，但归根结底，当他们不得不在周末或半夜修复某些东西时，他们会感激它，”Frey 说。

集中式或分散式组织

你的团队结构也将影响你的微服务工程文化——无论是好是坏。

例如，软件工程师通常会在将代码发送给运维团队之前编写代码，运维团队反过来将其部署到服务器。但是当出现问题时（问题总是会出现！），就会发生内部冲突。

因为运维工程师自己不编写代码，所以当问题第一次出现时，他们很少理解问题。因此，他们需要与编写代码的人联系：软件工程师。因此，从一开始，你就有了一个中间人，在问题和可以解决该问题的团队之间传递消息。

为了增加额外的复杂性，因为软件工程师不参与运维，他们通常无法完全理解他们的代码如何影响平台的整体运行。他们只有在运维工程师抱怨时才知道问题。

正如你所看到的，这种关系注定会不断冲突。

应对冲突

解决这个问题的一种方法是效仿 Netflix 和 Amazon 的领导，这两家公司都赞成分散式治理。软件开发思想领袖 James Lewis 和 Martin Fowler 认为，当涉及到微服务团队组织时，分散式治理是正确的方法，正如他们在 博客文章 中解释的那样。

“集中式治理的后果之一是倾向于在单一技术平台上标准化。经验表明，这种方法是限制性的——并非所有问题都是钉子，并非所有解决方案都是锤子，”文章写道。“分散式治理的顶峰也许是亚马逊推广的‘构建它，运行它’的精神。团队负责他们构建的软件的所有方面，包括 24/7 运行软件。”

Lewis 和 Fowler 写道，Netflix 是另一家对开发团队施加更高责任的公司。他们假设，因为他们将负责并在以后出现问题时被召唤，所以在开发和测试阶段将更加谨慎，以确保每个微服务都处于良好状态。

“这些想法与传统的集中式治理模式相去甚远，”他们总结道。

谁在周末值班？

在考虑集中式或分散式文化时，请考虑当问题不可避免地在不适当的时间出现时，它如何影响你的团队成员。分散式系统意味着每个分散式团队都负责一项服务或一组服务。但这也会产生一个问题：孤岛。

这就是 Lead Honestly 的 Frey 不赞成分散式治理概念的原因之一。

“‘单个团队负责特定服务’的模式在微服务架构中很常见。我们不这样做，原因有几个。主要业务原因是我们希望团队负责的不是特定的代码，而是面向客户的功能。一个团队可能负责订单处理，因此这将涉及多个代码库，但对业务的最终结果是有一个团队拥有端到端的整个过程，因此可以减少问题的遗漏，”Frey 解释说。

他继续说，另一个主要原因是开发人员可以更多地拥有整个项目的所有权：“他们实际上可以从整体上考虑[项目]。”

亚马逊网络服务容器服务开发人员倡导者 Nathan Peck 在 更深入地解释了这个问题。本质上，当你将软件工程师和运维工程师分开时，每当代码出现问题时，你都会让你的团队生活更加艰难——这对终端用户来说也是坏消息。

但是，分散化是否必然会导致分离和孤岛化？

Peck 解释说，他的解决方案在于 DevOps，这是一种旨在通过拉近这两个团队之间的距离来加强反馈循环的模型，从而加强团队文化和沟通。Peck 将此描述为“你构建它，你运行它”的方法。

但是，这并不意味着团队需要被孤立或远离参与某些任务，正如 Frey 建议可能发生的那样。

“分散式治理最有效的方法之一是建立‘DevOps’的心态，”Peck 写道。“[使用这种方法]，工程师参与软件管道的所有部分：编写代码、构建代码、部署生成的产品以及在生产中运营和监控它。DevOps 方式与旧的将开发团队与运维团队分离的模型形成对比，旧模型由开发团队将代码‘越过围墙’运送到运维团队，然后运维团队负责运行和维护它。”

正如 Armory CTO Isaac Mosquera 解释的那样，DevOps 是一种敏捷软件开发框架和文化，由于——嗯，几乎 Peck 所说的一切，它正在获得关注。

有趣的是，Mosquera 认为这种方法实际上与 康威定律 背道而驰

“设计系统的组织……受限于生成的设计，这些设计是这些组织沟通结构的副本。”— M. 康威

“现在不是沟通驱动软件设计，而是软件架构驱动沟通。团队不仅以不同的方式运营和组织，而且它还需要一套新的工具和流程来支持这种类型的架构；即 DevOps，”Mosquera 解释说。

Chris McFadden，SparkPost 的工程副总裁，提供了一个可能值得效仿的有趣示例。在 SparkPost，你会发现分散式治理——但你不会发现一个团队对应一个服务的文化。

“开发这些微服务的团队最初是一个团队，但他们现在在同一个更大的小组下分为三个团队。每个团队在某些领域和某些专业知识方面都有一定程度的责任，但这些服务的所有权并不局限于这些团队中的任何一个，”McFadden 解释说。

McFadden 继续说，这种方法允许任何团队处理与任何这些服务相关的新功能、错误修复到生产问题。有完全的灵活性，而且没有孤岛。

“它允许[团队]在新产品开发方面更灵活一些，仅仅是因为你没有受到太多限制，这基于我们作为一家公司和作为一个工程团队的规模。我们真的需要保留一些灵活性，”他说。

但是，规模可能很重要。McFadden 承认，如果 SparkPost 的规模大得多，“那么让一个更大的团队拥有其中一个微服务会更有意义。”

“[我认为]，对这些服务承担更广泛的责任更好，并且它给你更多的灵活性。至少这对我们目前的组织来说是有效的，”他说。

成功的微服务工程文化是一种平衡

在技术方面，自由——伴随着责任——看起来是最有益的道路。具有不同技术偏好的团队成员会来来往往，而新的挑战可能需要你放弃以前为你服务良好的技术。软件开发不断变化，因此当新的设备、技术和客户出现时，你需要不断平衡团队的需求。

至于构建你的团队，分散式但非孤岛式的方法，利用 DevOps 并灌输“你构建它，你运行它”的心态似乎很受欢迎，尽管也存在其他思想流派。像往常一样，你将不得不进行实验，看看哪种最适合你的团队。

以下是如何确保你的团队文化与微服务架构良好融合的快速回顾

• 保持可持续性，但也要灵活：在不忘记灵活性以及团队在合适的机会来临时进行创新的需求的情况下，平衡可持续性。但是，关于你应如何实现这种平衡存在明显的意见分歧。

• 提供均等的机会：不要偏袒你团队的某个部门。如果你要施加限制，请确保它不会从一开始就从根本上疏远团队成员。考虑一下你的产品路线图是如何形成的，并预测它将如何构建以及谁将完成这项工作。

• 将你的团队构建得敏捷而负责：分散式治理和敏捷开发在今天很流行是有充分理由的，但不要忘记在每个团队内部安装责任感。