Once considered one of the hottest up-and-coming technologies, microservices have now seen widespread adoption as a way to deconstruct the large, complex infrastructures within organizations across industries.
Traditional applications act as monoliths, meaning that they are single self-contained artifacts, while a microservice-based application is made up of several building blocks that can be composed together to get new applications and services up and running faster.
What are the top microservices patterns?
We’re going to review the top six microservices patterns that help enterprises break down large application structures into smaller, independent services.
1. Fine-grained SOA
Fine-grained SOA is the most common approach to microservices when just getting started. This pattern applies the same principles as service-oriented architecture but reduces the issues that would typically arise by breaking down the infrastructure into smaller, more granular pieces.
In most cases, this pattern is an extension of SOA integration, where each service provides connectivity to external systems. This forms tight dependencies to those external stores, which reduce the speed of change and makes the system’s cohesion reflective of the internal state of those applications.
2. Layered APIs over fine-grained SOA
The next evolution of the fine-grained SOA pattern is to layer APIs over it. In most cases, these two patterns will coexist. The layered API over the fine-grained SOA approach is closely related to API-led connectivity. In both, System APIs expose applications, Process APIs orchestrate them, and Experience APIs provide end-user experiences.
Microservices architectures can be difficult to rationalize when there is a lack of structure, making it hard to categorize and visualize the purpose of each microservice. This pattern creates some structure by organizing the microservices into layers grouped by purpose (systems, processes or domain models, and experiences), and enables the architecture to be managed more easily.
3. Message-oriented state management over layered APIs
The prior two patterns lacked state management capabilities, meaning that the microservices implemented using them lacked data integrity. The message-oriented state management over layered API patterns ensures data integrity by replicating the state of key business data between microservices or data stores.
This enables the systems to converge events and provide a consistent external view using a message queue allowing the state to be asynchronously sent to different locations or queried through other microservices. By decoupling components, the implementation and behavior of each microservice become obscured.
4. Event-driven state management over layered APIs
Organizations leverage event-driven patterns for real-time data updates that REST APIs and synchronous communications don’t provide; this is critical for use cases like fraud detection, workflow notifications, news feeds, and stock ticks. Event-driven systems use a queue (like message-oriented systems) but have standards enforced for the design and behavior of what is passed over the queue – specifically an event.
An event is an action associated with a representative state and timestamp. This event allows any service receiving it to reconstruct a materialized view of the state by replaying the events in order.
5. Isolating state in layered APIs
An alternate approach to event-driven microservices is to add persistence at each individual microservice. This pattern implements consistency at the time of query instead of in the interchange and achieves this by isolating the state of each microservice so each contains its own state.
Each microservice becomes a single source of truth within itself in this pattern and contains an internal data store that constantly reconciles with external stores – whether they are an event log or an enterprise asset. Single source of truth patterns tend to see complex issues (similar to the issues seen with master data management), but this can be simplified when an external store is used.
6. Replicating state in layered APIs (event sourcing)
A replicating state is essentially the opposite of an isolating state, since consistency is required. With isolated states, microservices become interdependent and failure in a single microservice can cause others to fail. A replicating state provides a single place to store all state mutations where each isolated microservice can rebuild its internal state.
A replicating state requires a deeper understanding of management processes and behaviors of each microservice to be predictable. By nature, this design is eventually consistent. While this may seem like a problem in traditional transactional design, it is alleviated with insight into the nature of the design. This enables greater freedom and speed of change and ultimately faster time-to-value.
To learn more about how to apply microservices to your architecture, download our whitepaper on the top six microservice patterns.
