Key Differences Between Public and Private Clouds
I’ve was lucky to take part on a workshop last week with one of the most respected IT organizations in the Middleeast. Our colleagues from the organization gave us a very good feedback on their requirements for a Private Cloud Toolkit, which will help them in build and manage their new datacenter.
What are we trying to achieve with Private Clouds
There are different names but I like to use the name Dynamic Datacenter where the workflows around provisioning and deprovisioning IT resources to user are automated. The main use case is somebody who needs computational resources for its projects sends a request to the IT department. There is a demand management workflow and once approved the provisioning of the infrastructure is scheduled based on the timings given at the request. After the infrastructure is provisioned it is handed over to the user. After the project is decommissioned, the hardware is deprovisioned. Sounds simple but the real processes can get really ugly even in organizations of decent size and complexity. The budgeting cycle, cost cutting concerns, internal politics, lifecycle of hardware and refresh cycles, logistics all add complexity to the process of allocating the needed resources on time which is the main promise of dynamic datacenters.
A Brief History on Public Clouds
This is not a new concept at all, xSP’s has been following this approach since a long time and there are well established product families called Control Panels. Especially after the virtual servers replacing physical hardware the automated provisioning became more of a software problem. xSP’s dump the hardware on the racks based on well known capacity planning techniques and turn them on for running virtualized workloads hence isolating the logistics from provisioning. Moreover with the big players building multi Billion USD investments on datacenters, the hardware pool simply becomes and infinite resource.
Key Differences between Public and Private Clouds
Although both are termed as clouds and the result that they’re trying to achieve are similar, there are key differences between public and private clouds. If these differences are not understood and tackled properly, there’s a great risk of failure for dynamic datacenter initiatives. Key characteristics of private clouds which are different from public clouds are:
Private Clouds Have Limited Resources
The hardware resources in public clouds are located at the organization’s datacenter. No matter how big and complex the data centers are they are still limited in size, power, rack space, cooling, number and types of servers, operations personnel, processes and tools when compared with the resources in public clouds which are located at the massive datacenters. Nowadays with the entrance of the IT titans investing billions of U.S. dollars yearly it can easily be assume that the pubic clouds have unlimited resources when compared with the public datacenters. Moreover the mature operational processes, advanced automation tools and the highly optimized and cost effective procurement and logistics dramatically reduces the the time to deploy new resources. This level of operations optimization could only be achieved by public cloud operators because it is their business while IT is a support function on all other businesses.
Private Clouds Should Support More Diverse Roles
Public Cloud offerings only support a limited set of roles and configurations. For example Microsoft Azure has Worker, Web Server, Database and the newly introduced HPC roles. Whereas in private clouds, there will be a diverse set of server roles that needs to be supported based on the organization’s needs. The ability to support different and configurable set of roles is delivered by the usage of templates. At the beginning an organization may decide to support only a limited set of roles and let the server owners do the configuration and support of additional software, however in the long run this might cause availability and supportability issues.
Nowadays getting a service from the public cloud vendors takes minutes. We give our credit card details, provide the roles and the number of instances and the virtual servers are provisioned and handed over to us in minutes. As long as we’re OK with paying for the servers, they keep on running. The illusion of infinite computing resources available on demand, thereby eliminating the need for Cloud Computing users to plan far ahead for provisioning.
The model is very different with the private clouds. First thing the IT department will ask when you request a new server is did you budget for the server. Or if it is for a temporary need, when you need it and until which date. Since the resources are limited, the operations department needs a allocate resources based on a schedule and decommission as soon as the need is ended in order to allocate to other requests. The demand is evaluated based on the availability of datacenter resources and scheduled to be provisioned at a future date. Enterprises usually have very bureaucratic budgeting processes and logistics takes a long time. My other personal observation is since most of the IT organizations are seen as cost centers cost cutting initiatives puts additional pressures on the virtualization projects. Usually the expectation from private cloud infrastructures is a reduction in costs which puts further cuts to the initial hardware budgeting.
A private cloud management toolkit should provide a scheduling engine where resources are assigned based on request timeframes and availability. When the resource is available, the scheduling engine should automatically provision the resources and inform the requestor on the availability. Scheduling engine should also have a prioritization mechanism to prefer high importance requests.
Complex Provisioning Workflows
Unless it is a customized offering, the provisioning for the Public cloud offerings is very simple, ask for the service, pay the money and start using. The story is different in the private clouds, which needs a full demand management solution. The process should ideally start with the budgeting request. Once the resources are procured they should be allocated to the requester as a virtual infrastructure. The requester should create any request in the context of this virtual infrastructure and the system should communicate back with the availability of the requested resources before starting the approval process. The system should provide monitoring capabilities for the workflow status, customizable workflows and configurable feedback and alerting mechanisms to end users.
Perception of being “Free”
For the IT services organizations that don’t adopt a chargeback mechanism, the computing resources are perceived as being “free” especially by the end user. If you have an important project you ask from the IT to provide you with the resources. Especially if the request is for a high visibility project that has a powerful sponsor that has access to the CxO. The user asks for the resources and want IT to provision. This again puts additional stress on the IT.
A private cloud management toolkit should have a very detailed reporting and dashboard infrastructure. This will provide the information to the end user on the availability of resources before requesting and the current usage of the user. Another important feature is the validation of resources before even starting the demand management workflow. Before submitting a request, a user should be warned on the availability of the requested resources and the nearest time of availability if currently not available.
Lastly expiration in public clouds only happens when you forget to pay. Setting expiration policies based on time or possibly other rules is of vital importance for managing private clouds. There should be a complex workflow where the end user should be warned at different timeframes before the expiration and should be given the chance to extend the usage by kicking off an approval workflow. The expiration policy engine should be customizable and support actions such as archiving the virtual machines before de-provisioning.