My take on Microservices in 2023
Microservices and Monolith Architecture in depth
Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
Search for a command to run...
Microservices and Monolith Architecture in depth
No comments yet. Be the first to comment.
On this page
Undoubtedly since Microservices came out sometime at the beginning of this decade, it grew up quite the popularity before being the most sought-after software architecture style globally. So where do we stand now and what does the future hold for the microservices architecture? Is monolithic architecture dead already?
Microservices is a software architecture style in which you structure your software design into smaller cloud-based, loosely coupled and independently deployed modules called services. These modules could communicate with each other through a combination of APIs and message brokers.
Software applications start as what is known as monolithic apps and grew to adopt the microservices architectural approach by breaking it down into a set of interconnected services.
Each service of these microservices tends to have its hardware (CPU and RAM), environment and possibly a dedicated team working on it.
Scalability: Since microservices are modular, they allow teams to scale individual components of their application with ease independently of each other without affecting the system as a whole.
Resilience: You know what they say, Don't put all your eggs in one basket. Since microservices are modular, having the system consisting of small units each deployed independently means the system does not have a single point of failure, which makes the software application more resilient, allows faster recovery time and you to determine each service's health and possibly sharing it to your application users could become so handy. just like folks at Xbox.
Technology Agnostic (this one is my favourite): Microservices consist of small modules, I think we have agreed on that already, and since these modules are deployed independently, they give the architects the freedom to choose technologies and languages for these modules each independently. Let's say we have a video streaming application that we wanted to use ExpressJS as our client-facing server for. And to have a better user experience we wanted to combine our video streaming offering with state-of-the-art AI-powered video recommendations, Yes, as you guessed, When we mention AI, Python would be our go-to. Microservices will let you incorporate different technologies for different services with ease.
Ease of deployment: Since every module is independently treated, each can be deployed to different environments whether staging or production it is. This allows developers to roll out different features flexibly.
Although using microservices looks like a no-brainer judging the advantages we mentioned earlier, that does not mean that adopting the microservices architecture does not come at its own cost. A few drawbacks include:
Debugging Pain: Tracing that bug across your set of services could be a pain in the #$#, believe me. And because of their distributed nature, each microservice has to have its unit testing separately.
Increased Complexity: Let us imagine that; you have a set of microservices that each has its code, database and dependencies, maintaining all these microservices would prove painful when their number exceeds tens or even hundreds, so you have to come prepared with a well-defined strategy, documentation and boundaries between them to handle them effectively.
Communication Overhead: They are small units, they are decoupled, remember? As your services are each separately deployed, they need to communicate with each other, that is more work you have to do setting up this communication strategy between them and that is of course increased traffic and latency issues.
One last thing, these microservices do not use the same communication protocols to communicate with each other, You could have a REST microservice that communicates via HTTP/1.1 communicating with a gRPC microservice that uses HTTP/2, hence, more complication.
Security: Because of their distributed nature, you have to secure each microservice on its own and secure the means of communication between them to prevent any impeach attack from outside your trusted points.
Design: Designing the microservices architectural pattern is in no way an easy task, You must have in-depth knowledge and a high understanding of the process to tailor the architecture to suit your use case and needs.
There are two big questions when talking about using microservices; When and How?
As we agreed already, all software applications start as monolithic applications before hitting that turning point where we going to ask, is it time now? Determining the right time is key. You do not just go with the trend, do not feel embarrassed to implement microservice architecture if you are not going to need it.
so, when?
Weigh the benefits against the challenges, using microservices architecture comes with a set of benefits and challenges we discussed earlier, you have to ask yourself if is it worth the extra headache already. Not to mention that there are these scenarios that state that we have to switch to microservices that include but are not limited to:
You want to use that new technology, but you are not sure you want to apply it to the whole application.
Run multiple instances of the application on multiple machines.
Expose your API to third parties.
here comes the even harder question, how? Let us say we already have a monolith application that we decided needed to be converted into a microservices-structured application. We have to follow the following steps
Plan
The first stage of turning to microservices and the most important one is planning, in-depth planning. Preparing your organization for the move and getting everyone on board with the idea is critical. Build your teams around each microservice, each team has to be familiar with the technology and business logic of their service.
You have to deal with each service as a standalone project before looking back at the wider picture and determining how they are going to communicate, standard protocols such as HTTP or gRPC would be your go-to for communication regardless of the programming languages used within the service.
One last thing is, to design the application to fail gracefully. always consider your worst case while planning.
Divide
A tricky part of transitioning to microservices is dividing or decomposing the application into smaller units. The first question that will come to your mind is, on what basis are we going to divide the services? There are mainly two well-founded approaches:
Decompose by business capability
Decompose by subdomain
Let's not dive deep into this further to keep it simple, For in-depth knowledge, I recommend no one better than Chris Richardson, author of Microservice patterns.
Pattern: Decompose by business capability Context
Pattern: Decompose by subdomain Context
Maintain
Another key part of transitioning to microservices is having a plan to maintain your application after transitioning which includes having a detailed CI/CD process to automate your releases to ensure that bugs are found and fixed quickly, having a well-founded CI/CD pipeline is crucial when you have an increasing number of services that need to be deployed, which actually could be multiple times a day.
If your team needs to deploy new features seamlessly within your big project, microservices design patterns are undoubtedly of great benefit. but that comes at a technical cost that requires a team with a strong technical aspect and a deep implementation of DevOps principles. Switching to microservices requires your team to go through well-planned phases that once implemented and carried out carefully will bring more benefits to your application and outweigh the challenges imposed by it.
Just plan it right.
