微服务团队

by Jake Lumetta

杰克·卢米塔(Jake Lumetta)

为什么团队文化对于成功的微服务至关重要 (Why Team Culture is Critical for Successful Microservices)

Developers are increasingly turning to microservices to build and modify individual components independently. Microservices are clearly beneficial from a technical standpoint, but before teams decide to implement microservices, they should consider how creating microservices will impact team culture.

开发人员越来越多地转向微服务来独立构建和修改单个组件。 从技术的角度来看，微服务显然是有益的，但是在团队决定实施微服务之前，他们应该考虑创建微服务将如何影响团队文化。

This article offers advice and insights from CTO’s who have enjoyed the successes and endured the growing pains of implementing microservices, as well as guidance for how to smoothly integrate microservices into your team’s culture.

本文提供了从CTO那里获得的建议和见解，他们享受了成功并忍受了实施微服务的痛苦之苦，并提供了如何将微服务顺利整合到团队文化中的指南。

规则1：没有成功的团队文化，就无法构建成功的微服务。 (Rule 1: You can’t build successful microservices without a successful team culture.)

Back when I was working with Java developers, I remember there being a source of tension within the camp around who got to work on the newest and meatiest features. Our engineering leadership had decided that we would exclusively use Java to build all new microservices.

当我与Java开发人员一起工作时，我记得在营地中围绕着谁来使用最新和最丰富的功能而感到紧张。 我们的工程领导层决定，我们将完全使用Java来构建所有新的微服务。

There were great reasons for this decision, but — as I will explain later — such a restrictive decision came with some consequences in terms of team morale. We learned an important lesson there: to the extent possible, communicating the “why” of a technical decision to the team can go a long way towards creating a culture where people are kept in the loop.

做出此决定的原因很充分，但是-正如我将在后面解释的那样-这种限制性决定会给团队士气带来一些后果。 我们在那里学到了重要的一课：在可能的范围内，向团队传达技术决策的“原因”可以大大有助于建立一种让人们紧贴循环的文化。

When it comes to organizing and managing a team around microservices, it’s always challenging to balance the mood, morale, and overall culture of your team. In most cases, the leadership needs to balance the risk of team members using new technology against the needs of the client and the business itself.

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

This dilemma, and many others like it, has led CTOs to ask themselves questions such as: How much freedom should I give my team when it comes to adopting new technologies? And perhaps even more importantly, how can I manage the overarching culture within my camp?

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

给每个团队成员一个成长的机会 (Give every team member a chance to thrive)

When the engineering leaders mentioned above decided that Java was the best technology to use when building microservices, the decision was really best for the company. Java is performant, and many of the senior people on the team we well versed with it. So that’s why we went with Java. However, not everyone on the team had experience with Java.

当上述工程负责人认为Java是构建微服务时使用的最佳技术时，该决定实际上对公司而言是最佳的。 Java表现出色，我们团队中的许多高级人员都精通Java。 这就是我们选择Java的原因。 但是，并非团队中的每个人都有Java经验。

The problem was, our team was split into two camps: the Java guys, and the JavaScript guys. As time went by, new and exciting projects came up, and we’d always reach for Java to get the job done. Before long, there was some annoyance within the JavaScript camp that crept up.

问题是，我们的团队被分为两个阵营：Java专家和JavaScript专家。 随着时间的流逝，出现了许多令人兴奋的新项目，而我们总是希望Java能够完成工作。 不久之后，JavaScript阵营中就出现了一些烦恼。

“Why do the Java guys always get to work on the exciting new projects, while we’re left to do the mundane front-end tasks like implementing third party analytics tools? We want a big, exciting project to work on, too!”

“为什么Java的人总是总是着手进行令人兴奋的新项目，而我们却不得不做一些平凡的前端任务，例如实现第三方分析工具？ 我们也希望进行一个激动人心的大项目！”

Like most rifts, it started out small but grew worse over time.

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

The lesson I took from that experience was to take your team’s expertise and favored technologies into account when choosing a de facto tech stack for your microservices, as well as when it comes to adjusting the level of freedom you give your team to pick and choose their tools.

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

Sure, you need to have some structure, but if you’re too restrictive — or worse yet, blind to the desire of people in your team to innovate with different technologies — you may have a rift of your own to manage.

