[urza]

Wau thanks, that is an excellent explanation. I appreciate that it start with things I know and understand ("so you build a web app"/"bash scripts"/"puppet") and builds on that explaining what problems each consecutive steps /layer of abstraction/ solves.

Now I wonder.. how many projects actually needs these kind of solution when even StackOverflow can do without it (they are in the range of few servers)? I would imagine it would be only few top popular web apps/services, but by popularity of these posts it looks like it is probably a lot more...

[bkanber]

How many people actually need it? Nobody! We managed to run servers for years without containers or orchestration tools. Docker is a new technology.

Does it make things better, though? Yes. Yes it does.

Kubernetes was designed at Google where they reaaaaally feel their scale problems day to day.

I see Docker/Kube/CoreOS/ etc as the natural evolution of where we were already going. Bash -> puppet -> vagrant -> docker -> kubernetes. Less abstract to more abstract.

So it's actually "only" an incremental evolution in terms of managing the server ecosystem. But it's a revolutionary improvement in how we think about server ecosystems, which is why many people struggle with Docker et al at first; it's a brand new mental model.

[ecnahc515]

I'd like to add that this isn't necessarily even about huge scale. It's about scaling deployment patterns too, which is different than scaling services.

Sometimes you need to have the ability to run more services when your "web-scale", but even if you're not at that point, scaling how you deploy new versions, and new services is still important.

Tools like docker, and Kubernetes really help with the application delivery aspect, and really enable you to rapidly iterate on your project.

You might have a site with 100-1000 users, not huge by any means, and 1 server could probably handle all of your needs. But once you start adding other components, perhaps redis, or a runtime like nodejs, those can all be managed, but if you need to rapidly iterate, something like Kubernetes/docker can make updating or deploying these easier in the long run.

[abledon]

Very few actually need them, but many companies have scale-envy and instead of getting bored with their tech stacks, stay inspired/passionate by playing with the shiny new tech running their low/medium traffic website.

[clay_to_n]

In addition to bkanber's comment, this technology is helpful sooner if you're using a microservices architecture, where you have very many small servers instead of a few beefy ones. Instead of "Time to spin up a new box" it might be "Time to spin up 3 box A's, 2 box B's, and a box C, D, and E...".

[marktangotango]

I think it's clear that the vast majority of profitable businesses, online or off, don't need the scale these services provide. But providers to these business can benefit from the scale to provide better, cheaper services. For example, the resurgence of the Static Web: ie site generators (ie Jekyll) and vendors offering hosting for these services (ie bitballoon, netlify, aerobatic, neocities, etc...).

Really, why should cost anything to have basic, low-traffic, site on the internet today? That's the quetion I ask myself.

[blitzd]

Containerization on it's own can have benefits even in smaller deployments - separating your different server concerns to the bare minimum can be very useful.

There's also other aspects, like being able to spin up the newest PostgreSQL within minutes, and when you're done you rm the container and image and have no trace and/or side effects.

There's some pretty useful multi-container configurations out there too, like a dockerized gitlab environment: https://github.com/sameersbn/docker-gitlab

[singham]

I think stackoverflow.com is not a correct example. Because most of data on stackoverflow.com is static.

[velox_io]

True, although I'd say most users are logged in, so that does make caching much harder.

stackoverflow is just a nice example that you don't need dozens of servers, even when you reach their scale.

I do believe Brook's The Mythical Man-Month does also applies to computers. In that communication overhead soon outweighs the benefits of adding more computer nodes.