In last Friday’s post Bob Cringely argued that while the recent announcement of the new z10 mainframe (link from the excellent John Willis ESM blog) from IBM shows that the mainframe is dead, stuff like Azul’s java appliance are the real inheritors of the mainframe title.
He makes some good points, and the comment thread that followed was pretty entertaining – worth checking out.
But that’s gotten me to thinking a bit, and I want to riff on his point a minute. For the purposes of this post, I define a mainframe to be any multi-processor, shared-memory box that boasts about big capabilities. Stuff like the z10, high end boxes from Sun, HP, SGI, and so on. While their fans can rightly point to many individual differences, in reality their broad characteristics are very similar. So with that in mind …
Is the Mainframe Dead?
No … at least not for the foreseeable future.
This is clearly the case for several reasons. First, there’s simple inertia, in this case primarily in the form of legacy software (as in this app just works, and we don’t have anybody who knows how to change it anymore) and operational expertise. Which leads me too …
Second, there’s the accumulated comfort of knowing these systems are reasonably reliable for many of the day to day operational tasks, and the expertise to make them so.
Third, mainframes handle certain problems fairly well, particularly problems involving decent sized amounts of data, particularly where that data is going into a single database.
For years various claimants to the mainframe throne – including the DecSystem 10s & 20s of the 1970s, Sun, HP & SGI boxes of the 80s and 90s (among others) – have vied for the honor of killing the mainframe.
Yet the mainframe remains a real presence in many enterprise shops.
What Then Is Changing?
That mainframes are an expensive way to do computing is pretty obvious to most folks – even if you want to it’s just hard to hide the numbers. Big capital, big operations staff, big iron … they’re really all synonyms, or at least all parts of the same elephant.
Of course everyone would like to reduce expense, if they can.
So here’s the big surprise: what’s beginning to significantly reduce the footprint of the mainframe category (and remember here I include the traditional JEE clusters as well) is their inability to scale.
Pretty ironic, don’t you think?
Choosing a mainframe is sort of like using one of those SuperGuppy planes to carry an entire stage of the latest rocket … if that’s the only way to carry the thing, then go for it.
But what is FedEx using to carry the zillions of packages they deliver each and every day? I’d argue that the FedEx fleet is the airplane equivalent of commodity processors.
Fast, efficient, cheap & capable – especially when working together.
In any case the need for scale – the exact requirement that led to the rise of big iron – is now increasingly what is consigning them to those problems that cannot be done any other way. Furthermore, for all intents and purposes that trend is only in it’s infancy.
Can you imagine FedEx trying to build their business around these ungainly, albeit uniquely capable planes?
The real changes are yet to come.
The Reality of Scale
Just take a look at just about any of the truly web-scale SaaS offerings out there – be they just about any part of Google, Amazon’s own systems, Yahoo!, Facebook, Myspace, or any of the apps built to deploy on clouds such as S3 / EC2 … how many mainframes do you see in there?
Ummm … none? Exactly right.
‘We saw the same thing when laying new new architectures for processing very high-volume satellite imagery, reliably and in real-time.
Hordes of commodity boxes will smoke that mainframe (in this case primarily SGI boxes) in aggregate volume and performance.
Our fabric made that horde self-managing, reliable, & easy to scale without changing a thing, or even taking the running apps down. That is crucial, even necessary … but it’s not the whole story.
Give Me Data Fissures
What makes any of this stuff work is that the workload itself has what I call natural data fissures, or if not entirely natural then at least easily-discoverable data fissures.
This is what the traditional HPC guys might call “embarrassingly parallel” … and I’m ok with that.
The truth is that most enterprise workloads have far more natural data fissures than we realize, but that’s a post for another day.
The point here is that apps that can recognize these independent chunks of data, process them and eventually bring them back together for delivery, are perfect for cloud / fabric deployment.
The New Way to Scale
Think back to the FedEx example – that company lives and dies on their ability to reliably move and deliver a very high volume of relatively modest-sized packages – and to do so with a cost-structure that enables them to be profitable.
Of course they could never have scaled their company with a fleet of those ungainly SuperGuppies … and they didn’t have to since most of their business comes in small boxes and envelopes.
FedEx left it to the guys that needed to move whole rockets at a time to buy the specialized planes that could handle that job.
While the analogy is not perfect, I’m pretty sure that if you squint your eyes a bit, the SuperGuppy is pointing the way to the long-term future of the mainframe.
The whole business of specialized, attached processors (like Azul) is a discussion for another time. Unique economics, unique technical capabilities. Note that there are some very interesting places where commodity comes together with these specialized boxes. For example, check out what some of our friends at Exegy are doing … more on this topic later.
{ 1 comment }
To some extent, the “response-to-Cringely” piece, that compares (as analogy) Fed Ex package carriers to SuperGuppies, works. What that response should also highlight, because it’s vital perspective, are the design and ability of mainframes to master complex, mixed workloads. When one considers, too, the unique security attributes found in today’s mainframe, one might better understand why these systems present the most appropriate asset for large-scale, mission-critical tasks.
The “Mainframe versus Distributed” debate persists; in part because the role of Linux on the mainframe is still not entirely appreciated. As “open” as Linux is, the fact that IBM mainframes run Linux coupled to extra-ordinary virtualization tends to make those system, de facto, “open.” Distributed vendors tend to generate “myth” about today’s mainframes. They do not give fair credit to the simplification, standards adherence, and applications availability exemplified by IBM’s new System, z10 Enterprise class.
The “SuperGuppy” vs “many smaller aircraft” analogy is vivid. However, the full story is not told by that construct. Mainframes will have a long future. Their design point of >30 years MTBF presages long, high-value working life for users. Net: there is no perfect solution to data explosion, regulatory proliferation, energy and space shortages. Racks of blades make some sense, sometimes. But, for the really big mixed workloads, included both OLTP and DSS, the mainframe still seems like the most appropriate vehicle to deliver the IT benefits that business increasingly needs.
Just my two cents here….
Comments on this entry are closed.