Crazy Idea Number 615: Variable Priced Power Systems Partitions

April 5, 2021 Timothy Prickett Morgan

When you stare down the blank page as much as I have in my career, you learn to not be afraid of that blank page. If you look at it long enough – usually for only a few minutes – ideas flip into existence like quantum particles spinning their curlicues. Most of them are silly, some are utterly useless, but eventually you get one that is worth following to see where it might go.

So it is with an idea that popped into my head, which was a daydream about IBM creating variable priced partitions on the Power Systems machines. This would stand in stark contrast to how Big Blue prices and sells Power Systems today, but certainly could be an overlay on top of existing metered pricing metrics or lease prices or outright acquisition prices.

Today, when you buy a Power Systems server, you pay for it based on what it is: It is a Model 9009-22A with a feature #EP16 processor module, which has a “Cumulus” Power9 processor with four-cores running at a base speed of 2.8 GHz, plus two feature #EP46 processor core activations, plus eight feature #EM63 32 GB memory sticks, plus a feature #EC59 storage backplane for NVM-Express flash, plus four feature #EC5C 3.2 TB flash adapters, plus one feature #EC37 two-port 10 Gb/sec Ethernet adapter, and so on. You have the IBM configurator build the whole system, add the operating system on a per core basis, add its features, kick out a list price, and then the customer argues for a discount and usually gets something but not much because, frankly, if they need IBM i, it is not like there are a lot of choices.

If they don’t like the deal, they can backstep to a certified pre-owned machine with Power8 or Power7+ processors, which would be cheaper but which has a much shorter technical life because these machines will not future releases at some point. Or they can defer the whole thing and pray their current machine doesn’t break or run out of capacity.

In this typical real scenario, the price of the core hardware and systems software is static and based on capacity. But what if it was based on capacity with a function modifier instead? This would not be the first time this has happened of course. IBM has artificially lowered the price of Power Systems hardware running AIX and then Linux for many years compared to OS/400 and IBM i variants of the same hardware, and back in the day, IBM even priced hardware based on whether it was running traditional 5250 green-screen workloads or more modern “client/server” workloads using other interfaces into the system and database.

I objected, rather strongly many times, to such staggered pricing, mostly because IBM acted like it wasn’t really doing that when you could see that it was it you looked at the feeds and the speeds. Running 5250 workloads cost significantly more than running these so-called client/server workloads. IBM artificially raised the cost of using the very efficient and very compute non-intensive 5250 protocol and artificially lowered the price of using SQL, JDBC, and other interfaces if customers could be coaxed to move to them. And if they did so almost exclusively, the cost per overall unit of compute, as expressed in the Commercial Performance Workload (CPW) transaction processing benchmark test that Big Blue still uses to gauge performance on IBM i, was 3X to 5X cheaper. And perhaps more importantly, if you did the math, backing out the numbers, the cost of the system was almost entirely activated software function and not the underlying hardware and its inherent capabilities. Remember how IBM actually put governors on specific processors and models, with different features giving different 5250 and client/server performance depending on the features?

At the time, this interactive software tax, as I called it, violated my senses of both equality and equity across the Power server base. Why should have IBM i customers paid more for hardware when they are already paying a premium for software? Wasn’t enough enough? But at the same time, I could understand that IBM wanted to encourage companies to modernize and get off the old protocols and onto the new ones. I think what I really objected to was that the cost for traditional OS/400 5250 workloads didn’t get cheaper, but gradually got more expensive, while the cost of the client/server capacity as we rolled through the “Cobra4” and “Apache” PowerPC processors in 1997, up through the “Northstar” processors in 1998 and 1999, and up through the S-Star and I-Star chips before we got to Power4 in 2001, when IBM just decided to charge per core for OS/400 and then an additional fee for 5250 access and simplify its product line.

There is such a thing as being too clever for your own good.

