Introduction to Microservices Architecture and Common Buzzwords
Microservices in short, where each application function is a service in itself.
It is an architectural model where these services are deployed in discrete containers and these containers talk to each other through APIs.
The core principle in microservice architecture is to act fast to meet business requirements, and not to break things while moving fast.
In monolithic architectures, as the scale of the application grows, development, testing, installation and scaling processes become increasingly difficult and become unsustainable after a certain time. The way to get rid of these bottlenecks in large-scale application development is to develop software with microservice architecture. The necessary tools and equipment to operate the microservice architecture in a robust way have been developed a lot since the emergence of the architecture, and today, if a large and complex application is to be developed, the microservice architecture has become a necessity.
To understand microservices, software scalability must be known. Scalability in software is explained by the scale cube method.
Microservices are stand-alone applications, each service has a task and they work loosely coupled with each other to perform these tasks.
Some characteristic features of microservices:
- The services communicate with each other by asynchronous communication method. All services will be able to communicate with each other with their own APIs and they will do the same with the monolith.
- Each service is autonomous and developed by small teams, large teams are not required and increase the efficiency of all teams.
- The development to be made in each service is done quickly, it involves less effort and complexity, and it is quickly brought to life with only that service being affected in the whole application.
- It enables development teams to act autonomously. A team does not have to know the structure of the other service.
- The data of each service belongs to it. They can be configured as separate tables, separate schemas, or separate databases.
- Each service’s code is independent of the other, set up and managed independently. It can be scaled independently.
- Each service can be produced using a different programming language or library. It enables new technologies to be tested and implemented easily.
- Because microservices are small, they are easy to maintain. Also increases the frequency of introducing new features in the software and enabling very fast response to requirements.
- It allows to automate the software development process to the desired extent from testing and installation.
- It provides very good fault isolation. If a problem occurs in a service, it will not affect the whole system, it will remain only in that service. The rest of the system will continue to run smoothly.
COMMON BUZZWORDS & PATTERNS
Microservice Decomposition Methods
- Decompose By Business Capability
Identifying business capabilities and hence services requires an understanding of the business. An organization’s business capabilities are identified by analyzing the organization’s purpose, structure, business processes, and areas of expertise. Bounded contexts are best identified using an iterative process.
- Decompose By Subdomain
This approach breaks down the organization’s domain model into separate subdomains that are labeled as core (a key differentiator for the business), supporting (possibly related to business but not a differentiator), or generic (not business-specific).
- Self-Contained Service
Design a service so that it can respond to a synchronous request without waiting for the response from any other service.
- Service Per Team
Instead of decomposing monoliths by business capabilities or services, the service per team pattern breaks them down into microservices that are managed by individual teams. Each team is responsible for a business capability and owns the capability’s code base. The team independently develops, tests, deploys, or scales its services, and primarily interacts with other teams to negotiate APIs.
Refactoring to Microservices
- Strangler Application
Monolithic applications can be incrementally transformed using this pattern by replacing a particular functionality with a new service. As soon as the new service is ready, the old component is strangled and the new service is put into use, while the old component is decommissioned.
- Anti-Corruption Layer
Isolate the different subsystems by placing an anti-corruption layer between them. This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach.
Data Management
- Database Per Service
Data schema changes can perform without any impact on other microservices. So that means if any data failures happened, it won’t be affect other microservices.
- Saga Choreography
Each service performs its process, and if the result is successful, it fires a success event for the next step to continue. In case of a failure, it fires a failure event for the previous step. So, the services that have worked before this step can sequentially perform rollbacks.
- Saga Orchestration
In this approach, an orchestrator manages the entire operation from one center. An orchestrator receives a start command from a source and commences calling related services sequentially. After each successful response, it makes the next call to the following service. If one of the steps fails and the service returns a failure message, the orchestrator makes rollback calls for each previous step/service.
- API Composition
This pattern uses an API composer, or aggregator, to implement a query by invoking individual microservices that own the data. It then combines the results by performing an in- memory join.
- CQRS
The command query responsibility segregation (CQRS) pattern separates the data mutation, or the command part of a system, from the query part. The CQRS pattern splits the application into two parts: the command side and the query side. The command side handles create, update, and delete requests. The query side runs the query part by using the read replicas.
- Event Sourcing
The Event Sourcing pattern basically provide to accumulate events and aggregates them into sequence of events in databases. By this way we can replay at certain point of events. This pattern is very well using with CQRS and saga patterns.
- Domain Event
Domain event is, something that happened in the domain that you want other parts of the same domain (in-process) to be aware of. The notified parts usually react somehow to the events.
Transactional Messaging
- Transactional Outbox
The pattern introduces a supplementary table, called OUTBOX, to the service’s database. This table stores the event notifications that are supposed to send from the service to the message broker. When service writes to the aggregate table, it also writes a record to the OUTBOX table as a part of the same transaction.
Reliability
- Bulkhead Pattern
The Bulkhead pattern is a type of application design that is tolerant of failure. In a bulkhead architecture, elements of an application are isolated into pools so that if one fails, the others will continue to function. It’s named after the sectioned partitions (bulkheads) of a ship’s hull. If the hull of a ship is compromised, only the damaged section fills with water, which prevents the ship from sinking.
- Circuit Breaker
A circuit breaker acts as a proxy for operations that might fail. The proxy should monitor the number of recent failures that have occurred, and use this information to decide whether to allow the operation to proceed, or simply return an exception immediately.
The Circuit Breaker pattern provides stability while the system recovers from a failure and minimizes the impact on performance.
Cross Cutting Concerns
- Externalized Configuration
Centralized Configuration Service helps in managing the configurations across different microservices in a consistent way. Operation teams can create/update/read the configurations in a consistent and streamlined fashion. It serves as a single source of truth when it comes to configurations, which ensures the consistency of it.
- Service Template
This pattern has the following benefits:
- A developer can quickly and easily start developing a new microservice.
- It ensures that cross-cutting concerns are implemented in a standardized consistent way.
- It encourages developers to ‘do the right thing’.
Testing
- Contract Testing
One clear benefit of Contract Testing is the collaborative nature and behaviors that are instilled. It is at the very least, a great excuse for teams to be communicating in this way about the contracts that exist between their services.
Communication Patterns
- Idempotent Consumer
When an event arrives, the consumer needs to uniquely identify it using an event key assigned to the event. The idempotent repository is checked to see whether it contains the key, and if it does not, the logic wrapped by it is executed, otherwise it is skipped.
- Service Registry & Discovery
Service Discovery is an infrastructure which keep tracks of all the services instances and route the request to it.
The service registry is a key part of service discovery. It is a database containing the network locations of service instances
Observability
- Log Aggregation
Use a centralized logging service that aggregates logs from each service instance. The users can search and analyze the logs. They can configure alerts that are triggered when certain messages appear in the logs.
- Distributed Tracing
Distributed tracing is a method of tracking application requests as they flow from frontend devices to backend services and databases. Developers can use distributed tracing to troubleshoot requests that exhibit high latency or errors.
