Private cloud architectures involve a tight coupling of software and hardware, layered with automation and orchestration. These environments can be prone to complexity, which leads to additional deployment time, administrative costs and risks. Removing as much complexity as possible will help ensure a smoother deployment and ongoing environment.
Standardization is vital to reducing the complexity of private clouds. The more disparate systems used, the greater the need for automation and orchestration customization, which increases the cost and complexity. Hardware and software infrastructure components should be looked at with the goal of utilizing one platform for each layer (server, storage, virtualization, and so on) wherever possible (there may be exceptions).
For greenfield deployments, this is typically an easier task, as there is no legacy infrastructure to work around. Components can be selected based on cost/features and standardized on moving forward. A common approach to this is pod-based designs of compute, network and storage, which can be purchased and added as capacity demands increase. You’ll either want to settle on a standard for a pod or a standard for individual components if not using a pod design.
When deploying private clouds on, or integrating them into, existing infrastructures, the standardization task will be more difficult. Legacy infrastructure not ready for refresh will have to be carefully considered on a case-by-case basis. For example, if new servers are being purchased as a part of the project but there are existing servers in place, you’ll want to carefully consider whether or not to replace them, as well, in order to standardize on a hardware platform. The additional "soft costs" incurred by maintaining the existing servers must be weighed against the "hard costs" of replacing them. Costs such as maintaining additional replacement parts, maintaining staff expertise, and automation integration will need to be considered.
This decision will need to be made for each component of the infrastructure. In most cases, a single platform will be suitable for a given component, but there may be exceptions. For example, storage workloads vary widely, and there may be cases where separate storage systems may be utilized for different purposes based on performance and cost. Whenever it looks as though two components will be needed over a single standard, ensure that the benefits outweigh the potential additional soft costs. Also, look for other ways to solve the same problem. Continuing the storage example, technologies such as caching or auto-tiering may be able to provide the same performance levels on a single storage system.
Standardization is fundamental to successful private cloud deployments. By standardizing on hardware and software, you are removing variables that can cause cost and risk later. With a standard platform, you’ll require only one set of administrative knowledge and streamline your automation and orchestration roll-out.
