[dagw]

I believe the real secret reason the cloud is so popular among developers (based on 10+ years of experience) is that cloud providers are so much nicer and faster to deal with than your company IT department.

Also on the price side, I'm not comparing the price of cloud vs colo, but the price of cloud vs what the company IT department charges my department for being allowed to use one of 'their' colo servers, and that is many times what a cloud server costs. (as a real world example, the place I used to work internally invoiced $150/server/month for a virtual server that would cost me $20/server/month on AWS before any discounts).

Cloud lives not by competing against smart people running their own servers, but against inefficient internal IT services, and there they have them beat both on price and quality.

[hotpotamus]

I'm the ops guy on a small dev team, and I run a sort of hybrid setup for prod that does involve me working on hardware in a colo sometimes, though fairly rarely (I'd love to spend about half my time hauling servers around and cabling stuff so that I'm not stuck at a desk all day, but that's not the way it is).

The whole point of my job is to enable developers to deliver code that provides customers value. On that level I actually embrace the common "condescensions" (so-to-speak) that I'm tech support for developers or a YAML wrangler.

I actually had an experience recently where a developer asked to make some changes to our infrastructure. I pretty much developed our container orchestration system (based on Docker Swarm rather than Kubernetes - a choice our architect made that I've come to appreciate), so I walked him through how my IaC works, told him what he needed to change and then reviewed his pull request and applied the changes. I guess we're on a devops journey now if I want to put it in corpo-tech speak.

Anyway, I suppose a lot of IT departments/guys get lost in creating their "perfect" unassailable systems and forget that the big picture is that the job is to enable customers; most directly are likely to be the developers or other internal employees, but ultimately the end customer who's handing you money to solve their problems.

[dalyons]

Also the vast array of managed services. Managed databases, message queues, infinite storage, data warehouses, caches , etc etc. Many of which are very complicated to host well yourself and operationize (failovers, monitoring , backups etc)

This idea that you can build a DC that competes on cost for rented cloud compute - it might be technically true but it’s mostly missing the point of why modern shops prefer the cloud.

[traceroute66]

> Many of which are very complicated to host well yourself and operationize (failovers, monitoring , backups etc)

Oh you are hilarious.

Time for your daily reminder that failovers, monitoring and backups DO NOT EXIST in the cloud UNLESS (a) you configure and manage them (b) deploy your services in multiple zones (and spend $$$$$ along the way).

Lots of people cannot do (a) properly and it is regularly demonstrated by AWS US-East-1 and others that not many people do (b) fully, or in many cases, don't do it at all.

So yeah, the cloud is still "complicated", it's just a different sort of complicated. And if you do failovers, monitoring and backups properly, the cloud is still "expensive", its just a different sort of expensive.

[dalyons]

hey maybe avoid the patronizing crap? I've been involved in running at-scale properties in the cloud and not for 20 years or so now so, whilst i dont know everything i do somewhat know what im talking about.

Making an RDS postgres instance multi-az with automatic failover, and bulletproof backups to s3 is ticking a couple of boxes. Compared to building all of that yourself at the same level of uptime - its not complexity of the same magnitude at all. And sure it will cost you more for the instances for redundancy, but its pretty easily worth it - i dont have to pay an ops team to babysit my databases. Thats just postgres - not even getting into things like aurora, dynamo, kinesis, sqs, lambda - things that either dont have a self-hosted equivalent at all, or if they do are way more complicated to run at scale than PG.

In some cases its trading cloud costs for personnel costs. Both opex. But in many others its having access to services, datastores etc that i couldnt otherwise have as a dev.