User Control and the Private Cloud

One of the comparison points between the public and private cloud domains is the difference in the level of control and customization over the cloud-based service.

In a public cloud environment, users typically receive highly standardized (and in many cases commoditized) IT services from the provider. In the private cloud, it is usually the case that users have a higher degree of control and customization over the cloud-based service. I would wager a bet that to many this makes perfect sense and it is simply a manifestation of who has control over the means of delivery (third party in the public domain, end-users in the private domain).

Presumably, those users who are heading down the public cloud route have come to grips with the fact that they will have less control over certain elements. They are happy to get fast, on-demand access to services at the cost of some control. However, I have come to learn private cloud users have a much different expectation. They want the features they get from a public cloud, but typically do not want to give up one iota of control/customization capability. Not to be the bearer of bad news, but in most cases this is all but impossible.

While I believe it is obvious that private clouds provide a much higher degree of customization and control than their public counterparts, that does not mean every single thing about a service delivered via a private cloud is configurable by the end-user. In fact, some things that are pre-configured and immutable deliver significant value to the user.

As an example, let's consider the scenario of an enterprise working to build a private cloud to run their application platforms. Part of this effort is likely to include the creation of a service catalog that contains different application platforms they can run in their cloud. A significant portion of the service catalog will consist of vendor-supplied, virtualized application platforms. These virtualized offerings have been pre-packaged, pre-integrated, and optimized by the vendors, and they are ready to simply activate and run within the private cloud.

By getting these virtualized packages from vendors, the company spares the cost of developing and maintaining them over time. This is good for multiple reasons, including:

- The company can focus on core competencies, which we can assume do/should not include application infrastructure administration
- The company benefits from pre-packaged application stacks, which the vendor configures, integrates, and optimizes appropriately to achieve the best possible result in terms of service delivery time and service performance.

Of course, these pre-packaged, virtualized application stacks also have another effect on the company. Namely, it means the company gives away some control over the exact configuration of the software bits. This may include things like the location of the installed product on disk (which I've learned is not nearly as inconsequential as I thought), default system users, initial disk allocation, etc. Some of these things may be reconfigurable by the end-user (system users, disk allocation), but invariably some remain burned into the virtualized stack for all of eternity (installed product location).

In this case, end-users sacrifice some control and in turn achieve simplicity, rapidity, and standardization. After all, if the system required the user to specify installation locations for each product in the application stack for every service request, the delivery of said service would not be as simple or fast. In addition, there would be a lesser degree of standardization among the running services, since it would be possible for the software inside those instances to have varying installation directories. This may seem minor, but it could have substantial impacts on the ability to centrally administer these cloud-based services.

In the end, the very specific use case above highlights general themes regarding control in a private cloud environment. Private cloud environments typically offer more control and customization capability than their public cloud counterparts, but that does not mean they offer the same control capability that users have grown accustomed to in their traditional environments. Users must usually sacrifice some control in order to achieve the benefits of simple, fast, and standardized cloud-based service delivery and administration. When confronted with potentially giving up control over a specific capability, users should consider this simple question:

- Do I need control over this element?

It seems like an obvious question, right? However, I emphasize need because users often merely want control. They are used to a certain culture, or a "that's the way we do it" mode of operation. Making decisions based on culture and standard operating procedure does not always yield the best results for the enterprise.

Of course, the entire onus is not on the users when it comes to this dilemma in the private cloud. Vendors must carefully design and implement private cloud solutions and services so that they offer a high degree of customization and configurability, all the while delivering out-of-the-box value. They cannot be overwhelming to use, and at the same time they should accommodate a wide array of use cases. As you may imagine, this is far from easy and the state of this art is just beginning to evolve.

Original Article - Cloud Computing Journal

Join Us: http://bit.ly/joincloud