Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I really have a love/hate relationship with containers. On the one hand they are entirely self contained, make redundancy simple, and - if used well - are more legible than some adhoc set up procedures.

At the same time, i've seen some horrible decisions made because of them: Redis for things that do not need them. Projects with ~10.000 users (and little potential growth) tripping over themselves to adopt k8 when my desktop could run the workload of 100.000 users just fine. A disregard for backups / restore procedures because redundancy is good enough. "Look I can provision 64 extra servers for my batch job that pre-calculates a table every day".

---

It seems every year fewer teams appreciate how fast modern hardware with a language like Rust or Go can be if you avoid all the overhead.

My standard advice is to use a single container that holds everything. Only after its build and in use can you make the best choice at which angle to scale.

> A complex system that works is invariably found to have evolved from a simple system that worked. - John Gall



Containers help in two ways. First in deployment, if you really have a complex system (and "modern" development practices seem to encourage complexity).

But containers really shine during development if you have more than a few developers working on the same projects. The ability to have a standard dev container for coding and testing saves so much time. And once you have that, deploying with containers is almost free.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: