At Edgescale, we’re engineering the infrastructure that brings artificial intelligence into the real world. Our work powers AI in the places that keep society running — manufacturing floors, hospitals, utilities, transportation networks, and more. By bridging the gap between the cloud and the physical edge, we enable real-time intelligence where humans and machines work together.
Many of our initial Physical AI Infrastructure conversations start the same way, with someone asking: “Why can’t we just build this ourselves?”
It’s a fair question, since Dell will sell you a server, Red Hat will sell you OpenShift, NVIDIA will sell you a GPU, etc. Then, there’s an open-source project for many of the other layers needed. On paper, it looks like a shopping list – so I understand why many people assume that, if they only had the right ingredients, they could make this work themselves.
In practice, though, the DIY approach always becomes a complex science project – and it’s the reason roughly 90% of physical AI pilots never reach production, stuck in what the WEF and McKinsey call “pilot purgatory” for 18 to 24 months, before sputtering out.
I sat down with Marc Rouanne, our co-founder and CTO, to walk through exactly what “doing it yourself” actually requires. Marc spent three decades in networks and infrastructure before Edgescale – as Chief Network Officer at DISH, plus two decades at Nokia, with teams in the tens of thousands of engineers. If anyone has earned the right to say “don’t do this yourself,” it’s someone who tried, with more people and more budget than most teams will ever have.
What follows is that breakdown, layer by layer. My intention here isn’t to scare you – it’s simply to help shed light on the complexity that we’ve seen many organizations already run into when trying a DIY approach, leading to multi-year (and often, failed) pilots.
Layer one: you have to build the appliance before you can build anything on it
Most people think they can get started by simply “buying a server” – but it’s not that simple.
Once you’ve picked a server, you still have to select memory, add protection and recovery, choose a GPU type, and wire in connectivity – and none of that comes pre-integrated. As Marc put it, GPU compute historically hasn’t shipped integrated with high-throughput data connectivity or autonomous recovery at the edge. So, you’re not just buying a server – you’re building an edge appliance from parts that were never designed to work together, and every one of those parts requires its own evaluation, its own vendor negotiation, and becomes its own point of failure.
Layer two: the firmware problem nobody budgets for
Below the operating system sits the layer most software teams never think about: firmware. The UEFI – the modern equivalent of BIOS – runs into the tens of millions of lines of code. Before you’ve written a line of your own application, you’re testing memory timing, PCI lane allocation, GPU-to-CPU bandwidth, and clock behavior at the firmware level.
This is the layer where “it should just work” goes to die. It’s also the layer where you discover you need a dedicated hardware team, separate from your architecture team, separate from your purchasing team – because none of those three groups speaks the other’s language, and all three have to sign off before you have a machine that’s actually ready to run anything.
Layer three: choosing – and living with – your orchestration layer
Assuming you clear layer two, now you need an architecture: a Kubernetes distribution to run containers at the edge. There isn’t one obvious answer. Some distributions are open-source and lightweight. Some are heavy and full-featured. Some are cloud-managed and compatible with EKS or Anthos; some are deliberately disconnected from any cloud control plane. There are a dozen credible options, each with real tradeoffs.
Selecting the right one, for real workloads at the edge, is not a weekend evaluation. It took our own team roughly a year to make this decision correctly – and that’s with the benefit of having done comparable infrastructure work before, at telco scale.
Layer four: the compatibility problem hiding under the architecture problem
Picking a Kubernetes distribution doesn’t finish the architecture question – it just reveals the next one. The hardware layer and the application layer are never 100% compatible out of the box. If you need real-time data manifold capabilities, you need real-time pinning support in your software stack, and you need your hypervisor to actually expose the resources your applications require.
This is a genuinely hard problem. Dell doesn’t fully solve it – they acquired VMware to try, then walked away. Red Hat’s OpenShift solves it to a point, but not for domain-specific workloads. Which brings up the next question nobody asks until they’re already committed: how many cameras (or insert any of thousands of types of devices or peripherals here) can your stack actually support in parallel, at what streaming bitrate, on what network, without saturating your CPU? That’s not a hardware question or a software question. It’s the combination of both, plus the application on top – and almost nobody has mastered all three at once.
Layer five: security becomes its own department
Data center security is a solved problem: they have the benefit of being able to use locks, badges, and guards. Edge security is a whole other ballgame. The moment your appliance leaves the data center, you need role-based access control, and you need it designed for what is, in practice, a hostile environment – a machine sitting unguarded in a facility, exposed to a threat model data center teams have never had to think about.
Worse, the skill sets don’t transfer. People who understand hardware generally don’t understand security. People who understand IT security generally don’t understand Ethernet security or 5G security. You need an entirely separate practice – identity, access control, and network security purpose-built for exposed, physical, distributed hardware – and you need it before you can say the appliance is production-ready.
Layer six: connectivity is its own department, too
Once security is handled, connectivity becomes the next standalone discipline. Real deployments span Wi-Fi, Ethernet, cellular, and satellite – often at the same site, sometimes on the same appliance – and each medium has its own latency, jitter, and reliability profile.
The people who understand Ethernet and LAN, the people who understand Wi-Fi, the people who understand cellular, and the people who understand satellite are, in Marc’s decades of telco experience, rarely the same people, and rarely people who work well together. Very few vendors have solved multi-medium fusion at the connectivity layer. You’re not choosing a connectivity vendor – you’re assembling a connectivity team.
And once it’s live, you inherit a subtler problem: a control system built for the data center will assume a machine that’s gone quiet is dead. At the edge, quiet often just means the connection dropped and the appliance is still doing its job. If your monitoring can’t tell the difference, it starts killing healthy machines the moment they reconnect – which is, as Marc described it, the operational equivalent of “friendly fire” against things that should be trusted.
Layer seven: now you have to deploy and update software across all of it
Software deployment is yet another layer where cloud-native assumptions fall apart. The cloud won in large part because deployment is the same for everyone, everywhere. At the edge, it isn’t (at all). Every site is different, every stack is a slightly different combination of vendors, and there’s no shared deployment substrate underneath it the way there is in a hyperscaler’s data center.
Without an automated CI/CD pipeline built specifically for this diversity, you’re dealing with what Marc calls “the famous Homebrew problem” – it’s fine for updating one personal machine, but totally unusable for a mission-critical fleet. Once you’re running ten to fifteen applications from different vendors on a single appliance, each with its own patch cadence, you run into a much more basic question: who’s the boss? Who decides when the next release goes out? Who tests backward compatibility? Do you even have a notion of production versus pre-production – and the lab environment and process required to test the difference?
Layer eight: release management at scale is a different problem than release management for one machine
Assume you clear layer seven for a single site. Managing releases for one integrated system is hard enough. Managing the update graph for ten to fifteen separately-sourced software components – each with independent release cycles, dependencies, and breaking changes – creates a compounding complexity problem. It will break. Even the biggest cloud providers, with all their testing infrastructure, break production from time to time. You will too – the only question is whether you have the release management discipline to make that a minor incident or a major one.
Layer nine: observability and triage across a stack nobody centrally owns
Now assume the system is live and something goes wrong. In the cloud, or in a lab, this is fairly straightforward – you have logs, you have a controlled environment, you have observability tooling built for exactly this. At the edge, once your appliance is out in the field, you need your own log correlation and root-cause analysis across every vendor in the stack, because none of those vendors built their tooling to talk to each other.
Telecom operators call this triage, and it typically takes an army of specialists – often dozens, sometimes hundreds of engineers inside a single operator – to correlate a fault across hardware, connectivity, and software from different vendors. You can’t call your connectivity vendor and ask them to diagnose a memory problem. Somebody on your team has to know enough about every layer to know whose problem it actually is before you can even open a ticket with the right vendor.
Layer ten: reproducing the problem (and having somewhere to reproduce it)
Once you have a working theory of what broke, you need to reproduce it – which means a lab, or a digital twin of the deployed environment, and a channel to every vendor in your stack for patches and support. That’s straightforward the first time. It becomes exponentially harder once you’ve scaled from one site to a hundred, each running a slightly different configuration.
Layer eleven: the control plane you didn’t know you’d have to build
At real scale, you need a centralized control plane: a place to understand what’s happening across every site, track KPIs, manage root-cause analysis, and coordinate security and upgrades for every piece of software in the stack. In practice, this means you need a NOC and a SOC – a network operations center and a security operations center. At that point, you haven’t just built AI infrastructure. You’ve built and staffed your own managed service provider, for infrastructure that was only ever supposed to be a means to an end.
Layer twelve: and none of this touches the application layer yet
Every layer we’ve covered so far is infrastructure. You haven’t touched the application yet – the actual AI use case you set out to build in the first place.
For that, you need a computer vision specialist. You need someone fluent in Modbus for talking to industrial equipment. You need someone who understands MQTT. You need a Kafka specialist – and then you need to decide whether you’re running open-source Kafka or Confluent, a decision that itself demands months of lab validation before you trust it in production. Every one of these is a distinct hiring problem, and most organizations that think they can build this themselves have budgeted for approximately none of them.
Layer thirteen: the systems integrator tax
Most organizations that get this far bring in a systems integrator to close the gap. That doesn’t remove the complexity – it adds a translation layer on top of it. You still have to explain, in exhaustive technical detail, exactly what you want built, because the SI doesn’t know your environment. Writing that specification well enough for an SI to execute against is, by itself, routinely a six-month project – before a single dollar goes toward the actual implementation.
Layer fourteen: why headcount doesn’t solve this
The instinctive response to all of the above is to throw people at it. Marc’s viewpoint, from direct experience, is blunt: it doesn’t work. He had roughly 25,000 engineers at Nokia and couldn’t get this right. He had a $10 billion purchasing envelope at DISH, with access to every major supplier, and still couldn’t do it. Past a certain point, adding people doesn’t add capacity – it adds coordination overhead, and productivity per person goes down.
What changed, in his words, isn’t that the team got smarter. It’s that AI-native teams – engineers working with agents that code and test continuously – can now move at close to the speed of a thousand people. Without that AI factory underneath you, doing the coding, the testing, and the verification at machine speed, this isn’t a hiring problem you can staff your way out of. It’s a category of problem that didn’t have a solution before AI-native development existed.
Layer fifteen: and then you do it all again, at every single site
Here’s the part where even the most successful teams tend to fall apart. Assuming your team has cleared every layer above – hardware, firmware, orchestration, compatibility, security, connectivity, CI/CD, release management, observability, triage, control plane, application specialists, the SI, and the org chart required to hold it all together – it still only works at one site.
Now you need to re-create it all at your second site. And your tenth. And your hundredth.
None of the work above is a one-time cost. It’s a per-site cost, because every site has different equipment, different network conditions, different vendor mixes, and different failure modes. The complexity we just walked through doesn’t amortize – it repeats and compounds. That’s the difference between an edge deployment and an edge platform: a platform is the thing that lets complexity flatten out as you scale. Without one, scale is just the same fourteen layers of pain, multiplied by your site count.
Why we built Edgescale as the antithesis to the DIY approach
We didn’t write this breakdown to make anyone feel bad about wanting to build their own stack. We wrote it because Marc and Brian have lived every layer of it – at Nokia and at DISH – across careers spent building and operating physical infrastructure at a scale most companies never approach. They didn’t found Edgescale because DIY was theoretically hard. They founded it because they’d personally tried to solve this exact problem with more engineers and more budget than most orgs will ever have, and it still didn’t work without a fundamentally different approach.
Edgescale is that approach: one integrated, sovereign Physical AI Infrastructure solution – the Cube – that replaces all fourteen layers above with a single decision. Hardware, firmware, orchestration, security, connectivity, release management, observability, and the application layer arrive pre-validated, as one system, not as fourteen procurement decisions you have to make and then integrate yourself. There’s no software subscription to negotiate for each layer. There’s one appliance, and it works – at global scale.
The difference shows up immediately in the numbers. A DIY, SI-led Physical AI platform build runs on the order of $12 million per generation, with cost and schedule variance of plus or minus 50%, and takes 18 to 24 months to reach production – if it gets there at all. The Cube is online in 15 minutes and in full production within weeks, at roughly 60 to 80% lower total cost of ownership than building it yourself. Your data stays sovereign, on-premise, by design – not as a policy someone has to enforce, but as an architectural fact.
And the fifteenth layer – the one where all your DIY complexity resets at every new site – is perhaps where the Cube shines the most. The Cube is designed to scale horizontally, from one site to hundreds or thousands, with zero per-site engineering and zero local IT involvement. The same appliance that comes online at your first location comes online the same way at your thousandth. The complexity doesn’t repeat, because there’s no complexity left to repeat – just an appliance, doing the same job, everywhere it’s deployed.
The question is not whether a good enough team can eventually build all of this. Given enough time and enough money, probably (though Marc would reiterate that he tried, with 25,000 engineers and billions of dollars at his disposal – and it didn’t work). The real question is why you’d spend two years and eight figures rebuilding, from scratch, infrastructure that already exists, works, and scales – especially when the fifteenth layer, the one that breaks most DIY efforts, is the one problem Edgescale was built to solve first.
Regardless of where your team is at in the journey – whether you’re just starting your evaluation of Physical AI solutions, or you’ve already spent months/years bringing a pilot online – Edgescale (and our partner ecosystem of NVIDIA, Red Hat, Palantir, Hitachi, and more) can help. We’re staunchly against the rip-and-replace of systems you have in place that are already working, and we seamlessly integrate with all your existing systems, devices, and data.