In an orchestrated environment, the developer would log into a portal (preferably from a device of his or her choosing) and input the desired specifications for the compute environment required. The developer would fill out various fields defining physical/virtual, CPU speed, disk space, performance levels, RAM, etc. The system would then:
This is a far more streamlined process, but also more complex to create. The last piece that’s truly required to define the architecture as a private cloud is "measured service." Whether or not the feature is heavily utilized, a private cloud architecture should have the ability to show which business units, departments, and consumers are using which resources, and how much is being used. This allows for key business metrics to be drawn, and informed decisions to be made. For example: Department A is utilizing 23% more IT resources than any other department; let’s dig into why. Monitoring and chargeback are key to regulating the value and usage of a private cloud infrastructure.
With the ability to rapidly provision resources on demand, spin up new applications or expand old ones on the fly, organizations need to ensure the power isn’t being abused. Virtual machine sprawl is an example of this in the server virtualization world. Server virtualization made it so easy to spin up a new server resource that the power tended to be widely overused.
It’s always important to know what you’re really getting and map that to what you really need. Many organizations will only need some level of converged infrastructure; some will require a full private cloud.