Public vs Private vs Hybrid Cloud vs Bare Metal: A Workload-by-Workload Comparison

Comparisons of public vs private vs hybrid cloud usually organize themselves around the models, describe each one, and leave the reader to work out which applies. That is back to front. Nobody comes to this question with a model. They come with a workload in hand.

So this is done the other way. Find your workload, get a placement and the trade-off that comes with it. Several of these land on public cloud. One lands on leaving things exactly where they are.

This is the layer below the model-level decision. If you have not yet worked out whether your organization broadly belongs on dedicated infrastructure, start there and come back. What follows assumes you are past that and are now placing individual workloads.

The four models, in short, since the rest of this assumes them. Each is a cloud architecture decision before it is a purchasing one — public cloud services running on someone else's data center, private cloud on physical servers dedicated to you, bare metal with no hypervisor between your operating systems and the hardware, and hybrid as a deliberate combination of the three.

[graphic: Public cloud, shared and billed by consumption, large managed service catalogue. Private cloud, virtualized and dedicated to you, self-run or provider-managed. Bare metal, physical server with no hypervisor, direct access to hardware. Hybrid, a deliberate combination, steady here and variable there.]

Production databases: private cloud or bare metal

Placement: private cloud or bare metal in most cases. Public cloud managed database services when your team has no database operations capability.

Databases are the clearest case for dedicated infrastructure because they punish the things shared infrastructure does. They are sensitive to storage latency and to noisy neighbors fighting over the same underlying disk and network. They run continuously, not in fits and starts, so the elasticity premium buys nothing. They gather data, which makes them ever more expensive to move.

The bare metal vs virtualization question comes down to what the hypervisor costs you against what it gives back. Bare metal is the right answer when storage performance is the limiting factor and you want no hypervisor overhead at all. Private cloud is the better answer when you want dedicated resources alongside snapshots, live migration, and the operational conveniences virtualization provides. That second set is worth more than most teams expect during a hardware failure.

The real counter-argument: managed database services are very good, and they replace real expertise. If nobody on your team can tune a query planner, size a buffer pool, or plan a failover, a managed service is buying you a capability rather than just convenience. Do not move a database onto infrastructure you cannot operate.

Trade-off accepted: you take on capacity planning and operational responsibility in exchange for performance consistency and predictable cost. A fully managed private cloud narrows that trade by moving the infrastructure half of it — hardware, hypervisor, storage layer, patching — to the provider, though the database itself remains yours to run.

Web and application tiers: follow the traffic shape

Placement: depends entirely on traffic shape. This is the workload where the answer genuinely diverges.

Stateless application servers are the easiest thing to run anywhere, which is exactly why placement should follow economics rather than architecture. If your traffic is more or less flat, dedicated capacity is cheaper because you never trigger the elasticity you are paying for. If your traffic multiplies unpredictably, public cloud autoscaling is doing real work by adding computing power in real time, and you should keep it.

Cloud bursting exists for the middle case, and hybrid cloud bursting is one of the few genuinely useful hybrid patterns. Run the baseline on dedicated capacity and scale resources into public cloud resources only when the overflow arrives. Be clear about what this costs you: two environments to configure, two deployment targets to keep in sync, and traffic crossing a network boundary. Teams choose this pattern for the cost profile and then find the operational overhead was the real cost.

Trade-off accepted: flat traffic buys cost efficiency at the expense of headroom. Variable traffic buys headroom at a premium on every steady-state hour.

Object storage vs block storage, and where cloud storage belongs

Placement: follows the data, not the compute. Usually private cloud when files are large and actively used, public object storage when files are large and mostly idle.

The object storage vs block storage distinction matters before placement does. Block storage sits close to compute and behaves like a disk, so it generally follows the workload onto whatever infrastructure that workload runs on. Object storage is addressed over the network and can live somewhere else entirely, which is what makes its placement a real decision.

After that, volume decides very little. The access pattern decides almost everything.

Data that sits still is cheap to store just about anywhere, and cloud storage from AWS, Microsoft Azure or Google with lifecycle policies moving older data to colder tiers is hard to beat on price. Archives. Compliance retention. Rarely-read backup targets.

Data that moves is another matter. Every retrieval crosses a network boundary and may incur transfer cost, and those charges are a consequence of user behavior rather than an architectural choice you can observe. Design teams opening large files. Media pipelines pulling source assets. Analytics jobs scanning object storage repeatedly. Storage cost stays low while transfer cost climbs.

This is the one place our own pricing model changes the arithmetic rather than just competing on it: InMotion Cloud plans carry a fixed egress allowance instead of per-gigabyte metering, which removes the variable that makes this workload hard to forecast. If your files are idle, that is worth nothing to you and public object storage is the cheaper answer.

Pricing discussions also miss a latency dimension. For very large files opened interactively, the time to open is a productivity cost paid by every person on every file, every day. It appears on no invoice.

Trade-off accepted: colocating storage with compute removes transfer cost and latency, but it requires you to provision for peak capacity rather than grow on demand.

Batch processing and analytics: usually public cloud

Placement: public cloud in the majority of cases. Private cloud only at sustained high utilization.

Here the argument runs against dedicated infrastructure most clearly.

