Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
In this podcast, Gregg reflects on his presentation ‘Keeping it Legal, Techniques for Maximizing TCO with the zIIP’ at the CMG Technical Conference in Dallas. Gregg shares that the CMG audience supported IBM’s position and approved zIIP offload. Gregg continues that the participating audience hoped for additional transparency regarding who is offloading to the zIIP in a certified manner, and called for openness concerning the generosity factor of each customer’s products.
I was very fortunate to be able to present at CMG twice, and the second presentation, of course, as you mentioned, Mike, was titled, ‘Keeping it Legal.’ The presentation is available to anybody who wants to take a look at it. Basically what the intent was, was to discuss the current issues with regard to zIIP offload, what was approved, what’s not approved, and to make it a very interactive discussion. Everybody in the room contributed, we learned some interesting facts from some of the attendees, things were going from a contractual or licensing perspective, as far as the zIIP goes.
In general, I came away with a couple of thoughts from that, that folks were very pro-IBM in terms of their support of IBM and what we would call approved or intended zIIP offload situation. Folks understood what IBM was trying to do, in terms of when they built and offered the specialty engines. They were intended for new workloads, and there are just very sound financial and business reasons why they were intended for new workloads. It’s nutty to think that anybody could be in business and all of a sudden sell everything that they’re doing for free, I mean, it’s just bizarre to even think that that’s a possibility.
You know, IBM spends billions and billions of dollars building world class, world class operating systems and subsystems. They support the user community as well. They support the IFC group beyond anything I’ve ever seen. And all that costs money, to deliver a world-class operating system like System z that most of the critical data in the world exists in or on -- it costs a lot of money to do this. So, the thought that IBM could all of a sudden say, ‘Hey, everything’s for free,’ I mean, come on. That’s like only a concept that Bernie Madoff could love. And what I mean by that is, ‘Hey, you know, I didn’t build the application, I didn’t build the operating system, I didn’t hire the people, the buildings, I have none of the infrastructure, but somehow, what I think I’ll do, is I’ll just find a way to use all that and offer it to somebody for free, and I’ll take all the money.’ I think that most System z customers understand that IBM and ISVs needed a way to offer TCO, but in a controlled fashion. And the best way to do that was with new workloads. And what I mean by controlled is, we’re all in business, right? We’re all in business, and we’re not going to be in business if all of a sudden, the software that we’re offering isn’t chargeable. It’s a ridiculous paradigm and in the end, the customer takes the hit. There’s no free lunch. You know, there just isn’t.
So, we spoke a lot about that, and I’m not speaking about any specific product out there, I’m only speaking about the concept of what the specialty engines were intended for, why they were intended for that, and how they were controlled in terms of their use, and how doing something where those controls are completely eliminated, in the end is not beneficial to anyone other than possibly one particular entity who may be doing this kind of work, that is offloading other company’s code.
I feel very strongly that what IBM did with regard to TCO and the zIIP was very beneficial, and the zAAP, and the IFL is extremely beneficial to customers, and also it allows ISVs to offer a product with a strong TCO advantage. It allows us, in particular, Progress DataDirect, to compete with other integration products that aren’t as computationally intensive. We just are, it’s not because we don’t know how to write code, believe me we do, it’s just that we are in the middle of millions and billions of transactions a day, and you’re going to consume CPU’s, especially if your workload is computationally intensive, and there’s no way to get around the fact that going web services or SQL to non-relational transforms, it’s computationally intensive. And so, what the zIIP allowed us to do was to offer the customer an alternative, to be able to run those computationally intensive workloads on the zIIP, in a coherent memory, on the best operating system in the world, with the greatest controls and management tools there, co-located, it clearly brings a significant benefit to the customer.
Now, what are we going to do if all that stuff, all that software, is all of a sudden brought into question, because there’s another solution out there which says we’ll offload everything. Not just our own code, but we’ll offload everything. So, we discussed that in the presentation, you know, we got some customer input as to what they thought. The appropriate thing to do was, with regard to zIIP offloading. The majority supported IBM’s position, which was quite pleasing for me to see.
As you can tell, it’s kind of a subject that I feel quite strongly about. I feel that the zIIP clearly gave us the opportunity to give something of significant benefit to the customer base. Yet now, in this past year, there’s been a significant amount of confusion, the signal to noise ratio in the market is not good, there’s a lot of noise, the signal’s being lost. And by the signal I mean, appropriate approved zIIP offload. Things are slowing down because people are just unsure what to do, so people are not getting the benefit that they should be getting from the zIIP.
And we discussed that, and basically, in the end, I think a couple messages came out of that discussion. One of them was customers wish that, perhaps, maybe IBM could be a bit more, straightforward on which company’s zIIP offload is approved or not approved using some sort of certification letter. I heard that from several customers, they really would like to know that. And then the other one was they would like to know and have published somewhere the generosity factor of each customer’s products. For example, our generosity factor is 100%. Basically, in our product, what is zIIP qualified, is zIIP eligible, and the generosity factor basically can be thought of as zIIP qualified divided by zIIP eligible times 100. And which basically means that of the work that you execute in enclave SRB mode, zIIP qualified, how much of that do you make eligible for offload? And customers want transparency in that, and I think that’s a great idea, and I’ve been thinking about working to get something on our website which allows other companies to put up their various generosity factor numbers, however, as you might imagine, that’s somewhat difficult to do, because some companies might consider it to be sensitive. Although, it’s quite simple for any customer to determine the generosity factor of each product once they’ve installed it, so why not make it accessible prior to them installing it?
Anyway, that’s it for the CMG presentation. To conclude, I felt that the customer base was very behind IBM, very behind approved zIIP offload, and very much for transparency and openness with regard to who is offloading to the zIIP in a certified manner as well as what their generosity factor is.
View all posts from Gregg Willhoit on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.