The Flexera 2023 State of the Cloud Report reveals that 72 percent of enterprises have a hybrid cloud strategy. Organizations that want to mix the resources of multiple private and public clouds in hybrid cloud configurations should consider certain key factors as they design their solutions.
The Differences Between Public, Private, and Hybrid Clouds
Before I cover those considerations, let me nail down some terminology. A public cloud is hosted by a cloud provider, such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, and IBM Cloud. It provides on-demand, pay-as-you-go services that are accessible over the public Internet. Multiple organizations access public cloud resources concurrently.
A private cloud, by contrast, typically serves the needs of a single organization and is often purpose-built to fit a particular infrastructure and use case. It may be hosted on-premises or in a colocation data center.
A hybrid cloud spans at least one public and one private cloud. You might also have a private, on-premises virtualized environment that is connected to a public cloud. While that doesn’t fit the NIST definition of a hybrid cloud, many of the same considerations apply.
With these definitions in mind, you can start to consider the best architecture for your individual use case. Begin with the end. That is, what are you looking to achieve with your decision to use a cloud computing architecture: Agility? Cost reduction? Scalability?
Private Cloud Use Cases
Many organizations use public clouds, which provide benefits such as high availability and the ability to scale to meet elastic demand, but for some use cases, private clouds are a better option:
1. Specialty Hardware or Configuration Requirements
In some cases, organizations can’t get the hardware or infrastructure that a particular application needs from a public cloud provider. For example, if your workload requires a virtual machine (VM) with a non-standard CPU and RAM configuration, or requires an operating system that is not supported in any public cloud provider, deployment into a private cloud environment may be your only viable option.
2. Governance or Regulatory Requirements
In other cases, security or governance issues force organizations into using a private cloud. Certain countries require that the application data pertaining to people in that locale remain within the country.
3. Network Latency
If your users are in an area distant from a public cloud provider, latency could slow down access to your application and make a private cloud a better option. Similarly, a cloud application for your internal users may run faster using an on-premises private cloud.
4. Cost
When planning for cloud, you should try to calculate your total cost of ownership (TCO) over the projected life of the project. Our cloud cost management solution lets you build three-year cost forecasts to help ensure that you are using the appropriate and most cost-effective cloud infrastructure. For workloads that have a steady state load 24×7, you may find that a private cloud is more cost effective than on-demand public cloud infrastructure.
Hybrid Cloud Use Cases
While the benefits of private clouds can be compelling for certain use cases, sometimes organizations require a combination of these benefits along with the advantages of public cloud. In such circumstances, a hybrid cloud may prove to be the better choice:
5. Untested Workloads
Sometimes it’s not clear to what degree an application will succeed in the market. Cloud-oriented businesses tend to follow the mantra “fail fast, fail cheaply.” Considering that advice, it makes sense for organizations to use public cloud resources for a new, untested application before embarking on the capital expenditure associated with launching in a private cloud. Once an organization can establish a steady-state workload pattern and see a clear line of sight to the longevity of an application, it may choose to bring the application to a private cloud environment.
6. Cloudbursting
The term cloudbursting refers to a situation where workloads are “spilled over” to a different cloud environment to meet capacity demands. This is usually a temporary situation — for instance, to handle a spike due to a seasonal traffic or a news event that drives traffic to a particular application for a short time. Our customers use the term “buy the base, rent the spike” to describe a use case for cloudbursting. A hybrid cloud scenario would see the steady state handled by the fixed private cloud environment and the spike handled by on-demand resources from a public cloud.
For cloudbursting to be practical, organizations need secure, low-latency network connections between private and public clouds. Housing a private cloud in close physical proximity to a public cloud helps reduce latency issues. Offerings such as AWS Direct Connect and Azure ExpressRoute allow private clouds to be hosted adjacent to a vendor’s public cloud regions with low-latency and secure network connectivity between public and private cloud resources.
7. High Availability and Disaster Recovery
Achieving a highly available, geo-redundant setup for a private cloud can be expensive. It requires twice the capital expenditure (and sometimes more) than a single private cloud, and it requires a data center location that is geo-dispersed from the primary data center. Most organizations are reluctant to absorb and justify such expenses. Without a geo-redundant private cloud configuration, organizations are vulnerable to catastrophic events.
Cloud customers can, however, use hybrid clouds to promote high availability (HA) and disaster recovery (DR). For example, in a “warm DR” scenario, an organization can keep its production environment in a private cloud and a recovery environment in a public cloud, ready to spin up as necessary. The organization replicates data across to the public cloud, but all other resources remain non-operational until needed. In the event of a disaster, administrators can quickly start the application in the public cloud, since the data is already present there. When disaster strikes, this configuration results in significant cost savings as well as dramatic improvement in application availability.
8. Regulatory Requirements
I noted earlier that regulatory requirements sometimes dictate that your application data must reside in country, for which you could choose a private cloud. However, this requirement may not preclude having parts of your application, such as stateless web servers, run in a public cloud to improve performance.
9. Cloud Services Brokering
Another use case is what we call cloud services brokering, or self-service IT, by which we mean a way of automating IT operations to offer your technically unsophisticated end users the option of push-button deployment to public and private clouds and virtual and bare-metal servers without involvement from operations staff. Depending on the use case, you could limit your end users’ access to a specific public or private cloud, but a hybrid cloud architecture provides maximum agility for meeting the needs of your lines of business.
Hardware and Hosting Considerations
Regardless of the particular use case, every cloud implementation requires attention to compute, storage, and networking resources. The hardware you use for each of these areas will depend on your specific needs. In many cases you can use inexpensive commodity hardware for your private cloud, or repurpose your existing hardware, but if your application requires a high level of compute-intensive operations or has specific I/O demands, you may have a more limited number of options from which to choose.
Networking hardware considerations are driven by application needs as well as latency demands and price. Some private cloud platforms, such as Google Anthos and Microsoft Azure Stack, certify certain hardware to work with their software. In general, it’s a good idea to use commodity hardware. It’s easy to acquire, easy to maintain spare inventory, and easy to replace — in contrast with specialty or custom-built hardware.
When you set up a private cloud, you also have to decide where to physically host it. One option is to run it on-premises, which gives you full access to the hardware and lets you provide physical security, including access by your internal staff. When you implement it in-house you are responsible for paying for power, networking, and operations staff.
A more common alternative is to house a private cloud at a colocation facility. You can still maintain a fully controlled environment, but the provider is responsible for the physical aspects and operations, and you can choose a facility adjacent to a public cloud provider to reduce latency between clouds.
Choosing a Private Cloud Platform
Once you’ve settled on an architecture that meets the needs of your use case, you have to choose the platform on which to implement it.
When selecting a private cloud platform, you should take several factors into consideration:
Cloud Management
Take control of cloud use with out-of-the-box and customized policies to automate cost governance, operations, security and compliance.
- Momentum issues such as community size and enterprise traction, which will affect your ability to find people with the expertise to work with a given platform and determine the availability of technical information.
- Qualitative factors regarding stability, reliability, and documentation and support.
- Technical issues such as connectivity options, API compatibility, and high-availability features.
- Systems administration features such as ease of deployment, ease of management, and ease of upgrade, as well as resource monitoring and configuration management.
- Back-office support for things like billing and chargeback.
- Commercial support availability, so you can focus on building the application features that are critical to your business rather than chasing cloud platform bugs.
- Access to such resources as technical specifications and people with the expertise to work on the platform, which may prove easier for popular open source platforms.
Private Cloud Implementation Tips
Once you’ve chosen an architecture and a cloud provider, consider the type of service level you need to provide for your users. Design a configuration with the appropriate level of availability that includes multiple instances of load balancing, compute, and storage resources and the ability to maintain operations should a node fail. Identify single points of failure and design solutions to address them.
Identify your typical traffic levels and expected spikes, monitor actual traffic, and adjust as necessary. The importance of usage monitoring of your cloud resources cannot be overstated. This will determine how much you can afford to “overcommit” your resources in the cloud. There are numerous open source, commercial, and cloud-native tools that can help with monitoring your cloud platform, as well as many configuration management tools which can help you automate configuration of additional resources on short notice to expand your cloud infrastructure as needed.
Expect your private cloud to fail, because it will, sooner or later. As I said earlier, you must design your applications to handle underlying hardware failure in the cloud. In the event your private infrastructure fails — because of a power outage or some disaster — you must be able to re-create your application in a different cloud — either in another private cloud in a different geographical location or in a public cloud. Make sure that the cloud management solution that you use to orchestrate your workload is located in a different data center from that of the primary cloud it manages. You don’t want a failure that affects your cloud platform’s data center or its connectivity to also bring down your management system.
