Introduction to Microservices

Over the past few years, I have learned that the easiest way to cover the most important subtopics in a topic is to go through a list of interview questions. I have learned so many things when I get ready for interviews. So I have put a link at the end of this post which has Microservices interview questions. You should check it out.

That is just a quick tip. Lets move to the content now.

What is a Microservice?

I have worked in projects with more than 50 modules, more than 50 people worked on those modules, all deployed at once in a WAR file and have dependencies like a web (Everything is tightly coupled). Testing, deploying, managing dependencies and even building and running the project was a cumbersome task. These are monolithic applications.

A monolithic application puts all its functionality into a single process. But Microservice Architecture puts each element of functionality into a separate service.

This must be the simplest explanation!

More Details

The microservices model is the opposite of traditional monolithic software. Monolithics are appropriate if you have few modules and the development process is not that complicated. Microservices are popular in companies where there are so many services, modules and requires agility and scalability. Each service is self-contained and should implement a single business capability. The services are built around the business capability.

Examples: User-service to handle users, loan-service to manage loan functionality, buy-service to handle buys, vehicle-service to manage vehicles.

Unlike monolithic, microservices (collection of small services) can run in its own process and deployed, upgraded, scales and restarted independently. Those services can communicate via HTTP using Rest services or other messaging mechanism like JMS. Below is a diagram which explains how Microservices work. Having several independent services and methods of communication is not enough. There are more components involved and needs more orchestration.

Characteristics of Microservices

Services are components. There are component in huge monolithic applications and those are libraries and called using in-memory functions ( Example: user-business.jar, car-business.jar, auth-service.jar). In microservices, services act as modules and communicated via HTTP. This helps to deploy each component independently.

Organized around Business Capabilities. Create components and teams based on the business requirement. Example: to manage the user-service component, there should be a team consisting of UI experts, Software Developers, QA experts, DB experts, Projects Managers other experts needed.

Product mindset. The team should own a product over its full lifetime rather than handing it over to different maintenance organization.

Smart endpoints. All the logic should be included in the service itself. Any logic should not be included in the communication mechanism.

Decentralized Governance. Each service can use different technologies and tools based on the requirements.

Decentralized Data Management. Each service can manage its own database.

Infrastructure Automation. Use CI, CD, and other tools to create build pipelines.

Design for failure. Applications should be able to handle failures. It is important to detect failures of services quickly and restore automatically if possible. Monitoring and logging the service information is important in this case.