AWS S3: Sometimes you should press the $100k button

My theory is that single-platform clouds actually make more sense than trying to be everything for everyone. While the latter can scale to $billions, the former might actually have higher margins because it delivers more value.

An example might be something like a Kubernetes-only cloud driven entirely by Git-ops. Not TFVC, or CVS, or Docker Swarm, or some hybrid of a proprietary cloud and K8s. Literally just a Git repo that materialises Helm charts onto fully managed K8s clusters. That's it.

If you try to do anything similar in, say, Azure, you'll discover that:

Their DevOps pipelines are managed by a completely separate product group and doesn't natively integrate into the platform.

You now have K8s labels and Azure tags.

You now have K8s logging and Azure logging.

You now have K8s namespaces and Azure resource groups.

You now have K8s IAM and Azure IAM.

You now have K8s storage and Azure disks.

Just that kind of duplication of concepts alone can take this one system's complexity to a level where it's impossible for a pure software development team to use without having a dedicated DevOps person!

Azure App Service or AWS Elastic Beanstalk are similarly overly complex, having to bend over backwards to support scenarios like "private network integration". Yeah, that's what developers want to do, carve up subnets and faff around with routing rules! /s

For example, if you deploy a pre-compiled web app to App Service, it'll... compile it again. For compatibility with a framework you aren't using! You need a poorly documented environment variable flag to work around this. There's like a dozen more like this and clocking up so fast.

Developers just want a platform they can push code to and have it run with high availability and disaster recovery provided as-if turning on a tap.

Yeah, heroku is absolutely the best in just getting something running. Truth is most projects don't ever have to scale, either because they are hobby projects, or cause they just fail. Heroku is the simplest platform that I know to just quickly test something. If you do find a good market fit and then need to scale, then sure, use some time to get out of it. But for proof of concepts, rapid iteration, etc. Heroku is awesome.

For every $100k bill there’s a hundred of us with 14TB that costs SFA to roll with.

> The people footgunning themselves with massive bills would just not have a working solution AT ALL.

Sometimes guard rails are a good thing, and the AWS philosophy has very firmly been against guard rails, especially related to spending. The issue has come up here again and again that AWS refuses to add cost limits, even though they are capable of it. Azure copied this limitation. I don't mean that they didn't implement cost limits. They did! The Visual Studio subscriber accounts have cost limits. I mean that they refused to allow anyone to use this feature in PayG accounts.

Let me give you a practical example: If I host a blog on some piece of tin with a wire coming out of it, my $/month is not just predictable, but constant. There's a cap on the outbound bandwidth, and a cap on compute spending. If my blog goes viral, it'll slow down to molasses, but my bank account will remain unmolested. If a DDoS hits it, it'll go down... and then come back up when the script kiddie get bored and move on.

Hosting something like this on even the most efficient cloud-native architecture possible, such as a static site on an S3 bucket or Azure Storage Account is wildly dangerous. There is literally nothing I can do to stop the haemorrhaging if the site goes popular.

Oh... set up some triggers or something... you're about to say, right? The billing portal has a multi-day delay on it! You can bleed $10K per hour and not have a clue that this is going on.

And even if you know... then what? There's no "off" button! Seriously, try looking for "stop" buttons on anything that's not a VM in the public cloud. S3 buckets and Storage Accounts certainly don't have anything like that. At best, you could implement a firewall rule or something, but each and every service has a unique and special way of implementing a "stop bleeding!" button.

I don't have time for this, and I can't wear the risk.

This is why the cloud -- as it is right now -- is just too dangerous for most people. The abstractions it provides aren't just leaky, the hole has razor-sharp edges that has cut the hands of many people that think that it works just like on-prem but simpler.

Each time a developer does something on a cloud platform, that moment the platform might start to profit for two reasons: vendor lock-in and accrued costs in the long term regardless of the unit cost.

Anything limitless/easiest has a higher hidden cost attached.