5 ms·

Containers are not there to solve a problem. They are there to produce buzz, then busy engineers, then bills, all packaged in a way that overloaded (and sometim

by erikb 9y ago

Containers are not there to solve a problem. They are there to produce buzz, then busy engineers, then bills, all packaged in a way that overloaded (and sometimes quite unskilled) manager can show something to their bosses. And in that regard Containers are successful as hell. That's why we have a religion around them now. You can hate it but you can't really ignore it if you need to pay rent and work in the industry.

deleted 9y ago
[deleted]
bdcravens 9y ago
They really did solve a lot of problems for us, but I don't think we over-engineered our solution, which I think is an easy rabbit-hole to dive into.
- shitgoose 9y ago
  i am sure there are folks who solved a lot of their problems by writing monolith apps. they just don't walk around preaching their religion.
  - bdcravens 9y ago
    Yeah, I would agree there's quite a disconnect between "rubber hits the road" and the "Gospel of Docker". This was magnified when I attended Dockercon in Austin last year. As a very small team that has used Docker (and ECS) to solve some problems, I was excited to learn more. It became quickly apparent that I was at the wrong conference for that: it felt like an enterprise vendor party where everyone was passing around cups of kool-aid.
    - erikb 9y ago
      Yeah the kool-aid stuff is really annoying. Btw have you checked out the details of systemd slices? I somehow thought it's nearly the same as docker, just without the hype. Just practical technology on the level it's supposed to be.
  - deleted 9y ago
    [deleted]
  - erikb 9y ago
    Well Linux is quite a monolith despite day-1 criticism about that fact. They call their style "pragmatism" and in some regards the market seems to validate it.
sidlls 9y ago
You're getting downvoted because of the impression of a sort of caustic nature of the comment, I suspect, but I agree with your real point. I put containers and "orchestration" like kubernetes right up there with "Big Data", Kafka and a bunch of other technology that is the current fad. All of these have a legitimate use case. Odds are the use case of anyone reading this comment isn't one. But because of the terribly broken interview process and bandwagon effects, engineers feel compelled to force them into the development process in order to bypass filters (human and automated) on their resumes and keep a sort of social cache among their peers.
- viraptor 9y ago
  I downvoted it, because it's an opinion about things some people do and has nothing to do with the technology. You can use it well, you can use it badly. If you claim "They are there to produce buzz, then busy engineers, then bills", then you haven't seen a problem they solve. That's fine. Just don't try to tell people there is no such problem.
  - sidlls 9y ago
    I think it has everything to do with the technology. Specifically the technology solves problems most (almost all) organizations don't have, yet their adoption is practically ubiquitous as is their requirement to appear on a resume to get past gatekeepers. If in the end the technology is used more as a means to "produce buzz, then busy engineers, then bills" than to solve problems for their legitimate use cases it hardly is an error to point it out.
    - viraptor 9y ago
      Are you saying almost all organisation don't need to solve the problem of consistent deployment artifacts and easily reproducible testing/dev environment? Because these are some of the problems containers can solve. (not the only problems, and they're not the only solution - but they can be a solution to those specific cases)
  - erikb 9y ago
