Building a Microservices Data Fabric
|Architecture & Security|
Microservices by definition exist in numbers. You’ll certainly have more than one microservice, and probably more than one instance of each.
This makes data a problem. Each will need data from somewhere, such as a relational database, and may need to share common state with other instances of the same service (and that’s not appropriate for a relational database)
What I plan to show here is how this can be achieved with Hazelcast IMDG (In-memory Data Grid). The IMDG is a collection of processes that act as one, spreading the load of data across the processes in a fast manner.
A Go routine can access this data in much the same way as accessing a database, but is immune to planned or unplanned changes in the cluster size. You needn’t lose data or access to data is there is a partial failure on the cluster, as it has self-healing behaviour. And being memory based, data retrieval is very fast.
Behind the scenes, Hazelcast can be uploading and downloading data to multiple legacy technologies such as SQL databases, so it’s easy to introduce the data fabric into the architecture for immediate benefits of speed and to hide the details of the backend storage.
Neil is a solution architect for Hazelcast, the world's leading open source in-memory data grid.
In more than 25 years of work in IT, Neil has designed, developed and debugged a number of software systems for companies large and small.