In the early part of 2013, EMC announced a new storage virtualization product called ViPR that delivers a software interface to block, object and HDFS storage services layered on heterogeneous storage. As part of that announcement there was an architectural discussion regarding how ViPR would be providing these services to applications that entails breaking out the design into two components: the control plane and the data plane.

The control plane provides common interfaces for provisioning, policy & management while the data plane provides interfaces for data access from applications. In separating out these two layers, EMC creates an architecture that is agile and enables new services to be added over time without impacting production services. Since ViPR is focused on storage, it will, unfortunately, never be expanded to encompass an entire cloud management stack. However, the architecture is interesting and aspects of it lend itself to building a best-of-breed cloud management platform.

Starting with the control/data plane concept, I broke apart the cloud into multiple planes and then focused on how the layers would communicate to enable a cloud management platform that inherently scaled in and out as well as up and down. Figure 1 illustrates the outcome of this effort and each plane is described in more detail below:

Application Plane – This plane focuses on the deployment, lifecycle and management of the running applications. In today’s lingo, this is part of the Platform-as-a-Service (PaaS) architecture. The thing about PaaS is that services need to be designed to “plug-in” to the PaaS container in order for them to be made available to the applications. In this architecture, the application plane now has a common interface to manage the data plane and the compute plan. Hence, those services are now available to the application regardless of their underlying location or implementation.

Data Plane – Since this is a comprehensive cloud management platform, I’ve moved the data plane out up in the architecture to become an aggregation layer for all types of data including databases, files, as well as, operational information created by the compute and control planes. Through these two layers’ designs, I can now build business applications as well as a single pane of glass to manage my entire cloud regardless of the physical components that make up the cloud infrastructure.

Compute Plane – This plane manages the resources for operating the application and data planes. The integration of the application and data planes no longer need to rely on a single hypervisor to support its cloud design which provides tremendous freedom for the cloud applications and data to migrate where the economics (performance, costs, etc.) are best.

Control Plane – This plan implements the interfaces for operations staff to configure and operate the underlying hardware platforms that comprise the cloud infrastructure. It implements governance and access controls as well as supports policies for deciding where resources should be allocated from when requested from the compute plane. The compute and hardware planes together deliver a consolidated and unified cloud resource pool regardless of the underlying componentry.

Hardware Plane – This is the physical equipment that will comprise the cloud infrastructure resource pool.

Figure 2 illustrates how the integrated stack would look and how the planes communicate to drive independence and agility.

While this is all conceptual, it follows many of the existing patterns from building Service Oriented Architectures (SOA). What’s really interesting to me about this architecture is that everything above the control and hardware planes can scale out in a common manner with a single set of tools and interfaces, hence, driving toward single pane of glass. It also puts a lot of emphasis on good administration of the control plane so that applications perform and that regulatory concerns and risks are mitigated.