当然，您需要具有一定的结构，但是如果您过于严格-或者更糟糕的是，对团队中的人们对使用不同技术进行创新的渴望视而不见-您可能需要管理一些麻烦。

So, evaluate your team closely, and come up with a plan that empowers everyone in your team. That way, every section of your team can get involved in major projects, without anyone feeling like they aren’t being given a chance to thrive.

因此，请仔细评估您的团队，并提出一项使团队中每个人都拥有能力的计划。 这样，您团队中的每个部门都可以参与重大项目，而不会有人觉得自己没有获得发展的机会。

技术选择：稳定性与灵活性 (Technology choices: stability vs flexibility)

One of the biggest issues CTOs and developers have to wrestle with is how much technological freedom to allow developers.

CTO和开发人员必须努力解决的最大问题之一是允许开发人员拥有多少技术自由。

Let’s say you hire a new junior developer. They may be excited about some brand new fresh off the press JavaScript framework. Almost too new.

假设您雇用了一个新的初级开发人员。 他们可能对某些全新JavaScript JavaScript框架感到兴奋。 几乎太新了。

That framework, while sporting some technical breakthroughs, may not have proven itself in production environments, and it most probably doesn’t have great support available. CTOs have the hard choice between okaying that move for the good of morale and excitement within the camp — or declining it to safeguard the needs of the company, to protect the company’s bottom line, and to keep the project stable as the deadline approaches.

该框架虽然取得了一些技术突破，但可能尚未在生产环境中得到证明，并且很可能没有强大的支持。 CTO很难做出选择，既要采取行动以鼓舞士气，又要在训练营内兴奋起来，要么拒绝以维护公司的需求，保护公司的底线，还是在截止日期临近时保持项目稳定。

The right answer depends on a lot of different factors, which also means there is no right answer.

正确答案取决于许多不同因素，这也意味着没有正确答案。

技术自由 (Technological freedom)

Some CTOs and founders fully embrace technological freedom and then allow things to settle naturally on a few technologies that work well when turning to deployment.

一些CTO和创始人完全拥护技术自由，然后让事情自然地落在了一些易于部署的技术上。

“We give our team and ourselves 100% freedom in considering technology choices. We eventually identified two or three technologies not to use in the end, primarily due to not wanting to complicate our deployment story,” said Benjamin Curtis, Co-founder of Honeybadger.

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

“In other words, we considered introducing new languages and new approaches into our tech stack when creating our microservices, and we actually did deploy a production microservice on a different stack at one point. [While we do generally] stick with technologies that we know in order to simply our ops stack, we periodically revisit that decision to see if potential performance or reliability benefits would be gained by adopting a new technology, but so far we haven’t made a change,” Curtis continued.

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

When I spoke with Stephen Blum, CTO at PubNub, he too expressed a similar view in favor of welcoming pretty much any technology that cuts the mustard:

当我与PubNub的首席技术官Stephen Blum 交谈时 ，他也表达了类似的观点，赞成几乎欢迎任何能减少芥末的技术：

“We’re totally open with it. We want to continue to push forward with new open source technologies that are available and we only have a couple constraints with the team that are very fair: must run in container environment and it has to be cost-effective,” Blum said.

“我们对此完全开放。 我们希望继续推动可用的新开源技术的发展，并且我们团队中只有两个非常公平的约束条件：必须在容器环境中运行并且必须具有成本效益，” Blum说。

高自由度，高责任感 (High-freedom, High-responsibility)

Freedom comes with a caveat though: if developers enjoy the fruits of freedom of technology choices, they also need to take ownership of making sure the build works.

但是，自由伴随着一个警告：如果开发人员享受技术选择自由的果实，那么他们还需要拥有所有权以确保构建能够正常进行。

During my interview with Sumo Logic CTO Christian Beedgen and Chief Architect Stefan Zier, they expanded on this topic. They added clout to the position that, if you’re going to give developers freedom to choose their technology, it has to come with a high level of responsibility attached.

在我接受Sumo Logic首席技术官Christian Beedgen和首席架构师Stefan Zier的采访中，他们就此话题进行了扩展。 他们增加了影响力，即如果您要让开发人员自由选择他们的技术，那么它就必须承担很高的责任。

