Space-Based Architecture

By:- Suresh Patidar24th May 2016

Agenda

❖ Scalability, Why and How?

❖ Space-Based Architecture

❖ Components

❖ Pattern Analysis

❖ Considerations

❖ Q&A

Scalability, Why and How?

➢ Application workload is increasing each day. This is inevitable.

➢ We expect fast and reliable softwares even with increasing workload.

➢ Speed and reliability means the death or life of a business.

➢ In most of web applications bottleneck starts appearing as the user load increases, first at web-server layer, then at application-server layer and finally at database-server layer.

But why so much Workload?

Today’s softwares are not limited to operators and limited society. They directly interacts with millions of people and thousands of other softwares.

Few examples:

➢ Large scale community sites, like facebook, twitter, hi5 etc.

➢ Prepaid Telecoms

➢ Banking sites

➢ Online gaming

➢ Online fraud/risk management

Why scalability/performance is so important?

A brokerage can lose up to $4 million per millisecond of latency.

- The Tabb Group

An additional 500 ms latency resulted in -20% traffic.

- Google

An Additional 100 ms in latency resulted in -1% of sales.

- Amazon

Hourly cost of downtime for 33% of the companies is $10k to 100K

- Forrester survey of 235 comp.

Then what is the solution?

The solution is to have scalable softwares. With scalability we create speed and reliability.

➢ Vertical scalability; More powerful machines leads to faster software.

➢ Horizontal scalability; More boxes leads to faster and more reliable software.

➢ Linear scalability; The overall throughput = (number of processing unit) * (throughput per unit).

➢ Dynamic scalability; Scale on demand (usually using some sort of provisioning and monitoring capabilities)

We usually refer to horizontal scalability, since it is more applicable and cost effective.

Space-Based Architecture

“Space-Based Architecture (SBA) is a software architecture pattern for achieving linear scalability of stateful, high-performance applications using the tuple space paradigm” - Wikipedia

➢ Applications are built out of self-sufficient units, known as Processing Units.

➢ PU co-locates the business logic, data and messaging capabilities required by one instance of an end-to-end business use case.

➢ It makes straightforward to address Non Functional Requirements (NFRs) such as near-linear scalability, high availability, low latency, and high throughput.

➢ It is closely related to other successful patterns addressing scalability challenge such as shared nothing architecture (SN).

Architecture diagram

Washing your car The Tire-Based Way

Washing your car using Space-Based Arch.

Scaling Easily with Self Contained PU

Components – Processing Unit (PU)

The Processing Unit typically contains the application modules, along with an in-memory data grid and an optional asynchronous persistent store for failover. It also contains a replication engine that is used by the virtualized middleware to replicate data changes made by one processing unit to other active PUs.

Components – Messaging Grid

The messaging grid, manages input request and session information. When a request comes into the virtualized middleware component, the messaging-grid component determines which active processing components are available to receive the request and forwards the request to one of those processing units.

Components – Data Grid

The data-grid component is perhaps the most important and crucial component in this pattern. The data grid interacts with the data replication engine in each processing unit to manage the data replication between processing units when data updates occur.

Components – Processing Grid

The processing grid, is an optional component within the virtualized middleware that manages distributed request processing when there are multiple processing units, each handling a portion of the application. It mediates and orchestrates the request between those two processing units.

Components – Deployment Manager

The deployment-manager component manages the dynamic startup and shutdown of processing units based on load conditions. This component continually monitors response times and user loads, and starts up new processing units when load increases, and shuts down processing units when the load decreases.

Pattern Analysis

Considerations

➢ The space-based architecture pattern is a complex and expensive pattern to implement. It is a good architecture choice for smaller web-based applications with variable load.

➢ It is not well suited for traditional large-scale relational database applications with large amounts of operational data.

➢ Although the space-based architecture pattern does not require a centralized data store, one is commonly included to perform the initial in-memory data grid load and asynchronously persist data.

➢ It is also a common practice to create separate partitions that isolate volatile and widely used transactional data from non-active data, in order to reduce the memory footprint of the in-memory data grid within each processing unit.

Thank You!