5 ms·

Docker only solves problems if you have a technology stack that's full of problems.

by wrldos 4y ago

xupybd 4y ago
Yes it's been fantastic at allowing our outdated legacy php app run.
hkt 4y ago
I remember first meeting docker when trying to resolve dependency hell with ruby, so, accurate.
szastamasta 4y ago
And also makes it easy to test with different database versions, gives you 5 minute onboarding for the new devs on team (run this docker compose and you have everything in place). Lets you test your software in exactly the same environment as in production. Switch between stack versions in no time. Etc. It really solves real problems. Not only enterprise level bullsht.
- JackFr 4y ago
  Multiple ephemeral UAT environments are great huge.
- wrldos 4y ago
  I've never seen a dev stack in docker actually work. What I see is the poor new guy spending several hours trying to get docker working and configuring private repositories that don't work, then nothing works when they finally get it up which results in the dude spending at least 2 more days trying to reverse engineer the shit show or consult little pockets of knowledge hiding in out of date confluence documents and other people's heads who are on holiday.
  - dopidopHN 4y ago
    I’ve been in mostly dis functional software company. And … that’s not my experience. I least not lately. 10 years ago : absolutely. But nowadays it’s a docker command or a git pull then yarn/gradle/whatever … and if that does not work something is wrong and a ticket is raised.
    - Akronymus 4y ago
      "What is a git pull" "what is a yarn? Gradle?" Theres already a lotnof complexity in those "simple" parts
      - xboxnolifes 4y ago
        You're reaching really fucking hard here.
        wrldos 4y ago
        They're really not. I have two guys unfucking a yarn and NPM shit show at the moment.
        Akronymus 4y ago
        How so? Is it really that inconceivable that someone has never experienced those before? From personal experience, I used to use TFS for version control for a few years before using git at my newer job. I also never once had to deal with yarn or gradle. And I also know from experience, that you can make a unmaintainable mess in every build system. Also, who is gonna teach the juniors how to use the tools, if everyone sets that knowledge as mandatory? Or do you expect everyone to learn it in their free time before starting any tech job?
        dopidopHN 4y ago
        Don’t you have automated builds? The step in those builds should works on developer machines. Is that too much to ask? If the step in the build do not work? How did that get merged in the first place ?
- dennis_jeeves1 4y ago
  >5 minute famous words.
- KronisLV 4y ago
  > And also makes it easy to test with different database versions, gives you 5 minute onboarding for the new devs on team (run this docker compose and you have everything in place). It's eerie that I had this experience 5 minutes ago, in a stand-up onboarding meeting for a new colleague: they ran into issues when trying to launch the project through the IDE run configuration (IDE version, plugins, project configuration etc.) but the container based approach that I introduced just in case about a year ago just worked, the first time. Provided, I actually went the extra mile and documented how to authenticate with the necessary private repos etc., so one could follow a short list of steps bit by bit. > Lets you test your software in exactly the same environment as in production. I'd say containers are good for this, but not perfect. Depending on what you're developing and how, you might still run into stupid issues: mostly in setups where you use Windows for your development box and bind mount files, the permissions will get screwed up, as will line endings. Here's an example: https://blog.kronis.dev/everything%20is%20broken/containers-are-broken https://blog.kronis.dev/everything%20is%20broken/containers-... I'd say the best possible developer experience nowadays is along the lines of: - have GNU/Linux distro X as your developer workstation - have the same GNU/Linux distro X as the base for your containers (a more cut down version, but with same package repos) - still ship software in containers, ideally run those on nodes that have some GNU/Linux distro That's why I primarily base all of my container images on Ubuntu nowadays, same OS as my workstation. It's not efficient or optimized, but it's good enough, predictable and mostly free of headaches: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-for-all-of-my-containers https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo... I can just install some software on the workstation and have it run basically the same as it will in the container, same install instructions and everything (though maybe less focus on clearing up package caches not to bloat container layers, which doesn't matter outside of those). Sometimes that is useful for local debugging or launching things directly with IDE integrations, as opposed to trying to get remote debugging working (though things like DBs, Keycloak, Redis etc. are still better in containers, I'm talking more about back end/front end tooling/runtimes). If you go to this other post of mine, it actually has an example of this: https://blog.kronis.dev/articles/a-week-of-linux-instead-of-windows https://blog.kronis.dev/articles/a-week-of-linux-instead-of-... (search for "Being able to run the same thing inside of containers and on the host system.") At this point I'm basically unironically shipping my dev box, sans dotfiles. It doesn't scale, but it's the least painful dev and ops experience I've had in years. One can probably take elements from this for more sane and enterprise setups, too (such as focusing on GNU/Linux instead of Windows for development, or at least something with a similar file system).
jusssi 4y ago
> if you have a technology stack that's full of problems This is every company older than 7 years whose primary business is not creating beautifully engineered backend software. Unless quality is somehow forced on them by regulation or contracts, then it's just 90% of companies.
drowsspa 4y ago
Meaning everything that needs to compile a C native dependency.

