In this tutorial, we are going to discuss Microservices Architecture for application designs where and why we use this architecture on our applications. We will discuss the benefits and challenges of this architecture. After that, we will design Microservices architecture in the e-commerce domain.
The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications.
Why are Microservices used?
Microservices were used to overcome the challenges of monolithic architecture that prevailed initially in the market and also enables you to deploy independent services.
So, before we move on to what is Microservices in simple words, let’s see the architecture that prevailed initially in the market i.e. the Monolithic Architecture.
In layman’s terms, you can say that its similar to a big container wherein all the software components of an application are assembled together and tightly packaged.
Following are the challenges of Monolithic Architecture:
- Inflexible – Monolithic applications cannot be built using different technologies
- Unreliable – Even if one feature of the system does not work, then the entire system does not work
- Unscalable – Applications cannot be scaled easily since each time the application needs to be updated, the complete system has to be rebuilt
- Blocks Continous Development – Many features of the applications cannot be built and deployed at the same time
- Slow Development – Development in monolithic applications take lot of time to be built since each and every feature has to be built one after the other
- Not Fit For Complex Applications – Features of complex applications have tightly coupled dependencies
The above challenges were the main reasons that led to the evolution of microservices. So, now let us understand what is Microservices in simple words?
What are Microservices?
Microservices are small business services that can work together and can be deployed independently. These services communicate with each other by talking over the network and bring many advantages with them.
Microservices is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.
In the given Architecture, each service is self-contained and implements a single business capability.
One of the biggest advantages is that they can be deployed independently. However, it offers the opportunity to work with many different technologies.
From Martin Fowlers Microservices article;
A microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP or gRPC API.
These services are built around business capabilities and independently deployable by a fully automated deployment process. There is a minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
So we can say that Microservices architecture is a cloud-native architectural approach in which applications are composed of many loosely coupled and independently deployable smaller components.
- have their own technology stack, included the database and data management model;
- communicate to each other over a combination of REST APIs, event streaming, and message brokers;
- are organized by business capability, with the line separating services often referred to as a bounded context.
Microservices are small, independent, and loosely coupled. A single small team of developers can write and maintain a service. Each service is a separate codebase, which can be managed by a small development team.
Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application. Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.
Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services. Services don’t need to share the same technology stack, libraries, or frameworks.
So these Characteristic brings us some key benefits;
- Code can be updated more easily — new features or functionality can be added without touching the entire application
- Teams can use different tech stacks and different programming languages for different components.
- Services can be scaled independently, it is reducing the waste and cost associated scale to entire applications because of a single feature might be facing too much load.
So we can say that; Each service is:
- Highly maintainable and testable — enables rapid and frequent development and deployment
- Loosely coupled with other services — enables a team to work independently the majority of time on their service(s) without being impacted by changing to other services and without affecting other services
- Independently deployable — enables a team to deploy their service without having to coordinate with other teams
- Capable of being developed by a small team — essential for high productivity by avoiding the high communication head of large teams
Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP. Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services.