So, it is with a certain amount of irony that I am contemplating something similar as I try to figure out how to make the Power Systems business larger and more resilient than it already is. First things first: I do not want to increase the cost of the IBM i stack on any Power Systems partition. But I do want to switch from core-based pricing to CPW based pricing, and move to a monthly subscription model to make the capital costs of a complete system come way down. Take the price per core and divide it by an average CPW rating for the CPW SKUs and be done with it. Come up with some metering of performance and price metric that makes sense that so on average customers who do the same now pay the same. What the heck, let them pay a little less because they deserve a break. Then, scale that per CPW pricing across the logical partitions of the machine. If a customer only needs 1,000 CPWs and a core is rated at 4,500 CPWs, then they will pay only for what they are using.

Relax, the trick is we want them to eventually use more capacity at a lower price, bringing new workloads onto IBM i because it is cheaper to do so now. But we need to keep this simple so people can understand it, and also we need to make it fair so people don’t try to game it. The cost per CPW will be lower on an entry one-socket Power10 machine in this future pricing scheme than on a big NUMA box – and justifiably so given the extra cost of the big NUMA hardware.

Now, the next thing I want to do is start pulling Windows Server and Linux workloads off X86 machines and onto logical partitions running on Power Systems. And here, we absolutely want to charge less per CPW for the underlying partitions. Figure out what a relative CPW rating is for a modern X86 server chip from Intel and AMD, and figure out what those systems cost and what the cost per CPW would be – the kind of thing I do when there are new CPUs in the field and which I will be doing with the “Milan” Epyc 7003 processors just launched by AMD on March 15 and the “Ice Lake” Xeon SP processors from Intel due on April 6. Whatever that cost, the price per CPW for Linux partitions supporting a slice of the hardware and a full Red Hat environment is now going to be 20 percent lower than that number for both Linux and Windows Server.

But that’s not all. We also want to price Power and X86 capacity based on what you do. So, we now want to break out application serving as distinct from database processing at the very least within the IBM i environment, and perhaps more. Application serving has to be a lot cheaper than database serving, and you will recall that the Application Server variant of OS/400 was considerably less expensive than the full-on OS/400 with the database activated. Forgive me, I cannot find the difference in price, but it was substantial. Let’s strip out the database and call the Application Server variant one-fifth the cost of the Database Server variant. Put the database in one partition and put as many application servers against it in their own partitions as you see fit. These application serving partitions don’t run the database, so they should not have to pay the full IBM i licensing cost. In addition to more fair pricing for the IBM i stack, this gets customers used to the idea of tuning hardware differently for database and application servers.

Now, the whole point of this variable-priced partitioning exercise is not only to get cloud-style utility pricing that makes immediate and obvious sense to customers used to buying on-premises gear – and that is consistent across on-premises and all public cloud and hosting sites – but also to encourage customers to move from X86 to Power among a class of people who already know the advantages of the Power architecture and therefore represent the low hanging fruit. We have some time before Power10 is here in big NUMA machines later this year, and a little more time before entry Power10 machines are here in early 2022.

We want IBM to identify the Windows Server and Linux workloads in use at IBM i shops and find a Power-based alternative for the top 20 most important ones, and then build an ecosystem of partners and a consulting practice that spans IBM Global Services, those ecosystem partners, and resellers that are downstream from IBM and actually do this.

How much computing capacity is out there in the Windows Server base? How much could be absorbed by a two-socket Power9 server with 24 fat SMT8 cores or 30 fat SMT8 Power10 cores? We think a lot of shops might have 3X to 10X more raw computing power on Windows Server machines. Even if IBM charged a lot less for CPWs in the Linux partitions, it could double or triple the spending of CPWs in IBM i shops just by porting some of those workloads from Windows Server on X86 to Linux on Power.

Unix applications would be a bit easier to move because IBM has the QuickTransit hardware emulating software – remember that? – and could run this abstraction layer to move vintage Unix applications to Linux partitions. A QuickTransit variant called “Rosetta” is how Apple moved off Power iron to X86, and it would be very funny to turn the tables and move X86 workloads to Power in the same fashion. And, interestingly, Apple is using “Rosetta 2” to move from X86 to Arm now. In both cases, there is a performance hit to such emulation. But that sure beats rewriting code in a lot of cases.