5 ms·

IMHO containerization exists because of this "pattern." It's a way to just take big balls of crap, roll them up along with the entire host OS image, and deploy

by api 7y ago

IMHO containerization exists because of this "pattern." It's a way to just take big balls of crap, roll them up along with the entire host OS image, and deploy them as a unit. Problem "solved." Of course now you have microservice architectures where you're basically creating programs made of containerized services. Any bets on how long it'll take to have containers-of-containers be a thing? Maybe this could be the "big box of crap" pattern.

shoo 7y ago
Putting the application in a container doesn't make it easier to make safe, controlled changes to the internal workings of the application. It doesn't help any developers understand the theory (if any) underlying the application code, that might help them understand how to code with the grain when making changes. Stuffing it into a container to deploy it is orthogonal. It doesn't solve many problems
- foobiekr 7y ago
  You're both right. I have worked professionally in a company that is a giant, sprawling software slum at best. Containers are huge there because they are perceived as fixing this issue even if they just make it worse in practice.
  - api 7y ago
    I see containers, at least when used this way, as a consolidation loan for technical debt. They let you consolidate your existing debt load embodied in all your messy uninstallable ball of crap software and then max out your credit again. One of the issues here is the lost art of writing installable and well-organized software. It's quite normal these days to have services and apps that consist of multiple often redundant services and sub-applications wired haphazardly together with crap strewn all over systems.
    - foobiekr 7y ago
      It may sound contrarian, but I was very, very recently looking at a project that uses three or four different base containers because the people involved can't agree to use the same flavor of linux. It's more like they are doing the technical equivalent of credit card churning but never closing out the accounts. I have never seen anything like this, and I have, on and off in my career, worked in contexts best described as "software superfund decon expert."
lmm 7y ago
> Of course now you have microservice architectures where you're basically creating programs made of containerized services. Any bets on how long it'll take to have containers-of-containers be a thing? As soon as Kubernetes gets mature enough to have to make backwards-incompatible changes and keep old code running, we'll have to have a way of deploying clusters that were defined in the old versions. So probably a few years?
Rury 7y ago
Yeah, software gets bigger as more requirements are thrown at it, no matter how it's done. Eventually you just end up with a these balls of crap. Frankly, I think this pattern describes most programming constructs as well. As what's a good approach for managing largeness (or complexity)? Dividing it into smaller simpler understandable chunks, that can be changed in isolation, which is what containers attempt to do, as what many programming constructs attempt to do. But you're right, it'll just grow more, and things will likely just get divided again into more chunks. I don't see a way out of this process. In fact, I feel this describes a general law, as it describes everything large in general. Take companies for example. Large companies are less innovative, because they're more complex and hard to change, just like large software. Additionally, large companies tend to containerize things into divisions, departments, teams, and so on, in attempt to manage complexity. Bigness is the anti-thesis to change/innovation...

by api 7y ago

shoo 7y ago

Putting the application in a container doesn't make it easier to make safe, controlled changes to the internal workings of the application. It doesn't help any developers understand the theory (if any) underlying the application code, that might help them understand how to code with the grain when making changes. Stuffing it into a container to deploy it is orthogonal. It doesn't solve many problems

foobiekr 7y ago
You're both right. I have worked professionally in a company that is a giant, sprawling software slum at best. Containers are huge there because they are perceived as fixing this issue even if they just make it worse in practice.
- api 7y ago
  I see containers, at least when used this way, as a consolidation loan for technical debt. They let you consolidate your existing debt load embodied in all your messy uninstallable ball of crap software and then max out your credit again. One of the issues here is the lost art of writing installable and well-organized software. It's quite normal these days to have services and apps that consist of multiple often redundant services and sub-applications wired haphazardly together with crap strewn all over systems.
  - foobiekr 7y ago
    It may sound contrarian, but I was very, very recently looking at a project that uses three or four different base containers because the people involved can't agree to use the same flavor of linux. It's more like they are doing the technical equivalent of credit card churning but never closing out the accounts. I have never seen anything like this, and I have, on and off in my career, worked in contexts best described as "software superfund decon expert."

lmm 7y ago

> Of course now you have microservice architectures where you're basically creating programs made of containerized services. Any bets on how long it'll take to have containers-of-containers be a thing? As soon as Kubernetes gets mature enough to have to make backwards-incompatible changes and keep old code running, we'll have to have a way of deploying clusters that were defined in the old versions. So probably a few years?

Rury 7y ago

Yeah, software gets bigger as more requirements are thrown at it, no matter how it's done. Eventually you just end up with a these balls of crap. Frankly, I think this pattern describes most programming constructs as well. As what's a good approach for managing largeness (or complexity)? Dividing it into smaller simpler understandable chunks, that can be changed in isolation, which is what containers attempt to do, as what many programming constructs attempt to do. But you're right, it'll just grow more, and things will likely just get divided again into more chunks. I don't see a way out of this process. In fact, I feel this describes a general law, as it describes everything large in general. Take companies for example. Large companies are less innovative, because they're more complex and hard to change, just like large software. Additionally, large companies tend to containerize things into divisions, departments, teams, and so on, in attempt to manage complexity. Bigness is the anti-thesis to change/innovation...