« Canonical (Ubuntu) Needs a Mainframe (and zBC12 Post #3) | The Mainframe Blog Home | U.S. Class Action Lawsuit Filed Against Infosys »
Canonical (Ubuntu) Needs a Mainframe: An Elaboration
I forgot about this 2011 blog post. That wasn't such a great prediction, was it?
I want to quote one of the comments Mark Shuttleworth wrote which I think illustrates his profound misunderstanding, a misunderstanding that might have contributed to Canonical's recent security failure:
Cloud architectures are fault-tolerant by software architecture, only an idiot would pay for the same fault tolerance twice. Therefore, no matter how hard IBM tries to sell the idea of mainframes being the hardware for cloud, I don’t see it panning out that way. The whole point of the work that’s brought us cloud is to be able to do very large, very reliable services on low-cost, unreliable hardware.
OK, forgetting for a moment that reliability is only one of the many qualities of service — security is another one, as Canonical has belatedly and tragically discovered — no, I disagree, and so do most IT professionals. The reason is very simple: everything in IT fails, particularly software and administration (people). Over the past few days I've repeatedly explained that IT doesn't work well unless you get both the hardware and the software right, and unless both are co-engineered to work together cooperatively, with really, really excellent, common, consistent autonomics that reduce the people risks as much as possible. That's especially true in availability engineering.
One of the many beautiful aspects of the zEnterprise family of solutions — IBM's decades-long genius, really — is that IBM always expects software to fail, whether its own software or its customers' software. Only last week I heard a long and painful story from a client. That client explained in great detail how often their pure software cluster failed, leaving thousands of users with nothing to do. Programmers are not perfect. Nor are hardware designers necessarily, but "defense in depth" is extremely valuable when engineering for high availability.
And that's what IBM has done and keeps doing. It's not that IBM hasn't tried other approaches. Decades ago IBM implemented software-based clustering in IMS, for example. It's merely "OK" by mainframe standards, meaning it's superb software clustering but it isn't what customers expect. IBM still supports that form of clustering, but a couple decades ago IBM introduced the first version of Parallel Sysplex which relies on a combination of common, hardware-based features and software-enabled products that exploit those hardware features. IMS is one of many examples but only one example. Parallel Sysplex evolved over the past two decades and continues to evolve and improve. (This month's announcement of RoCE memory-to-memory high performance networking is a good example. Ostensibly that's a hardware feature, and it is, but it's actually a clever, packaged, integrated combination that provides a common service to all applications, transparently. Always with multiple layers of availability and fault tolerance.)
Frankly it takes an amazing amount of hubris to suggest that programmers always get it right, every time, and never ever muck up what they previously got right. Or that it's not possible to learn from other engineers who took a different approach that actually works in the real world. Again, look at Apple. Why on earth did Apple buy hardware companies? Why do they have engineers who can design chips? Why are they reportedly investigating the purchase of their own chip foundry? Both hardware and software matter to achieve a particular business outcome. Granted, Apple isn't maniacally focused on maximum qualities of service enterprise IT engineering like IBM is with its zEnterprise solutions. Apple is engineering for different outcomes than IBM and literally never compete. But the core principle is the same.
I should say that I very much respect Mark Shuttleworth and his accomplishments. But I think he got this one wrong, very wrong. We all make mistakes sometimes, myself included. We hopefully learn from those mistakes, otherwise we're doomed to repeat them.
| by Timothy Sipples | July 26, 2013 in Security Permalink |
TrackBack
TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d834521c8469e201910468e5c5970c
Listed below are links to weblogs that reference Canonical (Ubuntu) Needs a Mainframe: An Elaboration: