Monolith to Micro Services

Whenever you hear about successful micro services story it probably started as monolith… And that is probably the most natural way of product development, if you are starting something new, you want to build a new product, monolith is way to go. Using micro service architecture from the start just doesn’t make sense… And reason why it doesn’t make sense is explained in rest of text.

Monolith is perfect solution when you are starting with small/limited resources, you want to provide value for your customers fast, you want to move and develop fast and all this with limited resources and time…

You start to face limitations of monolithic apps once you experience growth of your customer base, and once small areas in your monolithic app that were responsible for different parts of your app (for example user management) need to support huge number of your customers and their requests from your product.

If you look any monolithic system, it has a lot of different responsibilities that it handles, different problems that it solves… So for example it would have

• User Authentication and Authorisation
• Invoicing and Billing
• Other modules depending on what kind of problem it’s solving.

Usually inside monoliths this areas are also a bit separated in different modules, encapsulated, but then we also use them together, and together they make your product useful.

So this areas that you have in your monolith once you experience customer growth, start also to grow to be more complex, to support more features. You also have more people (usually more teams), working on those and then you start to see problems of monoliths.

puppy = teams, bowl = monolithic app. Teams start to block one another so there is always team that suffers can’t get their features in (puppy on left ☹️)

To the rescue comes micro service architecture, and this is also one of the reasons why starting with micro services doesn’t make sense because you need a lot of resources (money, people, time…) to develop and maintain it…

Areas that we described from before as modules, now can be separated in micro services based architecture, and this is also one additional reason why micro services systems shouldn’t be build when you are building something from “scratch”.

Having existing data, customer feedback, experience in some domain will help you make this separation more cleaner, because if separation is not done properly you will have problems with “independency” / “autonomy” of teams.

Mapping of different areas/contexts of your product is important part of splitting and this is something that shouldn’t be done only by engineers, this is where you need also to involve business side of the product, and this is where Domain Driven Development (DDD) shines.

Borrowed from https://www.connell.dev/domain-driven-boundaries/

“Micro” in micro services doesn’t really mean one technology, or just dealing with one specific type of data like users in micro service, or one framework, or one small app… This depends on the system.

Take for example picture above, micro service doesn’t really mean each coloured box (like user, payment, product etc) should have it’s micro service, but it’s a way of creating areas that have different responsibilities and those areas can run inside single or multiple services, but all areas work together at the end well — like example before in monoliths with modules.

This is where micro services shine, and cleanly defined boundaries between this areas allow your teams to be really independent and fast.

each puppy = team has it’s own space = area of responsibility

By independent micro services for teams it means that they can

• Work independently on features in their area of responsibility
• Independent deployment
• Independent testing

If all of this can be done in single team, you can argue that you have micro services architecture.

Of course, micro services introduces new problems to your system, you free up teams but then your system becomes super complex, and this is something that you should be aware of from the start if you are trying to use micro services.

Having this separation between teams, allows teams to make different technical decisions, choose different way how their services communicate — have different APIs, store data differently, etc.

Also a lot of similar logic is replicated across micro services, in different technologies, for example user authentication and authorisation… So there appears need for reusing the code, creating packages/libraries that can be shared between micro services.

So switching to micro services doesn’t really mean that teams have 100% freedom, they gain more freedom and independency but that still should be limited, and you also trade this independency for complexity…