Skip to content
Daisie Register June 17 2013 5 min read

Cloud Consumption Modeling: Part 2

In our previous installment on Cloud Consumption Modeling, from Todd Cowles, Virtualization Engineer at Iron Bow, he outlined Cloud services and looked at the traditional justification for moving services to the Cloud. This time he takes a deep dive into Cloud Consumption Modeling and why it’s so important in purchasing decisions.

Now that you’ve inventoried and organized things, what’s next?

Your next task is to make decisions based upon the new organizational structure. Now you can determine which are most important, build out resource pools and drop those virtual machines into their new homes. Once you’ve got your Cloud environment up and running the conversations between administrators and managers are no longer vague, but based in concrete facts about utilization and the opportunity to reallocate resources depending on where need is greatest.

You can establish consumption models based upon known metrics. You don’t have to purchase additional technology or services; the most you might have to do is call in vendors to have them help you realign properly.

Once organization occurs and metric overlays are attached, you now have finite measures for purchasing decisions. How much money would an organization save if it was basing upgrades on a full knowledge set regarding the usage of CPU, memory and storage capability? Because you are developing metrics based upon organizational usage, you now see that CPU and memory utilization is at 40 percent, with peaks to 45 percent. Seems to me that you have approximately 35-40 percent more CPU and memory capability. When your standard purchasing cycle comes around, you take a look at your metrics and realize, that while you’d normally buy new blades, you don’t actually need to. Therefore, all those meetings you would have had about ROI/TCO will not have to happen and no money will be wasted in unnecessary purchasing.

This makes for a fun conversation; the one where you get to point out to your vendor that you don’t need to buy more hardware from them, that you’re testing out the competitor’s less expensive product that has a better warranty. Before you know it, you’re walking away with a sweet deal where you’ve extended your warranty for an additional year at the same rate as last year…which gives you plenty of time to test/dev the competitor’s platform.

Based on theories of supply and demand, prices for hardware will begin to drop; just look at Enterprise Flash Drive prices and how drastically they’ve dropped over the last two years. The goal of using consumption based models, such as the Cloud, is that it begins to commoditize hardware. Hardware is important, but its importance will never be where it was five years ago. A Cloud Consumption Model also begins to change the vendor/organization relationship. It doesn’t matter which vendor’s blades you have – the organizational focus is based on consumption and utilization metrics. Do the new Cisco blades perform the same as the HP blades? While there are some technological differences, your application sets are going to perform the same on whichever blades you choose. Therefore, price becomes the primary factor in your purchasing decision, closely followed by warranty and support.

This is what the Cloud is going to do. It is going to allow for the dynamics of organizational relationships to shift focus from hardware spending cycles, to gaining the utmost utilization out of that hardware, for as long as possible. This is where agencies begin to save money; this is where the realization that it’s not about hardware or software but rather an organizations ability to leverage existing resources for future mission capabilities and not having to acquire a big spend to do so.

And that’s what’s so funny about all of this Cloud discussion. As many of us snickered while “salesey” folks discussed their companies respective cloud advantages, we always knew that the real answers lay with assisting the customer in untying years of bad purchases; which the exact same salesperson sold them three years prior. Maybe they had a different hair color, name and suit, but either way, it was the same person. I’m beginning to see the talking points regarding “Cloud” fall prey to “we need Hadoop clusters” and “tell me about Big Data!” I have no problem with putting the flag in the ground and stating that the use cases haven’t been presented properly to the federal agency environments.

Travel with me for a moment and imagine this world, one where a natural disaster occurs. First responders deploy and establish a command post, for which they need internet connectivity, internal portal/external portal presence and fully functional desktops, with printing. What do you do to get the first responders what they need?

I know a viable Cloud Consumption Model would support the above scenario quite well. If you had all your metrics inline, one could very easily determine whether they could stand up an interim data center and provide the required services. Better yet, what if you were able to migrate your workloads to another data center, freeing up local resources for support? Once the mission was complete, your workloads were migrated back, all being done with compliance and security intact. Now we’re talking about migrating entire data center workloads around? Yes, from one compliant data center to the next. Why? What if a different region was being charged significantly less per Kilowatt? It would probably hold true that there’s less demand in the region. Migrate your workloads, save X amount of dollars and migrate back when the savings are no longer applicable, or are null.

Cloud Consumption Models are relevant because their use brings competitive pressures to bear on the existing models of consumption and purchasing. It challenges the current, very physical approach, of licensing. It supports a prolonged sustainment use-case of net-new hardware acquisition. Overall, it does begin to reduce capital expenditures, allowing agencies the opportunity to gain a renewed focus on software enabling and development technologies. Guaranteed.