erik_seaberg 9y ago
Containers solve one problem: if your team is bad at packaging and you have dependencies you aren't aware of.
acdha 9y ago
I downvoted because the first claim is so badly wrong. Containers solve several problems which many places struggle with, the most important of which is having a common baseline for every project. Having a clear ops/dev responsibility boundary, tools, auditing, documentation, etc. which is identical for every team, every language, and every environment is huge in any organization over the smallest startups. That’s a shame because the rest of your comment is right: that space is on the red hot point of the hype curve and there’s a ton of money being spent so someone can brag that they’re doing the same thing as the cool kids at Google or Netflix when in reality that’s like saying you’re an Olympic marathoner because you bought the same shoes. It’s profitable now but I wonder whether we’re due for some backlash.
- yjftsjthsd-h 9y ago
  Containers may solve some problems, but they're hardly the only solution and the others seem (note: personal bias) simpler to me. > common baseline "Here is the standard image with standard packages; if you need something else, add it to Chef/Ansible/whatever-we-use" > responsibility boundary "Ah, this binary is in /opt/$COMPANY - go ask the devs why it's broken" > which is identical So use configuration management (Chef, Ansible, whatever) for the system and tarballs/packages for your stuff, rather than shipping whole system images per-project?
  - acdha 9y ago
    First, this is engineering so there's no right answer for everyone. If deploying things using the configuration management tool of your choice works for your project and staffing, it's the right choice. Here are some complications for the traditional approach you mentioned: 1. Containers provide a standard interface for managing things in any language: that means you don't have to know that this Java team used Tomcat, someone else used Jetty, the Python apps use mod_wsgi or gunicorn depending on when they were written, etc. Yes, Chef/Ansible/etc. can coordinate that too but you have to maintain conventions for editing shared configuration, permissions, storage, firewall ports, dealing with religious arguments about systemd, etc. That's especially true if you're using vendor or open-source apps where it's really nice not to have to spend time repackaging something where someone at Oracle, Atlassian, etc. use the LSB docs as rolling paper rather than reading material. Again, having done it for years I'm not saying this cannot be done but it's refreshing not to ever have a talk about user IDs, using a sane config .d layout on RHEL, etc. again. That brings me to: 2. Coordinating changes or updates: again, yes, it's always possible any way you choose to do it but it's really nice not to have to maintain changes in multiple branches for teams at various stages of upgrading, deal with special cases, etc. Shoveling everything into a container means that the only team which deals with those questions is the one best equipped to answer them. That's especially nice when the problem is something like upgrading a common distribution package and it'd take a non-trivial amount of time versus no time to answer the question of whether your backport will break something else used somewhere in your company. 3. This is similar: “Ah, this binary is in /opt/$COMPANY - go ask the devs why it's broken”. In simple cases, yes, that's easy but once it gets more complicated — “this gets slow every Tuesday night”, “we're getting sporadic disk full errors”, etc. — it's really nice to have an inside/outside division which is consistent across every system and every project. Following the LSB rules gets you a lot but that's not universally followed so you're going to have to spend time on exceptions, arguing with vendors, or getting upstream open source projects patched. Again, that's all valid work but some times you don't have the time to spare for.

by erikb 9y ago

deleted 9y ago

[deleted]

bdcravens 9y ago

They really did solve a lot of problems for us, but I don't think we over-engineered our solution, which I think is an easy rabbit-hole to dive into.

shitgoose 9y ago
i am sure there are folks who solved a lot of their problems by writing monolith apps. they just don't walk around preaching their religion.
- bdcravens 9y ago
  Yeah, I would agree there's quite a disconnect between "rubber hits the road" and the "Gospel of Docker". This was magnified when I attended Dockercon in Austin last year. As a very small team that has used Docker (and ECS) to solve some problems, I was excited to learn more. It became quickly apparent that I was at the wrong conference for that: it felt like an enterprise vendor party where everyone was passing around cups of kool-aid.
  - erikb 9y ago
    Yeah the kool-aid stuff is really annoying. Btw have you checked out the details of systemd slices? I somehow thought it's nearly the same as docker, just without the hype. Just practical technology on the level it's supposed to be.
- deleted 9y ago
  [deleted]
- erikb 9y ago
  Well Linux is quite a monolith despite day-1 criticism about that fact. They call their style "pragmatism" and in some regards the market seems to validate it.

sidlls 9y ago

You're getting downvoted because of the impression of a sort of caustic nature of the comment, I suspect, but I agree with your real point. I put containers and "orchestration" like kubernetes right up there with "Big Data", Kafka and a bunch of other technology that is the current fad. All of these have a legitimate use case. Odds are the use case of anyone reading this comment isn't one. But because of the terribly broken interview process and bandwagon effects, engineers feel compelled to force them into the development process in order to bypass filters (human and automated) on their resumes and keep a sort of social cache among their peers.

