There is a fundamental – and growing - similarity between the online gaming world and the Managed Service Providers (MSPs).Their user bases can be huge and their collective patterns of demand reasonably volatile. And while the final utilisation of the service provided may be vastly different, the tools needed to manage the infrastructure and provide the services is pretty much the same for both.
Throughput is the key here – the shear volume of work the systems are required to perform, both accurately and efficiently. There is, deep down, little difference between a game player becoming annoyed at having to wait a second or two for every play of an interactive game and having a transactional website hang when a user is online, ordering a product.
The commonality is in the user response. They are at best annoyed and at worst, they go somewhere else.
This begs a question which is now starting to get asked, if only rarely for now. Are current systems architectures sufficient to give the headroom on scalability that users are really going to require, or is something like parallel computing better equipped to manage current, let alone future demand?
Perhaps unsurprisingly, Jim Liddle, Sales and Operations Director for GigaSpaces Technologies in Northern Europe tends to think this is the case
GigaSpaces core offering is XAP, the eXtreme Application Platform. This is a grid-based, parallel processing virtual middleware platform which combines an Application Server and a Data Grid which scales the data layer in real time to meet changing loads. This all runs entirely in memory across many nodes, while presenting whatever it is running to the user as a single application. The scaling is managed by a set of SLA management tools, which set the rules for service scale up and down. These rules are in turn driven by user-defined business policies.
One of the important aspects of XAP is that it highlights the commonality of purpose that exists between different types of use. GigaSpaces has, for example, already gained a strong foothold in the banking and financial institutions, while the same system is now being exploited by gaming companies such as Yazino. This is an online casino business described as being `massively multiplayer’. In both cases, the commonality is fast, accurate and reliable transaction management.
That commonality of end-user purpose exists between businesses that are still running legacy systems on on-premise infrastructures and those already well-established in the cloud. And according to Liddle, XAP suits both equally well. The way the company has configured the system, it bridges the forced differentiation between `private’ and `public’ cloud, by automatically offering the former within the latter.
“As users need to scale up their services it can exploit the resources made available to it, whether on-premise or with a service provider,” he said. “So if real scale-up cloud bursting is required, it can push it out to third party service providers such as Amazon, and still make it look like a single application.”
This is a seamless process and there is no negative impact on operations or performance from the transition. The company partners with both Amazon and Rackspace and users pay for the resources at an hourly rate. In practice, in signing up with Gigaspaces users also purchase access to pre-configured instances on these services.
This service is particularly suitable for new applications and services developed using Java, C++ and .NET environments. According to Liddle, it also with a wide range of scripting languages, such as Python and Perl.
There is no limit on the scope or scale of the application, and it sidesteps the normal infrastructural tiers such as the application tier, and the operating system tier. It overcomes the problems of Amdahl’s Law in parallel systems – which shows that any performance improvement through parallelisation of an application will be limited by the portion of that application which still requires to be processed sequentially – by running entirely in memory over multiple nodes. There is no requirement for disk caching or similar processes.
One of the reasons XAP can scale rapidly is that it co-locates the logic and data for a task on the same core to be processed together. This means that much of the shifting of data into and out of storage common with traditional systems architectures is removed. While this may have been designed with fast transaction management for the financial community in mind, Liddle is well aware that it also maps well on to the needs of the MSP community. “This approach means it can exploit the individual cores of the multicore processors found in commodity servers. It exploits the fact that memory is now extremely cheap.”
