Problem solve Get help with specific problems with your technologies, process and projects.

Applying cloud stack features to a private cloud

As cloud software matures, enterprise customers are frustrated that new features show promise, yet aren't associated with the enterprise buyer.

Enterprises are increasingly expressing frustration that discussions about selecting and using cloud software tend to focus on the cloud provider, rather than on the private cloud user. As cloud software features mature, enterprise buyers are voicing more annoyance with the fact that some new features, such as OpenStack's Grizzly release, hold considerable promise but are rarely associated with the enterprise buyer. It's time to look at cloud software from an enterprise perspective.

It's likely that cloud providers have focused on open source cloud software -- such as OpenStack, Citrix CloudPlatform and Eucalyptus -- because they need cloud software, but private cloud commitment among enterprises is still uncommon. But the number of enterprises with private needs, particularly the need for cloud bursting and failover capabilities, is growing. The fact is most cloud software tools and application program interfaces (APIs) can be significantly useful to enterprises. The bias lies in how the cloud software is presented and not how it's developed.

The fact is most cloud software tools and APIs can be significantly useful to enterprises.

The goal of the cloud stack software is to instantiate an application by assigning it to a compute facility, link it with storage resources as needed and then connect it with other applications or components and users via the network. The biggest difference between enterprise-flavored cloud software deployments and those of cloud providers is the issue of multi-tenancy. In public clouds, it's critical that applications are isolated because they belong to different users and cross-talk is a security risk. This difference in perspective is what creates differences in priorities and interest in each of the three cloud API resource types: compute, storage and network.

Cloud stack software's features are accessed through a series of management APIs that are typically segregated by these three resource types. The APIs in turn link downward to the resources they represent, usually through customizable "hooks" that can be provided with the cloud software for popular hardware, by the network or hypervisor provider, or even by users themselves.

Rethinking app deployment with 'as a service' elements

An enterprise's focus on cloud stack software should be on the software's ability to more effectively manage the complex interplay between dynamic applications and expanding resources. Application models that break the "install-on-server" mold -- such as virtualization and SOA -- have complex, interrelated deployment and redeployment processes. A single error can completely break an application or a whole business. By providing a management model to deploy applications, cloud software can oversee these complex situations using a process sometimes called "operationalizing" the application-to-resource connection, which is the process of creating a set of practices and tools that facilitate efficient support and management.

The biggest difference in enterprise versus operator cloud resource control is in the network. Enterprises may see the features of OpenStack's Quantum that provide for Network as a Service or virtual network creation as redundant, but they're not. Network as a Service means connecting network setup and management to applications, something that's valuable even for enterprises. For enterprises that move applications between sites for load balancing or failover, for example, Network as a Service may be the most valuable thing in the private cloud. The recent OpenStack Quantum release also includes the framework for Load Balancing as a Service, but it needs additional vendor or user work to exploit it.

In fact, the whole "as-a-service" notion of the private cloud, supported by cloud software, is a powerful way for enterprises to rethink how they buy and deploy both applications and resources. Database as a Service -- the creation of "query servers" that respond to SQL requests rather than distributing low-level storage access -- facilitates public and hybrid cloud service usage; however, it can also reduce network cost and improve performance for purely internal application deployments. The use of a centralized identity service, a feature of some cloud stacks, can improve application security and compliance.

Even in the most basic of resources, compute, the cloud's as-a-service concept can be valuable. While it's not necessary to deploy cloud software to launch applications in such a way that they can be moved quickly if a resource fails, the cloud's principle of resource independence makes this much easier to do and much easier to operationalize. Users report that configuration errors during these application moves are more common than not; cloud tools could make these moves nearly automatic, possibly decreasing the possibility for such errors.

With a little imagination and the help of your major IT and network vendors, you can create a private cloud-based application and resource control framework that will improve your operational stability and likely lower costs.

About the author
Tom Nolle is president of
CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982.

Dig Deeper on Managing cloud infrastructure

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.