“It’s really important that [whoever builds] the software takes full ownership for it. In other words, they not only build software, but they also run the software and remain responsible for the whole lifecycle,” they said.

“(无论谁构建)软件都必须拥有全部所有权，这一点非常重要。 换句话说，他们不仅可以构建软件，而且还可以运行软件并对整个生命周期负责。”

They continued by explaining that a system that resembles a federal government system should be put into place to help keep those freedoms in check by heightening responsibility.

他们继续解释说，应该建立类似于联邦政府系统的系统，以通过提高责任感来帮助限制那些自由。

“[You need] a federal culture really. You’ve got to have a system where multiple, independent teams can come together towards the greater goal. That limits the independence of the units to some degree, as they have to agree that there is potentially a federal government of some sort. But within those smaller groups, they can make as many decisions on their own as they like within guidelines established on a higher level,” he said.

“ [您确实需要]一种联邦文化。 您必须拥有一个系统，多个独立的团队可以共同实现更大的目标。 这在一定程度上限制了单位的独立性，因为他们必须同意可能存在某种联邦政府。 但是在那些较小的群体中，他们可以根据更高级别的指导方针自行选择做出许多决定。”

Decentralized, federal, or however you wish to frame it, certainly seems to be an attractive approach to structuring microservice teams. It’s an approach that gives each team and each team member the freedom they want — without giving anyone free reign to pull the entire project apart at the seams.

分散的，联邦的，或者您希望构架的框架，肯定是组建微服务团队的一种有吸引力的方法。 这种方法可以为每个团队和每个团队成员提供他们想要的自由，而无需让任何人自由支配以将整个项目分开。

But not everyone agrees.

但并非所有人都同意。

限制技术以简化事情 (Restrict technology to simplify things)

On the other hand, Darby Frey, Co-founder of Lead Honestly, takes a more restrictive approach to technology selection.

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

“At my last company, we had a lot of services and a fairly small team, and one of the main things that made it work, especially for the team size that we had, was that every app was the same. Every backend service was a Ruby app,” he explained.

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

Frey told me how this helped simplify the life of his team, as every service has, “the same testing framework, the same database backend, the same background job processing tool, etc. Everything was the same.”

弗雷(Frey)告诉我，这如何简化了他的团队，因为每个服务都具有“相同的测试框架，相同的数据库后端，相同的后台作业处理工具，等等。一切都相同。”

At the same time, Frey is sympathetic to the concept of developers wanting to introduce a new language, admitting that he “loves the idea of trying new things”. However, he feels that the cons outweigh the pros.

同时，Frey对希望引入一种新语言的开发人员的概念表示同情，并承认他“喜欢尝试新事物的想法”。 但是，他认为弊大于利。

“Having a polyglot architecture can increase the development and maintenance costs. If it’s just all the same, you can focus on business value and business features and not have to be super siloed in how your services operate. I don’t think everybody loves that decision, but at the end of the day when they have to fix something on a weekend or in the middle of the night, they appreciate it,” said Frey.

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

集中式或分散式组织 (Centralized or decentralized organization)

The way your team is structured is also going to impact your microservices engineering culture — for better, or worse.

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

For example, it’s common for software engineers to write the code before shipping it off to the operations team, who in turn deploy it to the servers. But when things break (and things always break!), an internal conflict occurs.

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

Because operation engineers don’t write the code themselves, they rarely understand problems when they first arise. As a result, they have to get in touch with those who did code it — the software engineers. So, right from the get-go, you’ve got a middleman relaying a message between the problem and the team that can fix that problem.

由于运维工程师不会自己编写代码，因此他们很少会在第一次出现问题时就理解问题。 结果，他们必须与进行编码的人员(软件工程师)保持联系。 因此，从一开始，您就拥有了一个中间人，在问题和可以解决该问题的团队之间传递信息。

To add an extra level of complexity, because software engineers aren’t involved with operations, they often can’t fully appreciate how their code affects the overall operation of the platform. They only come to know of any issue when operations engineers complain about it. As you can see, this is a relationship that’s destined for constant conflict.

为了增加额外的复杂度，因为软件工程师不参与操作，所以他们通常不能完全理解他们的代码如何影响平台的整体操作。 当操作工程师抱怨时，他们才知道任何问题。 如您所见，这是一种注定要不断发生冲突的关系。

