4 ms·

So...this all seems insanely complicated. Is there any kind of rough guidance about how "big" an organization or codebase needs to be before it becomes a net wi

by defen 7y ago

So...this all seems insanely complicated. Is there any kind of rough guidance about how "big" an organization or codebase needs to be before it becomes a net win to go down this path? Either in terms of lines of code or number of services or requests served or servers needed or any other kind of metric? Obviously the breakeven point is somewhere between "CRUD app that runs for free in Heroku" and "millions of requests served per second" but I don't know where it is.

bunderbunder 7y ago
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.
danbeaulieu 7y ago
Think about using containers if any of the below apply: - You have heard or said the words "Hmm, it worked on my machine" - You run or want to run multiple applications on the same host - You care about software supply chain - You think serverless patterns may apply to your workloads - Scheduling applications on to your infrastructure is manual
- defen 7y ago
  > - You have heard or said the words "Hmm, it worked on my machine" I currently use VirtualBox + SaltStack to solve this problem, which has worked well and has significantly less overhead than going full Docker / K8s

by defen 7y ago

bunderbunder 7y ago

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.

danbeaulieu 7y ago

Think about using containers if any of the below apply: - You have heard or said the words "Hmm, it worked on my machine" - You run or want to run multiple applications on the same host - You care about software supply chain - You think serverless patterns may apply to your workloads - Scheduling applications on to your infrastructure is manual

defen 7y ago
> - You have heard or said the words "Hmm, it worked on my machine" I currently use VirtualBox + SaltStack to solve this problem, which has worked well and has significantly less overhead than going full Docker / K8s