Microservices – Panacea or just another pattern?

Posted by

Microservices is the keyword these days. And it is solving many problems, helping applications become agile and the support team getting better sleep. But, as it is catching the fire, it also raised eyebrows – is it necessary to have microservices in my application?

The other day, I faced this question from such an angle. And, here I want to express my thoughts and experiences with microservices.

First, let us accept that Microservices is just another design pattern. Each design pattern has a scope and is actually a path or approach to the solution to a design problem. So, microservices is an approach for a design problem. Let us appreciate the problem then. The problem is the first issue we talk about object orientation – high cohesion and low coupling. We have been talking about this issue for decades now and everybody reading this understands it.

For the same problem, we talked about in-proc and out-proc processes when we were kids in programming. Then also, we were worried about managing application – but with a little different problem – the problem of stability of the application. We had a hard time with the challenges of components failing or misbehaving. And out-proc helped us a lot in many scenarios – from stability to throughput to management.

Perhaps, those problems were at a micro level if we look at a large system now. But the problem is still the same. Little different from some other management angles – complex monolith, scalability and agility.

The problem of the monolith – monolith when we started our programming life was just a single application with a single executable with or without a lot of in-proc binaries. As the scale goes up, the challenge on monolith also comes from the angle of other managerial challenges. When we have a behemoth, the challenge is about code management, change management, build management, deployment management, version management, dependency, monitoring, scaling and what not? So, when the challenge has grown up, the approach to the solution (read design pattern) need to be also equally strong. You cannot take a spoon and take out a bucket of water from your space.

Problem of scalability – With modern applications being targetted for multi-tenant SaaS scenarios and we being promising all the time to business that we shall always handle all business problem from a sudden spike in the sales to a slump or changing a part of the business without impacting others, the applications that run the business need to be able to deliver the promise as well. So, here comes the 3 dimension scaling. I shall write specifically about multi-dimensional scaling little later. But, in short, we should be able to scale different part of the applications with different degree and dimension of scaling. This was not a part of the problem when we started our programming journey.

Agility is another dimension of the problem at hand. Like we have MNP today and we can change our mobile service provider at will without impacting the address books of our contacts, the challenge for an enterprise application is to replace a part of it without letting the users know. Microservices definitely help in this regard.

The other challenge that I have not talked about is the partitioning of the persistence layer of the enterprise application. That has been the toughest guy to crack all through the time. However in the last decade, a lot of changes evolved and coupled with microservices, it could deliver to the enterprise to a good length.

So, enough for today. I just talked about the microservices as the answer to some problems and possibly clarifies that though it might not be a panacea to the enterprise problems, it can definitely help the enterprise have a good sleep.

Leave a Reply

Your email address will not be published. Required fields are marked *