I don't know that it's about size so much as it's about mix. The biggest, most complicated, most microservices-y organization I ever worked at didn't use conta

I don't know that it's about size so much as it's about mix. The biggest, most complicated, most microservices-y organization I ever worked at didn't use containerization, and didn't want to use containerization. It also had the most smoothly-running system I've ever seen. But they also had a very strictly controlled run-time environment. There was typically only one set of run-time dependencies that was consistent on all servers and in dev. Meaning that all services could be spun up and spun down on any server, without having to worry about fancy wrappers to make sure that they could maintain their own special snowflake needs that were incompatible with everyone else's special snowflake needs. But it also meant that developers couldn't create special snowflake needs, which in turn meant that taking on a new dependency wasn't a simple package manager operation; it involved coordination with operations and perhaps across many product teams. As draconian as it sounds, for the most part everyone there loved it. It was just such an easy place to work, because the whole IT situation was uncannily straightforward and simple and consistent. By contrast, I have also seen a company whose employees I could count on one hand, with a fairly small and tightly focused product, that absolutely needed to be Dockerized. Primarily because every single component was written in a different language, or a different version of the language, or used a different NoSQL datastore, etc. And at that point, with that much mix, you absolutely need some way to layer a consistent abstraction on top of all of it. Otherwise you'll be spending all your time fiddling with environment issues.