Monolithic migration as the common use case

When we analyze the preceding enterprises, there is one common theme. All these enterprises started with monolithic applications and transitioned to microservices architecture by applying learning and pain points from their previous editions.

Even today, many start-ups are starting with monolith as it is easy to start, conceptualize, and then slowly move them to microservices when the demand arises. Monolithic to microservices migration scenarios have an added advantage that we have all information upfront, readily available for refactoring.

Although it is a monolithic transformation for all of those enterprises, the catalysts were different for different organizations. Some of the common motivations are lack of scalability, long development cycles, process automation, manageability, and changes in business models.

While monolithic migrations are no brainers, there are opportunities to build ground-up microservices. More than building ground-up systems, look for an opportunity to build smaller services that are quick wins for the business. For example, adding a trucking service to an airline's end-to-end cargo management system, or adding a customer scoring service to a retailer's loyalty system. These could be implemented as independent microservices exchanging messages with their respective monolithic applications.

Another point is that many of the organizations are using microservices only for their business' critical and customer engagement applications, leaving the rest of their legacy monolithic applications to take its own trajectory.

Another important observation is that most of the organizations examined previously are at different levels of maturity in their microservices journey. When eBay transitioned from the monolithic application in the early 2000s, they functionally split the application into smaller, independent, deployable units. These logically divided units are wrapped with web services. While single responsibility and autonomy are their underpinning principles, the architectures are limited to the technologies and tools available at that point in time. Organizations such as Netflix and Airbnb built capabilities of their own to solve specific challenges they faced. To summarize, all of them are not truly microservices, but are small, business-aligned services following the same characteristics.

There is no state called definite or ultimate microservices. It is a journey, and it is evolving and maturing day by day. The mantra for architects and developers is the replaceability principle--build an architecture that maximizes the ability to replace its parts and minimizes the cost of replacing its parts. The bottom line is that enterprises shouldn't attempt to develop microservices by just following the hype.