It's up to you to make your containers bloated or keep them slim. You can use the alpine versions of the official Dockerhub images. Python on Alpine is 30 MB (vs 267 MB for the debian one). https://hub.docker.com/r/library/python/tags/
If your app is a compiled go binary (so, it runs anywhere) why do you need a container?
The whole point of containerisation is to group installed dependencies (as opposed to installable dependencies like with a regular deb or rpm package) and configuration into a 'black box'.
If your binary is already a single-file distribution, why lump it in with the crapfest that is docker?
I don't think that's the whole point. If all you care about is packaging your code in a container, then you don't need Docker. That was solved long ago. Docker simply adds a nice API on top which allows you to package, ship, and manage your apps in the same exact way.
By using something like Docker Compose, you can explicitly define each container and the relationships between the containers. Then, you can start/stop groups of containers (an application stack) while still retaining some component isolation and the ability to upgrade and scale containers independently. All of this is defined in a relatively simple YAML file, which can be committed to VCS and tweaked. I can't tell you how awesome it is to find repos on Github that have use docker-compose. Even complex apps with many pieces can often be launched with a single command. It's easy to take these stacks and tweak them to your needs, adding/removing/changing components as necessary.
Since Docker provides a standard way for managing any container, orchestrators like Swarm, Rancher (my preference for small-medium clusters), and DC/OS can take that functionality and scale it across many hosts. You can get a birds-eye view of your Docker cluster (all apps) or drill down into individual apps and their components. Each container is a uniform piece and can be controlled, scaled, updated, audited in the same way. Throw a UI in front of it and now you can manage applications that you know nothing about. That's great for developers that manage just a few apps, and it's incredible for enterprises with thousands of them. If you don't want to think about infrastructure at all, then you can use a SaaS Docker provider. Obviously there are pros and cons to each approach, and there are some remaining challenges.
Docker isn't perfect, especially in regards to storage and networking. Distributed storage isn't simple, but a lot of progress has been made with volumes and volume drivers. It's not as easy as it needs to be, but the general direction seems to be good and with the proper tooling I think this will be less of an issue.
If "you" here is one person and "your app" is one app, then yes, why do you need a container. If "you" is 200 developers, and "your app" is 75 different applications written in Java, Java plus native libs, .NET, python, the other python, R, scala, NodeJS, and various C libraries, then docker containers, and more importantly images, are about as ideal as it gets. We're running Mesos so we don't have to use docker to get containers, but packaging up the products as images is a significant advantage.
Alpine containers are nice if you're just looking at size. But they break down once you `docker exec` into them to try to debug something:
$ docker exec -ti mycontainer /bin/bash
stat /bin/bash: no such file or directory
$ docker exec -ti mycontainer /bin/sh
/ # curl https://localhost:5000/
/bin/sh: curl: not found
/ # strace $command
/bin/sh: strace: not found
Thats not really broken. It is just a minimal image. If you want more pacakages then install them via the Dockerfile before you fire up the image. I like starting with a bare container. For example I might take an alpine image, install openvpn and use it to serve an always on vpn connection to other containers. The VPN container doesnt need a shell or anything else really. The only thing I want to see when I attach to the container is what openvpn is spitting out.
Well yeah, "break down" was probably too much of a term. I did not mean to diss Alpine; I just meant to point out that the downsides of minimal images should be carefully considered.
You can create containers that are just a few MB with compiled languages like Go (5 MB). https://www.iron.io/microcontainers-tiny-portable-containers...
From the article: "Rather than starting with everything but the kitchen sink, start with the bare minimum and add dependencies on an as needed basis."