微服务架构中职能团队的划分_将团队转移到微服务架构的3个技巧

微服务架构中职能团队的划分

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

在下面，您会发现CTO和项目负责人在反思他们在团队文化和微服务方面的经验时提供的关键建议和见解。

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

当我与Java开发人员一起工作时，阵营内部一直在紧张地讨论谁可以使用最新和最丰富的功能。 我们的工程领导者决定，我们将完全使用Java来构建所有新的微服务。

做出此决定的理由很充分，但正如我将在后面解释的那样，这种限制性决定会带来一些影响。 交流技术决策的“为什么”可以大大有助于营造一种让人感到包容和了解的文化。

这种困境以及许多其他类似的困境导致首席技术官问自己一些问题，例如：在采用新技术时，我的团队应该给我多少自由？ 也许甚至更重要的是，我如何管理自己营地中的总体文化？

给每个团队成员一个成长的机会

当上面示例中的工程负责人认为Java是构建微服务时使用的最佳技术时，该决定对公司来说是最佳的：Java具有卓越的性能，并且团队中的许多高级人员都精通Java。 但是，并非团队中的每个人都有Java经验。

问题是，我们的团队被分为两个阵营：Java专家和JavaScript专家。 随着时间的流逝和令人振奋的新项目的到来，我们总是希望Java能够完成工作。 不久之后，JavaScript阵营中的一些烦恼就蔓延到了：“为什么Java的人总是总是在激动人心的新项目上工作，而我们却被遗忘了执行诸如实施第三方分析工具之类的平凡的前端任务？ 我们也希望有一个令人兴奋的大型项目！”

像大多数裂口一样，它开始时很小，但随着时间的流逝变得越来越糟。

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

当然，您需要一些结构，但是如果您过于严格-或更糟糕的是，对团队成员使用不同技术进行创新的渴望视而不见-您可能需要管理一些困难。

因此，请仔细评估您的团队，并制定出一项计划，赋予所有人权力。 这样，您团队中的每个部门都可以参与重大项目，没有人会觉得自己被摆在了替补席上。

技术选择：稳定性与灵活性

假设您雇用了一个新的初级开发人员，他对某些全新的，现成JavaScript框架感到兴奋。

该框架虽然具有一些技术突破，但可能尚未在生产环境中得到证明，并且可能没有强大的支持。 CTO必须做出艰难的选择：这样做是为了提高团队士气，或者是为了保护公司及其底线并在截止日期临近时保持项目稳定而拒绝这样做。

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

技术自由

“在考虑技术选择时，我们给我们的团队和我们自己100％的自由。 我们最终确定了两个或三个技术不到底使用，主要是因为不希望我们的部署复杂的故事，说：” 本杰明·柯蒂斯 ，联合创始人Honeybadger 。

“换句话说，我们在创建我们的微服务时考虑将新的语言和新方法引入我们的技术堆栈中，而实际上我们确实在某一时刻将生产微服务部署到了不同的堆栈中。 [虽然我们通常会这样做]坚持使用我们已知的技术以简化操作堆栈，但我们会定期重新做出该决定，以了解采用新技术是否会获得潜在的性能或可靠性优势，但是到目前为止，我们尚未做出改变。”柯蒂斯继续说道。

