The difference between Space-Based Architecture (SBA) and distributed-caching

Recently I came across questions regarding the differences between GigaSpaces' Space-Based Architecture (SBA) concepts and Distributed-Caching products a.k.a in-memory Data-Grids (this last category includes GigaSpaces' Caching Edition as well).

I've chosen to address these questions in the following manner:

1. Provide a quick background describing how Distributed-Caching falls under the context of SBA. Why Distributed-Caching can only serve as part the overall architecture required in order to address the end-to-end scalability and latency of applications.
2. I will illustrate how end-to-end scalability and latency can be addressed by taking a stateful application from the financial world and providing a high level architecture view of how it will look like under the context of SBA.
3. As a consequence – it should be highlighted that the real comparison is not between SBA and Caching but between SBA and an application level bundling approach which includes caching.
4. We'll conclude by comparing SBA to an Application level bundling approach, such as application servers in terms of latency, scalability, complexity etc.

Background – IMDG/Caching under the context of SBA    

Let us preface by using an analogy. The relationship between an SBA and Distributed Caching is equivalent to the relationship between a J2EE Application Server and Entity Beans. One is subsumed by the other.

In order to understand the difference, we need to realize that a Data Grid solution always works in conjunction with some sort of messaging solution, and with a business tier that does the actual processing. When vendors offer a Data Grid solution, they are offering it in the context of this bigger picture. This is true both for GigaSpaces-IMDG (In Memory Data Grid)  and other vendors.

Most vendors offering Data Grid solutions use the classic ‘best-of-breed' approach. They offer several different software bundles, each dealing with a different application tier, each with its own high availability cluster, failover, and scaling possibilities – the Data Grid product being only one of these bundles. In a stateful environment, an external transaction coordinator and load balancer is also needed to maintain consistency between the tiers.

Very early in the process we realized that with the best-of-breed approach, end-to-end latency and scaling depended not only on the Data Grid product but also on other products, whether it's the application server, the messaging system or the transaction coordinator, and the weakest link in this chain determines the application's end-to-end scaling and latency.

We determined  that covering the functionality required to  build an end-end application architecture having the best of breed in each tier is often an overkill and as mentioned above a very limiting factor for what's  required by the application.  This was  the background that led to the emergence of the Space Based Architecture (SBA). SBA is an architecture which spans all application tiers, scales coherently as a single unit, and offers a unified high availability and failover model. If we compare SBA to an application server, we can think of the GigaSpaces SBA as a light weight equivalent of application-servers and Data Grid as only one tier in the overall SBA stack.

In the SBA approach, the Data Grid is part of an holistic architecture which guarantees minimal end-to-end latency and linear scalability. It can guarantee this because the entire business transaction is packaged inside a self-sufficient processing unit, which runs in an SLA-driven light-weight container  providing not only a Data Grid but also messaging facilities, high availability and failover. This is illustrated in the following example.

Understanding what SBA End to End Latency and Scalability means by example:

I've chosen an application taken from the financial world of a trading application (an Order Management System (OMS)) as an example since it is an application with highly demanding scaling and latency requirements in a stateful environment. (Note the scope of this description is to focus on the unique elements of SBA at a very high level. It is outside the scope of this paper to go into the details of what's required to build a trading application)

A trading application usually consists of a data feed that flows into the system in some sort of financial standard format (FIX). Those feeds needs to be matched, with very low latency, against other trades that exist in the market. The business logic typically includes the following steps:

• Parsing and validation (transforming FIX format into a binary object and validating that it conforms to certain rules);
• Matching (which queries the data store to find a matching trade, and executes the deal)
• Routing (which routes details of the deal to interested parties).

The application needs to provide a 100% guarantee that once a transaction enters the system it will not be lost. It also needs to keep end-to-end latency (latency from the time the system receives a trade to the time the business process ends) to a fraction of millisecond – and ensure this low latency is not affected by future scaling.

The first step in building such an application with SBA is to define its business logic components as independent services – Enrichment Service(parsing and validation), Order Book Service (matching and execution), Reconciliation Service (routing):

To reduce the latency overhead of communication between these services, they are all collocated under a single VM. In order to eliminate the network overhead of communication with the messaging and data tiers, messaging and Data Grid instances are both collocated in the same VM. All the interaction with all the services is done purely in-process, bringing I/O overhead to a minimum in both data and messaging layers.

This collocated unit of work (which includes business logic, messaging and data) is called a processing unit. Because the processing unit encompasses all application tiers, it represents the application's full latency path. And because everything occurs in-process, latency is reduced to an absolute minimum.

Scaling is achieved simply by adding more processing units and splitting the load between them. Scaling does not affect latency, because the application's complexity does not increase. Each transaction is still routed to a single processing unit which handles the entire business transaction in-process, with the same minimal level of latency.

We can see that the trading application guarantees both minimal latency and linear scalability – something that would be impossible with a tier-based, best-of-breed approach.

SBA vs. Application level Bundling approach Based on plain Data Grid

As mentioned earlier, the real difference between SBA and various Data Grid products is that these other products utilize a best-of-breed solution, which is only as strong as its weakest link. The following table summarizes the benefits of SBA, as compared to a best-of-breed solution based on a Data Grid product.

Summary

SBA has major advantages over a traditional  IMDG based solution. Unlike plain caching, SBA is aimed at addressing the end-to-end scalability and latency of the entire application and not just the data tier. IMDG is a component within the overall SBA context and therefore the comparison should be made between SBA and best of breed approach which uses an IMDG. SBA emerged from the experience of the huge limiting factors that we faced with the best of breed approach, and was explicitly designed to address those very limitations.  SBA dramatically delivers on its design promises, achieving high throughput with low latency and high availability, with linear scalability..  

Having said that it is also important to note that a critical part of SBA and specifically our GigaSpaces implementation of it is to provide efficient and enhanced integration with existing technologies and products such as external data bases, application servers, messaging system, enterprise grid products etc. The main difference is that we removed the dependency for that integration from the application transaction processing critical path. Through that were able to provide much better flexibility on the type of architectural choice that could be made without compromising on performance, scalability or latency.

References

For a more in-depth discussion of the differences in product vision and implementation between GigaSpaces and other caching products, you are invited to read our white paper, "Space-Based Architecture and the End of Tier-based Computing."