Buzzwords — Micro-Services. The Terminology of the word…
By: Mohit Sharma
Tags: Monolithic Architecture, Resilience, Scalability, Performance, Microservices

The Terminology of the word Microservice is found almost everywhere now, used so often that even a stand-alone application is first thought of as a Micro service. But still the idea of Microservice, the definition of it remains known to a handful of people and so every time you ask it the first thing a person does it go to our favorite teacher “Wikipedia” and tries to swallow this:

Microservices — also known as the microservice architecture — is an architectural style that structures an application as a collection of services that are: Highly maintainable and testable,Loosely coupled,Independently deployable,Organized around business capabilities,Owned by a small team.

But does it answer why is it called as MicroService? How does it even work ? How is it loosely coupled from even what is loosely coupled to?

Microservice Architecture

So why is it called Micro-Service ?

Microservice is an architecture, it's the methodology that is meant to focus only on building a module which has single function. And these functions are well-defined with their interfaces which have all the things required to perform that piece of operation.

This idea of performing a single operation helps to create a loosely coupled architecture. That's how will pull ourselves away from traditionally build monolithic pieces of software. These Monoliths where a single piece of bundled software tightly coupled, interdependent on each other, showing minimum to no modularity in the business functional separations.

A typical Monolith design.

Why and how is it benefiting us to use this architecture instead of Monoliths ?

1. Resilient: Your system remains loosely coupled, a single microservice going down won't get your entire application down, the biggest drawback which monoliths have.

Example: Suppose we have two Micro-services CatalogService and PaymentService.

In an idle situation a customer visiting the Shopping Website won't always complete the payment and place the order after browsing the catalog.

If my PaymentService is not accepting the payments due to any downtown reasons, my shopping site will be displaying my entire catalog and customers can still visit, choose something, even add to their basket.

2. Scalable: Demand and Supply, these two notions are common for every business in the world. The greater the demand the more supply is needed. This is also applicable for the microservice paradigm. Microservices are easy to scale which every functionality requires a scaling you turn it up, without affecting any other services. If you feel your shopping site is getting much more traffic than the usual, and you are getting a lot of Order failure while doing the Payments, you can scale up the PaymentsService to meet the demand.

3. Rapid Development and faster deployments: In monoliths we have all the functionalities in a single package, so it's hard to divide the single functionality among different developers and testers, which creates a longer development cycle. In case of Microservices, you can have smaller teams working on single functionality, as soon as it is ready we can take it up for testing. This makes rapid development.

This is true for the deployments too, if we have to enhance or fix a bug for a single functionality we can work on that single piece and take the advantage of Continuous Deployments (CD).

Example: If my shopping site is facing issue with CustomerService when he is trying to update his personal details, I can fix up that module and plan a release for it through the CD.

4. Fault Isolation: A large enterprise application can remain almost unaffected by the failure of a single module.

5. Ease to Understand: Separation of Concerns, distributed functionality among services, creates a better understanding for the developer.

Example: For my Shopping Site I can have three developers working together to achieve a common goal of the site. But while dividing the responsibilities each of them will be responsible for only one Service. Dev One will be working on InventoryService, Dev 2 working on OrderService while Dev 3 on PaymentService.

What are the Challenges ???