去中心化=高责任感 (Decentralized = high-responsibility)

One way to attack this problem is by following the lead of Netflix and Amazon, both of which favor decentralized governance. James Lewis and Martin Fowler, two software development thought leaders, laid out their thoughts via a lengthy blog post. According to them, decentralized governance is the way to go when it comes to microservice team organization.

解决这个问题的一种方法是跟随Netflix和Amazon的领导，这两个公司都赞成分散式治理。 两位软件开发思想领袖James Lewis和Martin Fowler在一篇冗长的博客文章中阐述了他们的思想。 他们认为，去中心化治理是微服务团队组织发展的必由之路。

“One of the consequences of centralized governance is the tendency to standardize on single technology platforms. Experience shows that this approach is constricting — not every problem is a nail and not every solution a hammer,” the article reads.

“集中治理的后果之一是倾向于在单一技术平台上实现标准化。 经验表明，这种方法正在收缩–并非每个问题都是钉子，也不是每个解决方案都是锤子。”

“Perhaps the apogee of decentralized governance is the ‘build it, run it’ ethos popularized by Amazon. Teams are responsible for all aspects of the software they build including operating the software 24/7,” it continues.

“也许分散式治理的最高宗旨是亚马逊推广的'构建，运行'精神。 团队负责他们所构建软件的所有方面，包括24/7全天候运行的软件。”

Netflix, Lewis and Fowler write, is another company pushing higher levels of responsibility on development teams. They hypothesize that, because they’ll be responsible and called upon should anything go wrong later down the line, more care will be taken during the development and testing stages to ensure each microservice is in ship shape.

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

“These ideas are about as far away from the traditional centralized governance model as it is possible to be,” they conclude.

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

周末谁在寻呼？ (Who’s getting paged on the weekends?)

When considering centralized or decentralized culture, you should think about how that impacts your team members when problems inevitably crop up at inopportune times. You see, a decentralized system implies that each decentralized team takes responsibility for one service, or one set of services. But that too creates a problem: silos.

在考虑集中式或分散式文化时，您应该考虑在不可避免的时候不可避免地出现问题时，这会对团队成员产生怎样的影响。 您会看到，分散的系统意味着每个分散的团队对一项服务或一组服务负责。 但这也带来了一个问题：筒仓。

That’s one reason why Darby Frey, the Co-founder of Lead Honestly, isn’t a proponent of the concept of decentralized governance.

这就是Lead Honestly的联合创始人Darby Frey不拥护分散管理概念的原因之一。

“The pattern of ‘a single team is responsible for a particular service’ is something you see a lot in microservice architectures. We don’t do that, for a couple of reasons. The primary business reason is that we want teams that are responsible not for specific code but for customer-facing features. A team might be responsible for order processing, so that will touch multiple code bases but the end result for the business is that there is one team that owns the whole thing end to end so there are fewer cracks for things to fall through,” Frey explained.

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

The other main reason, he continued, is that developers can take more ownership of the overall project:

他继续说，另一个主要原因是开发人员可以拥有整个项目的更多所有权：

“They can actually think about [the project] holistically,” said Frey.

“他们实际上可以从整体上考虑该项目，”弗雷说。

Nathan Peck, Developer Advocate for Container Services at Amazon Web Services, explained this problem in more depth here. In essence, when you separate the software engineers and the operations engineers, you make life harder for your team whenever an issue arises with the code — which is bad news for end users, too.

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

权力下放是否需要导致分离和孤岛化？ (Does decentralization need to lead to separation and siloization?)

Peck goes on to explain that his solution lies in DevOps, a model aimed at tightening the feedback loop by bringing these two teams closer together. This strengthens team culture and communication in the process. Peck describes this as the, “you build it, you run it” approach.

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

However, that doesn’t mean teams have to get siloed or distanced away from partaking in certain tasks, as Frey suggests might happen.

但是，这并不意味着团队不必孤军奋战或远离某些任务，就像弗雷建议的那样。

“One of the most powerful approaches to decentralized governance is to build a mindset of ‘DevOps,’” Peck wrote. “[With this approach], engineers are involved in all parts of the software pipeline: writing code, building it, deploying the resulting product, and operating and monitoring it in production. The DevOps way contrasts with the older model of separating development teams from operations teams by having development teams ship code ‘over the wall’ to operations teams who were then responsible to run it and maintain it.”

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

