Microservices is the new architecture paradigm
everyone is talking about, but it comes with its own set of complexities. As our industry gets more matured about using Microservices architecture, one of the key learnings coming out as:
The outer architectural building blocks are playing far more important role than the inner architecture of each microservice itself.
I will be sharing my perspective on microservices' outer architectural building blocks (In-memory computing
& caching, API Gateway, Containers, DevOps & Cloud Computing) in a series of upcoming blog posts. This blog post is focused on "in-memory computing technology", which plays an important role in microservices architecture.
In-memory computing, in itself, is a vast
technology domain but in the context of microservices architecture, I would
like to keep it focused on following solution offerings:
- In-memory database - a database system primarily
residing in memory (SQL or NOSQL).
- In-memory data grid - distributed computing based caching system usually having KV (key-value) storage.
In-memory database (IMDB)
In-memory database plays a collaborative role in
microservices architecture as usually it can be deployed independently and
provides highly efficient storage support to microservices.
Note that to sustain data stored in in-memory database during deployments, a backup approach with file-system based storage is required.
Note that to sustain data stored in in-memory database during deployments, a backup approach with file-system based storage is required.
These are following key design patterns, which
can be applied in the context of in-memory database:
- Pattern A - IMDB per microservice,
where each microservice having its own storage
- Applicability: Greenfield
development where you have opportunity to do microservices based
architecture first
- Pros: Independent (inclusive of
deployment flexibility) & completely in adherence to microservices
principles
- Cons: Duplication of data across
services
- Pattern B - IMDB as a shared
component across multiple Microservices having common storage
- Applicability: Brownfield
development where you are on a path to refactor monolith application to
microservices
- Pros: Practical approach when you
have shared data across services
- Cons: Not completely aligned with
Microservices principles
- Pattern C - Hybrid of Pattern A or
B (some microservices having shared database)
 |
| Microservices Architecture - In-memory database design patterns |
In-memory
data grid (IMDG)
In-memory data
grid relies on distributed computing using clustering as underlying approach
and provides a shared component (grid) for CRUD operations using memory.
As microservices
architecture recommends independent deployable units with minimal shared data,
in-memory data grid is not completely aligned to this architectural approach.
However, in-memory grid products can provide independent cache nodes to
respective microservice with variation of distributed cluster to store backup
data in the grid.
In nutshell,
conceptually these are different approaches:
- Microservices
architecture - It promotes independence and less dependency for linear
scalability (cluster of instances of microservice but clustering at layer level is not recommended).
- In-memory data grid - It relies on cluster of nodes (data layer) for horizontal scalability (nodes can be added/removed on need basis for scalability).
Because of the
above reason, vendor like Oracle has started their cloud roadmap with less
emphasis on Oracle Coherence for microservices architecture and more on cloud
based offering for Cache-as-a-service, which can be easily integrated with microservices Architecture. However, this is also similar to common grid
solution with variance that cloud is now playing the common grid. Also,
In-memory grid solution is still relevant and playing its role behind the scenes
(to support cloud's cache-as-a-service).
From
applicability perspective, following patterns can be leveraged for microservices architecture along with in-memory datagrid solution:
- Pattern A -
In-memory data grid as event/messages store
- Applicability:
Primarily for inter-microservice communication, this pattern can be
leveraged.
- Pattern B -
In-memory data grid as shared data
- Applicability:
To store shared data such as backend system response (cached data),
response data, content data, etc.
- Pattern C -
In-memory data grid as storage
- Applicability: To store data in grid for a microservice and use partition approaches to separate data for each microservice
To conclude,
in-memory computing plays a significant role for Microservices architecture as
an underlying storage mechanism for each microservice. Also, in-memory grid
computing offers an alternative solution, which respects microservice's
principle of independence up to certain extent and provides a out-of-the-box
solution to solve inter-communication & storage challenges for microservice
architecture.
References:
-->
 |
| In-memory database & In-memory data-grid solutions |
