Architecture & DesignHow to Align Your Team Around Microservices

How to Align Your Team Around Microservices content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Microservices Architecture

This article talks about why aligning your team around microservices is important, the challenges of doing so, and how to achieve the alignment.

What is Microservices?

Microservices architecture, a variant of service-oriented architecture, has become immensely popular over the past few years due to its ability to provide greater agility, improved performance, and better scalability. It is imperative that you have a proper team structure and team culture for the success of microservices in an organization.

For the success of microservices in an enterprise, you should be able to align your team around Microservices. But how do you reorganize your team around microservices?

This article presents a discussion on why aligning your team around microservices is important and the strategies that you should adopt to get your team on the same page as far as microservices architecture is concerned.

Read: An Introduction to Microservices.

Microservices Team Structure: Why It Matters

Microservices doesn’t just concern technology and architecture; it also concerns an organization’s organizational structure. If you are to be successful in implementing microservices in your organization, you should consider both – i.e., the architectural style that it is as well as the organization structure.

Your application’s structure should reflect the team structure. It is crucial to balance the culture, mood, and morale of the team for microservices architecture to succeed. Building microservices is not just about technology – you should also be able to build and organize your team the right way as well.

Cons of Using Horizontal Development Teams

Imagine you’ve several horizontal teams, each possessing a different aspect of a particular service. You can have one of those teams owning the API layer, another owning the business logic layer, and yet another owning the data access layer. Hence, if you’re to create a service by leveraging each of these components, you’ll have to constantly communicate with the members of these teams to get what you need to proceed.

As a result, this will slow the process considerably. The solution to this problem is using vertical teams and aligning those teams around the microservices you’re using in the application you’re building.

What is Conway’s Law

A recommended approach to organizing the team is by following Conway’s Law. This law states: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

According to this law, the structure of the application that you’re building reflects the structure of your organizations as well. If you organize your software team as a combination of frontend team, backend team, and an ops team, you’ll soon run into difficulties in managing the deliverables as the teams are dependent on one another.

You should form vertical teams, each capable of handling the API, business logic, and data access layers. The API layer offers contracts that enable different vertical teams communicate with each other.

Vertical teams must manage both the user interface and the application programming interface (API) layers. It is worth noting that the API layer will generate contracts that will facilitate communication between various vertical teams. These teams can, however, operate independently and are not reliant upon each other.

You can use this API layer to establish contacts among different vertical teams. This allows each team to develop at its pace using the same API that integrates or leverages services from other teams.

Create Microservice Build and Run Teams

Your teams should be small and adept at building and deploying microservices. While you give your team members enough freedom, you should also ensure that a high level of responsibility is attached. You should organize your teams in such a way that they own the responsibility of the piece of software they have been assigned to work on, end to end. Your build and run team should take care of all aspects of the software’s lifecycle, from development through testing to deployment.

Improve the Technology Stack

You should always consider improving your technology stack for better performance, scalability, and reliability of your applications. When using microservices architecture you wouldn’t have any constraints as far as the choice of technology and tools is concerned. That’s one of the primary reasons why microservices architecture has become so popular worldwide.

You should give your team absolute freedom to make technological choices or recommend technologies and tools. In one of my recent companies, we followed this practice – we have had a round table with the team so that they can come up with their recommendations.

You should listen to the recommendations of all, but it is you, the software architect, who should be making the final decision as far as the choice of technology and tools is concerned.

Adopt a Decentralized Approach for Microservices

When you are working with monolithic architectures, governance is centralized. One of the pitfalls of centralized governance is that you eventually come up with single technology platforms. Decentralized governance refers to the unavailability of any standardized pattern or technology pattern.

Software development teams are often split into silos without any overlap between them. If you are working for monolithic delivery, there would be frequent handoffs between the team members resulting in delay. Hence such processes are inefficient and doesn’t follow the agile principles.

Just replace such silos with microservices teams – follow a decentralized yet un-siloed approach and give your team the freedom that is needed but with responsibility. You should never favor a section of the team over the other members of the team – rather, give your team members equal opportunities.

Build a Successful Microservices Engineering Culture

For microservices to be successful, you should have a proper team culture. You should be able to build a culture where the team members have the necessary freedom to be comfortable while at the same time make them responsible for the deliverables they are assigned.

It is imperative that the members of a team have full confidence in the organization they work for. It is critical to collaborate with your team to develop a strategy that empowers everyone. This way your team members would feel motivated, and this would help boost the morale of the team.

Microservices Tutorial

A great way to approach microservices development is to see the output structure as a reflection on the team structure. Microservices development can be improved by having better team structures. Most importantly, any organization can adopt this approach to maximize business value.

Companies such as Netflix, eBay, Amazon, Twitter, PayPal have benefited from microservices architecture. A motivated, well-structured, and properly inculcated microservices engineering culture is essential to deliver value to customers faster and get you on the market quickly.

Adherence to Conway’s Law would help to structure or organize teams the perfect way and help the organization achieve its business goals with ease. You must adopt a decentralized but not siloed approach that leverages DevOps and instils a culture of “you own it, you build it, and you run it.”

Read: Serverless Functions versus Microservices.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories