Microservices With a Monolithic Style of Testing — Part 1

In times when there are thousands of organizations vying for their existence in a competitive world, faster rollouts of a feature in their respective domains are of the utmost priority. To overcome this problem, the adoption of microservices architecture in small and large-scale companies is growing at an exponential rate. But, this architectural shift requires altogether a new pair of glasses to look at how development, testing, and delivering a product differs from a regular monolithic gigantic service. In my previous post, I briefly talked about how a developer plays an important role in enabling the real benefits of using microservice architecture over a monolith. In this post, I will briefly talk about why there is a growing need to make a change in terms of testing strategies when companies are transitioning from monolithic to microservices architecture.

By definition, a transition to microservices from a monolith involves breaking a monolithic application or service into more logical, isolated components. Let's take an example here: a product which can book tickets for different trains. In the monolithic world, there will be a single application with a UI (User Interface) and backend code, which will do business logic (and talk to a database), bundled up in a single deployable artifact. 

In the microservice world, there will be a minimum of two different applications bundled up in two different deployable artifacts, one with a UI and other with a backend service which will do business logic (and talk to a database). 

This transition from monolith to microservices will help in delivering UI or backend changes INDEPENDENTLY (this is in caps, bold, and italics for a purpose). This is perfect in terms of architecture and development for the faster rollouts, but this transition will require altogether different testing strategy.

In other words, if they are independent services, then why not test them individually for faster feedback and fewer failure points to debug? For a monolithic diagram, running a test only has two failure points: either the UI/backend or database is not behaving as it is supposed to.

Now consider, if the same testing strategy as used in the monolith is used to test services in a microservices diagram, failure points have increased from two to three. That means more time required to debug and pinpoint which component is the culprit. More time to debug means slower rollouts of features, which is not what we are intending to do. 

In more complex systems, where there will be more than 30-40 microservices and each service is talking to its own databases, event handlers, logging mechanisms, etc, failure points are just going to multiply. Also, managing different environments for testing with so many microservices will be cumbersome. We can conclude here that a monolithic style of testing is not going to bear fruits for the microservice style of architecture.

For now, just give a thought to how can we treat them independently with testing glasses on. In my next post, I will talk about how we can break down the monolithic style of testing like we do for architecture.