By Richard Copeland, CEO, Leaseweb USA (https://www.leaseweb.com/en/)
It’s 9 a.m. on a Tuesday, and your CTO just walked into stand-up with a “small” request:
“We need to spin up an LLM-driven pilot by Friday. Just a proof of concept.”
Everyone in the room knows what that means. You’ll need GPU-heavy servers yesterday. You’ll need isolated environments for testing. You’ll need data compliance nailed down before legal raises a red flag. And you’ll need to do all of it while keeping the existing pipeline moving.
That’s the modern reality for DevOps teams. The pressure to deliver fast, experiment with new technologies, and keep everything stable has never been higher. And the teams that pull it off aren’t doing it by begging for hardware or waiting on procurement – they’re leaning hard on Infrastructure as a Service (IaaS).
The Old Way vs. The New Way
Before IaaS, requests like that AI pilot were almost laughable. Hardware took weeks or months to arrive. Budgets had to be approved. Someone had to rack and stack servers. By the time everything was ready, the business need had already shifted.
Now? You log in, provision GPU nodes, and within hours you’re training models. You can spin up environments for testing, tear them down when you’re done, and scale up when the experiment goes well. That’s the agility DevOps promises – and IaaS is what makes it possible.
Hyperscalers – A Big Part of the Picture
Of course, the big hyperscalers have built much of the modern cloud as we know it. They’ve made it easy to experiment with AI, host applications globally, and access specialized services. For many teams, they’re the obvious first stop.
But anyone who’s run workloads at scale on a hyperscaler knows the caveats. Costs can skyrocket without careful planning. Support often feels impersonal. And when your compliance officer asks exactly where your data is stored, it’s not always a straightforward answer.
This doesn’t mean DevOps teams should avoid hyperscalers. Far from it – they’re invaluable. But they’re not the whole answer, especially as workloads like AI and LLMs push new boundaries.
Where Local IaaS Providers Step In
This is where local IaaS providers play a complementary role. They’re not trying to out-scale hyperscalers; they’re offering things the big guys can’t always deliver.
- Flexibility. Need a custom setup for GPU workloads? Local providers oftentimes can tailor environments without forcing you through red tape.
- Sovereignty. Keeping it in-country is a must, if your AI model is trained on sensitive or regulated data. Local providers give you that assurance.
- Human support. Instead of waiting days for a generic response to a support ticket, you can get a real engineer on the phone who understands your stack.
- Cost efficiency. With more predictable pricing and less overhead, local providers often help teams save money and show ROI faster – something every DevOps lead appreciates when budgets are tight.
- Freedom from lock-in. Local providers usually don’t tie you into proprietary tools or long-term contracts, giving teams the freedom to mix and match infrastructure without being stuck in a single ecosystem.
For DevOps teams, these aren’t luxuries. They’re the difference between meeting that Friday deadline – or explaining to leadership why the AI pilot still isn’t off the ground.
Blending Both Worlds
The smartest organizations aren’t treating this as hyperscalers vs. local providers. They’re using both.
Maybe you run production workloads on a hyperscaler for global scale, but keep customer training data with a local provider to meet regulations. Maybe you experiment with LLM fine-tuning on local GPUs where you can get tailored support, while using the hyperscaler to scale out traffic during a product launch.
It’s not either/or. It’s about building an infrastructure strategy that works for your people, your workloads, and your compliance requirements.
Infrastructure Is Still About People
It’s easy to get caught up in the tech: compute, storage, GPUs, networking. But infrastructure is ultimately about the people using it.
Developers who don’t want to wait weeks for resources. Ops engineers who don’t want to be woken up at 2 a.m. by hardware failures. Data scientists who want to train models without fighting for GPUs. Customers who expect apps to be fast, secure, and always available.
Local IaaS providers add that critical human layer. When you can pick up the phone and talk to someone who actually knows your environment, it builds trust. And trust matters. Especially in DevOps, where speed is everything and mistakes are costly, on every level.
What Next? Asking the Right Questions
You don’t have to ask every provider exactly the same way – each use case is different. However, these questions will expose whether the provider is just selling generic infrastructure, or whether they understand your challenges as a DevOps team.
1. What exact service levels and SLAs do you offer – and what happens when they’re missed?
Ask for uptime guarantees (i.e., “99.9 %”, “99.99 %”) and what credits or remedies do you get if they fail. Also, dig into the fine print. Are SLAs covering all layers (compute, network, storage)?
Is there a catch (e.g. you have to configure things a certain way to qualify)?
This is critical to ensure the infrastructure meets your reliability needs, not just on paper.
2. How do you isolate or protect my workloads from “noisy neighbors”?
Especially in multi-tenant systems, one customer’s heavy usage shouldn’t degrade yours. Ask about how they manage resource contention and hardware overcommitment, as well as performance isolation.
If your provider can explain their approach (for instance, strong hypervisor isolation, dedicated resource pools, CPU pinning, and/or quality of service limits), that’s a good sign.
3. What are the underlying hardware generations (CPU, memory, storage) — and how often is hardware refreshed?
It matters whether you’re running old, inefficient servers or modern, power-efficient ones. Ask which CPU families, NVMe or SSDs, network adaptors, etc., are in use.
Also, find out how often they refresh hardware or how they handle failures. If they rarely refresh, performance may lag over time.
4. How is storage designed – what options do I have, and how do they differ in performance and availability?
Don’t accept “storage is storage.” Ask:
- Do they offer local (attached/NVMe) storage vs network/shared (NFS, SAN, distributed storage)?
- What IOPS and throughput can you expect?
- How do they handle data redundancy, replication, and failover?
- Snapshots, backups, and versioning supported?
A provider that can explain “this type is fast but not highly available; that type is slower but redundant” shows maturity.
5. How do you price network traffic (ingress, egress, private vs public) – and are there surprises?
Network billing is one of the sneakiest cost levers. Ask:
- Is incoming traffic free?
- What’s the cost for outgoing (egress) per gigabyte?
- Do they differentiate between public Internet egress vs internal/private network traffic?
- Are there quotas or overage charges?
You want to understand where your costs might balloon under load.
6. What automation, APIs, and tooling are available, as well as how mature and stable is your integration ecosystem?
Infrastructure without automation is a chore, so ask:
- Tell me about your full-featured API (compute, storage, network, user management)?
- Is infrastructure-as-code (Terraform, Ansible, etc.) supported?
- Are there CLI tools, SDKs, or provisioning templates?
- Tell me about your API stability (versioning, backward compatibility)?
It’s a big advantage if your provider lets you automate entire stacks reliably.
7. How is data sovereignty, compliance, and jurisdiction control ensured?
This is especially important for regulated workloads or data-sensitive industries – you need clarity about:
- In which countries and data centers your data will reside?
- Who has access to the infrastructure (internal staff, third parties)?
- Compliance certifications (ISO, GDPR, SOC, PCI, etc.)?
- Tell me about the process if regulation changes – can you shift/migrate or repatriate data easily?
This is where local providers often shine. Giving you more control and transparency.
8. What is your support model – tell me about response times, escalation paths, and access to engineers.
Support is vital in critical situations. Ask:
- How is support (i.e., tiered, 24/7, business hours, phone, chat, email) structured?
- What are response time SLAs for severity levels?
- Do you get direct access to engineers for urgent issues?
- Is there a “remote hands” or on-site technician service in each data center?
A provider who gives you human, rapid support (not just standard ticketing) is often worth the premium.
9. How do you handle scaling, burst capacity, and variable workloads?
Your infrastructure should adapt to demand. Ask:
- Can I scale automatically (auto-scaling)?
- What limits (quotas) are placed on instances, cores, storage, etc.?
- Can I provision additional capacity quickly, even for GPU or specialized workloads?
- Are there burst pricing models for peak times?
In fast-moving environments, you don’t want to be trapped waiting for provisioning windows.
10. What is your pricing and cost structure – including hidden fees, minimums, discounts, or committed volumes?
Get a full breakdown:
- Hourly vs monthly vs reserved vs spot pricing.
- Are there minimum usage commitments or volume discounts?
- Any setup fees, licensing, management overhead, or support add-ons?
- Pricing transparency (i.e, real-time billing dashboards)?
You want predictability, and the flexibility to experiment without committing too much upfront.
11. How easy is it to migrate out (i.e., avoid lock-in)?
Ask:
- Data export (can I get my VMs, storage snapshots, database dumps, etc., in standard formats)?
- Compatibility (are your APIs or tools standard or proprietary)?
- Contract terms (exit notice periods, penalties, lock-in clauses).
- Any hidden dependencies (e.g. you must use their proprietary control panel or network abstractions).
A provider that makes leaving hard is a provider trying to trap you – not a long-term partner.
12. How do you support new and specialized tech (e.g. GPUs, AI/ML workloads, LLMs)?
If you’re working with AI, you want the provider to support:
- GPU-accelerated instances (which kinds, how many, on-demand or reserved).
- Specialized networking (RDMA, high throughput, low latency).
- High throughput storage with throughput and IOPS for training workloads.
- Flexibility to try experiments, tear them down, and not get stuck with idle hardware.
A provider who is already working with AI / LLM customers and can explain how they support those workloads shows they are forward-looking.
Again… You don’t need to ask every one of these questions. You pick the ones that are most relevant for your use case. The important thing is… When a provider answers confidently, gives clear trade-offs, and backs them with technical detail, that’s a signal you’re dealing with someone who can partner, not just sell boxes.
##
