Container Pricing for IBM Z Brings Predictability to Cost
Container Pricing for IBM Z allows IBM to deliver pricing that’s not affected by the cost of unrelated software or whether the solution runs during a peak time.
By Andrew M. Sica07/01/2018
Container Pricing for IBM Z* allows IBM to deliver a revolution in the pricing of qualified solutions on z/OS*: pricing that’s not affected by the cost of unrelated software or whether the solution runs during a peak time. IBM has designed a set of solutions around the framework, each of which targets a key requirement of z/OS clients.
What’s Container Pricing for IBM Z?
Container Pricing for IBM Z is a framework that allows z/OS and the Sub-Capacity Reporting Tool (SCRT) to understand the characteristics of specific workloads, such as which resources the workloads are consuming and the program products that they’re using. Critically, this capability is available without the monthly “tagging and tracking” that’s associated with past offerings.
IBM provides a set of solutions that take advantage of the framework. A key characteristic of each of the Container Pricing solutions is that the application or workload doesn’t directly impact the traditional rolling four-hour average (R4HA) because the metered container workload is always subtracted out and reported separately by SCRT. This allows IBM to deliver pricing that’s predictable and relevant to the solution without impacting the cost of unrelated software in a way that’s not affected by whether the solution runs during a peak time.
One thing to note: Despite its name, Container Pricing for IBM Z has little to do with Docker or any sort of technical containerization.
In this article, we’ll explain the value of two solutions that take advantage of the Container Pricing for IBM Z framework—the Application Development and Test (DevTest) solution and the New Application solution. We’ll describe the problems they solve, as well as how they exploit new technology in z/OS and SCRT.
The DevTest Solution
The R4HA model has brought value to z/OS clients; however, it has some obvious problems. One of those problems is that it causes people to excessively focus on that peak R4HA value and, under business pressure, try to find ways to reduce it, sometimes to the detriment of other interests.
Different techniques are employed to reduce the R4HA, such as LPAR soft-capping or restricting access to test systems. Whatever the approach, it typically brings a lot of non-productive time spent managing the environment to control costs, and it frequently constrains resources. Development and test often suffers, because z/OS environments are restricted during peak times to ensure that they don’t drive up the monthly license charge (MLC) bill.
The DevTest solution is intended to take a more holistic view of the environment; a healthy and growing production environment requires a healthy development and test environment.
With the DevTest solution, the impact of a development and test environment on MLC charges is evaluated over a three-month period, with all of the capping and other cost-control mechanisms in effect. This three-month average sets the MLC cost of the DevTest container.
Over that same three-month period, IBM evaluates the independent peak size of the development and test environment (i.e., how large it grows when you’re less concerned about impacting product peaks). This sets the MSU baseline size of the container. The size can grow up to 3x this baseline with no additional MLC cost for development and test workloads.
Note that you might need additional International Product License Agreement (IPLA) entitlements, depending on the size of the container you choose. You may also decide to turn on additional capacity to take full advantage of the container.
The DevTest container, which includes your existing development and test environment, is reported separately by SCRT and isolated from production work. We’ll discuss this in more detail a bit later.
Remember, the goal here is simple: Remove the need for aggressive cost controls around development and test, and thereby enable more of those activities.
Implementing the DevTest Solution
After agreeing to a DevTest solution, you’re provided with a solution ID. This is essentially a token representing the Container Pricing offering you’ve been granted; it’s used to define the elements of the container, such as LPARs and workload manager (WLM) tenant resource groups. A tenant resource group is a new WLM construct that’s required only if you don’t keep development and test isolated from your production LPARs. Most clients do keep production and development and test isolated.
The DevTest solution can be implemented with a few simple SCRT commands. A great way to find out about these commands and the rest of the technical implementation is by using the content solution. For more details, see “A Content Solution for Container Pricing for IBM Z” below.
When you run SCRT, the DevTest solution LPARs no longer contribute to the traditional R4HA product peaks. Instead, they’re isolated to a separate section of the SCRT report.
No other implementation steps are required to get things going, but in addition to this SCRT setup, you should review the goals of soft-capping and other software cost controls used on your development and test LPARs.
The New Application Solution
Another problem the R4HA model creates is determining the cost of a new application.
Suppose for a moment you want to add a new application to an existing z/OS LPAR. Even if you understand the cost of a new product that you need, a major variable is whether the application will impact a peak hour. This uncertainty can be especially painful if the application has characteristics that make it unpredictable in any way. All of this can make it difficult to understand the true cost of the new application.
By exploiting Container Pricing for IBM Z, the New Application solution provides an obvious benefit. Remember, all container pricing workloads are removed from impacting the traditional R4HA, so they don’t affect the cost of other software running on the LPAR. The solution is priced based on the IBM software stack and the capacity needed for the new application (in MSU). With solution-specific pricing isolated from the R4HA, the price of a new application becomes significantly easier to predict.
Implementing the New Application Solution
As with any Container Pricing solution, you’ll receive a solution ID after agreeing to a New Application solution.
The New Application solution can be deployed to a new LPAR, or can be colocated on an existing LPAR. You determine this, based on where it will fit best technically.
Let’s assume you choose to deploy your new application to an existing LPAR. In this case, you use the WLM tenant resource groups and tenant report classes introduced in z/OS V2R2 to define your new application. This includes classifying the application work units (address spaces). These WLM constructs provide for the metering and (optionally) capping of a workload.
When you specify a solution ID for a tenant resource group in WLM, the tenant resource group is associated with the container pricing solution that the ID represents. The tenant resource group metrics, along with the solution ID, are reported in the System Management Facilities (SMF) type 70 subtype 1 records that are already required for sub-capacity pricing. You simply provide SCRT with the same set of SMF records as you do today, and it recognizes the presence of the colocated Container Pricing solution.
SCRT automatically removes the new application’s contribution to the LPAR R4HA, and that contribution is isolated to a separate section of the SCRT report.
The content solution for Container Pricing provides all of the assistance that you need to set up these new WLM constructs. Once you’re past that initial setup, z/OS and SCRT manage the impact of your container-based workload with no monthly spreadsheets or tagging and tracking.
Testing Container Pricing Support
If you want to try Container Pricing support—whether to size an application you’re testing or just to check it out—IBM provides a set of sample solution IDs on the software pricing website.
These can be used to define the container constructs to z/OS and SCRT as needed. Note that you’ll have to use the SCRT “IGNORE” command to submit your monthly report to IBM.
Details can be found at ibm.co/2jtn6zl.
A New Era of Pricing
Container Pricing for IBM Z ushers in a new era of pricing for software running on z13* and z14*. By disconnecting the pricing of qualified solutions from the costs of other software and from the R4HA, Container Pricing for IBM Z offers pricing that’s relevant to the solutions and predictable. The DevTest and New Application solutions supplied by IBM leverage Container Pricing to promote healthy development and test environments, and to simplify adding new applications on z/OS.
Andrew M. Sica is a senior software engineer, focused on Container Pricing and the sub-capacity reporting infrastructure.
Sponsored ContentAchieve Compliance Without Impacting Productivity
Post a Comment
Note: Comments are moderated and will not appear until approvedcomments powered by Disqus