Hacker News Reader

Comment by ibash | Hacker News Reader

Performance in the report is defined by how fast you can make a change to production, and how fast you can restore service.

That’s fine I guess.

What’s not taken into account is the time wasted on incidental complexity with devops tools.

For example a highly competent engineer I know is burning hours trying to get ssl working on k8s/gcp with a specific configuration.

Conceptually ssl is all straightforward, but there’s some arcane knowledge that’s been designed into k8s and gcp. Because they were designed for way more complex use cases… but they’ve also pushed out simpler tools.

View on HN

hitting this paradox a lot with containerisation.

Spent a good bit of effort building everything into a fully containerised stack, thinking once we got through the hard parts of it, everyone would be more productive and new devs would get up to speed fast. But it's not like that. We just have a whole different set of complexities, mainly at all the container boundaries where ports, volumes, user ids, file permissions, file paths etc now create issues where before they didn't.

I think we probably came out with a modest win, but I'm not sure it beat out what we might have achieved with the same effort going to other productivity measures.

I can’t speak to your experience, but often times I’ve run into this in development teams where there was not a strong level of systems knowledge or not a very strong understanding of exactly what an application needs to run.

Perhaps one of the more amusing issues I’ve seen was someone’s surprise that a temp directory creation put the files in /tmp instead of the application’s working directory. It’s not something a lot of people would think about in development/testing I suppose.

More often than not, containerization has seemed to force developers to better understand the impacts of their code on the system.

And when you choose badly the cloud platform that looked good at start. But later becomes complete pain... Always finding new amazing ways to break things... (looking at you Azure Container Instances)

In the end for some light work loads could have been just thrown on VMs already running for other reasons. And it would have saved lot of time and effort... And it could have still be deployed with some level of devops...

What would you use instead of ACI?

Not sure, in this case of workload with very low load a VM I think...

Reply on news.ycombinator.com