Reply to: Docker, when to use it?

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[Hobosapien]

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.

[portseven]

Yep. Plus you have a community provisioned repo of ready to roll docker containers running NGINX, MySQL etc (although YMMV based on the amount of trust you are willing to give it), a bit like AWS AMIs.

The reason devs love it is that it fixes the whole, 'well it works on my computer' thing. They can provide a docker container, and wherever you install/run it, the libraries, versions etc will be identical. If something breaks and needs fixing, they can reproduce exactly the same environment where it broke.

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.

[woohoo]

When you say PAAS, are you talking about using EC2 instances etc? The idea is, that you don't need to run Octopus deploy or whatever, you stipulate what the dependencies are, have the docker container pull your code (or bundle it up in the image) and then upload to your docker repo.

Then deploying to prod/dev/staging/QA etc follows exactly the same process. You just pull and run, no need to maintain an OS image etc. You can also deploy into ECS or whatever the equivalent is in Azure GCP etc.

For in house physical servers the selling point is that you get better ROI as you can run far more containers than VMs on a physical host.

So when I say PAAS, I'm talking of Azure and Application services. I don't maintain a VM, I just publish to a service. I can do that via github for example or directly from Visual Studio. I stipulate on the App service which version of the framework etc to use.

[woohoo]

Yep. Plus you have a community provisioned repo of ready to roll docker containers running NGINX, MySQL etc (although YMMV based on the amount of trust you are willing to give it), a bit like AWS AMIs.

The reason devs love it is that it fixes the whole, 'well it works on my computer' thing. They can provide a docker container, and wherever you install/run it, the libraries, versions etc will be identical. If something breaks and needs fixing, they can reproduce exactly the same environment where it broke.

Thanks...I see the whole thing it works on my PC, I can understand that. But in my entire career it's probably happened twice when the environment has differed and has caused a "works on my computer" thing.

Mostly, in my experience and I do mostly web apps nowadays, the "works on my computer" is down to the data or an issue integrating with a third party service. The last time it happened to me and it was down to the environment was about 4 years ago and not installing a legacy third party component.

I guess if I had several customers, running different versions of frameworks etc then it might be a bonus, but in 12 years of contracting it's never really been an issue.

[b0redom]

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.

Yep. Plus you have a community provisioned repo of ready to roll docker containers running NGINX, MySQL etc (although YMMV based on the amount of trust you are willing to give it), a bit like AWS AMIs.

The reason devs love it is that it fixes the whole, 'well it works on my computer' thing. They can provide a docker container, and wherever you install/run it, the libraries, versions etc will be identical. If something breaks and needs fixing, they can reproduce exactly the same environment where it broke.

[portseven]

Docker lets you ship your dependencies along with your app in a container which theoretically can be run on any host OS - not sure how mature the Windows side is. For example if you have a JAVA app with a bunch of crypto dependencies, you just docker pull and then run.

It's lighter weight than a VM as it doesn't require a separate OS instance per container, and only the specific dependencies are shipped with the container image, not all of the OS binaries.

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.

[b0redom]

Thanks, I can of understand most of that from the course. But I'm looking to see where I can use it.

So, when working in the cloud I'm mainly using PAAS, so I can't see it helping there. For other clients that have physical servers in-house. I usually deploy via teamcity/octopus etc.

Even where deploying code directly to a server it's never really been an issue ensuring the server has the correct dependencies.

So, I'm trying to think when/how I can use it.

When you say PAAS, are you talking about using EC2 instances etc? The idea is, that you don't need to run Octopus deploy or whatever, you stipulate what the dependencies are, have the docker container pull your code (or bundle it up in the image) and then upload to your docker repo.

Then deploying to prod/dev/staging/QA etc follows exactly the same process. You just pull and run, no need to maintain an OS image etc. You can also deploy into ECS or whatever the equivalent is in Azure GCP etc.

For in house physical servers the selling point is that you get better ROI as you can run far more containers than VMs on a physical host.