Over the past couple of months I’ve been working on and reading up extensively on microservices. Numerous medium articles, and 2 books* later, here’s just a quick summary of the important points that I’ve learnt.
*Building Microservices – Sam Newman / Microservice Architecture – O’reilly
Is it suitable for me?
The organization that you are part of is a very huge part of whether the microservice architecture (MSA) is suitable for your project/product or not. Conway’s Law states that software design often reflect the organization communication structure, unsurprisingly, the inverse holds true as well.
While not a fact set in stone, there is less resistance when implementing MSA if your organization embraces the agile culture. I feel that this is mainly because MSA is an evolution of Service Oriented Architecture (SOA). Having small teams with defined roles and objectives helps with separation of concerns and works in line with the technical aspect of MSA.
Sense of ownership
This is also closely linked to the organization and culture in general. MSA is not a magic bullet that could solve all the issues with the moving target problem. The team(s) need to take ownership of the service that they are building. There is no hard and fast rule that one team should only handle one service, but the team that built the service should be the one in charge of maintaining/improving it.
There are many other factors that I won’t delve into as the books do a much better job as putting the information across. But briefly, the other factors are as level
- Location of team (across countries)
- Team size (2 pizza rule)
- Outsourcing (cultural fit)
- Competency level
So you’ve thought through all of these factors and decided, “I think my team/organization is ready for MSA, where to start?”