DevOps, as Armory CTO Isaac Mosquera explained, is an agile software development framework and culture that’s gaining traction thanks to — well, pretty much everything that Peck said.

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

Interestingly, Mosquera feels that this approach actually flies in the face of Conway’s Law:

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

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” — M. Conway

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

“Instead of communication driving software design, now software architecture drives communication. Not only do teams operate and organize differently, but it requires a new set of tooling and process to support this type of architecture, i.e. DevOps,” Mosquera explained.

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

Chris McFadden, VP of Engineering at SparkPost, has an interesting example that might be worth following. At SparkPost, you’ll find decentralized governance — but you won’t find a one-team-per-service culture.

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

“The team that is developing these microservices started off as one team, but they’re now split up into three teams under the same larger group. Each team has some level of responsibility around certain domains and certain expertise, but the ownership of these services is not restricted to any one of these teams,” said McFadden.

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

This approach, McFadden explained, allows for any team to work on anything from new features to bug fixes to production issues relating to any of those services. There’s total flexibility, and not a silo in sight.

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

“It allows [the teams to be] a little more flexible both in terms of new product development as well, just because you’re not getting too restricted and that’s based on our size as a company and as an engineering team. We really need to retain some flexibility,” he continued.

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

However, size might matter here, as McFadden admitted that if SparkPost was a lot larger, “then it would make more sense to have a single, larger team own one of those microservices.”

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

“[It’s] better, I think, to have a little bit more broad responsibility for these services and it gives you a little more flexibility. At least that works for us at this time, where we are as an organization,” he said.

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

成功的微服务，工程文化是一种平衡行为 (A successful microservices, engineering culture is a balancing act)

When it comes to technology, freedom — with responsibility — looks to be the most rewarding path. Team members with differing technological preferences will come and go, while new challenges may require you to ditch the technologies that have previously served you well. Software development is constantly in flux, and so you’ll need to continually balance the needs of your team as new devices, technologies, and clients emerge.

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

As for structuring your teams, a decentralized, yet un-siloed approach that leverages DevOps and instills a “you build it, you run it” mentality seems to be popular, although other schools of thought do exist. As usual, you’re going to have to experiment to see what suits your team best.

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

Here’s a quick recap on how to ensure your team culture meshes well with a microservices architecture:

这是关于如何确保您的团队文化与微服务体系结构良好结合的快速概述：

• Be sustainable, yet flexible: Balance sustainability without forgetting about flexibility and the need for your team to be innovative when the right opportunity comes along. However, there’s a distinct difference of opinion over how you should achieve that balance.

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

• Give equal opportunities: Don’t favor one section of your team over another. If you’re going to impose restrictions, make sure it’s not going to fundamentally alienate team members from the get-go. Think about how your product roadmap is shaping up and forecast how it will be built and who’s going to do the work.

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

• Structure your team to be agile, yet responsible: Decentralized governance and agile development is the flavor of the day for a good reason, but don’t forget to install a sense of responsibility within each team.

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

If you’ve enjoyed this article, please help it spread by clapping below! For more content like this, follow us on Twitter and subscribe to our blog.

如果您喜欢这篇文章，请通过下面的鼓掌帮助传播！ 有关此类的更多内容，请在Twitter上关注我们并订阅我们的博客。

And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS. ButterCMS is a headless CMS that lets you build CMS-powered apps using any programming language including Ruby, Rails, Node.js, Python, ASP.NET, Flask, Django, Go, PHP, Laravel, Angular, React, Elixir, Phoenix, Meteor, Vue.js, and Gatsby.js

而且，如果您想在您的网站上添加博客或CMS而不用弄乱Wordpress，则应该尝试Butter CMS 。 ButterCMS是一款无头CMS，可让您使用任何编程语言(包括Ruby ， Rails ， Node.js ， Python ， ASP.NET ， Flask ， Django ， Go ， PHP ， Laravel ， Angular ， React ， Elixir ， Phoenix ， 流星 ， Vue.js和Gatsby.js

翻译自: https://www.freecodecamp.org/news/why-team-culture-is-critical-for-successful-microservices-2b0e24f124e9/

微服务团队