Which Workload Goes Where: A Placement Guide for Mixed Estates

EDITORIAL GUARDRAIL: Dynascale is a Dell partner, a private cloud provider, and a colocation provider. Never frame owning hardware as the losing option. Dynascale can quote every destination, so the recommendation must follow the workload. Remove this note before publication.

VIDEO PLACEHOLDER: Embed the Week 4 YouTube placement guide video here when its URL is available.

Most infrastructure conversations get framed as one question: cloud or on-prem? It's the wrong shape. Nobody runs one workload, and the answer that's right for a nightly batch job is almost never right for a customer-facing app or a GPU pilot.

The useful question is narrower and you have to ask it repeatedly: for this workload, where does it belong?

There are four honest answers, and each one wins somewhere.

Stay where it is. The workload runs on hardware you own, in a room you control. Cheapest option when the asset is already paid for and still supported.

Colocation. You keep owning the hardware; someone else provides the power, cooling, space, and connectivity. You're buying a building, not a platform.

Private cloud. Dedicated, single-tenant infrastructure that someone else owns and operates. You give up the asset and get back predictable cost and someone else's operations team.

Public cloud. Shared, elastic, metered. Unbeatable when demand is genuinely unpredictable and you want to pay only for what you used.

Most real estates end up using three of the four. The work is sorting, and sorting takes about six questions per workload.

The six questions

What shape is the demand?

Flat and predictable is the strongest argument for owning or for a fixed monthly private cloud line. Genuinely spiky — a quarterly close, a seasonal retail peak, a research burst — is what public cloud elasticity was built for. The trap is "spiky" workloads that are actually just badly sized: if the peak arrives on a schedule you can name, that's predictable demand with a tall peak, and you should price it as such.

How heavy is the data, and which way does it move?

Data gravity decides more placements than anything else. A workload that reads and writes terabytes against a dataset sitting somewhere else will spend its life paying for the round trip. Ask specifically about egress: how much data leaves, how often, and what it costs per gigabyte where it currently lives. On metered platforms, egress is the line that turns a good forecast into a bad one.

What does compliance actually require?

Not what the framework is called — what it requires. Some obligations demand physical custody of the asset or a named, auditable location. Others require single-tenancy but not ownership. Many require neither and are satisfied by controls and documentation. These are three different placements, and teams routinely over-buy because nobody read past the framework name.

What does it need to sit next to?

Latency is a placement constraint disguised as a performance metric. A workload that has to answer a user in the building, or sit microseconds from a database, has a much shorter list of valid homes than one that serves a browser across the country.

What does it draw?

This is the newest question on the list and the one most likely to end a plan. Most enterprise rooms were designed around racks drawing under 10 kW, and plenty were built for 5–15 kW. Current GPU deployments run 20 to 100+ kW per rack, and past roughly 30 kW the conversation moves from floor space to power distribution and liquid cooling. If a workload's power requirement exceeds what your facility can deliver, its placement is already decided — the only remaining question is where it goes instead.

Who operates it, and do they exist?

Every destination assumes an operator. Owning assumes you have engineers for firmware, patching, capacity, and the 2 a.m. call. Public cloud assumes you have cloud operations people, which is a different and often more expensive skill set. Private cloud and colocation move different parts of that burden. Answer honestly, using the team you actually have rather than the one on the org chart.

INLINE CTA PLACEHOLDER: Add the linked 60-Month Decision Worksheet here.

Where common workloads tend to land

Treat this as a starting hypothesis, not a verdict. Your answers to the six questions override it every time.

Core LOB databases and ERP — Owned or private cloud

Steady demand, heavy data gravity, frequent compliance requirements. Rarely a good public cloud candidate — the egress bill is usually the reason.

Virtual desktops — Private cloud, or owned

Predictable peaks that track the working day, and users who notice every millisecond. Owned works when the user population is concentrated in one place.

Development and test — Public cloud

Spiky, ephemeral, low compliance exposure. The clearest public cloud win in most estates, and the one people forget to move because it's already racked.

Backup and DR targets — Private cloud or colocation

Looks like a public cloud fit until the restore. Price the restore, not the storage.

AI training — High-density colo, or GPU-as-a-service

Enormous power draw, bursty utilization, expensive hardware. Buying makes sense when utilization genuinely justifies the asset; otherwise you're funding idle silicon.

AI inference — Private cloud or owned

Steadier than training, latency-sensitive, and often pointed at data you can't move. Belongs close to the data, for the same reasons the database does.

Customer-facing web apps, geographically spread — Public cloud + CDN

Genuinely variable demand and users everywhere. One of the few places we'd say so without hedging.

Legacy apps pinned to old OS or hardware — Hold, or isolate and colocate

Don't let one stubborn application dictate the placement of everything around it. Windows Server 2016 support ends January 12, 2027, which puts a date on a lot of these.

The DR line is the one to keep. Backup and disaster recovery needs geographic separation and cheap capacity, which reads exactly like a public cloud fit. Then you have an actual disaster and pull all of it back at once — and on a metered platform that egress event lands during the worst week of your year, as a bill nobody modeled. Price the restore, not the storage.

Four ways placement goes wrong

Sorting by department instead of by workload

Finance's applications don't share a technical profile just because they share a budget line. Sort by demand shape, data gravity, and compliance — the org chart is not a placement criterion.

Moving the estate instead of the workload

Lift-and-shift to a single destination guarantees that some workloads land somewhere expensive and some land somewhere that can't serve them. The savings from the ones that fit get eaten by the ones that don't.

Pricing storage and forgetting movement

Egress on the DR restore, egress on the analytics job, egress on the migration back out if you change your mind. Every one of those is a real number, and none of them appear on the list price you compared.

Deciding once

Placement decays. Demand shapes change, compliance obligations change, a facility hits its ceiling, a workload triples. Revisit the sort annually and whenever any of those four things move — not only when the hardware reaches end of life.

Where we fit

Dynascale is a Dell partner, a private cloud provider, and a colocation provider. That's a deliberate combination: it means we can quote every destination on this list, so the recommendation follows the workload instead of the thing we happen to sell.

It also means "leave it where it is" is an answer we're able to give, and we give it regularly.

Bring us the sort. We'll price the options over the same window and tell you which workloads are in the wrong place — including the ones that are already exactly where they should be.

PRIMARY CTA PLACEHOLDER: Request a workload placement review →

PRE-PUBLISH SOURCE CHECK: Re-verify rack power figures against Chatsworth, “How much power does an AI rack use?” Re-verify Windows Server 2016 end-of-support date against Microsoft.