viraptor 9y ago
I downvoted it, because it's an opinion about things some people do and has nothing to do with the technology. You can use it well, you can use it badly. If you claim "They are there to produce buzz, then busy engineers, then bills", then you haven't seen a problem they solve. That's fine. Just don't try to tell people there is no such problem.
- sidlls 9y ago
  I think it has everything to do with the technology. Specifically the technology solves problems most (almost all) organizations don't have, yet their adoption is practically ubiquitous as is their requirement to appear on a resume to get past gatekeepers. If in the end the technology is used more as a means to "produce buzz, then busy engineers, then bills" than to solve problems for their legitimate use cases it hardly is an error to point it out.
  - viraptor 9y ago
    Are you saying almost all organisation don't need to solve the problem of consistent deployment artifacts and easily reproducible testing/dev environment? Because these are some of the problems containers can solve. (not the only problems, and they're not the only solution - but they can be a solution to those specific cases)
- erikb 9y ago

erik_seaberg 9y ago

Containers solve one problem: if your team is bad at packaging and you have dependencies you aren't aware of.

acdha 9y ago

I downvoted because the first claim is so badly wrong. Containers solve several problems which many places struggle with, the most important of which is having a common baseline for every project. Having a clear ops/dev responsibility boundary, tools, auditing, documentation, etc. which is identical for every team, every language, and every environment is huge in any organization over the smallest startups. That’s a shame because the rest of your comment is right: that space is on the red hot point of the hype curve and there’s a ton of money being spent so someone can brag that they’re doing the same thing as the cool kids at Google or Netflix when in reality that’s like saying you’re an Olympic marathoner because you bought the same shoes. It’s profitable now but I wonder whether we’re due for some backlash.

yjftsjthsd-h 9y ago
Containers may solve some problems, but they're hardly the only solution and the others seem (note: personal bias) simpler to me. > common baseline "Here is the standard image with standard packages; if you need something else, add it to Chef/Ansible/whatever-we-use" > responsibility boundary "Ah, this binary is in /opt/$COMPANY - go ask the devs why it's broken" > which is identical So use configuration management (Chef, Ansible, whatever) for the system and tarballs/packages for your stuff, rather than shipping whole system images per-project?
- acdha 9y ago
  First, this is engineering so there's no right answer for everyone. If deploying things using the configuration management tool of your choice works for your project and staffing, it's the right choice. Here are some complications for the traditional approach you mentioned: 1. Containers provide a standard interface for managing things in any language: that means you don't have to know that this Java team used Tomcat, someone else used Jetty, the Python apps use mod_wsgi or gunicorn depending on when they were written, etc. Yes, Chef/Ansible/etc. can coordinate that too but you have to maintain conventions for editing shared configuration, permissions, storage, firewall ports, dealing with religious arguments about systemd, etc. That's especially true if you're using vendor or open-source apps where it's really nice not to have to spend time repackaging something where someone at Oracle, Atlassian, etc. use the LSB docs as rolling paper rather than reading material. Again, having done it for years I'm not saying this cannot be done but it's refreshing not to ever have a talk about user IDs, using a sane config .d layout on RHEL, etc. again. That brings me to: 2. Coordinating changes or updates: again, yes, it's always possible any way you choose to do it but it's really nice not to have to maintain changes in multiple branches for teams at various stages of upgrading, deal with special cases, etc. Shoveling everything into a container means that the only team which deals with those questions is the one best equipped to answer them. That's especially nice when the problem is something like upgrading a common distribution package and it'd take a non-trivial amount of time versus no time to answer the question of whether your backport will break something else used somewhere in your company. 3. This is similar: “Ah, this binary is in /opt/$COMPANY - go ask the devs why it's broken”. In simple cases, yes, that's easy but once it gets more complicated — “this gets slow every Tuesday night”, “we're getting sporadic disk full errors”, etc. — it's really nice to have an inside/outside division which is consistent across every system and every project. Following the LSB rules gets you a lot but that's not universally followed so you're going to have to spend time on exceptions, arguing with vendors, or getting upstream open source projects patched. Again, that's all valid work but some times you don't have the time to spare for.