3 ms·

> Docker doesn't require boiling the oceans. Look, this is from a Windows perspective but I totally get this pro of Docker. I am the last line of defense at my

> Docker doesn't require boiling the oceans. Look, this is from a Windows perspective but I totally get this pro of Docker. I am the last line of defense at my company when stuff goes wrong and the sheer amount of variables that customer environments introduce is frightening. In one case, some HP server management solution changed a benign environment variable to something strange; completely breaking MSBuild (which we used heavily at the time). It took weeks to escalate to me, and hours in a meeting and ILSpy figuring out what was going wrong. Oceans we're boiled by burning money. Docker is plug-and-play. We can mandate that customers can't futz with our image. Our software becomes an appliance that plugs into their network. We can upgrade from known states, with no HP BS throwing a spanner in the works. I am pushing it heavily for on-prem for this reason. That answers the question cleanly: stupid stuff that happens on customer environments. Don't get me started on how much this lifts off of the ops team - our Docker stuff isn't yet in production but ops are salivating over it. There is no installer to run, no xcopy, you just ask Kube to give you an upgraded cluster. I strongly suspect change aversion here. Nobody likes their cheese being moved.

Ameo 9y ago
> Our software becomes an appliance that plugs into their network That statement right there is, I feel, what Docker is all about. It converts your application from a set of files and configuration into a single blob. The conversion isn't free, but the benefits are clear and compelling.
rspeer 9y ago
I understand your desire, but do you think the stupid stuff is going to stop happening in customer environments with Docker? Are you still upgrading from a known state when you don't know how long it's been since they upgraded Docker? What if they're on a different version of the Linux kernel than you, or a different filesystem, causing Docker to work differently? All kinds of things about the customer environment that can affect your software are still out of your control. The problem I've encountered with Docker in my own experience is that, while it intends to abstract over fiddly details of the system environment it's running in, it leaks just as many fiddly details, at a different level. If your goal is a self-contained appliance, you still need something wrapped around Docker, like a VM, at which point a cynic can ask why you need Docker. Now, even though I say this, the ops team at my company (who know a lot more than me) do put Docker inside the VMs instead of just running the code in them. There is presumably some value to the abstractions it provides.
- tdbgamer 9y ago
  A tool doesn't need to fix _all_ problems to be useful. Yes, Docker doesn't cover differences in Linux kernel versions but it will take care of basically every other difference. Now the search space has been narrowed to Kernel/FS issues. Sounds great to me.
bonesss 9y ago
> We can mandate that customers can't futz with our image. Our software becomes an appliance that plugs into their network. One of the overlooked benefits of this approach is how technically aggressive it lets you be when deploying components into strange environments... More and more we're getting tools from our suppliers based on containers that use databases, proxies, heavy server tools, and such. We fire up in seconds tools that could never viably be installed in our environment and that we have 0 competence with. Long running databases in containers is something you need to think about, but guaranteed known states for supplier-side configuration frees them up to be daring, and firing up local DBs for config data with no outgoing ports lets me not care about how other engineers see the world.
- zamalek 9y ago
  > databases in containers is something you need to think about I think in a few cases it makes sense to move problems out of containers. A good amount of our customers would likely tell us what to do if we asked them to not worry about the SQL database in a container - they have their backup policies and so forth. This will change over time, but I'm pretty sure that there will always be scenarios where a VM or even metal is required.

Ameo 9y ago

> Our software becomes an appliance that plugs into their network That statement right there is, I feel, what Docker is all about. It converts your application from a set of files and configuration into a single blob. The conversion isn't free, but the benefits are clear and compelling.

rspeer 9y ago

I understand your desire, but do you think the stupid stuff is going to stop happening in customer environments with Docker? Are you still upgrading from a known state when you don't know how long it's been since they upgraded Docker? What if they're on a different version of the Linux kernel than you, or a different filesystem, causing Docker to work differently? All kinds of things about the customer environment that can affect your software are still out of your control. The problem I've encountered with Docker in my own experience is that, while it intends to abstract over fiddly details of the system environment it's running in, it leaks just as many fiddly details, at a different level. If your goal is a self-contained appliance, you still need something wrapped around Docker, like a VM, at which point a cynic can ask why you need Docker. Now, even though I say this, the ops team at my company (who know a lot more than me) do put Docker inside the VMs instead of just running the code in them. There is presumably some value to the abstractions it provides.

tdbgamer 9y ago
A tool doesn't need to fix _all_ problems to be useful. Yes, Docker doesn't cover differences in Linux kernel versions but it will take care of basically every other difference. Now the search space has been narrowed to Kernel/FS issues. Sounds great to me.

bonesss 9y ago

> We can mandate that customers can't futz with our image. Our software becomes an appliance that plugs into their network. One of the overlooked benefits of this approach is how technically aggressive it lets you be when deploying components into strange environments... More and more we're getting tools from our suppliers based on containers that use databases, proxies, heavy server tools, and such. We fire up in seconds tools that could never viably be installed in our environment and that we have 0 competence with. Long running databases in containers is something you need to think about, but guaranteed known states for supplier-side configuration frees them up to be daring, and firing up local DBs for config data with no outgoing ports lets me not care about how other engineers see the world.

zamalek 9y ago
> databases in containers is something you need to think about I think in a few cases it makes sense to move problems out of containers. A good amount of our customers would likely tell us what to do if we asked them to not worry about the SQL database in a container - they have their backup policies and so forth. This will change over time, but I'm pretty sure that there will always be scenarios where a VM or even metal is required.