Why Micro-services, Why Now?

API based programming model is nothing new for developer community. However in the past, developer community preferred to build a monolith application where functions are tightly integrated, can be patched as a single unit, and fixed and tested with coherency.

What changed now? Why the sudden buzz on API/microservice based architecture?

Well, I believe following are the reasons:

1. Over the last decade, the applications became more and more complex, a lot more functionality got added than that was first envisaged, and there came a point where the advantages of monolith started giving demising returns and in some cases the very strength became its weakness. e.g. for a small change in a simple functionality, there is a need to test the whole big application OR to change a functionality, we have to touch many core service points because there is tight coupling without standardized clearly defined interface etc.

2. Complexities of functionalities and external integration led to requirement of different kind of development expertise based on need within a single application, and experts in different domains preferred different set of tools and techniques. This is not exactly a convenient situation for a monolith app, which needs to be built on same middleware platform using same development framework. So instead of killing the productivity and force fitting the tools, the natural choice for developers was to make an architectural choice to start developing functions as independent units using the tools best suited for their work, and expose the functionality to consumers via well defined interface, which made it easier for change management etc.

3. Progress is containers/devops/automation made it that much easy for developers to spawn different kind of dev environments without making that itself an intimidating task. Since environments can be spawned on demand , as self service, and which were production like, they figured this is easier way to test and if required fail fast. Standardization of network connectivity and sufficiency of bandwidth only helped the cause.

4. And of course there are early adopters who we now call as “masters of scale” who tested the success with adoption of this architecture and made this as aspirational goal for extended developer community, making this architecture a preferred choice instead of forced option.

In couple of client engagements, I have seen the benefits even as Enterprise Levels when they adopt this strategy. It is easier said than done though, especially for legacy applications. But given that the cloud based technologies which automation are set to become datacenter standards, I think changing almost all monoliths to micro service based architecture is not a question of if, but when.

There are some pitfalls on the way though. If troubleshooting a transaction within a monolith was difficult enough, now imagine what happens when a transaction is basically flowing through potentially 100s of micro-services and hence need to create correlation across all those now independent services. I hope our mature analytics/AI provides some breather here, but in my view this is definitely one area to watch for.

Vidhya is my colleague, who has extensively used micro service based methodology both for development as well as consumer of API available. She has been recently instrumental is developing exciting demonstrations for enterprises to showcase the outcomes that they could potentially drive by embracing new gen apps.

At techathena, we invite you to listen to her to know more about her experiences with this exciting technology.

Join our session (on the below link), 25th May, 10-11 AM, to know more about micro-services and share each others experience. 

https://www.youtube.com/watch?v=a1qGYOVvHwc