Decomposition of Enterprise legacy systems into microservices

A journey towards building cloud-native applications…

Experiences untold…

The software development lifecycle has been evolved drastically over the past few years, and It may be an apt statement to define the application development process as an Art. Being an artisan in this ecosystem, I would like to recap our interesting experiences while accomplishing our recent mission, transforming legacy Webservices and ETL (Extract-Transform-Load) jobs into Microservices patterns.

Although there are so many references around the globe to define how to build and deploy microservices, This is a sincere attempt to capture the potential activities one could avoid when traveling through this journey for a better sign-off. Sometimes it’s better to know What not to do than What to do.

If you are working in an organization that places lots of restrictions on how developers can do their work, then microservices may not be for you. — Sam Newman

Why this is more an art than a migration…

In today’s world, transforming a monolithic legacy system into a microservices pattern is becoming quite common. Although many transformations are happening, very few understand that technology up-gradation is always different from business value addition. The vision has to be clear in improving the client experience, and it needs an artistic approach to plan and phase out the operations for delivery. It always takes time for an early team to enter into microservices architecture from an environment surrounded by monolithic. There is a craving need where the team folks shift their mindset to reactive culture while creating solutions. The distribution of teams with the right people is equally important as the distribution of services by their business values.

The easiest way to start this journey is to build a simple service, draw out services based on vertical capabilities, and define the bounded context that is business-critical and subject to frequent change. Attempting to replace the whole monolithic application with microservices overnight is a bad idea. The Strangler Pattern is one such popular pattern that can be considered when migrating a legacy system.

Gather together those things that change for the same reason, and separate those things that change for different reasons. — Robert Martin

The myth behind NoSQL…

While decomposing a complex application into microservices requires defining services by their business capabilities, It also demands customizing the existing storage and database into independent infrastructure components exclusive for individual microservices. No SQL databases become an obvious choice due to the flexible data models they support, which are quite different from traditional data characteristics.

Although the NoSQL databases can be a good fit for this architecture, the relaxed policies and scalability features offered by the NoSQL database must be considered by the team carefully without assuming their consequences. The “No schema” feature should not be taken for granted during the data modeling process because A bad design is always a problem causer irrespective of the database vendor used.

Extracting the best performance in NoSQL is based on the database design that supports frequent data access patterns and queries. It is the responsibility of the developers and data architects to evaluate the application’s growth and usage during sizing, to consider the trade-offs between eventual consistency and data availability during the transaction (quorum) management, to determine the right sharding mechanism during the storage and distribution.

The golden rule: can you make a change to a service and deploy it by itself without changing anything else? — Sam Newman

Why events are critical …

Reactive systems in microservices architecture follow an event-driven approach for inter-service communications. An event-driven system distances itself from a message-driven system where the former emits an event upon performing a particular action or reaching a specific state while the latter deals with an object of data sent to specific addressable recipients that await the arrival of messages.

Modern real-time systems qualify an event as more than just a change in state or behavior, which can potentially trace the system’s dynamics. The volume of events emitted by a component challenges the resiliency of the whole system. Hence event is no more just a signal but a critical entity that induces the need for a smart messaging platform like Apache Kafka and intelligent consumer that follows strategies like non-blocking and back-pressure.

Matured systems implement data pipelines and rational workflows to perform data migration and integration. So creating the messaging channel with the right attributes, writing publisher and consumer clients with appropriate property values are crucial in loading the data in real-time and tuning the application scalability.

The Monolithic architecture is not an anti-pattern — Chris Richardson

Final Insights …

• Monolithic patterns and Microservices are alternative ways of architecting an application. They are not replacements.
• Migrating a monolithic application to microservices should cater to the business need and add customer value. It must not be a mere technology upgrade.
• An optimal design yields high performance in any system. There should be no compromise in the designing process.
• Transforming into microservices includes a change in architecture and mindset as well.