Mainframe 3.0

Great ideas in technology don’t change, though they do change forms.

Courtesy of Sega

I started my corporate IT career near the end of the Golden Age for mainframes – just prior to PC’s taking off in corporateworld. SNA networks were de rigueur in enterprise shops and 10Base2 Ethernet and Token Ring were considering leading edge tech. (If you had a deep understanding of everything in that last sentence before following any of the links, contact me – I’d like to buy you lunch). This was “Mainframe 1.0”, a centralized computing model where all of the iron was essentially in one room. We could post big burly men wearing face camo and M-16’s around the doors and feel relatively confident that everything was safe and secure. We sent 9-track tapes off-site for backup and paid confiscatory rates to disaster recovery providers to put us up in their “recovery suites” should our data center fall victim to a fill-in-the-blank disaster. We worried mostly about fire, water, and extended power outages. A Chinese hacker was someone working in a rice patty, not an imminent threat to our security. Ah…the good old days. Mainframe 1.0 was compute, storage, and networking all together, all in one place.

As PC’s brought about the so-called “Client/Server” era, tech pundits began to proclaim the death of  Mainframe 1.0 and tried to convince us that  a decentralized computing model was really what we’d all been waiting for. A PC on every desk and a server in every closet.  Move the compute and the data closer to the user, we were told – it’s all good. The fact that it really wasn’t all good is a subject for another day, but the client/server era did bring about Mainframe 2.0.  In Mainframe 2.0, our well-proven and beloved big iron continued to do what it always had, (despite the denial of some), but it was reframed as just a Really Big Server in the shiny new client/server model. Mainframe 2.0 was all about moving high-horse power compute and storage into a hierarchy where it still handled the toughest, most critical workloads, but also played nice with others in terms of sharing data with smaller servers and client devices. A quick look at IBM’s annual reports through this era consistently showed healthy big iron sales. Clearly, rumors of the mainframe’s impending death were being greatly exaggerated.

Even though Mainframe 1.0 and 2.0 had been using virtualization technology since the 1970s, the introduction of virtualization on the Intel architecture somehow seemed to take the experts by surprise. As eyes began to reopen to the lessons and economies learned on Mainframe 1.0, and products like VMWare began to mature, we began to see a shift back towards a more centralized model. More workload on fewer but larger, centralized machines. Storage moving from server closets into high capacity, centralized storage arrays available over the network. Data and storage networks converging into one. Re-centralization was bringing better utilization, lower costs, and less management headaches. Who could have imagined?

As this new-found trend toward consolidation and centralization continues, we find ourselves at the beginning of Mainframe 3.0 and a new buzzword to go with it: Fabric Based Infrastructure, or FBI.  By definition:

A fabric-based computer is a modular form of computing where a system can be aggregated from separate building-block modules connected over a fabric or switched backplane

Practically speaking, FBI is compute, storage, and networking all together, all in one place, like Mainframe 1.0 of the 1980’s, but all in one rack and much more versatile and dynamic.

FBI is not built on the mainframe hardware of yesteryear, but the concept is strikingly similar. Products like VCE’s VBlock, or IBM’s brand new PureSystems take the best of Mainframe 1.0 paradigm and rebuild it with the latest technology. You might even liken it to the difference between the Iron Man Mark I and Mark II suits.

When you buy FBI, you are buying a pre-integrated bundle of compute, storage, networking, and virtualization, ready to use right out of the box (“ready” being a relative term depending on vendor). Sort of like Prego…”it’s [all] in there.” The mundane, time-consuming tasks of provisioning servers, storage, and networking manually are all abstracted away by higher level management tools. In an FBI world, the weeks of time previously required to set up a new server environment is reduced to minutes. Administrators create new server environments by simply requesting them through a browser-based service portal. The fabric manager takes cares of the rest. Almost sounds too good to be true.

VBlock fabric is built with Cisco UCS compute and networking, EMC storage, VMWare, and a software management stack, preassembled, tested, and ready for immediate provisioning. PureSystems fabric is built on IBM’s new Flex System compute platform, BNT networking, and V7000 storage. While VBlock specifically supports VMWare only, PureSystems takes a broader approach of supporting most any hypervisor, (VMWare, Hyper-V, KVM, PowerVM, etc), and can virtualize Intel or IBM’s Power architectures within the same chassis.  As you exceed the capacity of a single rack, the “fabric”  can be scaled out by adding additional racks of capacity.

VCE is a subsidiary company formed by VMWare, Cisco, and EMC, so it’s no surprise why only VMWare is supported on VBlock. On the other hand, this closed approach allows VCE to deliver a much more complete, ready to use solution. IBM is just arriving to the FBI party with PureSystems, and while it’s hard to nail down all of the details right now, it appears that more assembly is going to be required on a customer’s part to get to the same level of automation that VBlock offers out of the box.The Flex System hardware is also new to market for IBM, so early PureSystems customers will have to blaze that trail as well.

Besides VCE and IBM, NetApp also has an FBI offering in the form of a reference architecture, know as FlexPod, that shows how a fabric can built using Cisco hardware, VMWare, and NetApp storage products.Unlike VBlock and PureSystems however, FlexPod is not an actual product you can buy, it is merely a reference architecture.

If you’re considering building a cloud from scratch that needs to be implemented quickly, provision easily, and scale rapidly, I would encourage you to investigate fabric based infrastructure. An old idea might be just right for your new solution.