From monolith to micro service

Let’s first see when is it fine to keep using a monolithic architecture

You are working alone on a repository, your infrastructure requirements are pretty basic and you don’t plan to scale the project you are working on. Using a monolith is fine.

If you don’t, then read on, I’ll tell you what I think are the main advantages of switching to a microservice architecture and how you can start the transition.

Organize 

The main advantage of a microservice architecture lies in the possibilities it opens up for your company’s organization.

Decouple, collaborate and outsource

With different micro services you are able to decouple your application into different pieces of code that will evolve independently from one another. This approach requires that you define clear interservice communication mechanisms for data exchange, but once this is set, each service can be built by different teams within your organization.

You can even consider outsourcing services that are less critical to your core business offering without jeopardizing the rest of your codebase.

Increase agility

By breaking down your application into smaller pieces you have the possibility to quickly iterate over the areas of your application that matters most without impacting the rest. You also have the possibility to experiment with less critical components and be confident that the main service proposition is still being delivered to your users. This grants you an advantage over a monolith which would have to go through a full QA phase for any little update.

Secure IP

When you break down your product into smaller components, you can protect the most critical parts by reducing the number of people who have access to the codebase, making it easier to protect your IP without slowing down the iteration over the rest of your solution.

Scale

Technically speaking, investing into setting up a microservice architecture brings a bunch of benefits too.

Distribute your load

The title says it all, each microservice can be hosted on a distinct node that doesn't have to carry an homogenous configuration. You can also consider different Database technologies for different microservices and pick the configuration that makes sense for each microservice. You don’t need to make compromises anymore. 

Increase power where and when you need it

With a distinct node for each microservice, you are now able to provide a more powerful configuration to the specific service that needs more CPU and RAM, while having an increased bandwidth for that service that manipulates big files. You can even decide to build a service with distribution in mind and have replicas for it, while others are simpler and only run in one node. It’s really up to you and that grants you an optionality you can’t see in a monolith

Increase speed to identify and fix bottlenecks

Isolation is the first step to identify an issue, with a microservice architecture, this isolation is done at the conception level. You can easily identify where an issue is stemming from and fix it in less time it would take you to git pull a monolith. That requires a proper tracing setup between your services but once this is done, the benefits are immediate.

Adopt new technologies

You want to add an AI enabler in Elixir, Rust or Python to your business but your current stack is in PHP ? With a microservice enabled organization, you can fairly easily add a new service for that specific feature and maintain it separately. This is a great way to explore new technologies and stay updated with current trends.

Control costs

If you are concerned about the financial aspect of such a transition, you should account for initial resources to setup the overall infrastructure required to support a microservice architecture. Once this is done, you’ll be able to save.

Leverage existing tools

When your stack is highly decoupled, it becomes trivial to start an existing application and plug it to your overall solution. We are oversimplifying in purpose here, as you’ll probably need to adjust some database schema, but that is a relatively small impact compared to having to weave a new feature into a monolith. Moreover, you can often reduce the impact (and improve performances) by having certain data redundancy in between your services.

Reduce maintenance costs (target updates)

One major disadvantage of a monolith is the need to synchronize your updates. When you have to update a package or a library, most often than not, you’ll also have to update the other packages that depend on it

If you want to read more about how we helped Maiori breakdown their Prestashop monolith and launch a new microservice based online store, read more here