LinuxONE servers come to the Big Blue cloud:
IBM has taken a longer-than-usual stride towards making its proprietary hardware platforms cloudier, by offering bare metal LinuxONE boxes in the big blue cloud.
The LinuxONE servers use the same Telum processor IBM packs into its z16 mainframe but are designed solely to run Linux – Big Blue's own z/OS is not allowed.
But IBM promotes LinuxONE as offering just about the same level of hardware resilience as mainframes. The former typewriter champion also asserts that the LinuxOne architecture teamed with Telum trounces x86 for compute density and energy consumption.
And of course Linux is far less exotic that z/OS, making it a platform more independent software vendors will happily target. IBM reckons greenfield sites might fancy LinuxONE too, as it can run Kubernetes and is therefore suggested as a fine platform for cloud-native development.
The Register submits it would be a brave buyer that ignores decades of historical case studies about the perils of lock-in to proprietary platforms and makes LinuxONE the bedrock of a new IT stack. But stranger things have happened.
[...] Analyst firm IDC rates the non-x86 server market as likely to generate $13.1 billion of revenue during 2023, compared to $109.5 billion for kit running CPUs from Intel or AMD. LinuxONE is therefore not a big player and has competition from the aforementioned cloudy Arm machines and IBM's other platforms.
(Score: 4, Insightful) by jb on Thursday April 27, @04:33AM (1 child)
Well, many of us have always maintained that "cloud computing" is just a new take on the bureaux computing model that was prevalent in the 1970s. Adding mainframes back in to the mix makes the similarity even more obvious...
(Score: 2) by DannyB on Thursday April 27, @03:31PM
That reminds me of something. I was at some event in the late 1980s or early 1990s, and I personally heard Apple CEO of the time John Sculley say:
(paraphrased, not exact quote)
(audience laughed)
This was at a time when AppleTalk protocol could be carried over Ethernet, and a single Ethernet interface card added to your Mac was about $1000. Nevermind all the coax.
The thinking was that desktop computers ruled the world and mainframes were merely peripheral devices located elsewhere that could be called upon to do the user's bidding. It's funny how modern data centers are almost seen that way.
How often should I have my memory checked? I used to know but...
(Score: 1, Interesting) by Anonymous Coward on Thursday April 27, @08:57AM (4 children)
b) Spend millions migrating, rewriting and retesting your stuff every 18 months on newer platforms because the old stuff is no longer supported.
Note: talking about actual enterprise stuff where there's actually zillions of lines of code. Not talking about dinky little websites.
For most I guess option b) is still less bad than option a) but it still feels like having to choose and pay for a torture method.
For some it could be like having a working billion dollar silicon fab and having to pay millions of rent per year to stay at the same site vs spending millions to move the fab to a new site every 18 months (or different parts of the fab to different foundations at different times)...
(Score: 3, Insightful) by DannyB on Thursday April 27, @03:41PM (3 children)
Based on my observations over the last forty years of doing this, my opinion is that monopolist lock in is NEVER an acceptable option if ANY alternative is available.
That doesn't matter if you have to pay extortionate monopolist prices five years from now and they have you by the nads and it would cost too much to try to escape I-B-Monopolist's big-iron grip.
See Also: Anyone using Oracle databases
How often should I have my memory checked? I used to know but...
(Score: 0) by Anonymous Coward on Friday April 28, @11:15AM (2 children)
But if you're spending millions/year anyway, you could probably come up with your own Linux "Real LTS" distro and forks of suitable platform stuff and build on that. You might eventually have to resort to running that stuff in VMs (or even start out that way) but at least you don't have to spend as much time and resources needlessly changing stuff just because a bunch of hipsters took over a project. Then most/all of the changes to your Enterprise code would be due to your internal requirements (bug fixes, features).
So that'd be my option C.
For bonus points convince some similarly minded enterprise corps to join in and spread the costs. Let the OS and platforms stay about the same for decades/centuries (with just bug fixes), and build your stuff on top.
Seriously, it's not like your new business process/features changes (e.g. new state tax calculation logic) would require new OS features. You just need the OS bugs fixed. Your "Real LTS" distro maintainers would probably be focused on bug fixing and adding support for different hypervisors.
(Score: 2) by DannyB on Friday April 28, @03:53PM (1 child)
Been through that twice.
First time: UCSD p-System Pascal. We used it for so long that eventually we could no longer even figure out where to send the license fee to, and nobody every tried to contact us. The major factor that forced us off it was that it is 16 bit. Even with the latest edition of the p-System they had separated code space and data space so that it was possible for the p-Machine to know that code pointers were in this 64K memory space, and data pointers (stack, heap) were in this other 64K memory space. That was a huge leap forward. But it was still eventually a limiting factor for us.
I realized at the time that if I had the source code to the entire p-System, which was written in p-System Pascal, I would have changed this all to 32 bit pointers and made it all transparent to our large application source code.
Second time: Visual FoxPro. Eventually Microsoft lost interest in it. VFP 9 was the last. We knew well in advance based on industry trends that it would not last forever, so we were already well ahead in planning to rewrite for the web in Java. I realized that if I had the source code to VFP 9, (which was in Visual C++), that I would be able to fix things and keep it running for us, pretty much forever.
Third time this didn't happen. With Java, everything is open source. Java itself is open source. My development tools and IDE are open source. All the libraries we use are open source. Basically everything all the way down is open source. And while my company runs it on Windows (yuk, even in production), I could just as easily run it on Linux -- and have verified multiple times that this works. Even better, Java is being maintained and shows no signs of going away soon. It is still in the top few languages in use, and by very big organizations. So whatever you think of Java, as a practical matter, it works extremely well.
Another thing. Changing to Java and web based was a huge change in thinking about how the application works. We had thought for decades in terms of a desktop application that has to be deployed and updated. A web application has zero install and zero maintenance at the client end. All they need is a reasonably up to date browser.
How often should I have my memory checked? I used to know but...
(Score: 0) by Anonymous Coward on Saturday April 29, @12:36AM
(Score: 2) by SomeRandomGeek on Thursday April 27, @03:37PM
Unlike some others around here, I think developing for the cloud is a great idea, because all of the pitfalls that they see in the cloud I also see in non-cloud approaches. With that said, I will also say that it is especially easy to get vendor locked in the cloud. Instead of standing up an app server, you could just deploy an AWS Lambda or an Azure Function App. Instead of standing up a database server, you could just deploy AWS RDS or Azure CosmosDB, etc. For every kind of supporting infrastructure that you could deploy and manage yourself, your cloud provider offers a proprietary alternative that is ever so much more convenient. If you don't want to get vendor locked in the cloud, you need to make a conscious decision not to, and then be prepared to put twice as much effort into just about everything on an ongoing basis.
My own organization, after studying this carefully, decided just to allow ourselves to become vendor locked. If/when it becomes a problem, we will port to another platform. And the cost of porting will be less than the cost of making everything platform independent up front.