Microservices organisations
A modern way to foster collaboration between multiple teams working on a common product.
Our world is becoming more and more complex. The IT departments are growing, the amount of software legacy is increasing, the dependencies are tightening and the market competition is intensifying. People are looking for solutions on how to make it better and quicker together.
It seems that everyone already agrees on the usage of Scrum and Agile on a team level. A bigger scale solution is still under discussion and approaches such as SAFe, LeSS, Nexus or Teal organisations are still competing with each other.
For ages, people were using metaphors to explain complex solutions in simple words. Such a comparison gives an easy way to grasp the general idea. For example, when a scientist called Dijkstra wanted to explain a concept of controlling access to a common resource shared by multiple processes, he called it a semaphore. As it was in the early sixties, most peoples were able to easily imagine 3 trains trying to use 1 track with a railway semaphore in control. It grasped and nowadays every software developer understand what is a ‘semaphore’.
But we are no longer in the sixties and we use more complex concepts in the IT world. It will be hard to find a developer who is not familiar with microservice architecture. But, in case you are not — then it’s based on small programs, decoupled from others and with high internal autonomy. They are organised around business needs and there is no need to coordinate internal changes. They also isolate mistakes. From the delivery perspective, they allow independent releases and deployment so it’s easy to scale them and grow.
Can we combine it with the idea of self-organising teams? I would like to encourage you to imagine a company organised as a microservice application. To make it easier, let me show you the structure of the place where I’ve recently worked. Similarly, as a couple of microservices might work together to handle an API request, teams called ‘studios’ may be involved in delivering a product to our customers. These studios and those people were distributed globally but from the client perspective, the implementation was seamless. Similarly to microservices, the organisation gave the studios a little autonomy in internal affairs and provide shared services to support them.
Let’s have a brief look at Conway’s law, stating that the way the company is organised will have an impact on the created solution. In other words, the results delivered by tightly coupled product teams will also be tightly coupled.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
- Melvin E. Conway
An idea to mitigate the above issue was proposed by Amazon when they moved from the 2001 monolith application to a microservice one. They introduced small ‘two-pizza’ teams, communicating with each other only by APIs. Teams owned microservices and took care of them from planning through implementation and testing to deployment. That allowed Amazon to get rid of complex coordination efforts and resulted in 50 million deployments a year.
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of inter-process communication allowed […]- Jeff Bezos “The API mandate”
Another company that followed a similar path was Spotify with their autonomous and full-stack teams. Apart from simpler releases and avoiding synchronization hell, it gave them also better fault tolerance. So, even if the ‘search team’ make a terrible mistake you’ll still be able to browse albums and play songs — only the search function won’t work.
I believe that agile organisations should allow their teams to have the tiny fields that they can cultivate and analyse changes just like biologists who breed fruit flies. To be able to play, learn, fail and improve in short iterations, while ensuring consistency with the rest of the organization. I hope that this metaphor of a microservice organisation will help you to look at your project from a different angle.
