Michael Dolan Dot Com

Wednesday, March 21st, 2007

Recommended Reading for “Enterprisey” Types (and some for SystemTAP types)

Warning: Shameless Mainframe Plug (but I think it’s worth saying).

To steal an adjective from the guys over at Redmonk, the “enterprisey” types will find a January, 2007 paper by Forrester’s Brad Day quite interesting. It’s called “Why Choose Linux on a Mainframe” – a very compelling question. It’s common to be asked here, “why would anyone want to do Linux on a mainframe?” I was intrigued and read the paper.

I’ve discovered at IBM, mainframes are not a dying technology, in fact the longer I’m in IBM watching what customers are doing, the more I’m realizing that mainframes are actually a window into the future of where other platforms (x86/RISC) are heading. Sun, HP, Intel/AMD, and even the other IBM server lines watch what’s going on with mainframes and try to build those technologies/features into their products. It’s an odd thing having personally grown into the x86 culture thinking that the whole point was to get those outdated UNIX/Mainframes to x86 b/c of price points…

Anyway, this is a shameless plug for IBM-wares and I apologize, but I’m finding the customers using mainframes are doing some of the most interesting work and proof points around having 1 OS that runs and is supported everywhere. Most of these customers end up deciding Linux should be their strategic OS and once you have moved to Linux – workloads are ‘floating’ – they are not tied to any one type of hardware (within reason). Nationwide.com migrating their entire mission critical web infrastructure off a mix of 700 x86 and Unix servers was just the tip of the iceberg.

And if you think this is just a “couple guys out there” doing zLinux, Brad Day cites some of the metrics from LAST YEAR that still show how many customers are doing zLinux:

According to IBM, the Q2 2006 Linux/System z business closed out the quarter with more than 1,000 Linux customers on System z, 19% of System z revenues coming from Linux, and being deployed with 28% of System z customers and more than 800 System z Linux projects in production.

Unfortunately I can’t find a link to this paper other than one on Forrester’s website… If you’re ‘enterprisey’ then I’m sure the $279 won’t set you too far back (or you may have a subscription already).

On another note, for those of you concerned about observability, SystemTAP for Linux now has S/390 support for mainframe Linux (RHEL and SLES) ;-) Observers have to remember stap has enabled features built into the architecture to assist different types of users. Recently it seems the question on some minds is “why have a guru option at all” and “doesn’t that imply the architecture is unsafe”? I don’t necessarily speak for the developers (you can ask them though, they’re very open and engaging on the mailing list) but I’ll try to give my view.

In normal, user mode, stap is no different than other observability tools and it’s restricted like other observability tools to those things that could never crash a system. I’m told quite clearly, safety is not a goal; it’s a must. But, you have to understand the community users to see where a guru mode comes in.

SystemTAP guru users are the types living on the edge not caring what they do to a system and these users are going to try one set of things that you wouldn’t want to do on production systems. They are not the ordinary user – some are testing bleeding edge code and inevitably find bugs. Others are using stap and finding bugs in other code. The switch to manually/explicitly allow stap to execute a script with embedded C code is -g. I wouldn’t expect to see many, if any -g type users in production environments… it just wouldn’t make sense – and many can’t use -g even if they tried on a production system b/c compiling the embedded C code on a production machine requires gcc (which production deployments don’t – at least shouldn’t – have). Without gcc, the script would simply exit.

To use -g on a production system, you’d have to compile your script on another system using the new stap cross-compile feature and then run it on your production system… that’s a whole different class of user who 1) knows where in the kernel they want to look, 2) is dangerous enough to know they can write embedded C code to find that probe point, 3) knows how to cross-compile a script on one environment for another (and setup the test environment correctly), and 4) has the access to run it on a production system… not to mention that if they get to point 3), they’re going to test it on that system and work out any bugs there before running it on a production system.

The main point of having a guru option is that this one technology has the capability to do whatever someone can imagine (and I know of a few customers with great imaginations, just like those who imagined ways to save millions by running Linux on a mainframe). The way I see it is this: the Linux kernel is open source and even in the kernel developer crowd – who’s going to tell them what parts of their kernel they can/cannot have access to?

SystemTAP is architected for different goals than other tools b/c it’s architected in an open community. Just as Linux is modular by design to be open and adaptable when some others felt monolithic/prescriptive was a better path. When development happens in a closed environment, you get what someone else wants you to get.

Ironically, observability features first appeared way back when on the mainframe. It’s great to see that today as features evolve in an open community, an observability tool like SystemTAP can be used across all of the major system architectures: x86/64, RISC/POWER, and now S/390 mainframe. It’s still relatively early on for SystemTAP, but the project is definitely making strides and I’m impressed by the number and diversity of users I’ve seen so far. Just think about this: one observability tool can be used across your entire enterprise environment on an OS that runs on all hardware architectures… I wonder where that could lead?