5 ms·

The point is: Even if you're using single, static binaries (like we do in 90% of cases with Go), the big benefit of Docker is that you don't just get a binary,

The point is: Even if you're using single, static binaries (like we do in 90% of cases with Go), the big benefit of Docker is that you don't just get a binary, you get a service interface. I can't stress this point enough. If you don't know what's up with a failing service, any SRE can go into the Dockerfile definition (actually, we're rarely dealing with Dockerfiles anymore, these days it's more the Kubernetes definition), look at which ports are exposed, what the environment variables are, what the service is talking to, etc. You can harden security between those services much tighter than between binaries, by dropping capabilities, seccomp, network policies, read-only file-systems. Also, all the other advice about the drawbacks is pretty dated: While I've run into my share of super annoying Docker problems myself in the early days (and yes, especially on Ubuntu, goodbye Device Mapper...), I've yet to encounter a single, Docker related bug on Google managed GKE on Container-Optimized OS since we've switched all of our services there a year ago. I didn't regret our choice in a very long time.

aeorgnoieang 8y ago
Does Docker itself make defining service interfaces easier than configuration management? I'd imagine that, e.g. a well-written Ansible module for an application could do all the things you mention.
- lykr0n 8y ago
  Docker allows you to say "Application X" talks to "Application Y" and it will do the rest with minimal configuration. The same could be accomplished with Consul or Salt/Ansible/Puppet that knows about the services.
  - moosingin3space 8y ago
    Really? In my experience, that's been tooling on top of Docker that makes that sort of declarative networking easy.
    - lykr0n 8y ago
      Docker has evolved beyond just running docker containers. I don't have any experience with it, but: https://docs.docker.com/docker-cloud/apps/service-links/ https://docs.docker.com/docker-cloud/apps/service-links/
      - user5994461 8y ago
        That's the issue here, you don't have any experience with it. Like most features in Docker, this one doesn't work as advertised.
molf 8y ago
Cannot agree with this more; but (as you already hint at) Kubernetes is the actual win, and I would not be surprised if Docker would eventually be replaced with another container solution in the Kubernetes ecosystem.
- coconutrandom 8y ago
  Keep an eye on rkt: https://coreos.com/rkt/docs/latest/using-rkt-with-kubernetes.html https://coreos.com/rkt/docs/latest/using-rkt-with-kubernetes...
- xkarga00 8y ago
  cri-o is a container runtime optimized for Kubernetes. http://cri-o.io/ http://cri-o.io/
bonesss 8y ago
> any SRE can go into the Dockerfile/Kubernetes definition... look at which ports are exposed, what the environment variables are Ding ding! Applications are only a part of the issue. It's the whole server stack, all internal communication, configuration, service compsition, and networking setup. Having these things in a declarative format are a godsend for production, a godsend for mixed language environments, and a godsend for whoever gets to kill those services and replace them with better things. Working with sensitive data: there is also the whole shit-show of secrets management... It's not like this is impossible without containerization, but having formal security boundaries around them (both in process and systems), gives you guarantees instead of well-intentioned guesses.
- notyourday 8y ago
  > It's not like this is impossible without containerization, but having formal security boundaries around them (both in process and systems), gives you guarantees instead of well-intentioned guesses. Containers are ran on VMs. Most of those VMs are ran in a cloud operated by the same providers peddling the container is new cloud. AWS/GCP/Azure building block is not a container. It is a VM. VMs are not hard. VMs can be treated like containers. Use them. Tool around them. You would be amazed how less crufty your stack would be when you don't use abstraction on a top of abstraction. Containers gave us a rise of super flaky software architecture. The one that theoretically should be horizontally salable but is not. Whenever people talk about how containers did the same to the apps as to shipping i tell them they are absolutely right. There's a pile of hard science(tm) used to properly load containers on the ships based on the content of individual containers and the trip they are going to take. That's hard science is sorely missing from the app level container management
  - bonesss 8y ago
    "Hard science" would seem to be what orchestration frameworks are for, and why they're so integral to value creation. Frankly the parallel holds: you can do a lot more with shipping containers, but the standardised box is mostly a thing that lets you get started on the 'real work' :) Re: VMs vs Containers -- the implicit assumption in what you're describing, and in the article, is that you're building in AWS/GCP/Azure with engineers who are competent in that specific suppliers ecosystem and relevant server techs. Working with hybrid cloud installations and "air-gapped" systems with international partners invalidates a lot of those assumptions... Having a stable cross-section for deployment and scaling across clouds, backed with holistic answers to configuration-heavy parts of the application stack, is a total game changer. Containers don't let you ignore VMs any more then VMs let you ignore hardware, but trying to recreate Kubernetes ad-hoc in-situ is a crap-fest. As a software engineer I gotta disagree about abstractions creating cruft. That's what poor abstractions do. Good abstractions moves complexity to it's most reasonable point of management and the lowest point of pain. "All problems in computer science can be solved by another level of indirection" ;)

