At a glance:
- Auto-scaling's speed advantage doesn't help if p99 still misses the auction timeout during the provisioning gap. Planning capacity ahead avoids that gap instead of racing to close it.
- Vendor lock-in usually traces back to hyperscaler-specific services already built into the architecture, not to the decision to run on bare metal.
- The support question that actually matters is who picks up a live auction incident and what they know, not which ticket tier you're on.
Five assumptions about bare metal that don’t apply to modern specialty cloud infrastructure
"Bare metal means long procurement lead times that don't fit our deployment schedule."
Five years ago, that was fair. Getting bare metal online meant waiting on hardware orders, facility lead times, and rack provisioning.
Servers.com by Nexcess servers are already racked, connected, and ready to provision across our global network. Provisioning happens through an API or self-service portal in hours, not procurement cycles, for the configurations we keep in inventory, which is most of what an RTB deployment calls for. The deployment model is software-defined: servers are configured with the operating environment and handed over in the same window you'd expect from a cloud instance reservation.
Where the old assumption still holds is genuinely custom hardware: an unusual chip, a nonstandard storage layout, something outside what we stock. That's the exception, not the rule, and worth asking about directly rather than assuming it applies to your deployment.
"Bare metal requires more overhead than cloud, so we'd need a larger ops team."
Physical hardware, network maintenance, and facility operations stay with the infrastructure provider, not your platform team. What your team owns on Servers.com by Nexcess is the same layer it owns on public cloud: OS configuration, application stack, workload management.
Where things differ is self-service tooling. AWS and GCP have years of managed services and ecosystem integrations behind them; Specialty Cloud providers work with a narrower, more focused toolset.
If most of your complexity lives in the application layer, that gap matters less than it sounds. If your platform depends heavily on hyperscaler-managed services, it means being more deliberate about architecture.
"Bare metal can't handle auction traffic peaks the way auto-scaling does."
The scaling difference is real, but the question is whether it matters for this workload. We provision net-new capacity about as quickly as hyperscaler compute spins up virtual instances, but for real-time bidding, the question isn't how fast capacity comes online. It's whether the latency guarantee holds during the peak. A hyperscaler platform that auto-scales quickly but degrades p99 on existing nodes during the provisioning window can still miss auction timeouts.
Dedicated bare metal makes capacity decisions earlier and holds p99 steady throughout the peak instead. Teams plan around modeled peak load rather than reactive scaling, closer to reserved instance planning on a hyperscaler, just without the on-demand option when traffic exceeds the model.
That tradeoff pays off in the moment that matters: a live auction, not a load test. There's no provisioning gap where existing nodes absorb the load while new capacity comes online. Planning ahead costs some forecasting work up front, but it means the platform behaves the same way at 2pm on a normal Tuesday as during the three hours that decide whether a campaign hits its numbers.
"Bare metal locks us into a single vendor and limits architectural flexibility."
Vendor lock-in at the hardware layer is a real concern, worth separating from the portability of everything running on top of it.
The configuration, application stack, and deployment on those servers stay portable, since your team controls the OS image, application build, and network configuration. Moving workloads between bare metal providers or to hyperscaler compute involves the same migration complexity as any infrastructure transition.
What doesn't move is cloud-specific tooling: managed Kubernetes services, proprietary monitoring integrations, serverless functions wired into the data pipeline. If your architecture depends on those, that coupling exists regardless of where the compute runs. Bare metal doesn't add lock-in beyond what those integrations already created.
"Bare metal support means tickets and wait times, not 24/7 incident response."
For RTB, what matters is what support looks like during a live auction incident, not ticket tiers.
Our adtech support runs 24/7/365 with dedicated account management. When p99 spikes, you're talking to infrastructure engineers who understand RTB, not working through general-purpose cloud support until someone has the right context.
The real test: what happens at 3am on a Thursday when that spike hits. How fast does someone who understands the environment get on the call? SLA pricing tiers don't answer that.
The next RTB infrastructure evaluation that rules out bare metal on any of these five points is ruling it out on a five-year-old assumption, not on how the platform performs today.
