Network
At a glance:
A data residency requirement on the last page of an enterprise contract triggers a procurement project most engineering teams don't see coming
Colo expansion means facility search, hardware procurement at 8 to 10 week lead times, shipping, racking, cabling, and network architecture
The CFO question is hard to answer: what happens to the hardware if the customer churns
Managed bare metal shifts procurement, facility management, and the CapEx cycle to the provider. Workload configuration and management stay with your team, with shared ownership on infrastructure layers like Kubernetes and network architecture depending on how far you want the provider involved.
At ten customers across ten markets, colo means ten procurement projects. Managed bare metal means ten conversations
Singapore or Tokyo, in-region compute and storage. It’s a hard requirement, flagged early in the negotiation and confirmed before you sign. But between legal, procurement, and the final contract review, the engineering implications don’t land until the ink is dry.
By Thursday, you're mapping out what this means. A colo facility with the right power and connectivity specs, which takes three to four weeks to find, even when you know what you're looking for. Hardware procurement with your usual vendors is currently running 8 to 10 week lead times. Shipping, receiving, racking, cabling. Network architecture to connect the new footprint back without adding the latency you promised not to have.
You put the project at 18 weeks before anyone asks. That's being optimistic.
The CFO's first question is why not cloud, and you've got that answer ready. The egress costs for this workload run significantly higher on cloud than under your current colo model, and you've got the numbers to show it. That conversation still takes three weeks, because the CFO's second question is harder: what happens if this customer churns? The hardware in Singapore is there either way. You can find another APAC customer to backfill it, or you can write it down. You don't have a clean answer for that one. You've got a plan that assumes they stay.
You launch 21 weeks after the contract is signed. The customer waited.
Before the next one came in, someone on the team asked if there was a different way to do this. Not cloud, you'd been through that. Managed bare metal: the hardware belongs to the provider, you provision into their network.
Three weeks of actually running the comparison. What moves to the provider: hardware procurement, facility management, and the CapEx cycle. What stays with your team: workload configuration and management. Kubernetes setup and network architecture sit in the middle. Servers.com handles the hardware-layer networking, including ISP peering and physical infrastructure, and can support Kubernetes at the infrastructure level, but how far that extends depends on how much your team wants to own versus hand off. So, you still own the things that matter for how your workloads run. The procurement cycle is someone else's problem.
The CFO conversation went differently. If a customer churns, you wind down the capacity. No hardware sitting at full cost in a facility you no longer need. No write-down to explain at the next board meeting. If they need a different region next year, same answer.
The first expansion wasn't what mattered. It was thinking about what the second one would look like. And the third.
Every colo expansion is a project: facility search, procurement, hardware lead times, racking and cabling on the other end. Eighteen weeks minimum when things go well. That cost doesn't go down the more you do it; it gets harder once you're running a few in parallel.
Every provisioning decision on managed bare metal is the same conversation: do you have capacity in this market, and how fast? In most cases, the answer is yes, and the timeline may be days or sometimes hours.
By the time you have ten customers across ten markets, colo means ten procurement projects. Managed bare metal means ten conversations. That comparison is worth running before the next contract comes in with a data residency clause.