It all depends on performance per dollar - POWER and AIX, POWER and Linux, x86 and Linux, ARM and Linux, SPARC and Solaris... It's all about what gets you more work done per unit of money until you retire the box. Is it compelling? Not sure - depends on licensing terms, co-location costs, what are you doing, energy costs, AND compute power. As compelling x86 and ARM with Linux seem to be now, I wouldn't rule out other platforms without an assessment based on the workload.
Once I managed to bring a couple Itanium boxes we had from retirement because their then humongous caches were perfect fits for our working dataset and, therefore, for that specific workload they were 10x faster than our Xeons.
> Is it compelling? Not sure - depends on licensing terms, co-location costs, what are you doing, energy costs, AND compute power.
It seems like Linux always wins in terms of licensing, so does it currently lose in any of those metrics?
Also, since Linux runs on IBM POWER systems, it looks a lot like IBM's AIX has very little place to stand: Even if the hardware is better (which, judging from experience with other proprietary workstation vendors like Sun, I'd be surprised about) the value proposition of running Linux as opposed to a proprietary OS with less effective support and expensive licensing appears insurmountable.
So, I'd be willing to believe that IBM's hardware is better in some ways, but I'm more skeptical about IBM's software in a realm where an apples-to-apples comparison is possible.
You run the IBM power stuff mostly because it is the most cost effective way to run Oracle and other CPU licensed workloads. You can’t use VMWare partitioning to avoid paying. But the IBM hardware based stuff allows you to segment the workloads.
The other thing is that like mainframe, you can lease CPU on demand. So if your business is cyclical, it may be better to increase CPU November-January by 20%.
POWER is supported on linux to the point where it runs, but it doesn't come close to fully leveraging the hardware. AIX does. Stuff like hardware accelerators, transactional memory, hardware counters, reliability monitoring and self healing, etc. Lots of stuff left on the table because it doesn't perfectly overlap the x86, and it would be a massive undertaking to correct that in the kernel. You'd think that wouldn't be the way it is with IBM and RH... but I suspect there are some market segmentation ideas informing those decisions.
My company still runs a lot of stuff on AIX (also mainframes for that matter) and the reason is that it was set up that way in the 90s and no one feels like investing the sizeable amount to move these business-critical applications over to Linux just for the sake of it. Unlike all the other unices that were formerly used here (HP UX, IRIX, Solaris, Super-UX and others) you can still get AIX support so there is nothing forcing the hand of this migration. I expect them to still run some stuff on AIX in 10 or 20 years. Nothing new will ever be deployed to AIX and probably hasn't been in 20 years. At some point the AIX systems will only be around for a handful of niche things and at that point the cost of migrating those over might become lower than the cost of paying IBM off.
I mean, you'd have expected that of Solaris and Sun's hardware, too, but that didn't make Solaris on Sun workstations compelling enough to actually survive. That argument seems like a variation on one of the myths mentioned in these posts:
In short, I'm not sure IBM Power machines have any special hardware, and if they do, I'm reasonably sure Linux supports it. It is, after all, a smaller and more stationary target than the weird crap that ended up inside and hooked to commodity PCs that Linux ended up supporting.
Sun abandoned the workstation space well before Oracle finished abandoning SPARC and Solaris.
As for special hardware, the processor drawer of an E1080 looks a lot like the one of a z16 (without the distributed virtual cache of the Telum, or the insane water cooling blocks):
On the far opposite of the startup post company gobble up side - I've been pleasantly surprised how well our zSeries ran OpenShift k8 images for our inherited mainframes. A simple tune for s390x JDKs, and many of the Java based apps were off to the races. The hardware already was - so the cost of putting it to work ended up being cheaper than using cloud resources. The IO, as one might expect, is very solid. Loving the hardware we had was a less bitter pill than pushing out our own instances.
After noodling out how to make my docker images work on aarch64 and amd64, it was trivial.
This is the point - IBM doesn't seem willing to help. I'd love to be able to use LinuxONE machines as VM hosts (single thread performance and IO throughput are absolutely ludicrous) but there seems to be no entry-level machine that doesn't imply in a very sizeable investment. And I suspect LinuxONE and POWER10 machines would very cost effective ways for IBM to provide Linux VMs for public cloud environments at better price/performance points that it could be achieved with x86 or ARM.
To me, it's absolutely nuts they don't have entry paths to their crown jewels. What will IBM's competitive advantage if everyone migrates from AIX and IBMi to Linux? While there is no IBMi emulator, there are commercial environments that can compile and run COBOL and PL/1 code made for i on x86 Linux machines.
I think that was the point of the Red Hat acquisition. "See all those Linux boxes you run? Do you want to have someone to yell at when they blow up? It's either us or Canonical.".
There's no way z/OS is going to be free or open-source (if for no other reason than if they open sourced it, you'd still need a mainframe, which means you're going to pay IBM for cloud time), so if hobbyists are going to start with something they'll probably start with Linux. Once they are no longer a hobbyist, IBM will be there to help.
> There's no way z/OS is going to be free or open-source (if for no other reason than if they open sourced it, you'd still need a mainframe, which means you're going to pay IBM for cloud time)
This is probably why IBM mainframe OSes until the 1980s are public domain: You can't run MVS without an IBM mainframe, so why bother even copyrighting the source code? The Hercules people are grateful for that bit of pragmatism.
I believe the actual reason old IBM mainframe OSes is that computer programs originally weren't copyrightable. When the law was changed to make them copyrightable, this wasn't retroactive.
> There's no way z/OS is going to be free or open-source
I never said that.
What I said is that there aren't any onboarding routes to z/OS (or AIX, or IBMi). You either already are running one or more z/OS boxes, or you'll just deploy to cloud, CentOS, Kubernetes, OpenShift, on commodity CPUs (x86 and ARM), or any of the other stack that rivals a mainframe in some capabilities (and carefully avoid business requirements only a mainframe can fulfill)
Sure, I'm a bit sad to see tech lost as well. However I gave up hope decades ago that someone at IBM might have read the "Innovators Dilemma."
Or considered employing the longterm-thinking kind of executive that would have read it.
Not sure if big-blue ever had that kind of person in abundance to be honest.
Was recently reading up on the DEHOMAG thing recently, and well probably not. At least Watson tried to give the Nazi medal back, haha.
You wouldn’t. Most customers tolerate IBM, they aren’t investing.
The only exception is in the defense space, there are some things from a segmentation perspective that are cheaper to achieve on mainframes. But that isn’t a startup scenario, and those advantages are eroding as well.
IBM has huge margins on this stuff, so the typical play is use margin on the mainframe to win software and services deals. Startups need fast time to market, so it makes sense to overpay AWS by the drink than to overpay for a feast from IBM.
Softlayer was (is?) a good US-based bare-metal hosting provider before IBM acquired it. A company I worked at in the mobile gaming space in 2012 used them for their US backends. Not sure if they're good value these days.
