The experience of migrating a digital platform for public websites to a microservices architecture

Introduction

Like in any medium to large monolithic application project, the migration to a microservices architecture is never an easy task. Multiple technical and organizational factors must be considered. For instance, the process of migration would engage many engineers which could be really challenging for small to mid-size companies.

Web platforms are no exception as they usually evolve fast and receive huge traffic, given the enormous amount of valuable data they are supposed to display in different forms. Despite the comfort that a monolithic architecture offers for an IT team in terms of control and having everything in one place, a time comes when maintaining the application becomes draining and scaling it to meet new requirements gets impossible.

Company’s Issue

At Minotore, we’ve reached the point mentioned above for one of our projects. The application became huge with time and there were always new developments needed and so, we’ve started to question the architecture of the application, its limits and how could we improve it to meet future requirements easily. 

Solution

After research and multiple discussions, we’ve came to the idea of decoupling our services slowly because it would be impossible to stop everything and consider a migration project and that’s for two reasons: the client needs periodic deliveries for new requirements and a project like that would consume huge resources as it would be like starting the application from scratch.

The migration to microservices

The analysis of the progressive migration started by looking at the boundaries of our services and so considering a microservice for each group of services that belong to a certain context. Now, depending on the complexity of a certain context which is defined by how much impact and interactions it has with other components of the application, we’ve set the priority, starting work from the least complex.

However, at Minotore, we’ve seen this as an opportunity to not only decouple our applications into multiple APIs but to improve the design of each service and redevelop some of them from scratch. For example, the current “Financial Product” service which was using data stored in a relational database and relying on cache to speed up queries has now become the Product API which is generic for any kind of products and free from any specific business rules previously hardcoded and which relies on new technologies such as a NoSQL database which suits its unstructured aspect. So, we didn’t simply take our code and put it in a separate API and changed the interactions through RESTful APIs, but we’ve also moved to new technologies and better designs and that’s one of the advantages of a microservices architecture.

Previous Architecture

Let’s look at the previous architecture:

Even though this lacks a lot of details, it represents well the situation of the monolithic architecture, a VM for MySQL server and another one hosting a web server and a servlet server where all the application components reside including the backend and the frontend. Now if you’ve noticed, there’s a AngularJS in the frontend layer along with the JSF and there’s also a Webservices layer for the AngularJS components to interact with, this actually was a step done in the past towards the decoupling of the application and getting the architecture to SOA but it didn’t live up to the huge growth of the website.

New Architecture Part

And let’s see the new part of the architecture,

As you can see, we’ve added a new part to the architecture which is a Kubernetes cluster hosting our microservices. The web server reverse proxy is redirecting all calls starting by ? /microservices ? to the Kubernetes cluster where Kubernetes is the orchestrator for our stateless containerized services and the responsible for their scalability, resources, etc…While this may seem as a new weight to the architecture as it would take the resources consumption up significantly, it is a temporary situation which offers the team a great flexibility in the process of migration, in other words, it is an investment, and in the future, we will end up with a 100% microservices application and would have everything on the Kubernetes cluster.

Micro frontend

Having microservices is great, but having micro-frontends is even better especially in the context of a client managed website and for the endless tools/components needed for the evolving business experience.

In fact, we didn’t only move to microservices, but also challenged our frontend and came up with a new mechanism to be able to develop web components/widgets separately and be able to add them to any page on our websites in Realtime without any need for a whole app delivery and zero downtime.

This will be discussed in detail in a future article.

Conclusion

At Minotore, our experience with microservices was successful as we gained huge flexibility in our developments, took our tech stack and designs to the next level, were able to add CI/CD to our chain and automate a lot of tasks and opened new horizons to our culture.