Website developer services

From Monolith to Microservices: When and Why to Migrate

Are you wanting to migrate into microservices but have no idea where to start? In this article, we’ll help you clarify what must be considered and kept in mind before beginning your journey into the world of microservices.

Tekton
Nov 15, 2023

 

The First Step: Have a Really Good Reason for Making the Migration

 

“Our industry tends to focus on tech instead of the outcome. One should use microservices as a means to obtain a desired outcome rather than for the sake of using a new technology.”

When To Use Microservices (And When Not To!)

Sam Newman & Martin Fowler

 

“Monoliths are bad, microservices are good”…or so some of us in the tech world continue to hear. But if you’ve only decided to migrate into a microservice architecture because of this slightly misdirected popular belief, then we would suggest you reconsider.

Let’s not let new trends in technology blind us. Everything has its place and works well under the right conditions. Our job is to recognize when something is really needed and then apply it correctly. Applications can start as monoliths and later, when the time is right, then split into microservices.

The reason? Most of the time, at the beginning of a new project, the scope is not yet sufficiently defined, and business processes just aren’t mature enough. This could lead to issues that you will come to regret later, especially if the domains that each microservice must have aren’t clear enough – a perfect example of when starting with a monolith would actually be more appropriate.

 

When It’s a Green Light to Use Microservices

When is the right time to move forward with a microservices architecture? If your objective is any of the following:

  1. Deployment Independence: To be able to change and deploy one service without the need to change the others and have a zero-downtime deployment.
  2. Scalability: Microservices are scalable by nature; if your business needs high scalability, then microservices are your best option. However, beware that if microservices are not implemented correctly, you will end up with a microservices system that does not scale well.
  3. Agility: You’ll be able to facilitate continuous delivery since each microservice is an independent project, and delivery speed is valuable in today’s world.
  4. Reusability: This is a key feature in microservice architecture since they are components that can be reused by other applications or microservices.

 

What to Keep in Mind When Migrating to Microservices

So you’ve decided to go microservices. Now what? Here is what’s important to keep in mind:

  1. Have a Good Repository Setup: Mono repo and multi repo have their pros and cons. Choose wisely since this will have an impact on your CI/CD pipelines.
  2. Communication: Microservices can use synchronous or asynchronous communication, such as message bus communication. Distinguish between both to design the system better. Implementing patterns like Service Registry and Service Discovery will help not only in communication but also in scalability.
  3. Data: You must consider whether you go for the approach of API composition, event sourcing, or Two Phase commit in order to guarantee your data integrity. Choosing the right pattern will help you in handling data access, storage, and manipulation.
  4. Failover Tolerance and Monitoring: Now you have multiple points of failure. This is why monitoring is key, including implementing health checks, good logging techniques (like process traceability), and working with logs aggregation technologies (i.e., ElasticSearch, Kibana Stack, Splunk, Loggly, etc.), many of which allow you to set up alerts and even create dashboards.

 

A Real World Scenario

A client came to Tekton looking for a scalable solution for his business, which had already been in the market for many years and had the potential to keep growing. We evaluated different options and took the one that best suited the final goal. An Azure cloud solution was proposed using a microservices architecture.

These microservices were deployed in a Kubernetes cluster. The communication between frontend and backend was done through API Management as the only entry point (Plus, the security benefits APIM provides were leveraged). Furthermore, we implemented asynchronous communication between microservices within the cluster and synchronous communication when calling external services. Because we need to be aware of every activity and have proper response time to any incident, monitoring was accomplished through health checks, Azure Monitor, application insights, dashboards, alerts, and application logs (Loggly).

Finally, we are a company that had already adopted a DevOps culture, so choosing Scrum as the agile methodology was evident, they both work well together, and Scrum helps us to achieve high agility when delivering value to our customers. A mono-repo approach was chosen, this allowed us to execute continuous integration (CI) pipelines using Gitlab, and we obtained deployment independence by having each sub-repo configured correctly. Our deployments to non-prod environments were done automatically, but deployments to production were done following Continuous Delivery since the client had requested that deployments have his approval.

 

Final Thoughts

Going from monolith to microservices is not a decision you should make lightly. It requires deep analysis and an understanding of what this task involves and the needs of the business. We hope this article has helped you as a starting point for doing microservices and doing it right.
Website developer services

Similar posts