Monolith to Microservices Testing Strategy

Even though the majority of the large applications that we see today is built on a monolith architecture, their complexities are being realized now as they grow in size vertically and horizontally. The modularity in concept and logic is not reflected in the architecture which makes these applications complex to comprehend and upscale. The simplicity offered by monolith architecture in terms of development, testing, and deployment goes missing when it comes to reliability and adopting newer technologies. That’s where microservices architecture is gaining grounds. 

Before we get down to strategizing the shift from the monolith to microservices, let’s first understand what is wrong with Monolith architecture and why do we need to shift to Microservices. 

Monolith Architecture

Monolith is an all-encompassing single-tier architecture which contains all the elements of software. It will have all the layers required to manage the application including the user interface, business logic, database and 3rd party integration if any. This will serve perfectly for simple applications. While it is simple to manage, as the application gets complicated, over time, it becomes difficult to manage. Change management becomes a huge challenge and so does upscaling. Upgrading to newer technologies is another issue due to the complexity involved in changing the entire application. 

Microservices Architecture

In microservices architecture, the entire application is split into small units, each independent and reusable which make them easier to manage. It is a distributed system where each microservice unit has its own business logic, database and integration layers that make it autonomous, serving a tiny purpose and hence, called a microservice. In a microservice architecture, the application will consist of many microservices which complete it. For example, a commerce application can be considered as a collection of microservices such as the shipping service, payment gateway, cart service, catalog service, order service and authorization. This way, managing the application gets less complicated. 

The Strategy – Tested & Proven

Now that the need to shift from monolith to microservices is established, let’s get down to strategize the same in detail:

Identify and Isolate the Microservices

The microservices or autonomous units have to be identified first. Every process or unit of the application that can exist independently can be considered as a micro-process and isolated from the rest of the processes. This way, they can be reused and managed better. Each such microservice should have its own business logic which should not be cross-related to another. This is otherwise called domain modelling. 

Determine the right size of the service

Once the microservices are identified and isolated, its right size has to be identified. It should not end up being a small monolith. Ideally, a microservice should cater to a single purpose or responsibility which will make managing it simple and more effective. The testers know what exactly is expected of the unit and thus can ensure its quality more effectively. Further, each unit should be replaceable as per the need of the hour and changing technologies. 

Consumer-driven test cases

While retaining the independence and replaceability of microservices, they should also be able to communicate perfectly with other related units and applications. The best way to ensure the functionality of a microservice is with consumer-driven contracts where the consumer gives inputs as to what’s expected of the microservice. The test-cases are drawn based on the consumers’ inputs to make sure that they meet the expected response. Customer-driven contracts help the developer and tester understand what’s expected of the unit. Together, they make sure that each microservice performs as expected. 

Proactive Monitoring & Alarm

Actively listening to the microservices will help identify how they are performing. Runtime solutions are imperative to keep things running in the microservices architecture. This is possible when you are testing during the production itself, keeping the monitoring and alarm systems proactive. 

Keep 2-way service discovery open

Microservices need to discover the related services and communicate with them effectively for the application to perform as expected. This is possible only when the microservice is discoverable and is also able to discover the right services to connect and communicate with. Service discovery can be ensured using environment variables in smaller systems and for more sophisticated ones, systems such as Consul, Apache Zookeeper etc. can help.

Independent Deployment

One of the main features of microservices is that it should be self-deployable. It should either be embedded in a container or have a runtime container so that it can run on its own in a reliable way when there are multiple requests. Typically, these come with a load balancer such as Netflix Eureka which also serves the purpose of a service registry. 

On-demand release pipeline

When each microservice comes with an on-demand release pipeline, the application build and release costs reduce significantly. This is another reason why microservices are preferred. Accordingly, at any given point of time, there could be any number of concurrent versions of the same microservice running. The newer versions can be time-tested and the older ones phased out as the case may be. If the newer versions have any glitch, the older ones can remain running till the glitch is fixed and proven. 

 Feature flags for easier A/B testing 

Make sure that the microservices come with feature-flags that can be toggled on or off as required. This makes A/B testing of migrated services much easier. This can help identify similar microservices prevailing in the same environment and to reroute traffic to the ones available, improving the speed and performance of the application. 

Though the monolith architecture is the easiest to adopt and built on to, its complexity increases as it grows. Adopting a microservice-first approach will be more beneficial to the entire IT team as it makes the entire application more manageable and scalable. Standardizing the project procedure will help the developers adopt this as the norm which will help them make quick and cleanly built microservices. 

Since this is not a one-size-fits-all pattern, every organization has to find out the right strategy to adopt, right from deciding upon whether or not to shift from monolith to microservices and how to migrate, if it helps. 

Please note its written based on my experience.

#microservices #migration #ecommerce #automation