Billing
The problem is billing. How do you break down compute/storage/network/tech time/etc into atomic items to be costed? 500TB of storage cost X when sourced 6 months ago, yet adding that capacity tomorrow will be (X * 0.9).
Even the top tier stuff - VMware, System Center and so forth - are just shite at being able to handle the accounting stuff. They don't allow for the entry of the truly flexible costing mechanisms required to compute the cost of different tiers of resources purchased at different times, or even operated at different times.
Tech time, network resources and compute are all time-sensitive resources. Tech time is more costly off peak, but compute and network are less so. Storage is a function of amount, speed, vendor used, quality/redundancy of primary storage, quality/style/frequency of backups and "distance" from the compute occurring.
How do we factor in more intangible issues? Like the complexities of Microsoft's VDI licensing? In some scenarios firing up a VDI something or other to widget the workload remotely is straightforward and "cheap." (Where cheap is still 2.7 virgins per remotely connected device, per year.) In other situations you not only need to pay the virgin tithe, you might have to pay it multiple times per connected device *and* use a very specific (and rare) volcano for deity appeasement.
You want a cloud? I'll build you a cloud. Microsoft? VMware? Citrix? KVM? Openstack? Cloudstack? You name it; I'll build it for you. If you've got the cash, putting this stuff together is easy, peasy. (I say that blithely, but frankly, anyone with a couple decade's worth of work in the industry can do this stuff in their sleep.)
The issue isn't the technical bits. It hasn't been for some time. VMware, Microsoft et al have done a damned good job of making the systems administrator irrelevant, they are working very hard on eliminating the network administrator, and storage admins are on the block soon. The issue is the accounting.
To be able to achieve proper efficiency you need to not only be able to reduce your service provisioning to some sort of measurable atomic units, you need to be able to rationally set a price and track usage according to a variety of metrics. You probably need varied costing models to appeal to different departments with different needs and budgetary constraints.
You need support staff that are able to deal with a service-centric model and work in an SLA-style environment. You need a department head who can talk the business talk to vendors, the accounting talk to the beancounters and speak fluent nerd to those at the coalface setting up VMs and swapping dead nodes.
For a "cloud" to work in an efficient manner, the provisioning of that cloudy service needs to be itself treated as a business. Even if it is a business within a business. This goes all the way up to requiring your own dedicated beancounters – tech-enabled, of course, so that they can provide that costing rationalisation discussed above – as well as a "sales" team that will go out and sell your vision of IT to the rest of the company.
The above is why the project-based model remains the dominant purchasing model in most companies. It is because right now the tools to do anything else are complete ass. If you want to provide a true "private cloud" to the rest of the business then you need infrastructure to do so. Not technical infrastructure; business infrastructure.
Nerds are – quite frankly – shit at the business side of things. "Technical accountants" don't exactly grow on trees, and who wants to pay for sales engineers to work in internal IT, selling inward to the business itself? That's before we even get to the cost of CIOs who possess clue.
Until the line-of-business costs for apportioning and metering come down starkly, the false economy of project-based costing will seem intuitively correct at anything excepting hyperscale.
Biting the hand that feeds IT
