Microservice architecture components
Microservices are a loosely coupled set of services that cooperate to achieve a common goal. Besides microservices, there are other components that play a vital role in a microservice architecture. The set of components that help establish the foundation of microservices are shown in the following diagram:
Figure 1.1 – A microservice architecture with its components
The preceding diagram demonstrates the interaction of different microservice architecture components. These microservices are hosted on an orchestration platform, responsible for ensuring self-healing and the high availability of microservices. These microservices then communicate with each other using orchestration or choreography patterns. In orchestration, a microservice is responsible for invoking other microservice interfaces while in choreography, messages are exchanged using an event bus. A client can consume microservices via an API gateway, where messages are relayed to a specific microservice for actual processing. Each team has full autonomy in choosing the right storage mechanism for their microservices, as depicted in the preceding diagram, where different microservices are using a SQL database, an in-memory database, and a NoSQL database for their data storage needs.
We will discuss each component in the following sections.
Messages
Messages contain information that's needed for microservices to communicate with each other. These messages help microservice architecture be loosely coupled. Messages are further classified as commands or events. Commands usually contain more information for the recipient, with the expectation of then being notified about the delivery of messages. Events are lightweight and are mainly used as notification mechanisms, without any expectations from the consumer. These messages can be synchronous or asynchronous.
Persistence and state management
Data handling is an important aspect of microservices. Most of the microservices need to persist data/state. In a microservice architecture, data is decentralized, where every microservice has the responsibility and autonomy of managing its own data. Teams have full autonomy in selecting the right database technology for their microservices to achieve the desired business outcome.
Orchestration
An orchestrator is responsible for placing microservice instances on compute infrastructure. The orchestrator is also responsible for identifying failures and scaling microservices to maintain the high availability and resiliency of the overall architecture.
Service discovery
Service discovery is an integral part of the microservice architecture and helps in locating other microservices to enable collaboration. At a given instance, a microservice may have multiple instances running in a production environment. These instances are dynamically provisioned to address updates, failures, and scaling demands. The service discovery component plays an important role in keeping the microservice architecture highly discoverable by allowing new instances to be registered and become available for service.
API gateway
The API gateway acts as a reverse proxy, responsible for routing requests to the appropriate backend services to expose them in a controlled manner to the outside world for consumption. It also provides robust management and security features that are useful in protecting backend services from malicious actors. The API gateway will be covered in detail in Chapter 7, Cross-Cutting Concerns.
Now, let's explore the role of leadership while initiating a microservices endeavor.
