On 16/09/2013 7:31 PM, Timothy Sipples wrote:
There are some rubbish or at least highly misleading numbers being tossed about (again), it pains me to say. (Cache? I/O proximity? Etc.) Space rockets and Ferraris are both transportation vehicles, but are they really comparable? Maybe if you're writing marketing copy, but not so much otherwise.
All good points but it seems technology is improving to the point where RDMA can plonk data straight into core memory. It may not be L3 cache but it's fast enough. Switches and backplains are just getting faster and faster all the time. Of course, z is in the game, RocE being the stand out. I notice that IBM are already submitting experimental x86 linux kernel patches for RocE. When that become a reality Hybrid batch becomes even more compelling. Those guys at Dovetail have a very nice product that will absolute fly in the not to distant future.
IDEAS has some RPE/RPE2 metrics that attempt cross-platform workload capacity and throughput comparisons, and they put a lot of effort into them. But there are still huge standard deviations even in their stuff. You have to put some due diligence into this. The correct platform selection answer -- if there is a platform selection option -- is not always or even frequently obvious. And I really, really don't think zEnterprise sales are increasing because zEnterprise customers are too stupid to realize that 1 blade equals 5 zEnterprise machines. (Hint: It doesn't. Really, really doesn't.) If you search on "z/OS cloud" using your favorite Internet search engine you'll get some interesting results, some from IBM some not. I think Jon Perryman raises some very interesting points along the same lines. What makes z/OS unique and especially compelling for cloud services is its inherent multi-tenancy within a single operating system image. Everybody else so far seems to be approaching the problem from a "one image, one workload fraction" sort of baseline, then trying to figure out a way to distribute workloads across and to manage thousands of images. I'm not necessarily opposed to that -- and certainly zEnterprise does that superbly with z/VM, and much more vertically well managed while still optionally horizontally -- but I don't think "one image, one workload fraction" is the best, most optimal deployment approach for all or even most cloud services. z/OS is quite special, and it's something maybe we take too much for granted. TCBs, address spaces, and so on really are quite innovative, yet they were born decades ago and have evolved ever since. Imagine if you had to deploy one or more z/OS LPARs (or z/VM instances of z/OS) for each and every CICS region, IMS region, MQ queue, DB2 database, network transport (HTTP/HTTPS), DFSMS (e.g. for backup), each tool and utility, clustering (coupling) component, and so on -- and I'm really barely scratching the surface since it's closer to every individual CICS program (to pick one part). You could do all that -- it's technically possible to have one z/OS instance per workload fraction. But, my, that'd be some extra work, wouldn't it? You'd of course mitigate that burden as best you could, in part with yet more tools and utilities, but ample work it would be. And IT work keeps getting to be a bigger share of IT costs. Anyway, these are rather different architectural approaches to delivering shared services. I happen to think there's a big role for both approaches. -------------------------------------------------------------------------------------------------------- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
