What are Microservices?

Introduction to Microservices

Though there is no official definition of the microservice, however the closest definition I came across: Microservices are independently releasable services that are modeled around a business domain.

Before we delve into microservices architecture, let's go back to history.

Over the years, IT organizations have been building software systems based on the team's expertise and responsibility.

• Database Admin and Developers - Team that handles and deals with persistence specifically.
• Backend Developer - Team that builds the backend part of the application using any high-level language, Java, C++, etc.
• Frontend Developers - Team that builds user interfaces.

This separation between the three teams explains the reason for having a three-layer architecture, where each team is responsible for one layer based on the responsibility.

The chief benefit of the three-tier architecture is that each tier runs on its infrastructure. It can be developed simultaneously by a separate development team and updated or scaled as needed without impacting the other tiers.

Over the years, this architecture served well, but as the software system's complexity and the code's size grew due to the nature of business requirements. As a result, the application became a monolith, and this architecture could not cope with the software system's complexity.

It is a common phenomenon that any update in the functionality requires changes in all the tiers, and these changes will need to be managed by each team and deployed in the correct order.

As the scope of change is spread across all three tiers, this calls for designing the system based on business functionality where each team is end-to-end responsible for delivering specific business functionality.

This shift in the approach gave the idea of alternate architecture, "Microservice Architecture".

A system implementing microservices architecture will look like this: Three teams each are responsible for one single business function.

Principle of Microservices

A microservice application must follow the below principles:

• Independently Deployable

Independent deployable is the idea that a service can be deployed without deploying other related services. This is of the highest importance out of all the other principles. Achieving this will bring other benefits for free. To ensure independent deployability, you are forced to build services that are; loosely coupled, have evolving interfaces, and ensure stable contracts.

• Modeled Around Business Functionality

Microservices should be modeled around business functionality rather than technical functionality or feature techniques like domain-driven design advocate structuring the code to represent the real-world domain. The same idea can be used to define our service boundaries.

• Owns the State

Each service should own its state. In other words, a service should not share a database. If one service wants to access data owned by another, it should ask for it. This principle opens the door for polyglot persistence; for example, one service can use RDBMS for the store while another can use a document database.

• Share Information using Well-Defined Interfaces

This principle complements the "Own the state", Microservices should share information to relate services using well-defined interfaces like REST, gRPC GraphQL, Messaging Queue, or any other similar mechanism.

The last two principles allow technology heterogeneity. Each service is independent in deciding languages and technology that suit its purpose.

Advantages and Disadvantages of Microservices

Every system has advantages and disadvantages, and microservices are no exception. Let's see some advantages and disadvantages of microservices.

Advantages of Microservices

• Scaling - Unlike monoliths where everything has to be scaled together, microservices are easier to scale because they are independently deployable, and the cost of scaling is much less than scaling a monolith because only the target service can be scaled.
• Resiliency - Microservice architecture is more resilient than monolith as the fault can be contained within a single service. A faulty service can be taken out till it becomes healthy again.
• Faster Releases - Changes can be rolled out in production quickly, as microservice is less prone to delivery contention, as one team is responsible for it.
• Small Codebase - Unlike monolith, microservices codebases are smaller, and it's easier to maintain and deploy.
• Resource Requirement - It can run on commodity hardware, unlike monolith, which requires a high-end processor and memory. But the overall operational costs can go high due to the dedicated computing requirement for each service.

Disadvantages of Microservices

• Complexity - All the complexity of distributed systems is applied to microservice architecture. It should be built considering the fallacies of the distributed system from day one.
• Monitoring and Troubleshooting - Difficult to manage and monitor many services without proper tools.
• Reporting - With monolith architecture, reporting is easier because data is available in a single database. We have made it difficult with a microservice architecture as we have data spread across multiple services.
• Cost - Overall cost will go up due to several factors. You will need more hardware, network, and supporting software. Organizations should embrace microservice architecture only if other benefits outweigh the cost.

Challenges with Microservices Architecture

There are a few challenges with microservices architecture.

• Data Consistency - As microservice owns its state. Therefore consistency is restricted within a single service; however, our operation now spans multiple services. If a transaction is failed in one service, then our echo system should be able to undo the operation entirely.
• Complex Testing- Unit testing may be easier with microservices; integration testing is not. The components are distributed, and developers can’t test an entire system from their machines.
• Unclear Domain - Breaking microservice on an unclear domain or premature breaking will manifest itself as "Distributed Monolith".
  A distributed monolith has all the disadvantages of a microservice and the disadvantages of a single-process monolith.

Signs of distributed monolith:

• Change in one service causes re-deployment of other services.
• Service shares database.
• Long release processes and rigorous release planning.
• Panic before releases.

Best Practices for Microservices

• Use async communication - To avoid building tightly coupled components, consider using asynchronous communication wherever possible. Asynchronous communication provides loose coupling among services.
• Maintain backward compatibility - To deploy changes independently, ensure contract and API changes are backward compatible. When making a breaking change, expose a new version of your endpoint while continuing to support older versions. Consumers can choose to use the new version at their convenience.
• Version your releases - Use semantic versioning to convey the type of changes with each release. So that the consumer of your service knows whether a release is major, minor, or patch.
• Use Circuit breaker to avoid cascading failure - A circuit breaker is a device whose purpose is to protect electrical equipment from damage in case of a short circuit or overload. The same pattern can be applied to microservices. A software circuit breaker stops sending requests to a service that is not responding or responding promptly so that a faulty service can be isolated, which stops cascading failure to other dependent services.