Docker, when to use it?

[b0redom]

The main advantage is containers are at a higher abstraction level to VMs. You don't have to worry about the OS itself and compatibility issues with introducing breaking changes. Multiple containers run within one OS and are isolated from it.

The next abstract level up is to do away with the container and run the code under FaaS (function as a service) where you only pay for function execution cost and not for having a VM or container sitting idle. i.e. Serverless ideology where whole IT teams are redundant as DevOps takes it to the extreme of only really needing the developer.

Which is what AWS Lambdas are.... It's probably docker underneath, which is probably a VM underneath, which is probably physical tin running Xen underneath that.

It's just layers of abstraction.

[b0redom]

I still think you can achieve the same thing with a VM, devs create a VM image with everything they need, then send over the VMDK (or whatever format). A nice fully contained image. Yes VMDK is bigger, but storage and bandwidth are cheap.

BTW I fully accept I am being a luddite, and Dockers are the cool thing.

Yep. Same thing. The idea of docker + kubernetes (when it's done properly) is that there's only one process running in a docker container so if that dies, kubernetes can spin up a new one. It's harder to do that with VMs (running on VMware), you can do that with AWS and ASGs though I guess.

[Hobosapien]

Which is what AWS Lambdas are.... It's probably docker underneath, which is probably a VM underneath, which is probably physical tin running Xen underneath that.

It's just layers of abstraction.

Yep. The higher the layer the less one has to worry about infrastructure, scaling, and security. Just deploy and run. The Lean and Agile way.

[woohoo]

Ok from the sounds of it, I'm not working in the same environment as you guys so perhaps don't really encounter the problems you guys do.

[fool]

Ok from the sounds of it, I'm not working in the same environment as you guys so perhaps don't really encounter the problems you guys do.

Your PaaS likely uses something similar to Docker (or in some cases, Docker itself) to share servers.

This makes it easy for your PaaS to share servers as otherwise you'd have to handle orchestrating and running different types of apps, and would need to solve filesystem, IPC and network isolation, otherwise your depencies would likely conflict.

If you don't care and are happy just using whatever buildpacks are available, then by all means, fire away, but if you care about what's running underneath on the PaaS or have reason to run apps that aren't supported by a buildpack team (basically cathedral and the bazaar argument, bazaar generally wins), then you might consider using Docker itself as the leading opensource solution.

So end of the day, if you want to protect yourself from your supplier(s), and lock-in, or want to run this on-prem, you want open solutions that multiple vendors support. That's kubernetes*, and the apps are built with Docker. You can still use buildpacks with this solution (gitlab, openshift, dies, etc) but some people like to be in more control of their dependencies, and don't want a central admin team to dictate what they can run. Your PaaS does the same thing, it's just hidden from you.

* Some people use swarm, etc, but it seems like kubernetes has won the container wars at the moment.

[darmstadt]

Similar to the OP, I don`t quite get the use case for Docker, so from what you said the main benefit is has is that it`s lighter weight than a VM. So we are saving disk space, and cramming more workloads onto a physical server.

I think you can do everything you can with Docker, with a VM, its just you are saving money on less disk space, and CPU/RAM.

Pretty much so as each VM has an OS whereas a container doesn't. In my last project we did some availability exercises with KVM and containers for performance and suchlike and saw that containers were much easier to deploy. We were able to run over 250,000 MongoDB containers on one system with pretty good performance which was impossible to do with KVM. The highest we got was 10,000,000 containers on one system but that was just stupid and performance did drop after the first million or so. I've recently been working on containers which are x86_64 executables but need to run under ARM but so far it is not looking too good, needs some more time for cross platform to become more mature.

[Federico Razzoli]

I am a database administrator (DBA), so my point of view is different. Containers are supposed to be ephemeral, whilst database are supposed to be persistent. So, I wouldn't use it in production. Not because it's not possible or dangerous, but because it's designed to do something that I usually don't need. I prefer virtual machines, maybe with Vagrant (which applies Docker ideas to virtual machines, making them easier to build).

I use Docker in 2 cases:
* For testing. I don't need any persistence. Instead, I just need to start processes (the DBMS) quickly, without polluting my system.
* For monitoring. My preferred monitoring solution, PMM, is distributed as a Docker container. This is good, because it is a moderately set of different technologies interacting with each other, and if I had to care about dependencies and versions, it could be a nightmare.

[BlueSharp]

The whole container movement seems to be focused on reducing the number of VM OS instances running on the hardware stack with the added bonus of deploying all the dependencies with the container. I see it very much as the defacto tool now when using IAAS.

The whole PAAS offered now in Azure, serverless code, logic apps etc abstracts away a lot of the config and management fudge with containers. However I suspect under the hood Azure's PAAS is using server fabric and containers.