Working with customers from other countries can be difficult due to the language barrier. Speaking slowly and articulately can help when you have a translator, but if they don’t know anything about technology, it’s an even greater challenge. I regularly have such experiences, but I found a new language I’ve known all my life. It’s the language of math.
I recently met with a delegation from a large Chinese corporation that’s building a new office campus that will include a cloud data center for applications and data. I was told the CEO was a security expert and the CFO had some familiarity with PC servers. Neither knew anything about mainframes. We had an excellent translator, but he didn’t know about mainframes either. I did notice the CEO and CFO had a basic understanding of English technology terms. For example, PC, processor, and storage were good terms, while desktop, engine, and disk drives weren’t.
I had already presented some charts to this customer, but they hadn’t yet been translated. English phrases presented as bullet points made it even worse for the translator who was used to full sentences. In my next session with this customer, I chose to draw boxes and symbols on a white board to communicate. Using mathematical symbols and character drawings conveyed the messages necessary to augment the translation. The customer learned how the mainframe and hybrid computing differ from commodity computing. This article is an effort to share the “language of mainframe math” with you.
Other visual aids are helpful, too. We started with a tour of the IBM test floor, containing more than 100 servers and storage servers, across all the IBM brands. Seeing can aid in believing. The customer now could truly appreciate that the size of a modern mainframe was close to the size of a PC server rack.
It’s obvious that a single PC server costs less than a mainframe. This can be represented in a math formula as: PC $ < MF $$$$. Consider the other items represented in the formulas in Figure 1. This started a basic understanding of a single mainframe vs. a collection of PC servers.
We also discussed operational characteristics. I didn’t need to draw these. I asked if they knew what a Mercedes-Benz was, then a Fiat. They understood both. I said that the Fiat was probably three times less costly than the Mercedes. But you couldn’t pay three times more for the Fiat to get the equivalent of the Mercedes. No argument to either of these points. The conversation then went to tractor trailer trucks compared to cars. Again, no argument. Different roles and capabilities.
The campus this customer is building expects up to 500 businesses and more than 100,000 users with computing needs. We discussed hosting virtual desktops. We had to determine how many users could be hosted in a single blade environment. Using the IBM BladeCenter with HX5 blades as an example, we noted that two BladeCenters can go in a rack, 14 blades per BladeCenter, 16 cores per blade, and between eight and 16 virtual desktops per core. So we rounded that to 2 x 14 x 16 x 10 (an average user) ~ 4,500 virtual desktops per rack. But then there’s the management of those racks and users. Virtualization managers on PC servers can’t run at high utilization. So there are many other servers necessary to manage all the users. Instead, we replaced those management servers with a single mainframe running Linux and hosting the shared storage and backups, fraud services, security services for authentication, and workload management. While this was a useful argument, it didn’t close the deal. However, it brought the customer in tune with the concept of consolidation. So, next up, applications and database.
In my role in IBM Federal Sales, I’ve seen quite a few consolidation efforts on mainframes. One was for a large application that required a large database as well. The agency originally wanted to host this new workload on “commodity” blades (their term, not mine). The projection was 128 cores for the application and 48 cores for the database. IBM was able to convince this customer to use 18 cores for the application and 10 cores for the database as mainframe Linux workloads. More important, the agency had two 64-way mainframes, separated by more than 100 miles, that were each using only 27 engines. So the new work could be installed on the existing machines, in a fraction of the time, with no additional environmental impact (floor, energy, cooling) and built-in disaster recovery support. They would still have nine spare processors. This approach is reflected in Figure 2.
For disaster recovery, typically, the PC world must be completely replicated. That means the 128 cores for the application become 256 cores and the 48 cores for database become 96. The software license charges apply to all the cores. On the mainframe, capacity backup processors can be acquired for a fraction of the hardware costs. There are no software license charges for these backup processors; the license transfers when the work transfers. The math looks like Figure 3.
While we’re at it, we put virtual desktop management into the nine spare processors on the mainframe. The CFO was now animated; I was getting everyone’s attention.
That’s today’s math. What happens when a technology refresh is needed to get additional capacity? I can’t imagine how long upgrading 352 cores would take, but the agency we worked with expected it to take five months, with additional accreditation work required as well as plenty of temporary floor space to host the new racks of servers. With a z196 upgrade to a zEC12, it would be about two racks of floor space, temporarily and, perhaps, a four-hour outage to make the cutover. Sure, planning would be needed, but it’s a low-risk migration (see Figure 4).
Well, this put the conversation over the top. The customer was extremely excited. The fact this was all Linux-based technology meant that skills would also be readily available. All of this was summarized with the diagram shown in Figure 5.
There was clapping and hand-shaking after this presentation; it was a eureka moment. Now, our team needs to go make this a happy customer, not just a prospective customer. I’ll write more about this experience in future articles.
How’s the math in your IT operation?