4 ms·

From your post, I think you might fundamentally misunderstand Docker's use/value. From a value-add standpoint, Docker doesn't really care about "isolating share

From your post, I think you might fundamentally misunderstand Docker's use/value. From a value-add standpoint, Docker doesn't really care about "isolating shared library dependencies", but instead, compartmentalizing an entire application, dependencies and all. The value in this, of course, is that you no longer have to care about version conflicts between resources that are sharing a machine. As an added bonus, it means your deployment process can stay the same regardless of the type of container you're deploying. Before, if you had to deploy a Ruby app as well as a Python app, those required fundamentally different processes, as they each require their own package managers and interpreters. With a container, you compile each of those tools _into the container_, and then your deployment process is just "Create container image, send it somewhere". Hell, even if you wrote an application with 0 dependencies, you're still on the hook for installing the correct version of its compiler, the correct version of your deployment tool, and the correct version/OS of your VM. These are still dependencies, even if they're not dev dependencies. > It certainly doesn't make things easier, faster, more secure, or cheaper; If you don't think being able to reuse software makes your workflow easier, faster and at the very least cheaper, I'm not sure what you could possibly think would do those things.

tannhaeuser 6y ago
I'm sure you believe what you're saying. But, as pointed out in many posts here, very few people can setup Kubernetes, let alone know it enough for troubleshooting. As an example, in a project of mine we had to call-in an k8s expert after almost a week of downtime (turned out IP address space was exhausted on that Azure instance). And a constant in almost all recent projects of mine is sure people fiddling with k8s integration setups, and achieving very little. In that kind of situation, it is unwise and irresponsible to treat your infrastructure as a black box. You still need to be able to re-build/migrate your images for security, stability, and feature upgrades, so you're basically just piling additional complexity on top. The premise of Kubernetes and containers/clouds is an economical (and legitimate) rather than technical one: that you don't have to invest into hardware upfront, and pay as you go with PaaS instead. That tactic only works, though, as long as you have a strong negotiation position as customer. In practice, if you won't get locked-in to cloud providers by tying your k8s infra to IAM or other auth infrastructure, or mixing Kubernetes with non-Kubernetes SaaS such as DBs (which suck on k8s), then you still won't be able to practically move your workload setup elsewhere due to sheer complexity and risk/downtime. The economical benefit is further offset by a wrong assumption that you need no or fewer admin staff for Docker ("DevOps" in an HR sense).
- bird_monster 6y ago
  > But, as pointed out in many posts here, very few people can setup Kubernetes, My post, and most of yours, had nothing to do with Kubernetes, but containers in general. I don't care for Kubernetes, and would actively reject using it 99% of the time. Your post, however, was mostly about containerization of applications, whose validity has nothing to do with one particular product or pattern (Kubernetes). Containers are an almost unanimous win in terms of the simplification of development and deployment. Conflating Kubernetes to be the only approach to containerization is a farce.

tannhaeuser 6y ago

I'm sure you believe what you're saying. But, as pointed out in many posts here, very few people can setup Kubernetes, let alone know it enough for troubleshooting. As an example, in a project of mine we had to call-in an k8s expert after almost a week of downtime (turned out IP address space was exhausted on that Azure instance). And a constant in almost all recent projects of mine is sure people fiddling with k8s integration setups, and achieving very little. In that kind of situation, it is unwise and irresponsible to treat your infrastructure as a black box. You still need to be able to re-build/migrate your images for security, stability, and feature upgrades, so you're basically just piling additional complexity on top. The premise of Kubernetes and containers/clouds is an economical (and legitimate) rather than technical one: that you don't have to invest into hardware upfront, and pay as you go with PaaS instead. That tactic only works, though, as long as you have a strong negotiation position as customer. In practice, if you won't get locked-in to cloud providers by tying your k8s infra to IAM or other auth infrastructure, or mixing Kubernetes with non-Kubernetes SaaS such as DBs (which suck on k8s), then you still won't be able to practically move your workload setup elsewhere due to sheer complexity and risk/downtime. The economical benefit is further offset by a wrong assumption that you need no or fewer admin staff for Docker ("DevOps" in an HR sense).

bird_monster 6y ago
> But, as pointed out in many posts here, very few people can setup Kubernetes, My post, and most of yours, had nothing to do with Kubernetes, but containers in general. I don't care for Kubernetes, and would actively reject using it 99% of the time. Your post, however, was mostly about containerization of applications, whose validity has nothing to do with one particular product or pattern (Kubernetes). Containers are an almost unanimous win in terms of the simplification of development and deployment. Conflating Kubernetes to be the only approach to containerization is a farce.