Hybrid Microservices: Use What You Want and Leave the Rest

I have been reading lots of articles and buzz around the word "microservices" for a long time now. Everywhere, industries and people associated with it are leveraging this next level of SOA.

While talking about, reading about, and implementing microservices, it makes me fascinated in a way that I have created my own definition of it: "Use what you want and leave the rest of it!" Or we can simply call it hybrid microservices.

Each architecture comes with a pattern and set of processes, which makes that architecture complete. Microservices itself is a pattern or processes divided at the micro level of categories, and these micro-categories are evolved to serve the following bottlenecks in today's API driven world.

Creating a Highly Available and Maintainable System

Every industry or organization has different needs when we talk about high availability of systems. For example, eCommerce, finance, and social platforms need high availability of their systems.

What I need to discuss here is the need for microservices in small domains or industries whose systems are still running on old monolithic architecture.

"Use what you want and leave the rest of it," perfectly fits for such industries. Let's understand first how we typically explain a basic microservice architecture:

"I am running a small scale educational organization which has some basic departments in it. If we talk about in-house systems, they typically have monolithic architecture structure running on a single instance which serves each department as a single unit."

What if that unit fails? That will bring all departments' work to a halt.

Now consider a scenario where you have DepartMent Service, Administration Service, Student Service, Extra Curricular Service etc., and running on different clusters and used by different units. They can interact with each other and share data for different purposes as needed. If one service fails, others work will never be impacted.

Well, that is one part of the microservices concept broken down into services that purely depend on what the business needs. One can easily come up with the same type of architecture behavior.

Now, part two of this architectural style is having its own set of databases/data layer, which may be cumbersome to some of the business organizations because of certain limitations or policies. That is what I mean by "leave the rest of it." By doing so, one cannot assure it is 99% available, but the availability ratio is still higher than monolithic architecture, with the benefits of easy maintainability.

The Next Step- Already Taken!

Organizations seem somewhat resistant to making a move in a direction of trendsetters in IT. It's quite tough sometimes to make stakeholders understand what is in the future, and anyways, nobody can predict that.

With steps taken on segregating services at the micro level, you have already taken the "next step" to the future of IT. This is a very bold statement- what I mean is, in terms of technology, you have already made your architecture distributed and stateless, and that's what is at the core of the computing world.

You have a weapon ready with the least effort involved and you can leverage this beauty as needed.