Private Clouds – practices to note
November 3, 2010 Santa Clara, CA—Cloud Expo—Brian Wilson, director of cloud services at Quest Software talked about “The Private Cloud Top 10 Best Practices and Pitfalls to Avoid” in one session. Starting out, he defined the requirements for private cloud computing.
Private clouds are part of the move to virtualization and cloud management. Users must define and manage a secure cloud infrastructure with a specific business focus that is scalable to100’s of computers. A private cloud must work with the existing infrastructure and applications, or it isn’t worth the trouble to set up.
A private cloud needs the following six features: on-demand self service, self management, a shared resource pool, rapid elasticity, measured services, and broad network access. To make a cloud, virtualization is a technology, and not a deliverable for the project. The total of the software, platforms, and infrastructure has to be assembled as a service. Currently, companies choose between public and private cloud services, but in the future, a hybrid set of technologies and services will emerge to erase the distinctions between public and private.
The critical components of a private cloud include the physical components; storage, servers, and network infrastructure. At the minimum, a virtualized infrastructure plus automation services are necessary. This minimum set includes many components, some of which might be used in other configurations in existing installations.
The first pitfall is that virtualization alone does not make a private cloud. Any implementation needs to focus on the benefits of clouds, especially self-service and self-management. A pooled infrastructure is necessary as is the ability to provide measured services in an on-demand universal access environment. In addition, the cloud must have the ability to rapidly change size to meet demands. Elasticity means that the cloud resources must expand and shrink as needed.
A best practice is to carefully define the use case for the cloud. Some areas that are good candidates for clouds are development, test and QA, production, help desk, training, and sales evaluations and points of contact. Focus on the functions that are easy to transfer to the cloud for the first applications. Define the internal and external interfaces and, through them, the whole dynamic data center. Determine how the cloud will to be used and plan for expansion.
Another best practice is not to wait for the “big bang” to change. First, virtualize the key applications and develop pooled resources to serve them. Once the first applications are working, move more applications to the cloud. Avoid waiting for that “magic metric” to start an evaluation process. Keep asking “is there a better way to do this?” in evaluations and measurements. Generally, applications can be divided into thirds, the first two are easy and only slightly difficult to implement. After the first two thirds of the applications are working, you can start on the difficult last third. Get the reworked applications into the hands of the users as quickly as possible and critically evaluate the use models and user issues.
A third best practice is to identify the “right” applications for your cloud. Most of the good applications are dynamic. Not all applications should be on the network, so avoid those that are impossible or hard to virtualize. These applications include those that have hardware dependencies, are static over long periods of time, or have specialized testing scenarios. Evaluate the effort and benefits of any changes in operations and the effect a cloud application will have on them.
Another pitfall is the failure to understand the self-service aspects of the cloud. There are many models of operations, so define self-service and user expectations. Consider the models with finite resources and defined timeframes, such as airlines and hotels. Determine the importance of reservations, as opposed to requests, for cloud resources and figure out how to balance the levels of automation against any other requirements. Reservations without services are always bad, just like going to a car rental booth with a reservation and not getting a car to rent.
The next best practice is to know your users and plan their experiences. Take time to understand how they will and could use the cloud. Avoid confusion from having too many or too few constituent groups. Understand and communicate that things will change and be flexible. Understand that capacity sharing and other techniques will become more important as users change over time.
A pitfall is not to underestimate the users’ definition of production. Users make demands and set expectations for services and become resistant when a change makes more work for them. Determine user-friendly levels of redundancy, monitoring, and support for service level agreements and make sure the users understand their significance. Define production versus mission critical and work on each appropriately. A mission critical function needs to meet specialized requirements for up time, recovery, and backup that don’t apply to the normal production processes. The technology to support both in a cloud environment is readily available.
Another serious pitfall is to ignore application lifecycle management. It’s important to create a plan and a team to update and manage applications. Create reusable building blocks of images and applications and distinguish between the new and old versions of the applications. Find the sweet spot for the unique number of software images in the organization that are necessary and useful. Use the content as your carrot to ease the transitions to the cloud-based applications. Develop applications levels and management controls to allow the IT groups to service the management needs. Meet the delivery requests.
A best practice is to prepare for compute and storage platform growth. A virtual environment enables scaling and changes. Determine the scale points up front to avoid future headaches. Be prepared to increase quickly. The greatest challenge to meeting this best practice is the difference between the IT budget and actual needs.
Finally, a best practice is to (try) to future-proof your cloud. Define the scale and scope of your conversion project early and update often. Plan for scaling and heterogeneous systems and expect constant change. Try to define vendor-agnostic features and develop a vendor-agnostic roadmap for your cloud.
As a bonus feature, any cloud that needs broadband connections can use standard technology in a secure environment. In general, enterprise-level infrastructure is already globally deployed, so the only challenge is to get repeatable and consistent performance, since the cloud applications should not be latency dependent.
