Two questions, not one
People often mix up two separate ideas: what kind of service you buy (infrastructure, platform or software) and where and for whom the cloud runs. This article covers the second: the deployment model. The first is the subject of cloud service models. The two choices are independent, so a private cloud can offer infrastructure and a public cloud can offer software.
Public cloud
In a public cloud, a provider owns large data centers and rents resources to many customers. “Public” does not mean your data is visible to the public. Customers are separated from each other by software, and access is controlled by each customer’s own accounts and settings.
Advantages:
- no need to buy or house hardware
- capacity can grow and shrink quickly
- you pay for what you use rather than for peak capacity all the time
- providers typically offer a wide range of services
Trade-offs:
- you share underlying hardware with other customers, which some rules or internal policies treat with caution
- you depend on the provider’s choices, prices and outages
- usage-based pricing can produce surprises if not watched, a point developed under cloud costs
- you have less control over the physical environment
Private cloud
A private cloud is dedicated to a single organization. It may sit in the organization’s own data center, or be hosted by a provider that reserves the equipment for one customer. It uses cloud-style software so that internal teams can request resources on demand, but the resources belong to, or are reserved for, one organization.
Advantages:
- more control over the hardware, configuration and where data is physically located
- can make it easier to satisfy strict rules or contracts about data handling
- performance can be more predictable
Trade-offs:
- the organization carries the cost of buying and maintaining equipment, or of paying for dedicated capacity
- scaling takes longer, since you need spare hardware in advance
- skilled staff are needed to run the platform, including routine tasks like patch management and planning around the hardware lifecycle
- you may miss out on the breadth of services a large public provider can offer
A private cloud is not automatically more secure. It can be very well protected or poorly managed, depending on how it is run.
Hybrid cloud
A hybrid cloud combines two or more environments, typically a private one (or traditional on-premises systems) and a public cloud, connected so that workloads and data can work together. The key word is connected: running a few unrelated systems in two places is not much of a hybrid.
Common reasons organizations choose hybrid:
- keeping sensitive or regulated data on systems they control while using public services for less sensitive work
- gradually moving older systems rather than relocating everything at once, which is a common stage in cloud migration
- using a public cloud to absorb sudden spikes in demand (“bursting”) while normal load stays on existing equipment
- using existing hardware investments until the end of their useful life
- keeping a second location for resilience
Trade-offs:
- it is usually the most complex option, with two sets of tools, skills and processes
- the connection between environments must be secure and reliable; a virtual private network or a dedicated link is often used, and delays between sites, as explained under network latency, can affect performance
- security and access rules must be consistent across both sides, which is harder than it sounds
- costs can be difficult to compare across the environments
Multi-cloud
Multi-cloud means using more than one public provider. Reasons include choosing the best service for each job, reducing dependence on one supplier, or inheriting providers through a merger. It is separate from hybrid, although the two can be combined. The downside is similar to hybrid: more tools, more skills and more places for mistakes. Multi-cloud does not by itself remove vendor lock-in, because each system may still lean heavily on one provider’s unique services.
Community cloud
Less commonly, a community cloud is shared by several organizations with similar needs, such as common regulatory requirements. It is mentioned here for completeness; most readers will deal with the first three models.
Comparing the models
| Public | Private | Hybrid | |
|---|---|---|---|
| Who uses the hardware | Many customers | One organization | Mix |
| Up-front cost | Low | High | Moderate to high |
| Speed of scaling | Fast | Slower | Varies |
| Control | Lower | Higher | Varies |
| Management effort | Lower | Higher | Highest |
These are general tendencies; real situations vary a lot.
Choosing sensibly
Questions that guide the decision:
- What rules apply to our data? Legal, contractual or internal rules may limit where certain information can be stored. Sorting data by data classification helps, and so does understanding the privacy regulations that apply to you.
- How variable is demand? Spiky demand favors public cloud elasticity; steady demand may be fine on owned equipment.
- What skills do we have? A private or hybrid environment needs more specialist staff.
- What do we already own? Equipment that still has years of life may not be worth replacing yet.
- How will we keep things secure and consistent? Whatever the model, who gets access and how they sign in still needs clear answers.
- What does recovery look like? Spreading systems across environments can help with resilience, but only if the failover has been planned and tested.
Many organizations start with public cloud for new projects, keep a few systems where they are, and revise the mix over time. It is reasonable to treat the choice as something to review every so often, not a once-and-for-all decision.