Are you using Public Cloud as an Expensive Data Center?

It’s time to have a discussion on True Public Cloud. Wikibon did a post a few months ago on their definition of True Private Cloud, and I followed that up on my definition of private cloud. I think it’s time to discuss when you truly know your organization has adopted Public Cloud and when you’ve only lifted and shifted your data center from private infrastructure to Public Cloud VMs.

It seems like I’ve written on this topic in different formats before. I discussed the lessons learned from Netflix’ move to the Public Cloud. I’ve reviewed the difficulty of shoehorning traditional infrastructure into AWS. I’ve never just head on discussed the attributes of embracing Public Cloud as a way to deliver IT services. If you’ve treated your organization’s move to Public Cloud simply as a data center migration, then chances are you aren’t taking full advantage of Public Cloud. You are just paying for expensive hosting.

Let’s restate an important aspect of Public Cloud. Public Cloud is a different way of delivering enterprise IT. Everything from the application development, service management and operations is approached differently in a True Public Cloud organization. Even security, audit and compliance looks different. The concept of DevOps is put to practice in companies that embrace True Public Cloud. The best comparison I can give is that of ERP.

Companies implementing ERP transform business processes to fit the ERP application. Rarely do companies bring their existing business processes to an ERP application and customize that application. Customization is akin to private cloud. Let me give a specific development/operations/configuration management/compliance example.

Let’s take load balancer provisioning as an example. In the traditional enterprise, a load balancer is a configuration item (CI) in your configuration management database (CMDB). If an application needed to add additional front-end servers to the load balancer, a few actions take place from a service management perspective. First, a ticket is created to instantiate and validate the new application instances. Next, a ticket is opened to change the configuration of the load balancer. An additional ticket may be opened to make a firewall configuration change. All of these changes may go through a change committee and document for success or failure. During a SOX audit, the auditor will ask for all of the supporting evidence to show that the configuration control policy was followed in adding front-end servers to a particular application.

We will not address decommissioning of these servers. Generally, in a large enterprise with this much overhead associated with change, the operations team will leave the additional servers in place to avoid the hassle of re-provisioning.

Now let’s take a True Public Cloud use case. In a True Public Cloud, the application will detect that additional app servers are needed to handle the incoming load. The application will make a call to the Cloud Providers control panel via APIs and provision more front-end servers and the appropriate load balancer and IP filter rules. Once the load has subsided the provisioned front end services are retired. Auditors examine the audit logs from the control panel and match these to the application’s architecture to ensure its part of the organization’s policy.

If you are a customer of a Public Cloud and your processes look identical to your private data center, then you haven’t transformed your IT operations and accepted Public Cloud. You are just consuming expensive compute, storage and network without reaping the benefits of True Public Cloud.