Introduce yourself to the world of Microservices
To gain a deeper grasp of microservices, we must first understand the differences between microservice and monolithic architecture.
Monolithic Applications.
A monolithic application means a single, indivisible piece of software. A client-side user interface, a server-side program, and a database are typically included in such a system. It is integrated, all functions handled and served from a central place. Generally, monolithic applications have one large codebase and lack modularity. Developers use the same code base when they wish to update or replace something.
Advantages of Monolithic Architecture
- Easy to Manage: It is easy to log, handle, cache, and monitor performance. Because the monolithic application is a single unit.
- Easy to test: In contrast to the microservices architecture, monolithic applications are much easier to test. Since a monolithic app is a single indivisible unit, you can run end-to-end testing much faster.
- Simple to deploy: Monolithic apps are easier to deploy. When it comes to monolithic applications, you only have to deal with one file or directory for deployment.
Problems with Monolithic Architecture
- Changes are more difficult to implement in such a large and complicated application with such tight coupling. Any code modification has the potential to affect the entire system, thus it must be carefully planned. This makes the overall development process much longer.
- Since Developers use the same code base when they wish to update or replace something. As a result, they should zip again the entire application even for the small changes.
- Only the entire application may be scaled, not individual components.
- Applying new technology to a monolithic program is exceedingly difficult because maybe the entire application has to be rewritten.
Microservices Architecture
A monolithic application is a single unified unit, but a microservices architecture divides it into smaller autonomous units. Every application procedure is handled by these units as a separate service. As a result, each service has its own logic and database, as well as the ability to perform its own specialized operations.
The 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 resource API.
-Martin Fowler-
The whole functionality of an application is broken up into independently deployable modules that communicate with one another via defined methods called APIs (Application Programming Interfaces) in the microservice architecture. Each service has its own scope and can be independently updated, deployed, and scaled.
Characteristics of Microservices
- Microservices have a specific purpose for living (domain driven development) and each microservice should have its own well-defined scope.
- A microservice must run on its own process and not rely on another process. Ex: it should run on its own web container.
- Microservices can communicate with one another via a lightweight mechanism — most of the time it uses HTTP protocol to communicate.
- Microservices should have the ability to scale and deploy independently.
- Microservices should be built with as much decentralized control as possible.
- Different programming languages can be used to create different microservices, and they can work together.
- A smaller team should be able to develop a microservice (8–12 team members as average)
Scalability of microservices
The Scale Cube is a three-dimensional scalability paradigm described in the book The Art of Scalability.
X-axis Scaling (Horizontal Duplication)
Running numerous copies of an application behind a load balancer is known as X-axis scaling. Each copy handles 1/N of the load if there are N copies. This is a straightforward and widely used method of scaling a program.
An application should be able to scale up and down through x-axis. If one instance is insufficient, we should be able to spawn another instance and go on.
Z-axis Scaling (Data Partitioning)
When using Z-axis scaling each server runs an identical copy of the code. but at the database level, data is partitioned into different shards. Therefore each server is responsible for only a subset of the data. Some component of the system is responsible for routing each request to the appropriate server. for Ex: European customers are directed to European servers, Asian customers are directed to Asian servers etc.
Y-axis Scaling (Functional Decomposition)
This approach of scaling can be achieved by decomposing an application into smaller, independently deployable units. Microservices are well-suited to such a scaling paradigm because microservices are independent smaller services with their own database.
As a result, if our application has a high-demand service, we can only clone that particular service, rather than cloning the entire application.
Things to keep in mind when developing a microservice
- Each service should be able to use different programming languages, frameworks.
- Domain-driven design: services should be developed in such a way that a service can run independently without depending on other services.
- Service resilience and fault tolerance must be implemented: Because all services will communicate with one another, if one or some service fail to work or not responding, we need to have a proper mechanism in place to maintain this condition (Circuit breaker pattern, proxy etc).
- Use appropriate available frameworks for microservice development and deployment: we don’t have to invent everything; there are various frameworks that can do various task which we require.
- We need a full-stack team that can handle all aspects of the project.
Advantages of microservices
- All the services can be deployed and updated independently, which provides greater flexibility.
- A bug in a single microservice affects only that service and does not affect the entire application.
- Adding new features to a microservice application is significantly easier than adding them to a monolithic program.
- Easy to understand and manage, since services have their own well-defined scope
- Each element can be scaled independently. It’s cost-effective.
- Flexibility in choosing the technology, development team is not limited to any technology. They are free to apply various technologies and frameworks for each microservice.
- When a fault happens, we can cut-down the downtime by simply fixing the broken service.
Disadvantages of microservices
- Extra complexity. Because a microservices architecture is a distributed system, you must choose and configure all of the modules’ and databases’ connections carefully. Furthermore, each service must be deployed separately.
- When microservices communicate with one another, there is some latency.
- Dependency Management is hard.
- Should pay attention to versioning and deployment because upgrading your version may have an impact on your dependent services.
- Integrate testing is much more difficult due to a large number of independently deployable components.
