Think Micro all the way in a Monolithic World

SAAS-based solutions have enabled the growth of microservices and has shifted the backend services from monoliths to a micro or more agile services. In spite of using Microservices in the backend, the world is still using monolithic architecture at different layers. Be it at any layer, a typical monolithic architecture is a like a big elephant, very hard to move. A large and complex product can’t scale with a monolithic architecture. The software architects usually suggest to use microservices which can be scaled and increase the effectiveness of a software architecture. But this does not solve the scalability problem at each layer.

Here, I am trying to extend the idea of Micro services and Micro frontends to complete Micro components at each layer. The idea is to think about the whole system as a composition of micro components which are owned by independent teams.

Motivation

As the world is having a lot of front-end devices (mobile, laptops, iPad etc.) to serve, the effectiveness of a true scalable application is still far from infancy. Moreover, we need to understand the effectiveness of a team working on such projects. The effectiveness of a frontend team working on the frontend typically is not able to provide a neat piece of software which can scale and satisfy the requirements of all complex applications.

Similarly, from the database point of view, the DBAs are trying hard to provide a database architecture which can scale and also satisfy the typical requirements of today’s analytics as well. Analytics has actually become the Achilles heel of many database architects. They are copying/moving the data in different databases for different data scientist which trying to make a sense out of the data stored. The result is using big data technologies and moving from normalized to demoralized data structure and in result creating a lot of redundant data.

Is there a solution/thought/approach which can take on these challenges heads on and provide a clean piece of architecture which can scale as well as increase the efficiency of teams working on it? This article will try to describe the idea of breaking up each monolithic piece into smaller, manageable pieces. In addition, this article will try to sum up different challenges that might come up during the migration of existing monoliths to micro components.

Core Benefits

• Flexibility — The process of changing the monolith to micro will to give you the most flexibility in terms of the various patterns at your disposal. There will be better chances of using all the best practices.
• Extensibility — Since the whole architecture will be based on small components, these components can be extended without any hassle.
• Reusability — Usage of micro components will enable the reusability of the components and fasten the development process. Complex components will be able to use the same micro components to further enabled resusability.
• Encapsulation — Breaking the monolith into micro components will enable the encapsulation of components. We can add new components without affecting the features of an existing application. This enables testing, reusability, and reliability, as features will be responsible for their functions and do not consider the state of the application.
• Technology Independence — You can choose any technology to create different component as long as you have the run times. Each component can be put inside separate container which allows independence from technology.

Challenges in Migration of existing Monolith to Micro Components

Creating a new system with the basic concept of micro components will be far easier than migrating the existing monolithic system. Some of the problems that might come in your way are:

• Integration Problems: Your existing project might be using a lot of integration with third party systems. This might be a major challenge to know if the new migration will still work without hassle.
• Protocols Problems: The newer micro frameworks might use different protocols than their earlier counterparts. For example, moving from a SOAP based service architecture to a gRPC based interaction might affect the deployability of the final solution.
• Removal of existing bugs: There might be existing bugs in earlier monolith. Migration to a new architecture must ensure that those bugs are fixed and documented well during the migration. This means that you might have to spend additional round of testing for existing solution.
• Database Splitting Issues: Before splitting a database apart, you will need to consider issues of data synchronization during transition, logical versus physical schema decomposition, transactional integrity, joins, latency, and more.
• Lost Source code of Legacy Libraries: In some of the situations, the source code of legacy libraries is not available so as to migrate it to new architecture. This can be one of the biggest limitation if your code is dependent on such libraries. One option can be rewriting that legacy code and moving to new technologies but it will not be cost effective.

Resources

• Monolith to Microservices by Sam Newman
• https://microservices.io/refactoring/
• https://martinfowler.com/articles/break-monolith-into-microservices.html
• https://martinfowler.com/bliki/StranglerFigApplication.html
• https://martinfowler.com/articles/micro-frontends.html

My Bio

I am a hands on technocrat having versatile skills. I have worked in a highly scalable and agile environment across Mobile, web, cloud, enterprise and AI applications. I have designed and implemented microservices based application and also migrated the existing monoliths into the microservices architecture. If you have a full time requirement in high end consulting, I am interested in that. Please write to me at [email protected].