From Monolith to Microservices: What Have I Learned?
In software companies, it is common for developers, whether junior or senior, to deploy unstable code that fails in the Continuous Integration (CI) process and, as a result, the entire monolithic application. Is there a way to prevent this from happening? Yes. Take it from someone who has experienced it firsthand
If you’re reading this, you’re likely curious about or dealing with the challenges of monolithic applications. Or chances are you’re a Fullstack Developer like me.
And you’re probably familiar with the fact that as software systems grow and evolve, they become increasingly complex, tightly coupled, and difficult to maintain.
Monolithic applications are an example of this complexity, where the entire application is built as a single, interconnected unit – making it hard to scale, update, and deploy.
To address these challenges, the R&D department at Optimove began turning to microservices architecture. Lucky for me, I was there, working on it firsthand and watching the process up close. Here’s how it went about.
What are the Challenges with Monolithic Applications?
As a Fullstack Developer, developing within a monolithic application can be incredibly challenging. The size and complexity of the codebase can make it difficult to understand how different parts of the system interact, mainly when I must deal with legacy code that can slow down development. It can also make it harder to keep the codebase up to date with modern best practices.
Additionally, since the application is monolithic, any changes made to one part of the codebase can cause issues in other areas. And it affects the entire R&D department.
Though we face technical challenges daily as we grow and scale to meet our customers’ needs – one of the biggest issues we encounter is managing the increasing volume of data and traffic from our expanding customer base. Therefore, we want to continually optimize and upgrade our systems to ensure our infrastructure can handle the growing load.
Which led us to the transition to microservices.
Transitioning to Microservices
Planning the transition from the monolith to a microservices architecture was critical in ensuring its success. We began by thoroughly analyzing the existing monolithic application to identify the components that could be extracted and turned into independent microservices. It involved assessing the dependencies between components, the complexity of each component, and the potential benefits of turning them into their own services.
We identified our notifications service as a suitable candidate for extraction due to its distinct separation of concerns, extensive network usage and data processing, and potential implications for the overall system’s stability and scalability, making it an appropriate case for extraction.
To begin, we developed a detailed plan for the transition. It involved creating a new project for the microservice, defining its architecture, identifying the necessary APIs and data flows, and establishing a deployment process.
Minimizing the Impact of Issues During Deployment
The deployment process for the notifications service involved a gradual rollout strategy to ensure that any issues or bugs could be identified and addressed before the service was released to all users.
This involves initially deploying the service to a small subset of users and gradually increasing the rollout as issues are identified and resolved. This approach helps to minimize the impact of any problems that arise and allows for more efficient maintenance and updates to the service.
Pro-tip: During the rollout process, it’s essential to conduct load tests to ensure that the service can handle high-traffic loads and to identify any performance issues or bugs, such as memory leaks, resource constraints, or the need for horizontal scaling.
For example, load testing may reveal that the service experiences high memory usage when processing many notifications, which could indicate the presence of a memory leak. By identifying these issues early on through load testing, you can address them before they impact the user experience and ensure that the service is optimized for scalability and performance.
Five Recommendations from Optimove Fullstack Developers
Based on the teams’ experience, we recommend the following to brands considering a transition to microservices:
Start with a specific flow: It can be overwhelming to simultaneously transition an entire monolithic application to microservices. Starting with a specific flow can help you gain experience and identify potential challenges before scaling up.
Avoid distributed monolith: Design services that have one clear responsibility and well-defined boundaries.
Use a lightweight framework: Microservices are meant to be small and independent. Using a lightweight framework can help you achieve this goal and avoid the overhead of a heavyweight framework.
Invest in testing and automation: Microservices are typically deployed frequently, and testing and automation are critical to ensuring reliability and scalability.
Set clear goals: Set clear goals and benchmarks for measuring the success of the transition, such as improved performance and scalability. This results in a more flexible and agile system that can adapt quickly to changing requirements and traffic patterns.
A Final Word
Transitioning from a monolithic architecture to microservices is not an easy task. Still, it can be a worthwhile investment for brands looking to improve their software systems’ scalability, flexibility, and agility.
The transition at Optimove involves breaking down our gigantic monolithic application into more minor, independent services that can communicate with each other through APIs. This not only improved the performance and scalability of our system but also enabled faster and more independent development, ultimately leading to greater efficiency and customer satisfaction.
Or is a Fullstack Web Developer at Optimove. Or joined Optimove as a Customer Solutions Engineer in 2021 and was promoted to Fullstack Developer in the R&D department. He holds a Bachelor's degree in Information Systems Management from Ben Gurion University.