aeorgnoieang 8y ago

Does Docker itself make defining service interfaces easier than configuration management? I'd imagine that, e.g. a well-written Ansible module for an application could do all the things you mention.

lykr0n 8y ago
Docker allows you to say "Application X" talks to "Application Y" and it will do the rest with minimal configuration. The same could be accomplished with Consul or Salt/Ansible/Puppet that knows about the services.
- moosingin3space 8y ago
  Really? In my experience, that's been tooling on top of Docker that makes that sort of declarative networking easy.
  - lykr0n 8y ago
    Docker has evolved beyond just running docker containers. I don't have any experience with it, but: https://docs.docker.com/docker-cloud/apps/service-links/ https://docs.docker.com/docker-cloud/apps/service-links/
    - user5994461 8y ago
      That's the issue here, you don't have any experience with it. Like most features in Docker, this one doesn't work as advertised.

molf 8y ago

Cannot agree with this more; but (as you already hint at) Kubernetes is the actual win, and I would not be surprised if Docker would eventually be replaced with another container solution in the Kubernetes ecosystem.

coconutrandom 8y ago
Keep an eye on rkt: https://coreos.com/rkt/docs/latest/using-rkt-with-kubernetes.html https://coreos.com/rkt/docs/latest/using-rkt-with-kubernetes...
xkarga00 8y ago
cri-o is a container runtime optimized for Kubernetes. http://cri-o.io/ http://cri-o.io/

bonesss 8y ago

> any SRE can go into the Dockerfile/Kubernetes definition... look at which ports are exposed, what the environment variables are Ding ding! Applications are only a part of the issue. It's the whole server stack, all internal communication, configuration, service compsition, and networking setup. Having these things in a declarative format are a godsend for production, a godsend for mixed language environments, and a godsend for whoever gets to kill those services and replace them with better things. Working with sensitive data: there is also the whole shit-show of secrets management... It's not like this is impossible without containerization, but having formal security boundaries around them (both in process and systems), gives you guarantees instead of well-intentioned guesses.

notyourday 8y ago
> It's not like this is impossible without containerization, but having formal security boundaries around them (both in process and systems), gives you guarantees instead of well-intentioned guesses. Containers are ran on VMs. Most of those VMs are ran in a cloud operated by the same providers peddling the container is new cloud. AWS/GCP/Azure building block is not a container. It is a VM. VMs are not hard. VMs can be treated like containers. Use them. Tool around them. You would be amazed how less crufty your stack would be when you don't use abstraction on a top of abstraction. Containers gave us a rise of super flaky software architecture. The one that theoretically should be horizontally salable but is not. Whenever people talk about how containers did the same to the apps as to shipping i tell them they are absolutely right. There's a pile of hard science(tm) used to properly load containers on the ships based on the content of individual containers and the trip they are going to take. That's hard science is sorely missing from the app level container management
- bonesss 8y ago
  "Hard science" would seem to be what orchestration frameworks are for, and why they're so integral to value creation. Frankly the parallel holds: you can do a lot more with shipping containers, but the standardised box is mostly a thing that lets you get started on the 'real work' :) Re: VMs vs Containers -- the implicit assumption in what you're describing, and in the article, is that you're building in AWS/GCP/Azure with engineers who are competent in that specific suppliers ecosystem and relevant server techs. Working with hybrid cloud installations and "air-gapped" systems with international partners invalidates a lot of those assumptions... Having a stable cross-section for deployment and scaling across clouds, backed with holistic answers to configuration-heavy parts of the application stack, is a total game changer. Containers don't let you ignore VMs any more then VMs let you ignore hardware, but trying to recreate Kubernetes ad-hoc in-situ is a crap-fest. As a software engineer I gotta disagree about abstractions creating cruft. That's what poor abstractions do. Good abstractions moves complexity to it's most reasonable point of management and the lowest point of pain. "All problems in computer science can be solved by another level of indirection" ;)