How much private cloud do you really need? A private cloud is all about the IT department getting out of the way of its internal customers, enabling business units and individual developers to provision their own VMs and get on with doing their jobs. But building and operating a private cloud is a complex, and therefore expensive, task. There needs to be a large payoff before there is a real business benefit. Some businesses don’t really need a private cloud platform. Often, their business processes will prevent real self-service on their private cloud. For these organizations, there may be simpler ways to achieve their desired business outcomes.
One thing to consider is that a cloud platform has a number of features. You may not need all of these features. A key part of a cloud platform is the automated deployment of VMs with predefined configurations. Another element of the cloud platform is multi-tenant support: the ability for multiple organizations or departments to securely and independently use the same platform. One aspect of multi-tenancy is the user portal, which enables self-service provisioning by each tenant. A very visible part of this self-service portal is the catalogue. This is a list of the available VM configurations: hardware and the operating system and applications within the VMs. Another part of multi-tenancy is network segregation between the tenants and even within parts of each tenant. Not every customer wants all of these features in their private cloud. Not all of these features need a full private cloud platform. Deploying a platform like OpenStack may be too much complexity for the organization to handle in one change, or at all.
As an example, consider a small telecommunications business that deployed a private cloud to enable development and testing of new applications. However, only one person is allowed to deploy VMs using the cloud platform. The end user must first open a help-desk ticket to get the VM deployed. The ticket is then passed to the one person who is allowed to use the cloud platform to deploy the user’s VMs. There is no end user self-service. For this customer, the most valuable part of the solution is the network fencing that is part of vCloud Director. Everything else could be done with vRealize Orchestrator workflows or a PowerShell script. If the user self-service portal is not going to be delivered to users, then there is no reason for the portal.
The service catalogue is important for all of the automated VM deployment methods. That help-desk ticket should only need to specify which template VM or VM role is required. At a fundamental level, this means consistent VM templates for consistent and supportable deployment. To get more “cloud-like,” it is important that the catalogue include standard application builds. Whether this is databases or web servers or whole lists of standard software will depend upon the organization. Simply having a catalogue of VMs and applications may well be all that some organizations require. For organizations that require more, it is an important step along the way to full cloud automation.
At a larger-scale organization, a private cloud is about enabling developers to deploy their own infrastructure for development and test. For traditional development, this is an infrequent activity, probably suited to help-desk tickets and automated VM builds. This automated and consistent build will provide a huge operational support benefit without needing a large platform. For more agile and DevOps-oriented organizations, the developers will want a programmatic way to provision and de-provision this infrastructure. The user self-service portal will not answer this need. An API is what the developers want. The API does not need to be a cloud management API like OpenStack or vCloud Director. It does need to be a well-documented API that is accessible from multiple programming languages. It may be Perl, or Java, or even PowerShell that the developers choose for the automation.
Does a private cloud need a user self-service portal? In a lot of cases, it does not. For provisioning less than a dozen VMs a week, a responsive help-desk system will answer the need. Automation is still required to ensure a reliable and consistent outcome. A cloud-management platform may be overkill. If the cloud will provision a thousand VMs a week, then an API is probably more important than a self-service portal. Somewhere in the middle ground, there may be customers for whom user self-service makes sense.