Mainframe pricing

Put any two mainframe specialists in a room together and pretty soon the conversation will turn to cost. There’s the cost of the mainframe hardware, the cost of the software installed, and the cost of running the workload. Obviously, it’s only fair to pay for what you use. But, in these days of hybrid working, many people are now familiar with cloud pricing models, where you don’t have to buy any hardware and you only pay for what you use. If an application gets lots of traffic, you spin up some more containers to handle the extra load. And you don’t start paying until those containers have been turned on. That seems to be a huge difference in the mindset between the two ways of working.

Let’s have a look at the pricing structure that most mainframers are familiar with. It’s called the rolling four-hour average (R4HA). And the maths used to calculate it may seem a little arcane. It starts with the capacity of the LPAR that’s running the software. It also includes how powerful the processor running the software is. And the capacity (or powerfulness) is measured in service units – or because the processors are so powerful, millions of service units). That’s where the MSU value comes from. Every mainframe has an MSU figure associated with it.

So, as your mainframe runs each piece of software, that software is consuming MSUs. The consumption for the LPAR is calculated to produce a rolling 4-hour average. During the course of the day, there will be peak times when lots of software is running. And there will be quieter times when fewer jobs are being run. A lot of highly-experienced mainframers’ time is spent trying to keep peak capacity as low as possible and moving work to those quieter periods when the workload would, otherwise, be nowhere near the peak. And that’s because mainframe sites are paying for their peak usage. The good news is that most sites are not paying for the full capacity of their LPAR, just the amount that’s calculated from the peak R4HA. This is called the subcapacity pricing model and it is calculated monthly. It is even more complicated than that because many sites are using the option of soft capping.

Some mainframe sites have invested in specialty processors (zIIP, zAAP, etc), which take the workload off the main processing engines, and so out of the calculation. But this extra hardware has its own price tag.

Back in May 2019, IBM announced its Tailored Fit Pricing models, which came in two versions.

Firstly, there’s the Enterprise Capacity Model. This is designed for clients requiring operational simplicity and complete cost predictability, but who also expect substantial workload growth. Pricing is based on past usage and growth patterns, and is priced at a consistent monthly rate. Essentially, this model is discounted full capacity. This option is good for sites that have a firm control on their workload needs and those who need multiple interconnected mainframe environments to work as one large system. Customers are able to move software around and run them anywhere within the full capacity environment. This gives mainframe sites so much flexibility about where workloads are run – and all without incurring additional costs.

The second option is the Enterprise Consumption Model. This supports highly-flexible, container-based (cloud-like) consumption and billing. The client makes Monthly Licence Charge (MLC) and Million Service Usage (MSU) baseline commitments, but built-in annual entitlements and reconciliation processes reduce or eliminate seasonal variability issues. It also includes aggressive (~50% price/performance) pricing for MSUs as application usage grows. IBM claims that with this plan it will charge less for development and testing workloads to help customers grow their businesses.

This year, IBM has announced Tailored Fit Pricing for IBM Z – Hardware Consumption Solution, offering a “more standardized and transparent cloud-like hardware pricing model with combined base capacity and consumption-priced capacity”.

Tina Tarquinio, Director of IBM Z Platform Product Management wrote in a blog: “To meet the demands of modern workloads, IBM Z hardware can now include, on top of the customers’ base capacity, a subscription-based corridor of pay-for-use capacity”.

Provided customers are using a z15 and already have Tailored Fit Pricing for IBM Z software, they can use the Tailored Fit Pricing for IBM Z – Hardware Consumption Solution. The benefits they gain are:

• Ability to leverage the value of an always on, consumption priced capacity corridor, IBM Z’s additional headroom capacity corridor means not paying for what they don’t use in this corridor.
• Improved readiness to fulfil unpredicted business requirements at the instant they emerge.
• More flexibility to run planned and unplanned workloads when they need to.
• More time to get back to business by minimizing time spent on micromanaging infrastructure to reduce costs of operation.

This will help sites experiencing unpredictable spikes in mainframe usage.

IBM explained that “The usage charges have a granularity of one hour and are based on actual million-service-units – or the measurement of mainframe CPU usage per-hour – consumed as measured by the Sub Capacity reporting Tool (SCRT), not full engine capacity”.

BMC, Broadcom, and Precisely have already announced their support for the new Tailored Fit Pricing for IBM Z – Hardware Consumption Solution.

It all seems like a step in the right direction for IBM – especially because it wants to be a big player in the hybrid computing world. I wonder what other announcements we’ll hear along these lines in the near future?

Find out more about iTech-Ed here.