In a comment thread, from the article Multiple Hybrid Clouds Kludged Together? — Cloud Architecture, an insight was raised.
“… companies are not managing their software proactively to ensure they are staying in budget.” — Cary King.
This raised a few hairs on the back of my head, as I, Edward Haletky (Texiwill), recently went shopping for cloud services and some of the prices were outrageous to say the least for just a basic VM, if I suddenly needed more VMs the numbers would add up quickly to something outside of the budget. On top of that, there is the utilization charge back for cloud services. This particular Cloud Provider could not tell me what the rules for such charge backs. In a private or hybrid cloud, licensing costs for software and operating systems could eat through any budget in next to no time. Add in utilization charge back and budgets may be crushed under the weight of all these new charges.So we have two issues related to budget’s with respect to the cloud: Licensing and Charge back. With ITaaS these charges are then put onto the user of the service whether that be a business unit, organization, or some other entity. These charges could allow IT to actually become a profit center for the first time.
Licensing
Managing software licensing is already a massively challenging task when there are dedicated systems with relatively fixed capacity. Many enterprises struggle with making sure that they are not over-buying licenses or paying maintenance on licenses that no on uses. Most enterprises (whether they know it or not) own vast amounts of “shelfware” – software which was purchased to meet a need, but which either never got implemented, or for which the use has fallen by the wayside over the years, but for which money is still be paid every year.
Software vendors have contributed to the problem with complex and sometime opaque licensing models. Oracle is probably the most egregious party here with license agreements that require both a lawyer and an accountant to figure out. However, even before we get to virtualization and hybrid clouds, we also just have to deal with the fact that software vendors pursue so many different models by which they license their software. This is because different vendors have different objectives at different points in time.
For example, to call Oracle to task one more time, it is clearly Oracle’s objective to squeeze every last penny in license revenue out of every customer possible. Oracle does this by making the price a function of a variety of factors which in combination cause the customer to pay the most money possible for the software. Other vendors have different objectives. At the other end of the universe from Oracle is SolarWinds who publishes their prices and license scheme on their web site and tries to keep the price of the transaction low enough so an Admin can buy the product with a credit care and then expense the purchase.
In between these two extremes lie a vast variety of models. VMware itself has two main models. vSphere is licenses by CPU with qualifiers for the number of cores per CPU (more than 6 cores per CPU costs more) and memory limit by server (more than 256GB of memory per server costs more). VMware’s management offerings are licensed on a per VM basis. Most of the vendors in the ecosystem either license by server, by CPU socket, by core, or by VM.
So if we narrow down the question of how to know what software an enterprise is supposed to be paying for to just software running in a virtualized environment (lets narrow it down even further to just an environment that consists of a vSphere based private cloud combined with a vSphere based public cloud into a hybrid cloud), then we can easily have between 6 and 10 different licensing models to deal with.
To make this problem worse, most products do not have an API that one can query to ask how the product is licensed, how many units have been licensed and how many are either installed or in use. In fact many products do not even enforce their own licenses, leaving it up to a “trueup” process for enterprises to figure out what they really owe.
It is this lack of a standard way to report license terms, and license usage that risks turning hybrid clouds into a financial swamp for enterprises. Because if the idea behind a hybrid cloud is to be able to scale up capacity as needed so that the enterprise does not have to maintain the capacity for peak loads in its internal data center, then a mechanism is needed to track the elastic scaling out of licenses as it occurs, and to report this back so that everyone understands the financial consequences.
The idea of dealing with peak load via a hybrid cloud will also introduce a new challenge for software vendors. Most software vendors do not charge their customers as much (some charge nothing) for redundant copies of the software that sit in a dark data center that exists only for site DR purposes. Now what if you in retail, and you only turn on those extra servers in October through January for the holiday shopping season. Are you going to pay you software vendor the full price for licenses that are only used for one-third of the year?
Charge Back
The question of how to mange your licensing costs across an elastic hybrid cloud is then also related to how the public cloud vendor who is a part of your elastic private cloud will charge you. This is also destined to be complex. Cloud pricing is only simple in the case of SaaS, where the entire cost of the hardware, system software, applications runtime and applications software is bundled into however the SaaS vendor happens to charge you.
But hybrid clouds are going to be built around IaaS and PaaS cloud models in most cases, not SaaS cloud models. So now you have to figure out how to pay for the applications software licenses that you are going to run when you run them on the public part of your hybrid cloud. The applications framework could be part of what you license directly from the vendor, or it could be part of the PaaS offering from the cloud vendor. On top of this, you may also be billed for utilization whether that be based on CPU, Memory, Network, Storage, or some combination of these resources. Think of utilization charges within the cloud just like utilization charges for a cell phone. You may also end up with a very large bill because your cloud environment burst to a higher utilization threshold.
Let’s assume the simple case which is your enterprise application running on an IaaS cloud which in turn is based on vSphere (as is your internal private cloud). VMware licenses vSphere (more specifically vCloud which is the version of vSphere) to cloud providers on a memory execution cycle basis with the charge per memory execution cycle going up depending upon how much of the VMware software stack the cloud provider is using. In addition, with the latest technology, it is possible to charge back based on any utilization metric you desire or a combination of those metrics on top of your licensing costs.
Now you probably have no way to map any statistic that you currently track for the usage of your enterprise application to memory execution cycles. You probably do not know how the number of concurrent users, transactions per second, or back end I/O operations maps to memory execution cycles for a VM running on vSphere – so you probably have no way to predict what the charge from the cloud vendor is going to be until you try it. Even once you try it, it will probably be a real challenge to create a model that lets you know how much you would be charged if you ran X level of activity over on the public instead of the private part of your hybrid cloud. However, the cloud providers while perhaps not able to track your application can track the utilization of their environments, as such they can and some do charge back for utilization after they exceed a set minimum. So if your application increases CPU utilization above the threshold you could begin to get charged for more resources.
Summary
Managing licensing costs is a mess today in the physical world. Introducing elastic scaling of workloads into a hybrid private/public cloud introduces new uncertainties, new software licensing metering, and utilization metering and charge back issues. This is particularly true in the case of enterprise applications which are licensed by the enterprise from the software vendor and then deployed on an as needed basis on Iaas or PaaS clouds that can burst to higher levels of utilization and number of licenses concurrently in use.