We're training service experts, not sysadmins anymore

There's a quiet mutation that has been running through our trade for at least a decade, and almost no one calls it by its name. Companies no longer look for sysadmins. They look for Cloud Engineers: people who know how to orchestrate a specific provider's managed services — AWS, Azure, GCP — but who often wouldn't be able to rebuild that same service locally with their own tools. They know how to consume a service. They don't know how to build it.

This isn't an academic nuance. It's a loss of skill with very concrete technical, economic and strategic consequences for whoever has to pay for and maintain that infrastructure over time.

The difference between using a service and understanding a system

A good sysadmin knows the operating system, the network, storage, replication mechanisms, how a database behaves under load, the logic of a load balancer, the difference between an automatic failover and a controlled one. When they have to put a highly available service online, they know why they're doing it a certain way, and they could redo it on different hardware, with different software, from another vendor.

A pure Cloud Engineer, on the other hand, knows a brand's console and API. They know which checkbox to tick to get a replicated database, but they don't necessarily know what happens behind that checkbox. And that's where the problem arises: the moment that checkbox isn't there — because you switch providers, because you go back on-premise, because you need a behavior the managed service doesn't offer — the skill vanishes, because it was never really a sysadmin's skill. It was familiarity with an interface.

The paradox is that the few sysadmins who learned also how to use cloud services now find themselves leading teams that “live and think cloud,” unable to imagine the same result without a managed service packaging it up for them.

Lock-in isn't a side effect: it's the business model

When a company builds on top of a provider's proprietary services, it isn't just choosing a technology. It's signing a commitment. The more you use specific, integrated services — the serverless database, the managed queue, the function as a service, managed authentication — the more your code and your architecture mold themselves around that provider. The day you want to switch, you don't “move” the application: you rewrite it, in part or in full.

That's exactly the effect intended by whoever sells the service. And you can see it clearly in one cost line almost no one looks at when making the choice: outbound traffic.

Getting data out of a large hyperscaler costs on the order of $90/TB of egress. On a European bare-metal provider the same traffic, within the included allowances, costs €0, and beyond the threshold roughly €1/TB. A difference of up to 90 times. It's not a detail: it's the rope that keeps you tied. Migrating costs money, and it costs that way on purpose.

When the cloud is genuinely the answer (and when it isn't)

Let's be clear: this is not an anti-cloud article. A cloud infrastructure designed and configured properly offers very high availability and efficient disaster recovery that is objectively harder to achieve in-house. For certain workloads — unpredictable spikes, multi-region geographic presence, real elastic scalability — the cloud is the right answer.

The point is something else: not all services need the cloud, and almost none need a managed service from the cloud. Database as a service, ephemeral caches, container orchestration, message queues: too often they're chosen as a “turnkey” service not because it's the best solution for that specific case, but because the company lacks the person capable of building it. You buy the service to make up for a missing skill, not as a considered architectural choice.

My position is clear-cut: if I can build a MongoDB cluster by hand, I will always do so instead of taking the managed service. Not out of ideology, but because control, portability and cost justify it — provided you have the skill to do it well. And there are plenty of examples: Postgres in streaming replication, Redis Sentinel, a self-managed Kubernetes orchestration, an S3-compatible object storage on-premise.

With the numbers: a MongoDB cluster

Let's take a real case and put the numbers on the table. All figures are indicative, list price, VAT excluded, and vary by region and configuration — but the order of magnitude holds.

Option A — Managed service (MongoDB Atlas, M30 tier)

An M30 offers 8 GB of RAM, ~2 vCPUs, 40 GB of storage and includes a 3-node replica set.

→ About €5,500 a year, for a single cluster, with 8 GB RAM nodes.

Option B — Service built in-house (Hetzner bare-metal)

Three dedicated AX42 servers, each with an 8-core CPU, 64 GB of RAM and 2×512 GB NVMe in RAID 1, configured by hand as a MongoDB replica set.

→ About €1,760 a year, with 64 GB RAM nodes — eight times the RAM of the M30, at a third of the cost.

The delta: ~€460 against ~€147 a month means roughly €3,700–4,000 saved per year on a single service, with vastly more capacious hardware to boot. And here's the real point: a company doesn't have one service. It has five, eight, ten. Multiply that delta and you easily reach €20,000–30,000 a year in difference.

The cost you don't see: skill

At this point the managed-cloud advocate has their argument ready, and it's a serious one: “Sure, but bare-metal doesn't manage itself.” True. And honestly, it has to be said.

The managed service costs more because it sells you time and operational risk: no OS patching, no replica set configuration, no hardening, no failover testing, no monitoring to build, no nights up when a node goes down. You do everything from a web interface. For a team without deep sysadmin skills, it's often the only sensible choice — and the day the good sysadmin leaves, the company that did everything in-house is left exposed. The bus factor is a real cost.

The service built in-house costs significantly less in infrastructure, but it requires someone who can operate across multiple domains: OS, networking, security, databases, backups, observability. And here the math closes on the staffing side too.

The final economic paradox is this: the company that goes all-in on managed services spends more on infrastructure and can get by with a Cloud Engineer who costs relatively less (but ties it to the provider). The company that builds in-house spends far less on infrastructure, but has to hire a sysadmin skilled across multiple fronts — a rarer figure and, if genuinely good, more expensive.

And it's on the cumulative total that the scale tips: if the €20,000–30,000 a year saved on infrastructure covers and exceeds the incremental cost of a good sysadmin over a pure cloud engineer, the “in-house” choice isn't just cheaper. It's also the one that keeps a skill in the company that stays, independent of a vendor's price list.

Wrapping up

The enemy isn't the cloud. The enemy is the loss of the fundamentals. We're training a generation of technicians who know how to switch a service on but don't know what they're switching on, and that makes us — as an industry and as individual companies — more fragile, more tied down and, in the long run, more expensive.

The cloud should be used because it's the right choice, not because it's the only solution we have or the most fashionable one. And to be able to truly choose, you need someone in the company who still knows how to build things with their own hands. That someone, today, is worth more than their salary suggests.

Luca Vitali