Docker only solves problems if you have a technology stack that's full of problems.

by wrldos 4y ago

Docker only solves problems if you have a technology stack that's full of problems.

xupybd 4y ago

Yes it's been fantastic at allowing our outdated legacy php app run.

hkt 4y ago

I remember first meeting docker when trying to resolve dependency hell with ruby, so, accurate.

szastamasta 4y ago

And also makes it easy to test with different database versions, gives you 5 minute onboarding for the new devs on team (run this docker compose and you have everything in place). Lets you test your software in exactly the same environment as in production. Switch between stack versions in no time. Etc. It really solves real problems. Not only enterprise level bullsht.

JackFr 4y ago
Multiple ephemeral UAT environments are great huge.
wrldos 4y ago
I've never seen a dev stack in docker actually work. What I see is the poor new guy spending several hours trying to get docker working and configuring private repositories that don't work, then nothing works when they finally get it up which results in the dude spending at least 2 more days trying to reverse engineer the shit show or consult little pockets of knowledge hiding in out of date confluence documents and other people's heads who are on holiday.
- dopidopHN 4y ago
  I’ve been in mostly dis functional software company. And … that’s not my experience. I least not lately. 10 years ago : absolutely. But nowadays it’s a docker command or a git pull then yarn/gradle/whatever … and if that does not work something is wrong and a ticket is raised.
  - Akronymus 4y ago
    "What is a git pull" "what is a yarn? Gradle?" Theres already a lotnof complexity in those "simple" parts
    - xboxnolifes 4y ago
      You're reaching really fucking hard here.
      - wrldos 4y ago
        They're really not. I have two guys unfucking a yarn and NPM shit show at the moment.
      - Akronymus 4y ago
        How so? Is it really that inconceivable that someone has never experienced those before? From personal experience, I used to use TFS for version control for a few years before using git at my newer job. I also never once had to deal with yarn or gradle. And I also know from experience, that you can make a unmaintainable mess in every build system. Also, who is gonna teach the juniors how to use the tools, if everyone sets that knowledge as mandatory? Or do you expect everyone to learn it in their free time before starting any tech job?
        dopidopHN 4y ago
        Don’t you have automated builds? The step in those builds should works on developer machines. Is that too much to ask? If the step in the build do not work? How did that get merged in the first place ?
dennis_jeeves1 4y ago
>5 minute famous words.
KronisLV 4y ago
> And also makes it easy to test with different database versions, gives you 5 minute onboarding for the new devs on team (run this docker compose and you have everything in place). It's eerie that I had this experience 5 minutes ago, in a stand-up onboarding meeting for a new colleague: they ran into issues when trying to launch the project through the IDE run configuration (IDE version, plugins, project configuration etc.) but the container based approach that I introduced just in case about a year ago just worked, the first time. Provided, I actually went the extra mile and documented how to authenticate with the necessary private repos etc., so one could follow a short list of steps bit by bit. > Lets you test your software in exactly the same environment as in production. I'd say containers are good for this, but not perfect. Depending on what you're developing and how, you might still run into stupid issues: mostly in setups where you use Windows for your development box and bind mount files, the permissions will get screwed up, as will line endings. Here's an example: https://blog.kronis.dev/everything%20is%20broken/containers-are-broken https://blog.kronis.dev/everything%20is%20broken/containers-... I'd say the best possible developer experience nowadays is along the lines of: - have GNU/Linux distro X as your developer workstation - have the same GNU/Linux distro X as the base for your containers (a more cut down version, but with same package repos) - still ship software in containers, ideally run those on nodes that have some GNU/Linux distro That's why I primarily base all of my container images on Ubuntu nowadays, same OS as my workstation. It's not efficient or optimized, but it's good enough, predictable and mostly free of headaches: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-for-all-of-my-containers https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo... I can just install some software on the workstation and have it run basically the same as it will in the container, same install instructions and everything (though maybe less focus on clearing up package caches not to bloat container layers, which doesn't matter outside of those). Sometimes that is useful for local debugging or launching things directly with IDE integrations, as opposed to trying to get remote debugging working (though things like DBs, Keycloak, Redis etc. are still better in containers, I'm talking more about back end/front end tooling/runtimes). If you go to this other post of mine, it actually has an example of this: https://blog.kronis.dev/articles/a-week-of-linux-instead-of-windows https://blog.kronis.dev/articles/a-week-of-linux-instead-of-... (search for "Being able to run the same thing inside of containers and on the host system.") At this point I'm basically unironically shipping my dev box, sans dotfiles. It doesn't scale, but it's the least painful dev and ops experience I've had in years. One can probably take elements from this for more sane and enterprise setups, too (such as focusing on GNU/Linux instead of Windows for development, or at least something with a similar file system).

jusssi 4y ago

> if you have a technology stack that's full of problems This is every company older than 7 years whose primary business is not creating beautifully engineered backend software. Unless quality is somehow forced on them by regulation or contracts, then it's just 90% of companies.

drowsspa 4y ago

Meaning everything that needs to compile a C native dependency.