Plastic Clouds

What makes a real cloud "real" and a fake cloud "fake"?

A recent article entitled “Are you cultivating a ‘Fake Cloud’?” explored the tendency of companies that have virtualized, to label their offering as a cloud, despite perhaps not meeting commonly accepted characteristics of a true cloud deployment.  Let’s examine the characteristics of a true cloud pointed out in that piece:

• The ability to instantly self-provision resources
• The ability to instantly auto-provision resources
• The ability to scale to the functional limits of the enterprise
• The ability to align costs with use
• The ability to manage the interactions with other systems, including leveraging heterogeneous cloud-based systems

Many of these points whether explicitly or implicitly, lead to the “A word” – that being “Automation”.

In a world where Lines of Business can spin up workloads on public cloud options like Amazon AWS and others in a heartbeat, it would clearly be unacceptable for internal IT departments to introduce long lead times on self-service requests by introducing unnecessary time consuming manual processes.

Automated Decision-Making

The automated deployment and operation of these workloads however requires “automated decision making” to support them (lest we re-insert manual steps back into the process) and this remains a key gap in all of the major cloud stacks on the market today including VMware.

While some vendors may provide basic heuristics to guide workload placement, they are often based on simple balancing type algorithms (or worse) that could actually lead to driving higher cost and performance risks into our cloud deployments, and fail to understand the need to add (or remove) capacity on demand (for example, when should we “burst” to Amazon in a hybrid cloud scenario?)

The key automated decision making criteria would encompass the following for both automated deployment and ongoing operations:

• Pursue the fundamental goal of driving down cost (driving up utilization) of our cloud services while assuring performance of the workloads
• Factor in any required technical/business/policy constraints
• Span the depth of the technology stack including compute, storage and network resources
• Work across clusters and clouds

The first bullet is the most important since it sets out the goal for our cloud services.  It starts and ends with the application needs, and how we can leverage the ever-evolving dynamic infrastructure to meet those needs at the lowest cost.

The applications that we are providing the cloud infrastructure for must get the service levels they need at the best cost we can provide, subject to any technical or business constraints (bullet 2).  Examples of constraints are varied but may include technical constraints such as cluster boundaries (more on this in a second), logical network membership, as well higher-level policies such as affinity (which VMs should run on which hosts / clouds), disaster recovery and high availability amongst others.

Starting with this fundamental goal outlined above is very different from workload balancing algorithms such as VMware DRS (Distributed Resource Scheduler).  Incredibly innovative for its day (in the mid 2000s), VMware DRS (and vMotion) introduced the world to Virtual Machine portability and automation.  These technologies essentially worked to balance compute (CPU and memory) resources in our clusters and resource pools.

The Notion of Capacity Itself Becomes Elastic

As virtual and cloud infrastructures have evolved however, we no longer simply have the ability to dynamically change workload resource assignment, the notion of capacity itself has become elastic.  With modern converged infrastructure architectures (e.g. Cisco UCS and others), we have the capability to bring host capacity (blades) online (or offline) dynamically.  With hybrid cloud adoption, we have the opportunity to spin up capacity on demand in the public cloud to accommodate the needs of our workloads and applications.

Our automated decision-making must also go beyond compute (bullet 3).  As we looks to the needs of the application, we must understand how to allocate underlying compute, storage and network resources to meet the service levels of the application while optimizing cost.  These resources are closely interconnected – a decision to move a VM from one host to another may look great from a compute perspective, but could be disastrous for storage IO and latency for example.  Any automated decision-making must therefore understand the interconnected nature of the underlying resources as they pertain to application needs.

Finally, the scope of our decision-making is changing.  While our workload placement decisions used to be constrained to a particular cluster, the advent of Network Virtualization technologies (VMware NSX and others) is tearing down the artificial barriers between clusters and allowing us to pool them together into so called “super clusters”.  We therefore need decision-making capabilities that are not constrained to a cluster, but that can work across clusters and even clouds.

The latter is particularly important in the transition of the IT department to “trusted advisor” to the business, or “IT as a broker”, to understand the “what, when, where” of workload deployment and operations.  With automated decision-making at their side, IT departments will be able to chart a course towards true (and not plastic) cloud automation.