5 ms·

To the position that containerization is needless complexity for simple or non-scaling apps: one of the benefits of containers is it can create development envi

by msane 11y ago

To the position that containerization is needless complexity for simple or non-scaling apps: one of the benefits of containers is it can create development environments which can be identical to your production environment(s); no matter what platform you're always running the same code, same artifacts, same images. Virtualization does this too, but at great cost. I wish the kinks were better worked out at this point as well, and hope we start to converge around a few well-working patterns and toolsets. I expect it to happen. In the meantime it is chaos and easy to laugh at.

pbiggar 11y ago
But (and this is a thing I've been working on) do you really want your dev environment to be identical to your production environment? I think you don't. As an example, suppose you use Go. Your dev environment is 500mb of compilers and toolchain. Your production environment is (hopefully) a container with a single static binary on it.
- lstamour 11y ago
  The point is not that dev and production environments are identical, but that dev staging and production environments are identical. Your dev box can have whatever you like on it, but if it can't fake production behaviours, it's not going to help you catch and debug bugs in production. Of course there are limits. You could, it's perfectly valid, buy twice as much capacity in production and run it twice there. And use remote debugging tools. The point, especially with ops involved, is that your dev box is a snowflake and you want the least amount of manual configuration possible. It's not a requirement. Your app will run fine in production without it simply by testing in production. But few people willingly recommend that approach, even as pretty much everyone does it at some point or another. Even the best emulation of production won't prevent the need for debugging in production when a bug isn't caught before it gets deployed ;-)
  - pbiggar 11y ago
    Yeah, but folks are talking about using containers for actual dev environments. Because you want to make sure everyone is using the same version of the go compilers, etc.
    - lstamour 11y ago
      Hmm. By that logic, one VM compiles the app and produces or inserts it into another VM runtime environment....?
      - pbiggar 11y ago
        Basically yes. The dev container is used to build the production container's image.
        msane 11y ago
        I like where you're going with that
- msane 11y ago
  you're absolutely right, one needs to build images sans all of the dev toolchain and with staging/production flags. but the deps and parts they share in common should be identical. this is a hairy problem to solve, but containers are the solution, mixed with the right pattern, whatever it is. I might not want my dev containers to run on prod, but I want my staging/prod containers to be able to run on my local or whatever environment has the container/orchestration tool.

by msane 11y ago

pbiggar 11y ago

But (and this is a thing I've been working on) do you really want your dev environment to be identical to your production environment? I think you don't. As an example, suppose you use Go. Your dev environment is 500mb of compilers and toolchain. Your production environment is (hopefully) a container with a single static binary on it.

lstamour 11y ago
The point is not that dev and production environments are identical, but that dev staging and production environments are identical. Your dev box can have whatever you like on it, but if it can't fake production behaviours, it's not going to help you catch and debug bugs in production. Of course there are limits. You could, it's perfectly valid, buy twice as much capacity in production and run it twice there. And use remote debugging tools. The point, especially with ops involved, is that your dev box is a snowflake and you want the least amount of manual configuration possible. It's not a requirement. Your app will run fine in production without it simply by testing in production. But few people willingly recommend that approach, even as pretty much everyone does it at some point or another. Even the best emulation of production won't prevent the need for debugging in production when a bug isn't caught before it gets deployed ;-)
- pbiggar 11y ago
  Yeah, but folks are talking about using containers for actual dev environments. Because you want to make sure everyone is using the same version of the go compilers, etc.
  - lstamour 11y ago
    Hmm. By that logic, one VM compiles the app and produces or inserts it into another VM runtime environment....?
    - pbiggar 11y ago
      Basically yes. The dev container is used to build the production container's image.
      - msane 11y ago
        I like where you're going with that
msane 11y ago
you're absolutely right, one needs to build images sans all of the dev toolchain and with staging/production flags. but the deps and parts they share in common should be identical. this is a hairy problem to solve, but containers are the solution, mixed with the right pattern, whatever it is. I might not want my dev containers to run on prod, but I want my staging/prod containers to be able to run on my local or whatever environment has the container/orchestration tool.