Many applications today require the support of transactions at scale that must be calculated in real-time. These needs are most commonly seen in commercial transaction processing systems (OLTP) and some types of decision support systems such as fraud detection, risk analysis, predictive maintenance, and customer 360 applications. Typically these applications are integrated into a microservices environment to achieve distributed workflows, high availability, service isolation and more.
Optimizing the latency in a microservice workflow is the main objective of online systems.
How In-Memory Computing Handles Main Latency Contributors in a Microservices Environment
Network and disk access are the two main factors contributing to high latency in an online-application microservices workflow. In the past, disk access was an order of magnitude slower than local network access, but today SSD and high speed PCI sockets have closed the gaps and deliver millions of IOPS.
However, SSD technology still uses block devices that are slow compared to RAM, especially for small size data access patterns. In-Memory Computing that leverages in-memory data grids (IMDG) reduces the application latency to a minimum in microservices environments by storing relevant data for each microservice in its private and consistent distributed memory. Not only does this vastly decrease disk access latency, but it also reduces the need to access a remote data store when the grid is embedded within the microservice.
Low latency microservices solutions can be implemented in many ways, but choosing the correct architecture will impact user experience and application accuracy.
An example of low latency application is an algo trading workflow where the slightest delay in any object within the flow has a huge impact on the profit margin. It’s important to note that an IMDG is not the ideal pattern for historical data flows which are usually executed on archived big data and have different access patterns that are offline-oriented.
Time-sensitive application requirements are driving the growing trend of deploying in-memory technology in any environment. When specifically implementing microservices, adopting IMDG as a service datastore delivers additional advantages that make the service lifecycle management easier and safer.
Data Isolation
One such benefit is data isolation. Data isolation in a microservice architecture refers to the concept that data layers must be stored privately on every microservice. However, managing a persistent microservice layer is not that simple. Tasks like attaching volumes, purging, copying, backing up are sometimes considered a huge overhead to be managed by a simple microservice. It is therefore common to see microservices that use a centralized data store where the data is logically segregated instead. IMDG technology facilitates the data management process. The relevant data is simply copied to the microservice space and all the transformations are executed within the service.
Moving data from the enterprise’s systems of record to the independent microservices is easily accomplished by technologies like Change Data Capture (CDC) that were created to support the transition from monolith to microservices. An IMDG architecture then handles all the data management overhead including high availability, backups and scaling.
Collocated data and services in a microservices cluster
Dynamic Scaling with No Down-Time While Maintaining Consistency
Scaling out capabilities is a necessity for many applications, especially for those that need to handle planned and unplanned peaks. A microservice is usually built out of many instances (replicas or partitions) to meet changing traffic rates without dependency on a single physical machine. It is common to see microservices that grow and shrink on demand as a result of changing transaction rates.
Nevertheless, scaling is a complex task for two reasons:
- The scaling operation must be performed in a way that will not damage the service, e.g. overload the service.
- The scaling operation must maintain business logic consistency. For example, a transaction must not be performed twice due to a scaling scenario.
Therefore scaling must be achieved seamlessly and as quickly as possible. IMDG technology has a huge advantage over other storage technologies when it comes to scaling. The millisecond memory access allows the completion of scale-out events in a matter of seconds.
Real-Time Streaming Analysis Combining Analytics and Transactions
IMDG technology can also be used as a workload balancing system in a microservice environment. In a PubSub architecture one microservice streams data to a grid that may be shared among several application instances on another service. When the IMDG is embedded within the application, the IMDG partitioning schema is used not only to distribute the data among the grid instances but also to distribute the workload.
Each application instance is responsible for one or more partitions on the grid and holds the state for that partition. The business logic is triggered automatically as soon as the data is changed per partitioned instance. Scaling out the workload is easy. By adding a new application instance to the cluster, IMDG partitions will be automatically reassigned to the new instance and the workload will be scaled.
This architecture decouples the producer partition schema from the application schema and also has real-time characteristics as in-memory triggers can be set to process events as soon as they are streamed to the grid.
Example of streaming PubSub architecture
One such example is a fraud detection system that requires real-time actions in order to classify a suspicious transaction. Inference models are loaded into the grid and are matched against online transactions while transactions are streamed to the relevant model-partition.
Summary
Companies are gradually moving from monoliths having a centralized data store to a microservices architecture in which every service is responsible for a small amount of business logic independently. This modular approach breaks down a large system into small, autonomous and manageable components. Moving the relevant data closer to the application’s business logic greatly reduces the time it takes to perform critical online tasks. It ensures data isolation and decouples business logic from the main data schema. Scaling out the work on a subset of the data becomes easier and more effective than coordinating the work on a centralized data store.
See how Avanza, Sweden’s only digital bank that has the most satisfied savings customers for 10 years in a row, has rapidly deployed over a thousand services using a microservices-based architecture with Smart ODS.
