Anurag Banka | Software Development Engineer II in Gurgaon, India

In this post, I would like to give a glimpse of a practical application of micro-service on a monolith product which leads to better team productivity, customer experience, and product scalability.

Monolith are services; which are not easy to scale, hard to maintain, and can become a bottleneck for the growth of the product. Rapidly changing customer demand and business circumstances need a flexible and scalable system where new ideas can be introduced at a fast pace. Most of the monolithic services have a fixed release cycle of bi-weekly or monthly due to the cumbersome nature of testing and tight coupling of the domain.

By breaking a complex monolith architecture into a micro-service architecture, based on the different responsibilities of product, creates a solution for scaling both system and business. Articles from Martine Fowler and Chris Richardson are a great source of learning to bring best of micro-service practice in your domain. A typical transition from monolith to micro-service looks like below.

“If you can’t explain it simply, you don’t understand it well enough.” – Albert Einstein

The above statement is very well applicable for monolith service. It’s applicable to all big and small organizations. With a rapidly changing product requirement and team members, it’s a challenge to retain domain knowledge – and existing test framework was never sufficient enough to cover each expects of a system under test.

Micro-services are definitely a solution to a problem faced in monolith but it’s no silver bullet and several challenges occur to reach in a state of micro-services. Some big challenges to face while applying micro-service architectural reform in a billion $ system are

• Defining testing strategy for a new stack
• Defining new monitoring methods
• Ensuring high uptime of a system
• Collective domain knowledge

Knowing your domain is key to success for breaking any monolith system into Micro-service, but it’s never the case –  you know all your domain and dependencies via any testing framework may cover most of it but some corner cases might be missing.

Known risk can’t be taken for a live running system if you have a slight doubt on your domain understanding or testing suite. Black box testing (shadow testing) is a solution for building a new system in parity with the old one.

A three-front testing framework to ensure parity at upstream, downstream and database can help in building confidence in migration to the new stack. A typical orchestration of such black box testing would look like the below when at every external end parity will be ensured.

Following the above strategy, it was easy to catch approx. 500 bugs in the new stack. Also, the same framework resulted as a bridge between old and new stack for easy migration. It provided both system performance and business performance metrics to measure the success rate of the new system.

Every change for making the system better should be measured in terms of success metrics of the system and some of the metrics we achieved in the last 6 months are:

• More than 1% improvement in success rate, direct impact on revenue
• Easy scalability of functionality
• Easy rollout and rollback, N releases in a day vs once a month release
• Cloud Native solution
• Faster and Better customer support

At Expedia Group, we practice in keeping our product as simple as possible. It helps in taking fast business requirement adoption and building an internal open source culture where a team can collaborate and speed up delivery of new ideas.

Every new system comes with a new set of challenges, now you have thousands of services and a ton of data to make a better business decision for new success stories. This is just the beginning of a technology shift, we are on our journey of cloud, machine learning…

Come and join us in our journey of “Bringing the world within reach” through the power of technology.