Hacker News Reader

Comment by fleddr | Hacker News Reader

I started my career in simpler times. Developers would produce a zip and handed it over to an admin guy. Dev and Infra/Ops clearly separated. No CI, sometimes not even a build step.

I understand the power and flexibility of the cloud but the critical issue is the dependency on super humans. Consider a FE or mobile app developer. They already greatly struggle just to keep up with development in their field. Next, you add this massive toolset on top of it, ever-changing and non-standardized.

A required skillset overload, if you will. Spotify concluded the same internally. They have an army of developers and realized that you can't expect every single one of them to be such "superhuman". They internally built an abstraction on top of these services/tools, to make them more accessible and easy to use.

View on HN

And you're glossing over the pain points that drove the industry to coin DevOps - those times when the zip didn't contain everything it needed to run in production properly and the admin guy had to call the dev multiple times in the middle of the night because their app didn't start properly on deployment. Or the install/startup procedure wasn't documented properly. Or it changed and the document didn't get updated. Or there was a new, required environment variable that didn't get mentioned in documentation anywhere. Or a new, required library was on the dev's local workstation and not on the server. etc etc

Never had such issues, you can still do decent coordination in such hand-overs. Honestly the only issue was the inflexibility of the hardware.

As a former sysadmin who had part of his career in that paradigm, I never again want to wait until 10:30 PM to run manual production deployments handed to me by a developer and hoping their documentation was correct.

Give me CI/CD pipelines deploying containers to a k8s cluster during the day.

> Developers would produce a zip and handed it over to an admin guy

This is literally what the cloud is now for a fraction of the cost of the admin guy.

Current gen serverless containers basically deliver that promise of ease of use, scalability, and low cost.

For me, Google Cloud Run, Azure Container Apps, and AWS App Runner fulfill the promise of the cloud. Literally any dev can start building on these platforms with virtually no specialized knowledge.

https://www.youtube.com/watch?v=GlnEm7JyvyY

And implement them poorly and then wish for an admin guy or SRE when things go sideways at 3AM and production is down.

I'm just not sure how you define what goes into that zip in a way that does not make it substantially harder to solve tough problems than it would be to be familiar with cloud services.

Of course it'll cover you up to a point. If it's a CRUD web app that runs on a single server (or multiple stateless ones) and uses a relational database, you can have a zip file whose contents cover your needs. But if you have anything that justifies Kafka, Cassandra, or distributed storage, the "I'll just throw it over the fence to ops" paradigm isn't likely to fit as well.

I grew up in that era. Where symlinks and sighup to hot reload with zero downtime was an innovation!

Reply on news.ycombinator.com