April 19, 2013 | Written by: Maciej Sztukiewicz
Share this post:
My dear readers, the subject of cloud brokers that I raised in my last blog post brought a lot of attention and views but no comments. Maybe the futurologist role I played was difficult to digest. It is also possible that you were all collectively stunned by the deep razor of my thoughts, making you unable to react to such revelation. If I may choose I would prefer the second scenario.
In this post, I’d like to explain why I hate the unit pricing concept, already popular in the IT industry and now broadly adopted by the cloud computing world.
We’re all aware of the unit pricing concept, in which price is given per a specified single abstraction called a “resource unit” such as user, gigabyte of storage or virtual machine. The concept has been around for a long time in IT, and cloud computing accommodated it quickly. However, because of the increased complexity of delivered services and multiplication of possible units, the concept is no longer intuitive and transparent.
I will explain here what elements of that concept are the subjects of my pure disgust.
1. Smart aphorisms
I hate popular aphorisms like “we need to compare apples to apples and oranges to oranges.” People sharing this wisdom in reference to unit pricing tend to do exactly the opposite. They jump directly to comparisons of unit prices that sound similar but are in fact very different—not even “apple to orange” but more like “white rhino to computer mouse.” The conclusions drawn from these caricatured comparisons vary widely, confusing clients’ perception and potential decisions. Cloud computing providers, delivering long lists of proprietary unit prices, fuel this fire of comparisons and ambiguities.
2. Lack of standards
“The nice thing about standards is that there are so many of them to choose from.”
This sentence, though true in many areas, doesn’t reflect the current unit pricing situation in the IT marketplace. Every provider calculates unit costs and resulting unit prices using its own methodology. There’s no clear external reference point or standard for precise construction of reference resource units. By construction I mean specification, a kind of bill of material for a specific resource unit that would characterize all hardware, software, service and labor components included in the unit together with clear rules for applied amortization, allocations, treatment of one-time costs and other aspects.
3. Ocean of assumptions
Even if assumptions are documented and clearly expressed, their impact on calculated unit cost and final unit prices can be stunning. Take for example an IT provider that is asked to provide unit prices for two scenarios—one including hosting of cloud infrastructure in a provider-owned data center, the other assuming location of infrastructure in a customer-owned data center. The second scenario is a beautiful playground for speculation and long-shot guesses.
Is this customer data center ready and fully operational? Should the IT provider deliver surrounding infrastructure like racks, console switches, terminals and power supplies? Are shared storage and shared networks available? If yes, at what cost? If there’s no shared infrastructure, what assumptions should be made about needed components? Small changes in assumptions can result in very different unit prices. Finally, don’t be surprised when these calculated unit prices are compared as “apple to apple” to similar-sounding units from other providers that were developed with a very different set of assumptions.
4. Allocation nightmares
Let’s assume that a customer asks providers to deliver offers for cloud services with unit prices specified within “technical” domains such as virtual servers, storage and network. These parts constitute a majority of costs but not all costs on the provider’s side. What about costs of service management, focal points, delivery management, contract office, account financials and others? How should providers allocate these costs to particular “technical” units?
What about implementation costs that involve the work of project management offices and subcontractors? They appear in the beginning of the project, can be amortized and allocated to the final price units, but how exactly, and using what distribution key? An amortization period usually doesn’t match a required timeframe for delivered services, so should unit prices change in time? Changes in allocation assumptions and percentages will lead to very different results, making possible that one group of technical price units looks cheap and others sky high.
5. Naming pitfalls
Resource units and related unit prices have a certain base—the unit—that needs to be clearly specified. From the first glance it seems rather straightforward, but is it really so simple? If an IT provider offers a platform to be billed “per user per month,” what does it mean? What kind of user is it—concurrent user, named user? This can have an impact on the needed license type and resulting cost. Does the user fee include hardware capacity? If yes, what kind of capacity, and in which domain—virtual CPU, memory, storage? Maybe the name of the unit should be “concurrent user with hardware capacity” with hardware capacity specified further?
Another example is the modern desktop cloud concept—“desktops” that are run on data center servers with “look and feel” transmitted to users over the network. The potential “desktop price unit” can be misleading. In reality it can be a published desktop where the pool of desktops is based on the same shared operating system, or the more-demanding virtual desktop, which is run on a dedicated virtual machine for every user. The latter can also be equipped with a persistent image, meaning that a user can introduce modifications to the desktop that will be remembered after the end of the session. These published desktop and virtual desktop expressions are coming from the Citrix world; other providers such as Microsoft will use other names for similar concepts such as “remote desktop session,” “pooled virtual machine collection” or “personal virtual machine collection.” A potential customer needs to be careful to avoid a situation in which his requests for unit prices imply usage of certain technologies and providers.
What’s the solution?
Yes, expressing personal dislike can be relaxing for a moment, but for the longer term we need a solution. Can we see light in the tunnel of ambiguities regarding unit pricing? One solution is eventually having standards—detailed specification of commonly used cloud resource units, their cost components, amortization periods, proposed allocations and naming. The solution for now is normalization activity on the customer side, which unfortunately requires work and knowledge. If a customer receives offers from various IT providers, he needs to translate them into the same base for meaningful comparison. Examples of normalization activities are spreading additional account management fees into technical units, adding separate transformation efforts/costs to the equation, adding data center/hosting costs to pure service units and so on. Perhaps it is enough to write a clear request for proposal to avoid these problems. Yes, right. But if you find such a clear and self-explanatory paper you are luckier than the Lucky Luck cartoon hero. Even if such a magnificent artifact is released one day, the responses from providers will still vary because interpretation and speculation are interesting characteristics of human nature. Narrowing these interpretation margins is an important step in the adoption of the cloud computing concept.
Now it’s your turn to share your thoughts under these points!