A Fabric and a Server

The enterprise server market clearly has its big league players-HP, IBM, Oracle and a motley set of other players like Dell, Lenovo, and the others. But niche markets do exist and niche players are expected to innovate to strengthen their hold on the niche segments they target.

Unisys is one niche player that cannot boast volumes, but it can surely claim illustrious legacy combined with periodic strikes at reinvention. A mainframe maker, one of the original computer companies, Unisys jumped into adopting Intel's Xeon processor for its mainframes a few years back.

At a time when the conversations are rife with debates on cloud and converged infrastructure, Unisys launched a server architecture called Forward. Jim Thompson, CTO, Unisys, in an exclusive conversation with Dataquest details out the idea behind Forward. Excerpts

BEHIND THE IDEA-ELASTIC COMPUTING, MULTIPLE SOFTWARE STACKS

Forward is based on a belief system and a concept that says infrastructure in the enterprise and infrastructure in the cloud will kind of merge in a hybrid way. One of the things that the customers are looking to be able to do is any infrastructure they purchase, they would like it to be elastic in nature, something that they can grow and shrink as they need to do so. They would like to be able to run multiple software stacks on it-Linux derivatives and Windows derivatives. And then beyond that our enterprise class customers and traditional mainframe customers are looking to be able to run their mainframe workloads in the same kind of space.

THE FORMULA-FABRIC-BASED ARCHITECTURE ON INTEL XEON

The idea was to take the best we could get from our partners at Intel in terms of high performance processors, the Ivy Bridge class, E5 and E7 coupled that with things that we found in the high performance computing space, most notably the high speed low latency interconnect technology.

When we started the work on this program around 2005, one of the first things we realized was that in the Xeon space, there were no partitioning capabilities available. Nobody had done work for Xeon. Then, there are virtualization capabilities available for Xeon, but they don't give us the predictable performance that we need, they don't give us the error containment that we need and they certainly don't give us the security characteristics that we need. So, we had to actually go off and construct the software element called s-Par that gives us the ability to partition Xeon platforms. Those capabilities coupled with media-neutral interconnect technology like InfiniBand and memory-memory for partitions in the same physical machine and for partitions that are outside of the machine.

FLEXIBILITY AND SECURITY

The key to all of this is developing the system in layers so that once the customer deploys the workload; he has the ability to migrate our hardware components as Intel or the server providers change their technologies. He has the ability to change the versions of software stacks, both middleware and base-level stacks, and upgrade his application and he does that in a non-disruptive way. At the same time, we understand that, there are varying degrees of enterprise class or business-critical class attributes that a system has to have and it varies based on the client or the workload.

The system has to be able to be deployed in a way where it is highly secured, where it delivers predictable performance characteristics, where it can contain (curb) errors, if it's the hardware or the software in the system, it can be contained to the environment that they experienced it rather than taking a larger piece of the complex and taken together, that's a unique set of characteristics.

This design helps maintain a stable environment for the customer application space, while letting him evolve his infrastructure at a high rated speed. The other thing is it really doesn't matter where he runs it. So, from a hybrid cloud perspective, a partition that is running local to the customer's infrastructure versus the one that is running out of a service provider were the same for all intents and purposes, they are no different, in fact, there are ways to migrate the workloads through these different tiers. I think in a nutshell, that's what the system is all about.

FORWARD vs. CONVERGED INFRASTRUCTURE

Forward is not exactly an example of converged infrastructure. We do sell and resell a variety of converged infrastructure solutions and typically those converged infrastructure solutions have a couple of characteristics that are kind of at odds with what we are trying to do with Forward. One is they tend to be virtualized systems as opposed to partition systems. So we lose all the advantages of partitioning when we move into some of these traditional converged infrastructure solutions. The other characteristic is in many cases, what I would describe is rack-limited or backplane-limited in the sense that the expansion of the system, the way you grow it is limited by either a blade frame, or a backplane or a cabinet and some vendors deal with this by providing different size building blocks. But at the end of the day, you still focus with a system that's not all that elastic. If the customers wants to say it's a converged infrastructure play and it suits them in that model, it is fine.

USE CASES AND WORKLOADS

The initial set of use cases for the systems that shipped in December were narrowly focused on SAP ERP, UNIX migration, so we are talking about RISC, so that would be things like HP-UX, Solaris, AIX-migration of those workloads to Linux on an open Xeon environment and consolidation of Windows and Linux workloads. So those were the three initial use cases. We are going to do a release in the system this mid year that will add to the big data capability around the integration of Hadoop stacks from MapReduce and integration of our proprietary mainframe systems both MCP and OS 2200 that will connect into our Forward fabric.