In this post we are going to deep into Microservices Architecture and Design Patterns. Microservices architecture is based on a pattern whose main objective is to decouple components as much as possible. There is no formal definition of microservices, but there are common characteristics in these architectures.

Why use Microservices Pattern Architecture?

Imagine that you have to develop a banking software with various modules such as credit cards, payroll accounts, loans, mortgages, etc. Each service needs to interact with other services. If we were to use the traditional monolithic architecture:

1. The complexity of the application architecture would increase.
2. Even with multiple teams, they wouldn’t be truly independent.
3. Cascade failures could occur.
4. The time to put the software into production would increase due to the larger codebase.
5. The same technology would have to be used throughout the application.
6. Difficulty in scaling as it’s not possible to scale only a part.
7. The operations team would need to take control of the application for deployment.

On the other hand, if we modularize and adopt a microservices architecture for the banking software, we would have the following characteristics:

1. Independence between development and operations.
2. Speed and agility, improving time to market.
3. Better code and quality.
4. Code is developed based on business functionality and domains.
5. Increased productivity.
6. Scaling can be done easily for specific microservices as needed.
7. Each team responsible for a microservice can choose the technology to use.
8. Microservices should be consumable by other microservices.

Therefore, the reasons for using this architecture are essentially the points mentioned above. Although it offers many benefits, it’s important to consider that it also has its problems and complexities, such as monitoring, error handling, microservice failures, and communication between them.

Key Characteristics of Microservices:

1. Intelligent endpoints: Avoiding the use of Enterprise Service Bus (ESB).
2. Isolated databases: Each microservice has its own database instead of a common database for the entire application.
3. Automation: Each microservice is automated to enable continuous delivery.
4. Each microservice is a small application with its own architecture, consisting of a business layer and various adapters.
5. Some microservices can be exposed through an API and consumed by other microservices or client applications.
6. At runtime, each instance is typically deployed in a Docker container or a cloud environment.

Considerations for Microservices:

Before implementing a Microservices Architecture, certain considerations should be taken into account:

1. DevOps culture: Knowledge of continuous integration and continuous deployment.
2. Rapid provisioning: The ability to launch new resources quickly and efficiently.
3. Monitoring and debugging capabilities: Understanding what is happening within the services.
4. Ability to launch and manage many services rapidly.

Microservices Ecosystem:

When implementing the Microservices Architecture pattern, certain measures and implementations need to be taken to interact with the outside world, facilitate development, and avoid problems.

1. API Gateway: Acts as a simple entry point in the system, encapsulating the internal architecture and providing an API adapted to each client. It also has additional responsibilities such as caching, authentication, monitoring, load balancing, administration, and response handling.
2. Service Discovery: Maintains a “database” of services, their instances, and their locations.
3. Load Balancing: Routes requests from clients to available service instances, distributing the load.
4. Fault Tolerance: Due to multiple dependencies, a fault-tolerant system is required. Circuit Breaker is one implementation for this purpose.
5. Configuration Management: In a complex system with many dependencies and time-sensitive operations, it’s best to have an externalized configuration system for properties and microservice management.

Microservices Design Patterns

Below, we will mention a few design patterns, which we will discuss in more depth in other Refactorizando entries.

• Event-driven: In this pattern, a microservice publishes an event that another microservice consumes.
• Aggregator or Proxy: A web client requires information from multiple microservices. In this case, a microservice is invoked that aggregates the calls to other microservices to obtain the response.

• Chained: In this case, consecutive calls are made to compose the information.

• Asynchronous messaging: With a REST call pattern, requests and calls are asynchronous (implementations can be made to achieve asynchronicity). This often leads to the use of an asynchronous messaging service like Kafka to send information.
• Saga Pattern: The Saga Pattern is a sequence of local transactions where each transaction updates information within a service.

Conclusion

This Microservices Architecture pattern is a solution to many of the problems that exist in development, but not all of them. Before starting to implement a solution of this nature, its feasibility must be evaluated. It should be taken into account that such a solution ultimately integrates many services, and the cost could also increase.