Batch work and big data analytics are intermittent by definition. A nightly job, a weekly aggregation, a monthly close. Sizing dedicated hardware for a job that runs two hours means paying for twenty-two idle hours, and the arithmetic rarely recovers. Work that can be scheduled, paused, and retried runs well on public cloud, particularly on interruptible or spot-priced capacity.

One exception is scale and continuity. Once analytics stops being a nightly job and becomes a pipeline running most of the day, utilization rises and the calculation inverts. The other exception is data gravity. If the dataset already resides on private infrastructure, extracting it to process it and returning the results can cost more than the compute saved.

Trade-off accepted: a premium per hour in exchange for not paying for idle hours. A good trade at low utilization, a bad one at high utilization, and the crossover point is worth calculating rather than assuming.

Development and test environments: leave them alone

Placement: leave them where they are. Public cloud handles this workload well and cheaply, and unused capacity on private infrastructure you already own handles it for close to nothing.

Dev and test are defined by low utilization and high churn. Environments spin up, get used during business hours, and sit idle overnight and at weekends. Dedicated hardware for that pattern is hard to justify on its own.

Two things make it justifiable. If you already have private infrastructure for production, dev and test can often run in the headroom you are already paying for, which puts the marginal cost close to zero. And if your development work needs production-like data, keeping sensitive data inside the same compliance boundary is simpler than building separate access control for a second environment.

Absent those two conditions, this is a workload worth actively leaving alone. Migrating it consumes attention and returns very little.

Trade-off accepted: convenience and elasticity against fragmented environments and test infrastructure drifting from production configuration.

Disaster recovery and backup targets: anywhere production isn't

Placement: deliberately not the same place as production. Beyond that, it depends on your recovery objectives.

The first rule of disaster recovery is independence. A target sharing failure domains with production — the same region, the same provider, or the same on premises infrastructure — is not a target. That holds over the long term as both environments drift. Hybrid is the right design here, and one of the few places it is a design rather than an accident.

Recovery objectives set the rest. If you can tolerate hours of recovery time, cold storage in public cloud is cheap and good enough. If you need to fail over in minutes, you need warm or running capacity, which means paying for infrastructure that does nothing most of the time. That cost is the price of the recovery objective, and the business should be setting the objective, not the person sizing the infrastructure.

The line item people underestimate is retrieval. Restoring a large dataset in an emergency generates transfer charges at the worst possible moment, and archival tiers often carry retrieval fees and delays that sound acceptable on paper and turn painful during an actual incident. Test a restore before you assume the cost.

Trade-off accepted: slower recovery for lower standing cost, or faster recovery for higher standing cost. There is no configuration that avoids the choice.

GPU and AI workloads: split training from inference

Placement: split by phase. Training and inference have opposite logic, and mixing them leads to bad decisions.

Training is intermittent, bursty, and often experimental. It fits public cloud, because you want a great deal of capacity briefly and then none at all. Runs fail, get abandoned, and get restarted with different parameters, and owning hardware sized to your largest experiment means owning it through every week you run nothing.

Production inference is almost the opposite. It runs continuously, its load is often predictable, and it is latency-sensitive. That profile favors dedicated capacity for the same reasons production databases do, with the added pressure that GPU hourly rates make idle time expensive faster than CPU rates do.

Utilization is the deciding number, and idle GPU time dominates the economics more than most teams model. A GPU at 20% utilization on dedicated hardware is costing you roughly five times its effective rate. Most teams model the sticker price rather than the utilized price. Work out the second number before choosing.

Sustained inference at scale is also where packaged plans tend to run out of room. If the requirement is specific GPU generations, particular storage profiles, or a network topology built around the serving path, that is a custom infrastructure engagement rather than a plan tier — for us, a Virtual Private Datacenter.

Trade-off accepted: elasticity for experimentation, dedicated capacity for sustained serving. Teams that pick one placement for both phases overpay in one direction or throttle themselves in the other.

Reading the pattern: three variables decide everything above

Placement for every workload above comes down to the same three variables.

Utilization, meaning how much of what you provision you actually use. High and steady favors dedicated capacity. Low or spiky favors consumption billing.

Data gravity, meaning how much data moves and across which boundaries. Data gravity cloud economics is the variable teams model last and regret first. Heavy movement favors coupling storage and compute. Static data can live wherever is cheapest.

Operational capability, meaning what your team can actually run. Managed services are a workaround for expertise you do not have, and no cost model survives running on infrastructure nobody can manage.

Compliance is absent from that list on purpose. It constrains the whole estate rather than individual workloads, and it usually settles your tenancy model before you get to placement. Where it does bite at this level is dev and test, because production-like data drags the control regime along with it.

Hybrid is what happens when different workloads answer these questions differently, which is the normal case, not the exception. Most organizations of any size are already hybrid without having made a choice. The useful work is placing each workload deliberately rather than by chance, then re-checking the placement as utilization changes.

Working through your own estate

Placing seven workload types against three variables is a cloud workload assessment, not a reading exercise. Our Free Migration Assessment is that session — a solutions architect maps your current environment workload by workload and hands back a written placement plan, including the workloads we would tell you to leave on public cloud.

No obligation, and if the answer is that your estate is already placed correctly, that is a useful thing to have in writing.