Operations | Monitoring | ITSM | DevOps | Cloud

I have an Upsun project that's nothing but proofs of concept. It's a dashboard, basically. Each POC gets its own tile. Click in, and you land on a page with three tabs. The first tab is a written explanation of what the POC argues. The second tab is the POC itself, with a built-in demo that automates a walkthrough of the feature so the recipient can watch it run without me on the call.

I keep hearing the phrase "code is cheap." I don't know who came up with it. Whoever it was clearly has not seen an Anthropic bill. I get what they mean. The cost of writing a line of code has cratered, AI does most of the typing, you know the rest. Fine. But the phrase is combative in a way that doesn't help anyone, especially the engineers in the room. "Code is accessible" lands better. Less swagger, more honesty. Either way, here's the line my friend Guillaume gave me that finally cracked it open.

IT leaders rarely think they have an infrastructure problem. When a roadmap slips or an audit finding lands, the reflex is to hire more senior engineers, a bigger platform team, another DevOps lead. But headcount is rarely the real lever. The bottleneck is the "hidden factory": the undocumented, invisible work that sits between a developer writing code and that code reaching customers. It doesn't show up in post-mortems because engineers treat the workarounds as normal.

The video was a product manager who claimed she worked at Netflix. (Her claim, not mine. I have no way of verifying it, and I can’t find the video now.) She was talking about how Netflix now requires every PM to vibe code a working prototype before presenting an idea to engineering. Show, don't spec. Build the thing first. I sat there for about ten seconds being mildly annoyed.

If your infrastructure is configured outside version control through dashboards, scripts, or manual steps, environment drift is the expected outcome. Most teams have lived this scenario. A feature works in staging but breaks in production. Two hours later, someone finds a configuration setting that was changed in staging three weeks ago and never documented.

Security audits that focus only on application code often miss the delivery layer entirely. That is where the most common and most avoidable failures live. Most teams treat security as a layer added on top of a working system. The problem is that the delivery model itself introduces risk before a single line of application code runs. When deployments are manual, environments are inconsistent, or configuration drifts across stages, the system behaves unpredictably.

Cloud hosting is not invisible. Every project deployed, every resource provisioned, every region selected carries a real energy cost, and that energy cost has a climate cost. At Upsun, we've known this for a while. What we're sharing today is where we stand, what we measured, and what we've committed to doing differently from 2026 onwards. Our ambition is calibrated to what we can credibly deliver, and we think being upfront about that matters more than overpromising.

Most engineering teams underestimate the time infrastructure demands from them. The hidden cost isn't in provisioning, it's in the accumulated friction of environment drift, manual handoffs, and repetitive infrastructure maintenance that quietly consumes hours your team should be spending on product.

True data sovereignty isn't about managing your own cloud accounts; it’s about where your data resides and how it is governed. By utilizing a unified configuration file to deploy on sovereign infrastructure like OVHcloud, Upsun provides standardized sovereignty without the complexity of “Bring Your Own Cloud”.

Having workloads on two clouds is not the same as being able to move workloads between them freely. Portability is about the friction of movement, not the number of providers in use. Most teams that call themselves multicloud are not portable. They have separate workloads siloed on separate providers, each with its own toolchain, deployment pipeline, and set of operational conventions. Moving anything between those environments means starting from scratch. That is not portability.