4 ms·

Ehh, I somewhat agree but you're generalizing a lot. To pick one example: containers have been invaluable for setting up reproducible dev environments (via doc

Ehh, I somewhat agree but you're generalizing a lot. To pick one example: containers have been invaluable for setting up reproducible dev environments (via docker compose), even across just a few people. It doesn't take very long to setup, and the time savings are immediately obvious to me when we have to bring someone new onboard or install new dependencies.

taeric 8y ago
Oddly, the time saving is not obvious to me. Deploying to Java app servers was not exactly hard to get running. And it is only in this brave new world of docker that I have joined a team and not gotten a commit on day one. I don't blame docker. I think. However, I do feel it enables people to move faster with more complicated solutions where not necessarily needed.
- tpxl 8y ago
  I used websphere and deployments were hell when something stateful in the server broke and removing and readding the add didn't fix it. I like containers precisely because once you get a running configuration working, it's zero hassle to deploy.
  - taeric 8y ago
    I've already seen similar hell for deploying to a container. If you're system has state, and most eventually do, then things can get tricky. I do think containers are progress in many ways. Especially so for batch processing jobs. But they have not been pure progress.
- xyzzy123 8y ago
  So $work did java app deployment with Tomcat and puppet at scale (>100 services). Sweet. Mostly. 3 problems, 1 is that in the unlikely event you had an external system dependency, (say, shudder, imagemagick or really, any non java binary) you were totally hosed, because lots of systems work needed to be done to provide it (say, make rhel packages in corp repo plus puppet guff) and also keep it up to date. 2 was, since it was outside the supported path, actually, you couldn’t ship anything that wasn’t Java in Tomcat, Java invoked binaries were hard, but non Java services, even judiciously and with a super good reason were basically impossible. 3. Your stuff might be coupled to the base operating system in some way... which meant that the operating system patches needed to be tested against all possible application deployments and thus patching (including kernel) became the de-facto responsibility of the team owning the application, which lead to major delays in patch application. Containers mostly shift these problems around (and create new and different problems too) rather than solving them, but my experience is that they do genuinely shift them around in a useful way.
  - taeric 8y ago
    Amusingly, I've seen all of those problems even in the docker world. It is a bit harder to get yourself into that spot, but for fun, just try and use a GPU on an installation of docker from about 3 years ago. :) That said, I do agree. It is mostly shifting things around. And if this is where your pain point was, then you will likely like what containers can do for you.
- wgerard 8y ago
  > Deploying to Java app servers was not exactly hard to get running. I thought that too - not about Java per se, but similarly that "getting this app server running is designed to be easy." Then, I had to help someone debug an issue with installation over the phone. That was the exact moment I decided to look into containers, and I've never had to re-live that tedium since. > However, I do feel it enables people to move faster with more complicated solutions where not necessarily needed. I do agree with you here, but I think that's a people issue and not a tool issue. The tool itself is quite valuable even for simple cases.
  - taeric 8y ago
    I have had to relive the tedium of installing docker images on a coworkers machine. Can be more than a little infuriating when there is no obvious reason things that should be equal are not working. Especially when that is the goal of the system. And agreed it is a people thing, mostly. I'll even go further and say it is the way things will be soon. I just don't think it is doing anyone favors to pretend previous solutions didn't solve things. Or to pretend that modern solutions solve everything that ever came before. There are plenty of problems to go around.

taeric 8y ago

Oddly, the time saving is not obvious to me. Deploying to Java app servers was not exactly hard to get running. And it is only in this brave new world of docker that I have joined a team and not gotten a commit on day one. I don't blame docker. I think. However, I do feel it enables people to move faster with more complicated solutions where not necessarily needed.

tpxl 8y ago
I used websphere and deployments were hell when something stateful in the server broke and removing and readding the add didn't fix it. I like containers precisely because once you get a running configuration working, it's zero hassle to deploy.
- taeric 8y ago
  I've already seen similar hell for deploying to a container. If you're system has state, and most eventually do, then things can get tricky. I do think containers are progress in many ways. Especially so for batch processing jobs. But they have not been pure progress.
xyzzy123 8y ago
So $work did java app deployment with Tomcat and puppet at scale (>100 services). Sweet. Mostly. 3 problems, 1 is that in the unlikely event you had an external system dependency, (say, shudder, imagemagick or really, any non java binary) you were totally hosed, because lots of systems work needed to be done to provide it (say, make rhel packages in corp repo plus puppet guff) and also keep it up to date. 2 was, since it was outside the supported path, actually, you couldn’t ship anything that wasn’t Java in Tomcat, Java invoked binaries were hard, but non Java services, even judiciously and with a super good reason were basically impossible. 3. Your stuff might be coupled to the base operating system in some way... which meant that the operating system patches needed to be tested against all possible application deployments and thus patching (including kernel) became the de-facto responsibility of the team owning the application, which lead to major delays in patch application. Containers mostly shift these problems around (and create new and different problems too) rather than solving them, but my experience is that they do genuinely shift them around in a useful way.
- taeric 8y ago
  Amusingly, I've seen all of those problems even in the docker world. It is a bit harder to get yourself into that spot, but for fun, just try and use a GPU on an installation of docker from about 3 years ago. :) That said, I do agree. It is mostly shifting things around. And if this is where your pain point was, then you will likely like what containers can do for you.
wgerard 8y ago
> Deploying to Java app servers was not exactly hard to get running. I thought that too - not about Java per se, but similarly that "getting this app server running is designed to be easy." Then, I had to help someone debug an issue with installation over the phone. That was the exact moment I decided to look into containers, and I've never had to re-live that tedium since. > However, I do feel it enables people to move faster with more complicated solutions where not necessarily needed. I do agree with you here, but I think that's a people issue and not a tool issue. The tool itself is quite valuable even for simple cases.
- taeric 8y ago
  I have had to relive the tedium of installing docker images on a coworkers machine. Can be more than a little infuriating when there is no obvious reason things that should be equal are not working. Especially when that is the goal of the system. And agreed it is a people thing, mostly. I'll even go further and say it is the way things will be soon. I just don't think it is doing anyone favors to pretend previous solutions didn't solve things. Or to pretend that modern solutions solve everything that ever came before. There are plenty of problems to go around.