IBM launches Linux-only mainframe system
reuters.com
reuters.com
I'm really excited about this announcement. I think IBM finally realized they need to be more open if they want to grow the Linux on z community. I just hope they are not too late to the game.
There's a lot of mystery and misconception behind mainframes, so I am happy to answer any questions about mainframes that I can.
z/OS has a long history. It's predecessor, OS/390, dates back to the 1990s. Before OS/390, there was OS/360 which dates back to the 60s. Back then, IBM was first to market on business computer processing. (That was the only computer processing.) Major industries, like financial, insurance, and airlines, poured their infrastructure into mainframes, because it was the only name in the game. IBM prides itself in assuring its customers that the COBOL code that ran your business back in the 80s will still run today on z/OS 2.1 (the current version of z/OS). Chances are, when you swipe your credit card, that transaction touches a mainframe and probably some code that was written in the 1980s. Or earlier. I know, because I've seen the timestamps.
This compatibility is really evident when you use z/OS. The green screen is perhaps the most obvious example. When you see a systems programmer (that's mainframe-talk for sysadmin) debugging a system, you'll see them page through a really archaic, unsexy TN3270 interface. Why? The same reason Unix (and thereby Linux) uses teletype. Because that's what the operating system was built on.
Sure. z/OS has Unix System Services. In fact, it's even POSIX compliant. But can you `apt-get install ruby`?. No. There's no Ruby for z/OS (unless you count JRuby). There's no package manager for USS. It's just plain, vanilla Unix. There's no new open source contributions. There's no Bash that comes with the operating system. You get a 10 year old version of Shell. There's all kinds of shenanigans with SCP/SFP and ASCII/EBCDIC. IBM has to maintain the tools. (Actually, it's been turned over to Rocket Software.) It feels very "round peg, square hole".
So z/OS has an image problem. IBM made a huge mistake back in the mid-80s. When commodity x86 PCs became available, universities realized they could teach their computer science programs on cheaper hardware instead of expensive mainframes. Compute Science is platform agnostic, right? What IBM didn't do is recognize this as a problem. They didn't give out free mainframes to universities, so schools quit teaching with them. How many people do you know under 30 that had a mainframe-based curriculum? And for the self-taught, how are you suppose to learn the basics of a platform if costs millions of dollars? Anybody can install Linux on their $100 laptop in a few hours. But mainframes?
Fast-forward a couple of decades and now you have a talent pool that's extremely saturated with x86 people. And the mainframe people? Well, they are all retiring and there aren't many replacements. Second-generation mainframers are far and few. (I'm one of them.)
So let's say you have a new workload. It's undeveloped. What platform should you choose? There's probably not many technical reasons why you could not accomplish what you want to do in z/OS. But how many people do you know that consider themselves proficient with debugging z/OS? Outside of "dead languages", your options are pretty much limited to Java. (There's a few exceptions to this, but Java is the biggest modern language player.) But that's not to say there isn't any new development happening in the z/OS space. There's plenty of new workloads coming to WebSphere on z because porting a WebSphere application could be pretty easy. There's also performance benefits when you are on the same system where all your financial records are stored. z/OS is definitely an option, but it varies by use case.
With Linux on z, you get real Linux. And the majority know Linux. The majority can debug Linux. And you get the same benefits of being on rock-solid mainframe hardware and you get memory-speed I/O against mainframe data and services through a special networking interface called Hipersockets. Mainframes are also pretty good a virtualization, because they invented it. (z/VM has it's roots dating back to the 70s.)
Not sure what they're actually doing but closing it off too much holds them back. It can still be proprietary. However, people need to be able to hack on it or a VM of it for best results. Preferably, a way for people to learn it in pieces so they don't have to know all mainframe stuff at once. Think the pre-configured, appliance VM's for various services. Have those for z/OS admins, CICS users, etc.
It seems like, except for "Cracking the Mainframe" or whatever, there's no easy (or even moderately accessible) way of simulating a mainframe setup to learn. Again, I love this stuff. I read Redbooks in my spare time. I have Hercules and z/OS setup, and that took a long time to setup compared to an Arduino or firing up a Linux VM. An average HNer is probably like me -- he/she might want to fire up a z/OS instance and play around with it. But he has no way of doing it though.
These are the tinkerers who end up deciding what platforms to use down the road. The high school kids playing with those free STM32 micro-controllers that TI gave out was a brilliant move. When they choose to do their semester project junior year, they might stick with TI because that's what they know. AVR was lucky Arduino took off too for the same reason. 10 years from now, those high school kids are going to be choosing what to buy 10k units of to throw into the pick'n'place machine.
There are some interesting big-data cloud IaaS/SaaS offerings you've put out to keep up with the times but outside of alliances with large incumbent vendors (say, SAP in ERP; EPIC in Healthcare) to sell large modules, you're not going to see much traction.
Offer something the tinkerers can play with. Make that the gateway drug. Amazon did it perfectly with AWS - easy to roll out, pretty predictable pricing schemes, pay for what you need, and scale up (more VM's/larger VM's) or out (other products within AWS). Every other vendor is chasing their tail trying to capture that market.
Linux on the z community offers me nothing as a decision maker. If I was already vendor-locked into you guys, then the prospect is appealing. But even with low latency (operating within the u-seconds, m-seconds and people start losing jobs/panicing), five-nines SLA (healthcare, HFT prop trading) requirements, what does the Z platform have to offer? How can I even evaluate prospective costs when pricing this out to pitch to the (hypothetical) board?
(Disclaimer: I have not idea what I am talking about when it comes to mainframe, just a quick thought that popped into my head).
Mainframes gradually exited academia in the mid-80s. It was a terrible mistake by IBM, because they essentially eliminated the next generation of mainframers. They've since come to their senses with a program called the IBM Academic Initiative [0] which promotes the use of mainframes in Computer Science courses. It's only about 20 years too late.
But I think they could do a better job. Up until recently, the only way to try z/OS without accessing million dollar hardware was to break the law. You literally had to torrent a pirated copy of z/OS. And it's not easy to find. A few years ago, IBM changed this with their tool: Rational Developer and Test for System z [1]. It's essentially Hercules but you get a legal copy of z/OS. And it's $9500 per year per CPU. And there is some stupid hardware license usb key.
And regarding your questions, your points are valid. Vendor lock-in is a concern. IBM is the only player in the business, and they know it. But look at every major industry that's been around at least 30 years: all the mission critical stuff runs on a mainframe. Maybe it's because it's the only thing that runs their legacy COBOL code. But it works and it's rock solid.
The poster child of migrating to Linux on z is Nationwide. They successfully moved almost all of their x86 processing to Linux on z and saved a ton of money. There's the definitely-not-vendor-biased white paper out there. Do some googling on "Nationwide Linux on z".
[0]: http://www-304.ibm.com/ibm/university/academic/pub/page/acad... [1]: http://www-03.ibm.com/software/products/en/ratideveandtesten...
That's why I broached in another comment an application, VM model like we saw for VMware, etc. They have a pre-configured VM for about everything. Could do the same for various aspects of mainframes so people could selectively use or learn each piece while slowly building up understanding. Pre-configured Hercules with some good tutorials on usage might be a start if not the other model.
My limited understanding is that most mainframe customers are locked-in, e.g. they have legacy COBOL code running their ledger system and the expense to switch off of it is simply prohibitive. That plus the fact that the system is reliable, low-maintenance, etc. preserves the status quo, despite the fact that if you were to write the same applications today, you'd choose a newer platform because it would be more cost-effective.
As such, IBM has historically offered z/Linux and co-processors only to hold onto data and processing that was being pulled off of the mainframe because it was too expensive/too onerous to do on the mainframe using z/OS and the like. So customers, unable to completely shut down their mainframe, could kind of make the best of a bad situation and at least get some cheaper Linux cycles out of their expensive iron.
If the above is true (and correct me if it's not) what is the appeal of a Linux-only mainframe? Or is it only interesting if it is radically cheaper than a z13?
I think the answer really depends on IBM. Technically speaking, the hardware is rock-solid. There are no single points of failure in mainframe systems. But there are still some obscurities with the platform. There's a lot of packages you'd expect to be available in your s390x distribution of RedHat or SUSE that missing. And that's probably because the average open-source developer/maintainer doesn't have the means to develop/test on a mainframe.
IBM needs to realize they have an open operating system on a closed platform and the two don't mix. They are taking steps in the right direction, but time will tell if they get there. And they have to prove they can compete with the x86 guys on price.
> My limited understanding is that most mainframe customers are locked-in, e.g. they have legacy COBOL code running their ledger system and the expense to switch off of it is simply prohibitive. That plus the fact that the system is reliable, low-maintenance, etc. preserves the status quo, despite the fact that if you were to write the same applications today, you'd choose a newer platform because it would be more cost-effective.
You are mostly on track there. Mainframes haven't died because of many of the reasons you listed above. But I'd have to disagree with last statement about choosing a "newer" platform. Mainframe hardware is modern hardware, in the sense they are updated every one to two years. Mainframe operating systems are modern operating systems. They also get updated every one to two years. If you look at every industry that has been around for more than 30 years, almost all of their mission critical workloads are done on System z. Cheaper isn't cheaper when you have downtime.
But for some workloads, you are right: companies are only on mainframes because migrating to a different platform would be too costly. Even over 10, 15, 20 years.
See http://techcrunch.com/2015/08/16/ibm-teams-with-canonical-on...
I wish article (or IBM) provided some specs. Thousands of containers is just too broad of a statement- what are these containers doing? Running just a bash script hello world program or minting bitcoins?
I don't see how this is any different from a regular server rack.
well, the difference is that most rack cannot fit 10 TB of RAM and 140x5GHz cores: http://www-03.ibm.com/systems/z/hardware/z13_specs.html
but surely those are super-expensive and I doubt all that effective when it comes to performance per watt. I'm actually a bit more excited about Power8 servers, but are there any non-IBM available yet?
Yep, OpenPOWER machines are starting to come out - Tyan has the Habanero server as well as the Palmetto reference/development platform. http://www.tyan.com/solutions/tyan_openpower_system.html
(disclosure: I'm an IBMer working on Power)
> Data centers
> Big data
Can you give me some specific roles for this range of servers? What makes it's worth compared to x86 system?
In general Linux upstream these days "just works" on ppc64 & ppc64le. There's RHEL for POWER already, and IBM have loaned hardware to the CentOS project so we'll get CentOS on POWER pretty soon.
The licensing of (Open-)POWER is more open than x86 (but not as open as stuff like RISC-V), and there are several second sources for chips, in situations where that matters.
Generally speaking, you buy the hardware because your workload needs the single core performance, or you're arbitraging vendor licensing costs for software.
Also, IBM's bread and butter is "peaky" financial services and gov't business, so they have business models that makes it work from a $ pov. You can buy a box with 100 cores, pay for 20, and lease 30 more for a few days to meet your peak demands for tax/christmas/billing season.
I can fit 4 C7000 chassis in a single rack, which top out at an aggregate 32 TB of memory and over 2000 cores. 5 GHz cores running s390x microcode are not, FYI, twice as fast as Xeons.
It would be great if people who weren't familiar with the state of the art in x86 kit didn't blindly assume IBM et al's advertising was reality.
As with all IBM mainframes going right back to the 60s, the "z" systems are designed for continuous uptime, on the order of decades, and this is evident in many of the design decisions. For example, various subsystems and components have hot-spares available, so that even outright component failures will not cause downtime. Many components are then hot-swappable, even those that might not ordinarily be in other architectures, such as processors and main memory. No interruption to OS or application-level services is expected by hot-swapping such hardware. Across the useful life of the mainframe, most repairs and maintenance would be carried out without ever shutting it down.
I understand the platform also has extensive internal integrity checking built in, a potentially important factor for various types of jobs. Its auditing service is capable of detecting unusual conditions in various subsystems or jobs ("I've just picked up a fault in the AE-35 unit"), automatically retrying instructions on the processor if they executed anomalously. If the fault continues, the suspect processor is routed-around with no interruption to OS or applications, the job is resumed from last checkpoint on another processor, and the system phones home to IBM to log a service call. This monitoring is not being performed by processes running in userland or by the kernel, but is in fact baked into the hardware/firmware platform.
Furthermore, the systems can be configured with a variety of specialty offload processors or subsystems for tasks like encryption, key management, compression, and even logging -- which again might not be so commonly found on-board of some commodity servers.
(And, of course, even if you could put together an analogous solution with commodity kit, it's IBM! For the sorts of companies looking at a mainframe in 2015, having the IBM name on the SLA has got to be a pretty big part of the equation, right?)
Moreover, if you proposed to build and manage these sorts of capabilities from commodity x86 kit, I imagine IBM would claim that they'd have the lower TCO.
People fall into the mistake of just comparing cores and memory specs between x86_64 and s390x. The hardware redundancy benefits are pretty huge. You really need a full proof-of-concept to get any picture of how your workload might run on System z.
Not really, IME.
> You really need a full proof-of-concept to get any picture of how your workload might run on System z.
Absolutely. Some workloads can make sense. For others...
Whereas I have hands on experience with this stuff. So I guess I should thank you for giving me first-hand experience of being on the receiving end of that mansplaining thing people complain about.
> I imagine IBM would claim that they'd have the lower TCO.
Yes, they will. The funny thing is, the man from HP was in just last month explaining to me that Xeon Superdomes have a lower TCO, too, and last year the lady from Oracle was telling me how I shouldn't balk at the headline cost of ExaData and ExaLogic because, from a TCO perspective, they'd save me money.
No. Which workloads do you have that need more than 40 cores per image, are happy with a maximum of a hundred on, and won't run on clusters? (I hope it's not one that's going to be crippled by zVM's slow scan of large memory areas suspending guest execution).
> I/O offloaded
If you've actually worked with zLinux (I have) you'll know there's little effective offload, and that zVM overhead increases as the virtual IO ramps up.
> and five 9's
Is zVM offering sysplex? No. So you're relying on your single LPAR to be five nines? Never upgrading zVM? Never updating PR/SM?
Is the datacentre five 9s? The power? The network? Really?
Any rack can fit 10TB of RAM and the equivalent of 140x5GHz POWER cores.
I can easily get ~1TB RAM and 64 2GHz+ x86 cores in 1U. A standard rack is at least 42U. In terms of density it's nothing special.
What makes these different is that you get it in a box that someone else will be maintaining, and where all the dirty work of designing and building a high availability redundant system has been done for you. Most people never build anything remotely as redundant as these things tend to be.
If it's anything like previous-generations, that will be infiniband between books. The benefits on Z-class systems tend to be very big per-core, per-socket caches and, as the person you're replying to said, a lot of internal redundancy and automated failover (multiple backplanes with failover, spare memory and cores with failover, and so on and so forth).
You can hook up multiple IBM mainframes remotely and set them up to automatically ensure consistent replication of machine state to various extents depending on your reliability vs. performance tradeoffs and replication distance (latency being the issue), all the way up to active-active operation across systems.
So in other words: It works far better than the failover options most people deploy on their off the shelf servers in their self-wired racks (and yes, I run my own setup across off the shelf servers; and no, they're not nearly as redundant as a pair of IBM mainframes).
And it is an awesome thing - although I didn't realise it supported zVM these days, rather than just zOS.
In any case, you've still got two baskets, which was my point.
This only works well if you can negotiate an acceptable SLA, your main vendor doesn't balk when integrating with subcontractors or other vendors and if you have a rock-solid vendor manager on your side enforcing the SLA.
Needless to say, it often doesn't work that way.
E.g. we used to have an IBM Enterprise Storage System (aka the Shark) back in the day (around 2000), and it came in American fridge size, full of drawers of drives. You could just yank any drawer safe in the knowledge that all the raid volumes were distributed over multiple drawers. If a SCSI controller failed, you could yank a drawer of SCSI controllers and hotswap them safe in the knowledge they were fully redundant.
The "brains" of the thing consisted of a fully redundant pair of two AIX RS/6000 servers, and you could yank either one of them without losing data (all writes were committed to at least non-volatile memory on both servers before being acknowledged). Either server also had at least hot-swap RAM (raid-like memory controller) and may have had hot swap CPU's (tell the OS to move all threads off a CPU, swap, switch back).
On top of that, it had a phone connection and would dial out to report any early warnings of problems directly to IBM who'd send out a technician before anything even failed as long as you kept paying your support plan.
So yes, you can get that density with standard kit easily, and probably much cheaper too. Assuming you have enough skilled staff to manage it. The reason IBM still manages to sell this kind of kit, on the other hand, is because what they are really selling is peace of mind that most issues are Someone Elses Problem. For some people it makes sense to pay a lot for that.
Back in the late 1990s I was involved in provisioning a large Sun e15k. Not indestructable but nearly.
It broke. You know what happened? The factory roof leaked and poured water onto the DC sub-building which the roof then collapsed onto the e15k which promptly blew up and caused a spectacular fire, halon dump and about a month of work arguing with insurance companies and guys with shovels.
In that circumstance, it doesn't matter what promises the vendor make. That's still all your eggs in one basket.
Buy two and keep one somewhere else didn't help either as the network termination, switching and routing layers were down and all the people using it were about 300 miles away from the backup location anyway. So some poor fucker had to dismantle the backup e15k and disk arrays, bring them in a large truck[1] to the original location and erect a temp DC in a portakabin outside the building.
Edit: We would have been better served with two smaller DCs with off the shelf kit on the same site but different buildings running a mirrored arrangement. All for pocket change compared to a zSeries...
That's what the company I work for now do. We have off the shelf kit,SAN replication, ESX, redundant routing and multiple peers in different locations.
[1] imagine the shit if that truck crashed.
You'd be in exactly the same situation if you had off the shelf "normal" servers in a rack. The point is one IBM mainframe is generally going to be more reliable than the vast majority of "homegrown" setups in a single location.
If you're comparing against a setup in multiple locations, then you should compare against two or more of these.
And there too these kind of solutions are far more reliable if you are willing to pay the money. E.g. IBM provides a range of options up to full synchronous mirroring of mainframe setups over up to about 200km where both systems can be administered as one identical unit (distance is down to latency). They also provide a range of other options for various performance vs. amount of data you can potentially lose vs. cost tradeoffs.
> Buy two and keep one somewhere else didn't help either as the network termination, switching and routing layers were down and all the people using it were about 300 miles away from the backup location anyway.
And this wouldn't have been any better if you had two racks of kit instead of two mainframes.
> All for pocket change compared to a zSeries...
There we agree. I'll likely never buy or recommend one of these, for the reason that I tend to work on cost sensitive projects.
OTOH, you couldn't pay me to program in RPG/400 using SEU. Building menus, or playing around with a little CL on on the '400 is one thing. But RPG programming sucks. Well, it did anyway. Maybe things have gotten better. I understand the ILE stuff made RPG less column oriented and closer to a free-form language, but I had never had a chance to use that.
Let me guess you started in the early 90's, right?
I remember looking at HTTP for the first time and feeling like it was 5250 display files writ anew. The y2k mess made me jump into web dev full time.
-----
Hahaha... well, it's a long story, regarding the early part of my career. Especially the whole bit about exactly how I got involved with AS/400's in the first place.
Let me guess you started in the early 90's, right?
Almost. I graduated H.S. in '91, started programming in '92 or so, but didn't start my first IT job until 1997.
https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf
Designed for business apps, future-proofing, integrated database, largely self-managing, capability-security, continuing on solid (POWER) hardware... did about everything right. That's why we regularly fix crashed Windows and 'NIX machines but my company's AS/400 has been running for around 10 years.
I've always wanted a modern, clean-slated version of the System/38 w/out relics from that time and with any tricks we've learned since. Throw in hardware acceleration for garbage collection and some NonStop-style tricks for fault-tolerance to have a beast of a machine.
http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
A similarly amazing machine that IBM's System/38 learned from a little bit. Somebody posted a link to an emulator but honestly I don't want to dredge through that. Like you said, a modern system that reimplemented its best attributes without the limitations or baggage would be nice.
Mainframes are complex enough that there's rarely projects to implement them but there's lots of work on safer CPU's. See crash-safe.org's early publications for a CPU that combined Burrough's-style checks, Alpha ISA, and functional programming at system level. Given stack preference, you might like these:
(from Wikipedia)
Back in 2005, I installed SuSe on an s/390 box. If you could throw a lot of memory at it or MIPs, then it would run pretty well, and could be used as a file or email server. But anything that crunched data was horribly slow. Can't say that it's any better now, but if it's utilizing the zIIP, I'm sure it's miles above where it was 10 years ago.
Still, pretty high cost of ownership on the mainframe to get this. I can't imagine many people buying a million dollar mainframe just to run Linux. Seems like those who have a mainframe already would have been like us: let's partition out a Linux instance and try it out.
But you are right. A lot of shops go through a lot of effort to maintain their zIIP window in their z/OS processing. And a big selling point for many mainframe software vendors is that their product's processing is "zIIP-enabled".
[0]: https://share.confex.com/share/120/webprogram/Handout/Sessio... (slide 30)
The Techcrunch version of this story [1] has an interesting bit on the pricing model, suggesting that the up-front cost will be much lower than usual (but no specific numbers).
By offering an elastic, cloud-like pricing model, [IBM] is hoping to land more customers who might have been scared away previously by the up-front cost of investing in a mainframe. The metered mainframe will still sit inside the customer’s on-premises data center, but billing will be based on how much the customer uses the system, much like a cloud model, Mauri explained.
Of course it depends a lot on the specifics, since IBM does already bill in part based on usage. So this could be either a significant departure in pricing approach, or just marketing a tweak on it.
[1] http://techcrunch.com/2015/08/16/ibm-teams-with-canonical-on...
It shows how outmoded mainframes are that they're now selling one that only supports being a fleet of Linux machines. Mainframe customers are no longer scaling their legacy zOS systems, meaning the big mainframe users must be processing their transactions in the Linux cloud now.
I cut my teeth on an Amiga and understand the appeal of external processors, but it seems like bringing those features on-die would be better yet. Mainframes seem to be going the other way, though. What am I missing out on?
Excellent question. Statements like this, grandiose but nonspecific, are intended for managers and those who are looking for a justification to spend money.
If true, here's your specs for the z13:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=SP...
Interesting they're working with Canonical on this - the Z has historically been a SuSE stronghold, with a lot of the development of Linux-on-Z happening in Germany, and Red Hat trailing behind. I'd be wary it will be another increasingly typical adware effort from them.
(I follow the main zLinux mailing lists for my day job, and I see a lot of folks from SuSE, some folks from Red Hat, a bunch of people from IBM, and basically no-one from the Ubuntu/Canonical world. Usual disclaimers apply.)
Any specifics you can share?
Conversely, CPU intensive Java don't really seem to enjoy much, if any, advantage, which makes it a very, very expensive option for doing that.
There are a bunch of factors to consider (for example, if you've got zLinux and zOS co-resident on the same system there are some interesting things you can do with your legacy and modern code bases), but in general I'd want to prove anything myself before diving onto a Z.
"typical adware" - heh heh! Seriously, in the consumer space everyone wants "free" so affiliate marketing is a sensible route - see the consumer internet for evidence. In the enterprise markets customers are focused on delivery outside the pure bits - open source bits are necessary but not sufficient - subscriptions such as Ubuntu Advantage with SLA's, management frameworks and consulting are viable there.
Ubuntu's distributions are the reference root FS for Cloud Foundry, to which IBM is the second largest contributor of treasure and engineering effort.
Disclaimer: I work for Pivotal, who are the first.
http://www.lookupmainframesoftware.com/soft_detail/dispsoft/...
There was also Amdahl UTS, which was sold to a company UTS Global around 2000 that appears defunct now.
https://en.wikipedia.org/wiki/Amdahl_UTS
So where is this stronghold of AT&T descendant UNIXes on mainframes then?
Anyway, IBM i and AIX run on the same hardware. They used to be called System I and System P. Now it's just Power Systems.
Maybe thats what he ment.
Or well, come to think of it. There is a UNIX side to z/OS itself.
1. Reliability. Some have gone 30 years without downtime. Probably strongest selling point.
2. Channel I/O [1]: dedicated I/O processors plus scheduling that lead to high utilization (80-90+%) and throughput vs commodity servers. Second strongest point in mainframe's favor. I wish my desktop & servers had this rather than a knockoff.
3. Hardware partitioning that's more robust and rated at stronger security than most virtualization. Certain cutting-edge projects in INFOSEC are doing similar things at CPU and I/O layers. Mainframe's version, although not as cool, is decent and field-proven.
4. Built-in, proven software virtualization.
5. Hardware acceleration for some things such as databases and crypto.
6. IBM's ecosystem of apps, third-party providers, and services. This might matter to existing IBM customers.
So, those are a few advantages I hear from people who use mainframes. The z/OS-based mainframes have extra benefits in terms of software reliability, security through obscurity (obfuscation), and seemingly better use of both security (eg memory key) and functional (eg decimal) aspects of mainframe processors. The z/VM product has also been doing for decades what modern virtualization systems only recently do, even self-virtualizing since 70's.
So, there's some things to ponder. Whether it makes since financially vs other setups is a whole, different discussion. However, mainframes do retain strong, technical advantages over commodity architectures. They were doing cloud in one box before it was a thing. Their reliability is still unmatched with only VMS clusters and NonStop architecture getting close. So, it's a sensible choice for a business to spend extra $$$ to get high-throughput with no downtime and strong isolation of logical partitions.
Channel I/O [1] https://en.wikipedia.org/wiki/I/O_channel
How small is this market? You'd have to have apps that were written to take advantage of Power7. Equivalent x86 Linux servers are 1/4 the price.
It also has 170 cores and was actually a QEMU instance (w/ hardware virtualization extensions) vs raw dedicated metal. If you're doing any kind of numerical or analytic workloads (even databases), I wouldn't throw them aside so quickly. You can even get CUDA for them these days, and certain physical addons like CAPI allow you to map and coherently share physical CPU address space with FPGAs or GPUs. If I could get those things in a reasonable workstation configuration, I'd probably go for it tbh.
(I'd be more than willing to repeat this and post some more accurate numbers if anyone cares. I also need to get around to benchmarking AESNI vs that POWER8 machines _actual_ dedicated AES unit. The benchmark above was only flexing its vector/integer unit capabilities. ;)
You're severely underestimating the cost of dual-proc 16-core Xeons (about $3500 each for the E5-2698v3), and by the time you add memory, storage, I/O, networking, and other necessities, you're easily in the $15-20k range.
Source: I work for an integrator.
That doesn't sound right to me. What are you considering an equivalent x86 machine?
https://en.wikipedia.org/wiki/IBM_zEC12_%28microprocessor%29
These are the journalists specialized in IT news for a giant like Reuters?
Also, I know this is a newswire/business site, but this is super skimpy on the details.