The work on a microservices project is always stressful. Such projects introduce larger data sets, faster update rates, more requests, more failures, more latency challenges, more service interdependencies, more developers, more documentation, more servers, more networks, more databases.  

Yet, all that doesn’t mean you should avoid microsevices-based projects. The right organization of your team can help you mitigate the problems with microservices and enjoy the benefits that such architecture can bring. Here’s the list of our tips on team organization we offer to consider to turn the project into success.  

Do’s
Invest in the team. Before you start your microservices project, make sure the team is staffed with important-for-microservices experts such as:  

A software architect. In a microservices-based architecture, you’ll hardly get far without a savvy architect. He is the one to define how the system will function as a whole, decide on each microservice functionality, monitor the compatibility of different microservices technologies, databases, APIs and data exchange protocols. The software architect makes sure that the resulting system will be open for changes and updates and balances the needs and expectations of both customers and developers.  

Experts on orchestration and choreography. Orchestration and choreography are two ways to compose microservices into one coherently working system by deciding in what sequence the microservices will interact with each other. The experts on orchestration and choreography strictly define where and how the services get the needed data to deliver a correct, comprehensive and timely answer to a user’s request.

In simple cases, the software architect assumes the role of expert on orchestration and choreography. For more complex projects, for example those that involve a set of multi-microservice modules, the software architect can be the one who decides on the high-level system composition. To assist him with coherent communication of microservices within modules, it’ll be good to attract dedicated experts who will be responsible for the smooth co-work of microservices inside the module.

Experts on containers. Containerization isolates resources at the operating system level. A container wraps all the libraries and executable files needed to run a service or services in an isolated environment.  The container connects to its host OS via a certain interface, and it is independent of the resources and architecture of the host on which it is running.

Thus, containerization may greatly assist in coordinating and managing complex distributed systems. But, at the same time, containerized microservices are not that easy to work with. Bound services are more difficult to monitor and update. Also, for example, you may experience a situation when one of them gets too overwhelmed and uses all available resources, putting other services out of business.

An expert on containers ensures reasonable packaging of your services in containers to benefit from their ‘isolation.’

Fine-tune communication. Well-crafted communication does matter. The suggestions here include:

Keeping different microservices teams apart. Make microservices teams completely independent from one another, just as their future services are supposed to be, as it will be easier to set up clear borders between microservices and create a truly loosely coupled system.

Being dedicated to one certain service or, at least, an independent set of microservices, the developers avoid the temptation to access directly, for example, another service’s database and are compelled to count on purely API communication – just as perfect microservices systems are to be organized.    

Keeping the members of one microservices team close together. In contrast, prevent one microservices team from separation as a lot depends on their close cooperation. Do not spread team members across different offices, or what is even worse – countries. Building a successful microservice is a creative process of multiple discussions and brainstorming sessions, so team-splitting will harm delivery speed, reflect badly on the overall product quality and thus lead to extra costs.

How-to’s
How to avoid finger-pointing:

In the development of distributed systems, the usual “blame game” is at work more than elsewhere. When people from different teams can influence the microservices work and their responsibilities are not clearly defined, it’s difficult to find whose fault it is as the project team members can easily push blame on their colleagues in case of any trouble with the project.

Thus, one specific cross-functional team should be dedicated for one service and fully own its UI, its API, its business logic and the data layer for all types of clients – be it web, mobile, tablet, etc. Whatever happens — from a bug and to a need for update — one team is completely responsible for the service.

Though it’s hardly possible to ever completely prevent finger-pointing, such a clear division of responsibility significantly reduces the list of ‘suspects.’ And, as a bonus, it becomes a good motivation for the team to keep their service in perfect order.

How to introduce changes wisely:

Time to time, microservice APIs are to be changed. Such changes can be problematic in distributed systems, as every modification should be safe for the rest of the system. We’ve already mentioned monitoring of changes as the architect’s responsibility. It is also convenient to have a control group that consists of different-level project members, from an architect to representatives of microservices teams. They stay aware of all the system inner connections to allow easy and fast detection of potential risks.

A ‘would be nice to have’ 
Domain experts. The secret is to create not ‘microservices,’ but ‘domainservices.’ Thus, it’s a good idea to engage domain experts that can help you uncover multiple, and not always that evident, interdependencies between different business processes, which are laid as a base for microservices.