3 ms·

> TBH I'd rather read a few thousand lines of bash than the equivalent in Yet Another Migraine Looming spread across who knows how many containers that do who k

> TBH I'd rather read a few thousand lines of bash than the equivalent in Yet Another Migraine Looming spread across who knows how many containers that do who knows what. While that's a fair position to take, you also might be in the minority here. I've seen plenty of in-house solutions in corporate environments and one of the things that they've all had in common was how bad they were, due to them being a way to just get things done and no more (e.g. no proper testing, no proper documentation, bad/wrong abstractions). It's not like your (or anyone else's) collection of Bash scripts can compete with open source solutions that have had thousands of collective man years put into making them better and addressing the never ending churn of keeping things working across new distro releases etc. I'm not advocating to go straight to Kubernetes - Docker Swarm or Hashicorp Nomad, or even just Docker Compose can all be decent alternatives that are simpler to wrap one's head around and manage, in most smaller deployments. As for no one knowing what containers do, i would still take a collection of containers over the nightmare of 10 different webapps all being deployed in an instance of GlassFish/Tomcat, with who knows what sort of Cthulhu living in the shared libraries folder and everything being so brittle that you cannot even look at it the wrong way, or it'll break and you'll spend days digging through obscure error logs. Worse yet, have you ever needed to manage an environment that has applications that need 4 different JDK versions and many different launch methods (some use systemd services with Tomcat, some use Tomcat launch scripts, some have just a .jar that needs to be launched etc.), yet still count upon some shared environment configuration being present? Give me individual containers over that mess any day. I think that there should be a clear separation between what a server needs to keep operating and where the "business software" would run - basically an /app directory with a subdirectory per application with whatever it needs, be it bind mounted data storage, configuration files, log output (in lieu of log shipping) etc., as opposed to having some stuff be strewn across /var, /etc, /opt, /www and who knows how many other directories. Containers give me just that.

stephenr 5y ago
> you also might be in the minority here I'd be astounded if I'm not. The tech industry is ridiculously cargo-culty. I never said I expect the majority of people to agree with me, I said what I prefer. The majority of people probably think McDonalds is just fine, and that Google is "not so bad" too, and it doesn't bother me that other people disagree with my opinion. If you ask me to fix your fucked infra because someone threw together a Rube Goldberg like Kubernetes environment just to achieve rolling deployments of their application, I'm going to tell you it's a shit solution, just as if you asked me to critique a McDonalds hamburger I'm going to tell you it's a shit hamburger. Me saying it's shit doesn't mean you can't use the thing, it means my opinion is that there are better ways to solve the problem/achieve the desired outcome, and you can either accept that opinion and make a change, or disagree and I'll go provide my services to another client. It's really that simple. > thousands of collective man years put into making them better They've had a ridiculous large number of man years working on them, no question. The whole point is that we disagree about whether they're "better" or not. Adding complexity is not necessarily making something better. > i would still take a collection of containers over the nightmare of 10 different webapps all being deployed in an instance of GlassFish/Tomcat In... a decade and a half of doing this I think I've been asked to support one JVM based thing, and that was quite a while ago. I'm sure it is a shit show, but I'm also sure that there are better alternatives than 8 more layers of abstraction. Lightweight VM-like containers are literally a thing that exists, and can give essentially the same provisioning as a traditional VM, with the "lightweight" / "shared resources" aspect of a container solution.

stephenr 5y ago

> you also might be in the minority here I'd be astounded if I'm not. The tech industry is ridiculously cargo-culty. I never said I expect the majority of people to agree with me, I said what I prefer. The majority of people probably think McDonalds is just fine, and that Google is "not so bad" too, and it doesn't bother me that other people disagree with my opinion. If you ask me to fix your fucked infra because someone threw together a Rube Goldberg like Kubernetes environment just to achieve rolling deployments of their application, I'm going to tell you it's a shit solution, just as if you asked me to critique a McDonalds hamburger I'm going to tell you it's a shit hamburger. Me saying it's shit doesn't mean you can't use the thing, it means my opinion is that there are better ways to solve the problem/achieve the desired outcome, and you can either accept that opinion and make a change, or disagree and I'll go provide my services to another client. It's really that simple. > thousands of collective man years put into making them better They've had a ridiculous large number of man years working on them, no question. The whole point is that we disagree about whether they're "better" or not. Adding complexity is not necessarily making something better. > i would still take a collection of containers over the nightmare of 10 different webapps all being deployed in an instance of GlassFish/Tomcat In... a decade and a half of doing this I think I've been asked to support one JVM based thing, and that was quite a while ago. I'm sure it is a shit show, but I'm also sure that there are better alternatives than 8 more layers of abstraction. Lightweight VM-like containers are literally a thing that exists, and can give essentially the same provisioning as a traditional VM, with the "lightweight" / "shared resources" aspect of a container solution.