I think you mean "no one wants a '500' service unavailable" message when they hit submit. A 404, file not found, error means the file is missing regardless of the operational topology.

Bernard:

Some interesting thoughts. I guess I would extend the concept of "private cloud" to include dedicated provider hosted resources (in which case you do need to worry about security, etc), but that is another topic. :)

In regards to your point about reduced demand insight, I agree that it will be reduced, but I think the counter-balance to that is that capacity provisioning will be much more fluid. Most customers don't have capacity issues as much as they have capacity-where-they-need it issues, hence the typically low utilization rates on non-virtualized servers, storage, etc. In a virtualized data center environment, with the appropriate management/provisioning tools, you should be able to shorten the provisioning cycle and improve asset efficiency.

I agree with you that we will need some sort of chargeback/rationing mechanism. If resources are perceived as "free" their is not discipline around their use. Already we are seeing customers that have gone from server-sprawl to VM-sprawl--virtualization, clouds,etc are not going to fix ineffective governance.

Regards,

Omar Sultan
Cisco
blogs.cisco.com/datacenter

Bernard:

Excuse the comment from a commercial vendor, but you may be unfamiliar with CohesiveFT’s Elastic Server platform. We share your vision of “supply chain management” as well as public and private clouds coexisting and interoperating. Our Elastic Server platform allows ISVs to “publish” to a platform that deploys both to private and public clouds. Several vendor like Razuna and Mule are using the free version of the service to create vendor certified “one click to deploy” complete virtual machines that deploy to any of a dozen virtualized or cloud production environments. See Razuna’s portal here http://elasticserver.com/site/razuna

Craig

So, have you seen the VCL open source cloud provisioning model - automates and handles most of the issues mentioned? http://vcl.ncsu.edu - now also in Apache.org

Great article! In answer to your question, "Where is the CAPEX?" ask the Finance Department "Where is the cash?" Organizationally, we know how to deal with this problem. We've been doing it for years with cash. The finance department doesn't spend an organization's cash, the functional departments do. The finance department is responsible for understanding, forecasting and governing the organization's cash requirements. The IT department will evolve to provide a similar function with respect to private clouds.

Dave Menninger
Vertica

This bring out another point. Why in the world would you allow a non-systems operator to provision resources?

I have read many cloud articles, blogs, and threads and the constant focus seems to be that users can self provision at will. Why would you ever allow this?

Very few users understand enterprise system architecture. Most see a new widget and want to try/test it.

The new internal cloud is great, but not for the develops or users. It will impower the system integrators and operators to deliver APPROVED services more quickly.

Part of the delay in deploying new solutions has been accurately described above in regard to procurement, but vetting was completely overlooked. Many system requests are submitted every year for non-compliant, redundant, or irrelevant systems. The vetting process stops these requests prior to resource allocations.

We have been working with an internal product the produces workflow to enable both our clientelle and system operators to streamline this process. It allows users to submit a detailed systems request, justification, charge number, and system specificaitons. This is reviewed by tier one individuals to insure the basics are right. A tier two validates the requests against existing systems and mediates any disparities.

The final approver verifies all work previously accomplished and either accepts or denies the request. If accepted, the system is dynamically provisioned and the requester notified.

This provides an average TTD of less than 48 hours and mainatains standardized operations.