How to manage the move to microservices in a mature way?

Microservices in the last few years have become a well-known concept and the modus operandi methodology for building modern applications to drive Cloud transformations.

The approach to microservices, however, differs from organization to organization, and there is no ready-made panacea. By performing a mere replication of these approaches can result in incurring insurmountable technical debt.

Organizations adopt the microservices journey typically to combat the issues around slow time to market, complex and heavily customized applications, testing nightmares, scalability/stability issues, velocity, technology binding, vendor locks, continuous delivery, cost factor, and the list goes on.

A lot of initial time has to be spent to understand the complexities of the existing monolith system, core issues with the legacy, technology forecast, business limitations, future business requirements, organization processes, their strengths and weaknesses, team sizes, operational readiness, ways of working, Cloud readiness, integration dependencies, and several other factors before choosing an approach.

A typical transformation of moving to microservices can either be the concept of Brownfield or Greenfield or Bluefield development.

Brownfield approach is where the monolith, along with the new system, co-exist together for the entire journey. The end customer has no impact as facades redirect to either the new or the legacy platform. This approach is apt when the legacy application is not that complex, and it’s easy to create a demarcation between legacy and the newly built services around it.
If the core domains of the monolith are not tampered with, and new services are built around the perimeter of the monolith, it ensures quick implementation of new features and enhancements. However, the downfall is that flexibility is decreased as the core domains are hard to be modified. If the organization’s priority is faster time to market and velocity, maybe this is not a suitable approach.

In a Greenfield approach, the whole monolithic application is built from scratch on completely new software with no dependency on the existing platform. This is the most straightforward choice if the monolith is pretty complex and there is a need for a new strategy or direction for the business. Software development has changed in the last decade and with the advent of Cloud and innumerable SaaS-based platforms, this may turn out to be a pragmatic approach.

The third approach is the Bluefield, approach which is a kind of amalgamation of the Brownfield and Greenfield approaches. It is fundamentally building the new microservices-based system from the ground up by dismantling the existing legacy application. This approach is the complex of the three and one of the prevalent hurdles in this approach is the underestimation of the business teams who want IT organizations to deliver new functionalities irrespective of the underlying running system.

Irrespective of the chosen transformation method, a microservice journey is complex and seldom have organizations been successful. Intermittent checks are necessary to be taken, with regards to where you stand and correlate with where you started from.

However,

• If after building services, you are in a situation where all developers congregate to fix production issues
• If teams require several developers and take umpteen number of days to fix issues
• If your applications have several hours of downtime
• If your services cannot be tested as a single entity
• If the teams fear to make changes to the code when adding new features
• If you are reverting code and releases instead of failing fast or failing forward
• If you are building services that access the same database
• If the services and functionality is spread across multiple services and teams
• If your applications take multiple teams and several people to deploy changes to production
• If there are too many services depending on each other
• If your teams are still writing and performing manual tests
• If you are building services with hundreds of Classes having hundreds of lines of code
• If you have several services that have not been modified for several months

You have probably ended up building another monolith!

Want to know more about microservices and how you can make a mature transition without falling into the loop of building a monolith? Reach out to me and we can take the discussion further!

Published by: Shailendra Bhatt
Managing Delivery Architect at Capgemini Sweden (Digital and Cloud Solutions)

Shailendra is a skilled Cloud Solutions Architect with over 18 years of experience in building modern digital platforms for several major clients across USA and Europe. He has led and been part of several large end to end digital solutions for different clients and demonstrated expertise in architecting, implementing and supporting enterprise grade technical solutions. His primary focus is on Cloud Transformation and Modernization, Automation, Software Architecture, Digital Commerce and Omni Channel Solutions.