当我与PubNub的首席技术官Stephen Blum 交谈时 ，他表达了类似的观点，几乎欢迎任何能减少芥末味的技术：“我们对此持完全开放的态度。 我们希望继续推动可用的新开源技术的发展，并且我们团队中只有两个非常公平的约束条件：[它必须在容器环境中运行，并且必须具有成本效益。 ”

高自由度，高责任感

Sumo Logic的 CTO Christian Beedgen和首席架构师Stefan Zier在此主题上作了扩展，并同意，如果您要给开发人员自由选择其技术的权利，则必须附带高度的责任感。 “（无论谁构建）软件都必须拥有全部所有权，这一点非常重要。 换句话说，他们不仅可以构建软件，而且还可以运行软件并对整个生命周期负责。”

Beedgen和Zier建议实施类似于联邦政府系统的系统，并通过提高责任感来控制这些自由：“ [您确实需要]一种联邦文化。 您必须拥有一个系统，多个独立的团队可以团结起来朝更大的目标迈进。 这在一定程度上限制了单位的独立性，因为他们必须同意可能存在某种联邦政府。 但是在那些较小的小组中，他们可以根据更高级别的准则自行决定做出多少决定。”

分散的，联邦的或由您自己设计的这种微服务团队构建方法为每个团队和每个团队成员提供了他们想要的自由，而又没有任何人能够将项目拉开。

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

限制技术以简化事情

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

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

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

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

尽管Frey对希望引入一种新语言的开发人员表示同情，但他承认他“喜欢尝试新事物的想法”，但他感到弊端仍然超过了优点。

拥有多语言架构会增加开发和维护成本。 如果一切都一样，那么您可以专注于业务价值和业务功能，而不必在服务运行方式上过分孤立。 我认为不是每个人都喜欢这个决定，但是在一天结束时，当他们不得不在周末或半夜修理一些东西时，他们会很感激。”弗雷说。

集中式或分散式组织

团队的结构也会影响您的微服务工程文化，无论好坏。

例如，软件工程师通常在将代码交付给运营团队之前编写代码，然后由运营团队将其部署到服务器上。 但是，当事情破裂（事情总是破裂！）时，就会发生内部冲突。

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

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

如您所见，这是一种注定要不断发生冲突的关系。

应对冲突

解决此问题的一种方法是效仿Netflix和Amazon的领导，两者都赞成分散式治理。 软件开发思想领袖詹姆斯·刘易斯（James Lewis）和马丁·福勒（Martin Fowler）认为，在微服务团队组织方面，去中心化治理是必经之路，正如他们在博客文章中所解释的那样。

“集中治理的后果之一是倾向于在单一技术平台上实现标准化。 经验表明，这种方法是束手无策的-不是每个问题都是钉子，也不是每个解决方案都是锤子。 “也许分散式治理的最高宗旨是亚马逊推广的'构建，运行'精神。 团队负责他们所构建软件的所有方面，包括24/7全天候运行的软件。”

路易斯（Lewis）和福勒（Fowler）写道，Netflix是另一家推动开发团队更高层次责任的公司。 他们假设，由于他们将负责并在以后发生任何问题时都应负责任，因此在开发和测试阶段将更加谨慎，以确保每种微服务都处于良好状态。

他们总结道：“这些想法与传统的集中式治理模型之间的距离尽可能远。”

谁在周末寻呼机值班？

在考虑集中式或分散式文化时，请考虑当问题不可避免地在不合时宜的时候出现时，它如何影响您的团队成员。 分散的系统意味着每个分散的团队对一项服务或一组服务负责。 但这也带来了一个问题：筒仓。

这就是为什么诚实领导铅的弗雷（Frey）不支持分散治理概念的原因之一。

“单个团队负责一项特定服务的模式”是您在微服务体系结构中经常看到的东西。 由于某些原因，我们不这样做。 主要的业务原因是我们希望团队不负责特定的代码，而是负责面向客户的功能。 一个团队可能负责订单处理，因此将涉及多个代码库，但最终的业务结果是，只有一个团队拥有整个端到端的资产，因此遇到的漏洞更少。”弗雷解释道。

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

Amazon Web Services容器服务的开发倡导者Nathan Peck 更深入地解释了此问题 。 本质上，当您将软件工程师和运营工程师分开时，每当代码出现问题时，您的团队就会变得更加辛苦-这对于最终用户来说也是个坏消息。

但是权力下放是否需要导致分离和仓促化？

Peck解释说，他的解决方案在于DevOps ，该模型旨在通过使这两个团队更紧密地联系在一起，从而在此过程中加强团队文化和沟通，从而加强反馈循环。 Peck将其描述为“构建，运行”的方法。

但是，这并不意味着团队就不必像在Frey看来可能会发生的那样，远离完成某些任务的距离。

佩克写道：“权力下放治理最有效的方法之一就是树立'DevOps'的心态。” “ [采用这种方法]，工程师参与了软件管道的所有部分：编写代码，构建代码，部署最终产品以及在生产中进行操作和监视。 DevOps方式与将开发团队从运营团队中分离出来的较旧模型形成了鲜明的对比，后者使开发团队“遍历”代码向运营团队负责，然后由运营团队负责运行和维护它。

正如Armory首席技术官Isaac Mosquera所解释的那样，DevOps是一种敏捷的软件开发框架和文化，由于Peck所说的几乎所有内容，它正逐渐受到关注。

有趣的是，Mosquera认为这种方法实际上是在面对康韦定律的时候 ：

“设计系统受限制的组织只能产生设计，这些设计是这些组织的沟通结构的副本。” —康威

现在，软件架构取代了通信驱动软件设计，而驱动了通信。 团队不仅在运营和组织上有所不同，而且还需要一套新的工具和流程来支持这种架构。 即DevOps，” Mosquera解释说。

SparkPost工程副总裁Chris McFadden提供了一个有趣的示例，可能值得关注。 在SparkPost，您会发现分散式治理-但您不会发现每服务一个团队的文化。

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

McFadden继续说，这种方法允许任何团队从事从新功能到错误修复到与任何这些服务有关的生产问题的任何工作。 完全灵活，看不到孤岛。

“这也使[团队]在新产品开发方面也更具灵活性，只是因为您没有受到太多限制，而这取决于我们作为公司和工程团队的规模。 我们确实需要保留一些灵活性，”他说。

但是，这里的大小可能很重要。 McFadden承认，如果SparkPost更大，那么“那么拥有一个更大的团队拥有这些微服务之一就更有意义了。”

“我认为，对这些服务承担更多的责任是更好的选择，它给您带来更多的灵活性。 至少对于我们这个组织而言，这对我们来说是行得通的。”他说。

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

在技​​术方面，有责任的自由似乎是最有意义的途径。 具有不同技术偏好的团队成员会来来去去，而新的挑战可能需要您放弃以前为您服务的技术。 软件开发不断变化，因此，随着新设备，技术和客户的涌现，您需要不断平衡团队的需求。

至于组建团队，尽管存在其他思想流派，但一种分散但不孤立的方法似乎很受欢迎，这种方法利用DevOps并灌输“由您自己构建，由您运行”。 像往常一样，您将不得不进行实验以了解最适合您的团队的情况。

这是关于如何确保您的团队文化与微服务架构完美结合的快速概述：

• 保持可持续发展，但保持灵活性 ：平衡可持续发展的同时，不要忘记灵活性以及在正确的机会到来时团队创新的需要。 但是，关于如何实现这种平衡存在截然不同的看法。

• 机会均等 ：不要偏爱团队中的一个部门。 如果您要施加限制，请确保不会从根本上疏远团队成员。 考虑一下您的产品路线图是如何形成的，并预测它将如何构建以及由谁来进行工作。

• 使您的团队结构灵活，负责任 ：分散的治理和敏捷开发是当今的趋势，这是有充分理由的，但是不要忘记在每个团队中树立责任感。

接下来要读什么

翻译自: https://opensource.com/article/18/8/microservices-team-challenges

微服务架构中职能团队的划分