Everyone Ships One Container. The Shop Floor Runs Ten Platforms.

If you have spent any time evaluating industrial IoT and edge platforms, you have heard the same pitch, and it is a good pitch: we ship one container to your device. One small, purpose-built workload lands on the edge box, does its job, and reports back. It is a clean story — and, to be clear from the outset, a correct one. A minimal deployment footprint is a real engineering virtue. The vendors telling it are not being lazy or evasive. They are optimizing exactly the thing they own — and doing it well.

The problem is not the container. The problem is what happens when you stand on the shop floor and count.

The local optimum is real, and it is reasonable#

Take a typical edge platform and look at what it actually asks the device to run. It is genuinely modest. One container to ingest data from the line. One to manage the network path back to the cloud. One per sensor stream — sensor A, sensor B — because each stream has its own protocol and cadence. Maybe one for a soft-PLC if the platform reaches into control. From the vendor’s side of the table, this is the whole deployment. Four or five small containers, each doing one legible thing.

Every design pressure on that vendor points the same way: make the footprint smaller, make it start faster, make it survive a reboot without a truck roll. “Just one container” is the shorthand for a whole discipline of restraint, and it is worth respecting. Each vendor is standing at a local optimum, and from where they stand, it is the right place to be.

The trouble is that the local optimum is computed against a single workload — theirs. And no real plant runs a single workload.

The shop floor is where the optima sum#

A production line does not buy from one vendor. It buys condition monitoring from one, energy metering from another, a vision system from a third, an MES connector from a fourth. Each arrives with its elegant, minimal container. And each container arrives holding hands with everything required to operate it.

That is the part the deployment story quietly omits. A container is not a self-sufficient thing on an industrial floor. Behind vendor A’s one container sits vendor A’s cloud tenant, vendor A’s fleet or edge manager, vendor A’s device-onboarding and identity model, vendor A’s update mechanism, and vendor A’s inbound security surface. Then vendor B shows up with the same vertical stack. Then C. Then, before anyone has drawn the picture, ten of them.

The unit that multiplied was never the container. It was the management plane each container drags behind it. Ten “single” containers become ten parallel vertical stacks — ten clouds to trust, ten fleet managers to log into, ten onboarding flows to run per new device, ten update cadences to reconcile, ten inbound paths to defend. The device is fine; it can run the containers. The organization is now operating ten platforms to get ten small jobs done.

Name the real cost precisely#

Here is the reframe I want the shop-floor owner to make. Stop asking vendors “how small is your container?” It is a fair question, but it optimizes something that was already cheap. Start asking: how many management planes am I now running, and who patches each one?

That question surfaces the cost that actually accrues. Every added plane is another cloud dependency you inherit. Another agent that has to stay on a supported kernel or it becomes a liability. Another identity and inbound surface for your OT security team to reason about. Another vendor whose pricing changes and end-of-life decisions land on your line whether you planned for them or not.

The economics bear this out, and they are not subtle. As I laid out in SDIE Part 2 — Open by Standard, a production line’s fully loaded edge deployment lands somewhere in the $10,000–$50,000 range, and hardware is under 10% of that. The dominant costs are integration, licensing, and engineering time. Those are precisely the costs a management plane consumes. So when a tenth vertical stack arrives, the small container is not what moved the number — the tenth cloud dependency, the tenth onboarding integration, the tenth thing to patch is what moved it. The floor’s real budget is a management-plane budget, and every “just one container” quietly draws against it.

The tempting conclusion — consolidate down to one vendor, one throat to choke — is the wrong one, and most operators know it. You do not want a monoculture on the factory floor any more than you want ten silos. Best-of-breed exists for good reasons; the vision vendor really is better at vision than the metering vendor would be.

The resolution is not fewer vendors. It is an open interoperability standard at the deployment layer, so that every vendor can keep shipping their one container while the container lands on shared edge infrastructure. That is exactly what Margo is — a Linux Foundation interoperability standard, launched in April 2024, for how workloads are described, delivered, and reconciled on industrial edge devices. It is worth repeating the framing from that post: Margo is a standard, not a product. Nobody sells you Margo. Vendors and operators implement it.

Concretely, it means one shared spine underneath all ten vendors: one Workload Fleet Manager (WFM) that the whole fleet reconciles against, one lightweight Margo agent per device, one pull-based desired-state loop where each device’s agent reaches out over outbound HTTPS and reconciles toward its target — brokerless, no inbound listener to expose — a shared OCI registry every vendor publishes their container to, and one device fleet the operator actually manages. The application logic stays oblivious to the orchestration. The orchestration stays oblivious to the vendor. Vendor A’s container does not know or care that vendor B’s container is reconciling through the same WFM two cgroups over.

What I like about this is that it is genuinely win-win, not a concession one side makes to the other. The vendor no longer has to build and operate an entire cloud plus edge manager just to hand a customer one container — that is real cost and real headcount they can stop carrying. And the operator runs one management plane instead of ten. Both sides come out ahead of where the ten-silo status quo leaves them. That is a rare shape for an industry problem, and it is the reason the deployment layer is the right place to standardize.

From the floor, your container is the tenth platform#

I am writing this fresh from a recent Margo plugfest, and the theme customers kept returning to was not a feature or a benchmark. It was relief — the first concrete sight of a path to a single platform that can host every vendor’s container, instead of a rack of parallel ones. Multi-vendor interoperability is not a whiteboard aspiration here; the community has shown it working in practice, containers from different vendors reconciling on shared infrastructure in the same demo. Customer obsession, it turns out, points straight at interoperability.

So this is a collegial nudge to the vendors and platform builders reading, and I mean it as one professional to another: your single container really is elegant, and you should keep it that way. But from the shop floor, it is the operator’s tenth platform — and they feel the tenth management plane far more than they feel your tenth container. Start your design from the floor’s management-plane budget, not from your own footprint. Ship the container; let it land on shared infrastructure. You lower your own cost to deliver, and you stop asking your customer to run one more cloud. That reframing — from how small is my container to how few planes does the floor run — is the whole point, and there is room in it for all of us.