Goodbye Docker and Thanks for all the Fish
technodrone.blogspot.com
technodrone.blogspot.com
What’s wrong with Docker? Why would I want to switch to something else? Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them?
The author doesn’t actually answer any of these questions. No arguments against Docker are made, nor are any arguments made in favor of competitors.
Personally, I have to agree with the author and think it's difficult to see a bright future for the company that lives up to its $1.3B valuation.
Things Docker can/does charge for and could do very well with.
- Support: Businesses are happy to pay maintenance contracts for fixed LTS versions of Docker which is their EE product.
- Kube: Docker has pivoted their UCP product into a turnkey on-prem Kubernetes distribution. Plenty of room in that space to grow.
- Registry; You wouldn't run random images from DockerHub in production, right? Similar to Red Hat's product in this space there's a lot of money to be made in having officially supported images. Images with a pedigree, aduit trail, CVE reporting, yada yada. Partner with Canonical and since it's way easier to do this when you already have distro maintainers and you have a solid RH competitor that devs will like more.
- Security: Audit your images that have been sitting around and not updated in ages.
- Hosting: They'll be one of many but there's plenty of space in providing some ergonomics compared to Google/AWS's offerings.
There is plenty of ways Docker Inc. can create and capture value in this space. Their unique value is that whatever product they make, the world will check it out... They "just" need to make it good and figure out the business behind it.
Those are more like enterprise checklist items than real needs...
Mongo equally so (JSON in PostgreSQL). These valuations are fantasy.
https://techcrunch.com/2018/10/15/docker-has-raised-92-milli...
"Red Hat" as in RHEL specifically, or are you meaning any of the family (eg CentOS)?
Asking because I've not hit any problems using Docker CE with CentOS 7. Well, aside from general bugs (etc). But nothing seems to force the use of EE instead of CE.
Could be any of the FAANG companies but I posit Microsoft since they noticeably try to make Docker on Windows a seamless experience and also push Docker within their cloud offerings to modernize legacy apps towards Azure. They've already purchased a large community-oriented company (GitHub) and have acquired companies at a surprisingly high price (LinkedIn).
I see the thought process but disagree with the premise that they need to charge for their container technology directly.
For example, GitHub does not charge for git, but instead for the convenient layers that they add on top of it.
Another example is that Google does not charge for Kubernetes but you can buy support which every enterprise company wants and since GKE happens to be the most convenient way to get a K8s cluster rolling in the cloud (for most circumstances) and also now on a box now with GKE On-Prem, many will choose that path so Google still gets their money, just from product / services / support on top of the free core.
They can also monetize the "fallout paths" — turns out you're in over your head running all of that K8s stuff yourself? Come pay us more and use our K8s PaaS instead! Not sure if they actually have one yet, but consider something like GKE Serverless here.
Enterprise features and support around running containers in production are worth a lot of money.
Docker can continue charging for all of its porcelain layers on top like Docker Hub and Docker Enterprise and make plenty of money off of big fish.
They could also monetize by being acquired by Microsoft, Google, or Amazon.
2. Google still makes the lion's share of it's money from search/ads. Google Compute is struggling and being subsidized by search/ads.
IMHO, Docker's only exit strategy is to sell. They don't have enough time left to grow an organic business. Silicon Valley money always wants paid back, sooner rather than later.
The layoffs and new CFO at Docker, IMHO, are all about cleaning up the finances so that a sale is possible at a good price.
Their last round of investment barely averted a down round. The value bump was minimal and the investors are mostly from a bank in Brazil that likely doesn't understand exactly what they bought into (a lot of uneducated money out there right now because there is no place to put it). None of the original investors participated which shows they don't believe in the company anymore.
Their most valuable asset is Windows support. Hence, the most likely aquirerer would be Microsoft. I'll bet a paycheck they sell for somewhere between 1.5B and 2.5B. Keep this thread for posterity :-)
It's painfully obvious to anybody that has been in this game for a while...
(opinions and analysis my own)
2 - That seems fine and besides the point... Google is massive. Google Cloud (excluding the half that comes from G Suite) brings in $2B per year in revenue. That might only be a few percent of Google's overall, but a few percent of $80B is still a massive number.
Docker itself is in trouble because they got the wrong use case from the start. They completely missed out about orchestration.
Containerization requires to both have containers (docker images) and deploy them on fleet of servers (kubernetes orchestration). The later is where the value is.
That's actually how they started -- they were a PaaS called dotCloud before they were Docker!
This was before the term "orchestration" became common, but the point was that they were running apps in multiple languages. They were like Heroku except they supported more than one language (back when Heroku was basically Rails apps).
They didn't get much traction and had to pivot to Docker. I think the underlying reason is that writing a PaaS / distributed OS like Kubernetes is extremely difficult, and they were spread too thin. They didn't really nail a single use case like Heroku nailed Rails apps. They were trying to run everything and ended up running nothing.
----
This "rhyming" of history makes me smile, and makes me think how important timing is. dotCloud was the right product, done too early and done poorly. Docker was arugably the wrong product at the right time! I say "wrong" because I never thought it was a sustainable product or business, but it did come about at a time when people really needed a quick and dirty solution.
And now the surrounding ecosystem has changed drastically and I agree with the OP that Docker may be left out of it.
----
Another thing I find funny is that App Engine was already "serverless" 10+ years ago... you wrote Python apps and uploaded them as .zip files (web or batch processing). You didn't manage virtual machines. So somehow they were also a bit early, and maybe the product was lacking in some ways as a result.
I'm not sure that dotcloud and App Engine though were the right products though.
They have shown that a fully managed cloud solution is not the answer. Barely no company could use it, let alone migrate existing software to a whole new platform. It's limited to a very small niche.
Docker and Kubernetes are standalone products. Companies can use them internally and make it work with what they already have.
However I don't see how Docker Inc can be substainable in the long run.
What's most likely to happen is Docker being acqui-hired by someone like Microsoft.
1. Doesn't grow revenue at the speeds they want returns 2. Isn't "free marketing" (dear God I have seen this one too many times, CTOs even write it out in blogs sometimes) 3. Only really makes sense when you get out more than you put in, aka is community drive . Community driven open source is really the only profitable open source.
What's wrong with not using Docker? Outside of cloud/SOA/webscale sector, people having hard time to simply comprehend the drama.
I have not seen any justification for using containers on any scaleable system on real hardware for example.
In "ad-farm" world, running ad farms on pure hardware with netboot provisioning has been the "gold standard" since time immemorial.
Few points:
1. Netboot with root at tmpfs takes less time to boot, seconds over 10G (most of the time is spent on POST and DHCP actually.)
2. Netboot images can be stripped to the barest minimum of life-sustainance. Less software running — less problems.
3. Less attack surface for hackers.
4. Hard lockup proof - hardware watchdogs are more or less foolproof.
5. Linkup to the real network is as simple as it gets, you can use broadcasts for self-configuration and service discovery on the network.
6. If you deal with RDMA, well, you will be already spending most of your efforts on just getting software work as advertised on the bare system, and the additional troubles of containerisation will not worth dealing with.
Amazon, among other FAANG companies, never needed containers shipping entire bundled OSes.
Deploying a "base OS" (using PXE or netboot) can be done very reliably both on a hypervisors and VMs.
A simple build system can then generate traditional packages and push them into VMs allocated for a specific product.
It provides better security isolation and the ability to receive security updates on OSes and also on dynamically linked libraries.
Building and deploying new versions of you product is also much faster, especially at large scale: only your application package is rebuilt and deployed.
The fact that many other containers run entire OS is because it's easier to get started, or there are runtimes needed, or people just build and deploy in the same image.
People have hurriedly forgotten why Linux distros exist: https://opensource.com/article/19/2/linux-distributions-stil...
Even when you write a lot of software, environments always drag in existing tools and infrastructure (aka other open source). 99% it's easier to consume pre-built SME knowledge from. Linux distro #HailTheMaintainers
Strict versioning of every dependency - exactly the thing a packaging system solves.
Specific system configuration? Also not a problem at all with netboot images.
CI picks up your image build, then commits its record to a DB from which DHCP server looks up a boot image for given MAC, then it either SSHed a reboot command or used an IPMI reboot. Voila
Today, some server motherboard firmwares can boot images off HTTP, vlan, and can talk with the boot server itself on HTTP
It could have easily been VMs instead of containers. IMHO, it was all the packaging...
That being said, I’d agree that netboot + tmpfs has a lot of advantages; unfortunately, it’s not always practical, especially at smaller scales. Containers are convenient and don’t require any special hardware accommodations.
I see Docker as a framework. It's the "get me from nothing" to a fully featured solution for building, running and distributing containerized applications. And it happens to do it for anyone running Windows, MacOS or Linux.
It's the same reason why I would want to use a web framework. I don't necessarily want to write and string together a bunch of super low level things. I want to start at a higher level of abstraction so I can focus on writing the applications I care about.
As an end user, I don't necessarily care too much about OCI or the runtime spec. I care about running docker-compose up and having everything work.
The core argument is that you wouldn't care if you were using something else. I use Kubernetes. That's what I care about. If I'm on AKS, GKE, EKS, any other managed Kubernetes service, the only time I ever even see the word Docker is in the filename of the Dockerfile. They could switch their default runtime to anything else and I might not notice.
> Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them?
This is the exact same problem that Oracle has with Java, and MongoDB now has with their product. You can't make money off of an API, and implementation's are very rarely a differentiator. Another product will come along (actually, several already exist) that says "we support dockerfiles, we emulate the docker api, swap us out". There's nothing new to learn. The only thing that product needs is a benefit over normal docker, and if you think Amazon, Google, or Microsoft can't add value through more native integration with their cloud services, you're crazy.
Docker isn't going anywhere, but they become commoditized far too quickly than their valuation would suggest.
One argument could be that their moat is mostly brand. And, increasingly, other brands are working around them. Like Kubernetes. They already offer non-docker runtimes. They could, at some point, offer and promote their own packaging tool too. People might use a K8S tool solely because it's the "default setting".
Made up, but I imagine something like that.
With these changes going on, docker becomes just a fancy zip file, and since now there is a committee to design a standardized container there really is nothing left for for the Docker company.
Kubernetes IMO just used Docker's popularity to gain its own, but at this point the actual docker itself is no longer essential.
Security, performance, reliability and following best engineering practices. Everything else is fine.
https://arxiv.org/pdf/1804.05039.pdf
https://hackernoon.com/another-reason-why-your-docker-contai...
https://www.scylladb.com/2018/08/09/cost-containerization-sc...
https://thehftguy.com/2017/02/23/docker-in-production-an-upd...
A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).
https://containerjournal.com/2019/01/22/5-container-alternat...
I'm not sure what you're advocating for exactly, but the systems that the "leading tech companies" originally built were largely VM orchestration systems that required humans to pack software packages into VM images. This was suboptimal so Google et al pioneered containers and others followed suit. This is exactly what gave rise to Docker and Kubernetes. This seems a lot like saying, "ships solved the transportation problem so planes are not useful".
Never mind that most people don't have the resources to build, maintain, and operate their own orchestration systems.
> Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today.
Build tooling is an important but orthogonal concern (you can use Bazel and friends to build container images). I'm not sure what you mean when you say Kubernetes doesn't solve those problems today.
To be clear, I'm not a Docker/K8s fanatic; they can be frustrating at times and something better will surely come along and replace them eventually. However, they're a lot better than what existed before (which to be clear were not off-the-shelf solutions but rather patterns that a large, wealthy, competent organizations could use to build their own solution).
APT and yum simply install packages assuming the dependencies resolve correctly. The [unnamed ;)] system could be modified to generate a set of .deb and .rpm files (with locked versions) to deploy a product.
I chose Swarm as a pragmatic choice in an enterprise environment that didn't have any prior experience with Docker at all, really, at the operational level. We had to support financial models, often many different versions of the code at the same time, on top of the usual stack of applications to go with that. The choice was a "success", albeit one muted by the wacky networking layer they use. Compound that with RHEL's older kernels, and we had to deal with oddball issues like iptables/arp table getting out of sync with what's actually running, resulting in connectivity issues. And don't get me started on removing and redeploying a stack; that would occasionally wedge things so badly we had to cycle the docker daemon.
Still, a shame. The gap between "Look, I wrote a compose file" and running something on a small cluster is tiny, and that was its main strength, even if it did suffer from some serious heisenbugs. Why they decided to add and remove features between versions and do their damndest not to make a compose file 100% "forwards compatible" with Swarm is another mystery.
Docker is useful for developers because we pull containers and run on Ubuntu and OSX them without having to install anything. Much easier than Vagrant.
- The ops team are in a different country, and are wedded to very old-fashioned views of administration ("Automation? But I like manually running commands from a runbook!")
- You work with a team of people who are quants/actuaries/scientists/engineers but not professional developers, but you want them to have a turn-key environment so they can Get On With It. When they need new python packages or god forbid upgrade pandas or something else, there's a full CI chain that'll make sure that what they do here also works there.
- Swarm is (from personal experience) easy enough to teach people who don't know anything about Docker. You can show them how to query the state, modify it, look at logs, etc. all without the hassle and overhead of configuring and running K8s, even though it will always be my #1 choice for tech-literate orgs. Swarm, for many, including myself, was a pragmatic choice -- 80% of the immediate benefit of container orchestration with 20% of the cognitive overhead for the chaps in another country who had to maintain it if things went south.
Docker didn’t have enough of an advantage even though Swarm game shipped with it, so de facto if you had Kube you would have had Swarm first...
I am more of a mind to make sure that I can solve the task(s) that I am given, such as it is, with the resources available (people, knowledge, time, etc.). That inevitably means tradeoffs. In a parallel universe I would have used K8s instead, as I think it's exceptional and far superior to Swarm. However, with the limited resources available, I chose Swarm, and for all its faults it's running fine.
1. Open source politics aka is the project viable? 2. Where's the money coming from? Aka, what products/companies build solutions off the tech? 3. Look for growth, not survival. If a company is not growing, it is dying.
These extra three test "gates" help me select what technology I will use, learn, and bet my career on....
https://github.com/rancher/k3s
> k3s - 5 less than k8s
> Lightweight Kubernetes. Easy to install, half the memory, all in a binary less than 40mb.
Not really as a simpler Kubernetes installation model.
Unlike Kubernetes, Swarm deployments are actually maintainable by a small team (or even a solo sysadmin). If there is a bug (there always are), you can actually diagnose or even debug it without the feeling that you're wrestling with a 800-lb gorilla.
I love how easy it is to spin up something new with a simple YAML file, but I've no idea what it would be like in production - how are rolling updates handled, for example?
As the cloud providers adopted Kube, I knew Swarm would loose. Now, the answer is, "use an API" don't run it local if you don't have to.
I understand somebody wanting to type "docker run xxx" and have everything setup automatically, but if you're running anything but default networking and actually care where the xxx image comes from, it's gonna fail miserably. Coming from the VM world, I found it much easier to work with macvlan interfaces that lxd supports for example - the container gets it's own interface and IP address and all networking can be prepared and set up on the host instead of some daemon thinking it knows my firewall better than me...
Containerization has obviously been around for ages before Docker came on the scene, yet it's adoption has dwarfed that of other similar solutions, why is that?
People have to start with a technology somewhere, if they get frustrated with the process, often they'll discount it and move on, that first moment of success of "ohh that was easy" is really important.
Docker has that. Sure it hides a wide variety of complexity under the skin that, in more complex deployments, can come back and bite you , but for people getting started it's much easier than the alternatives.
The "App store" like nature of Docker Hub is another part of that, the ability to easily find base images that you can use to prototype solutions is super-useful as a beginner.
Of course once you've been using it a while, you might have questions about image provenance, vulnerability management etc, but those typically aren't part of the initial evaluation.
Containerization was mostly limited to Solaris and BSD. It took a while to get to Linux, in the form of Docker.
This makes some interesting reading: https://blog.aquasec.com/a-brief-history-of-containers-from-...
I use it for more than a decade myself and I liked the simplicity of it.
We used it extensively at my work in a Web company to package and deploy all our stack as far as 2006.
Another thing people use Docker for but shouldn't is application packaging. Using Docker you build one fossilized fat package with both all OS and app dependencies baked in. Then some day after years of using that Docker image you need to upgrade your OS version in the image but you can't replicate the app build because you didn't pin exact library versions and the global app repository's (pip, npm) later version of the package is no longer compatible with your app.
Application packaging is better to be done in proper packaging systems like rpm od deb or other proprietary ones and stored in organization's package repository. Then you can install these rpm packages in your Docker images and deploy them into cloud.
The difference in OS dependencies and app dependencies are clear when looking at contents of actual dockerfiles. OS dependencies are installed leveraging rpm or deb ecosystem. Apps are cobbled together using a bunch of bash glue and remote commands to fetch dependencies. Why not use proper packaging for both OS and apps and then just assemble the Docker image using that?
Exactly. Most uses of Docker are like a junk drawer: neat on the outside, a total mess on the inside.
People stuff their python 2 app in there and forget what their dependencies are, or where they got them from.
Good luck upgrading that 2-3 years from now.
I wouldn't waste my time learning that if I were you. Software like python needs pip to build, they can't be built with the OS package manager alone.
Well yeah, OS packaging formats are for putting together your build artifacts. You can use whatever to build the software.
If you want to do it 'right' you would use pip to build packages for any missing runtime dependencies from your OS repos and the package your application. I swear it's much easier than it sounds.
But nothing says you have do it like an OS maintainer though. You can also just vendor all your dependencies, slurp them all up in an RPM and install in /opt.
Then you proceed with bundling in higher level OS dependencies, because each app is not just a Python package but also a collection of shell scripts, configs, configuration of paths for caches, output directories, system variables, etc. For this we throw everything into one directory tree and run FPM [3] command on it which turns the directory tree into a RPM package. We use a fpm parameter to specify installation location of that tree to /opt or /usr elsewhere.
The way to bundle it properly is to actually use two rpm packages linked together by rpm dependency. One for the app and the other for the deployment configuration. The reason is you only have one executable, but many possible versions of deploying it. Ie. depending on environment (dev, staging, prod) or you just simply want to run the same app in parallel with different configuration.
eg. one rpm package for the app executable and statix files
my_app_exe-2.0-1.noarch.rpm
and many othe related config rpms
my_app_dev-1.2-1.noarch.rpm (depends on my_app_exe > 2.0)
my_app_prod-3.0-1.noarch.rpm (depends on my_app_exe == 2.0)
You then install only the deployment packages and rpm system fetches the dependencies for you automatically.
There are other mature places who use similar techniques for deployments, for example [4].
All of this then can be wrapped in even higher level of packaging, namely Docker.
[1] https://github.com/pantsbuild/pex [2] https://code.fb.com/data-infrastructure/xars-a-more-efficien... [3] https://github.com/jordansissel/fpm [4] https://hynek.me/articles/python-app-deployment-with-native-...
All engineers have to learn how to package their stuff.
https://docs.docker.com/network/macvlan/
And you can tell also Docker not to touch your iptables rules.
https://docs.docker.com/network/iptables/
I don't think I've ever run into a container in the wild that is dependent on a specific network plug-in.
Well there's your answer. Simple things gain traction.
But yes I agree (as a former Docker Inc employee and current maintainer of moby which is what Docker is built from), the default networking in Docker is often problematic... firewall handling is annoying, at least from a sysadmin perspective.
The use case is an individual developer who wants to get a test environment up and running quickly without needing to understand how IP routing works. It's great for that use, not so much for workloads in production.
How about MySQL as a counter argument? It's always been feature-weak compared to PostgresQL, with a less business friendly license and now owned by one of the most despised software companies by technologists. But it's probably still the default relational database people pick up. Habit, defaults and massive installed base can go a long, long way.
That's not really a meaningful statement to make. A singular "better" seldom exists outside children's discussions. MySQL for a long time had a more compelling multi-master situation, for example, and was simpler to operate as there was no need to schedule vacuums and fewer reasons to stop the database during normal operation.
But none of that is really relevant for choosing a database. It's an enabler technology, just like an operating system. You seldom set out to use a certain database, you set out to use a certain application and then choose a database and an operating system that fits the application's use case.
None of that is true for containerization technology. Any requirements come instead from the infrastructure layer, and the application is made to fit those instead of the other way around. Other than that, you are free to choose whatever has the least complex operational requirements. If I was an investor in Docker Inc. I'd carefully consider what that means.
Now, implementing DBMS with even basic SQL query language, is not a trivial job.
Reception still doesn't seem great.
In past year, PostgreSQL not only caught up but also surpassed MySQL in terms of performance (I think MySQL might still be faster if you mostly read the data, but I'm not sure) and operational features, so at this point not only you have as fast (and actually faster for writing workload) but also have more features and much much better reliability. So it is no brainier to use it right now, but earlier you had to choose what was more important to you.
For many years MySQL had a much clearer multi-master replication story than PostgresQL. For most use cases, other features are secondary to replication.
I'd say the opposite - for most use cases, replication doesn't even figure into it. I guess we both need to find more solid evidence than our own opinions.
To each their own.
And there are a lot of systems for which downtime really is acceptable, at least for the amount of time it takes to restore a backup. Not everything is a front-end, mission critical system. I manage plenty of systems that are only used in a back-end batch context.
So I think it's crazy to suggest that how well a db engine's replication work outweighs all other factors. Depending on your situation it may well be the most important thing, but there's a lot of room for others to have well-architected systems that have different priorities.
The database is the hardest component to switch and even if the company were to disappear today, it would take decades to migrate off.
Docker has none of this. It only happened a few years ago, it will be gone as quickly. It doesn't even have a strong brand name, people want kubernetes not docker, docker is merely a dependency that can be replaced.
MySQL also had (relatively) straightforward replication features since way back, something that is much newer to Postgres.
For info, I used MySQL for over a decade, and am a relatively recent convert to Postgres - and I love it!
Containerization is still on the rise and Docker is part of that. The toolset is still a good, fairly easy to use, place for individual developers to use containers on the client-side whilst creating containerized applications.
For smaller deployments (without orchestration) a single Docker engine with things like compose, can still work well.
Obviously on the orchestration side, Kubernetes has won, although it too will face the inevitable trough of disillusionment when people realise that all technologies have downsides.
Personally, for simpler workloads, I think Docker swarm can still be a good answer, as it's a lot less complex than Kubernetes to set-up and maintain.
The idea that the Redhat container stack (podman, CRI-O, et al) necessarily mean the end of Docker, doesn't really follow at all to me.
If anything the increased use of containerd directly is a bigger threat to Docker's market share.
And without enterprise sales, what is going to fund docker development for the small and simple docker workloads?
Of course, whether that will give them enough success to justify their valuation, is another matter. Personally, I had thought they would get bought out by one of the large tech. players who is heavily investing in containerization (e.g. Microsoft) but that doesn't seem to have happened so far.
Especially considering the work the Docker company is doing to support OCI. The dockerd internally uses containerd now, which supports both Docker images and OCI images.
That's confusing the product and the technology.
The technology is containerization, not Docker. Containerization is on the rise and will continue.
Docker as a product AND a company, is doomed. They have no business model and no sales. All of Google/Amazon/RedHat/Linux are working on a substitute so they don't have to depend on it.
The hype is in Kubernetes now and managed cloud solutions. Docker is an accidental dependency of Kubernetes, until it's finally get rid off.
However, I think it's premature to write off Docker the technology. There's a load of scripts/tooling/mindshare baked into the Docker model for executing containers, and I don't think that's going to switch to another model overnight.
As many people have commented on this thread, the killer app. for Docker the technology isn't running in production, it's running in development, where you're unlikely to want a full k8s cluster.
I hate to break it up to you but the model already switched overnight.
The job market is the biggest indicator for sure. Any experience with Docker is mostly worthless at this point. No company will hire somebody with Docker experience alone, without Kubernetes.
Kubernetes has replaced most of what you mention with its own idioms and tools. All the way from the lips of the CEO to the engineers in a F50, it's talking Kubernetes, not a mention of Docker.
My experiences are that every k8s cluster I've seen uses Docker as the underlying CRI and in development land, Docker as a product is very prevalent.
There is another thread discussing that RHEL 8 is replacing the docker command with its own command line tool. Looks like it's happening sooner rather than later. There is a lot of work going on industry wide to replace Docker, can't deny that either.
I personally find it very ironic that Kubernetes only supports docker (more or less) while it's trying hard to never use the word docker and it has a whole concept of replaceable container engines.
From what I've seen they don't have huge traction outside of Redhat for their stuff, so all the other major players in the space (Google, Microsoft, Amazon etc) are not shifting to use Redhat's stack.
so the challenge is, can they convert developers from using the easy to use Docker, to their newer more complex setup? I'm not sure I'd bet on that. Anecdotely, it doesn't feel to me like Openshift is winning the "Kubernetes distro" fight, if what I see on reviews is anything to go by it's mostly kubeadm, kops, Rancher or GKE/AKS/EKS.
So Redhat replace bits with their tooling, Google do the same (kaniko, GVisor et al) Amazon continue to push Fargate and serverless, there's not a unified "replace docker" effort, more a splintering of tooling/services.
My personal view is that on Dev. desktops Docker still provides the best experience. That will continue to keep them relevant until someone else can replicate/exceed that experience.
The is yet more of the ecosystem continuing to push over engineered tooling and 'winners' breathlessly without basic technical scrutiny that leaves end users dealing with needless complexity and debt.
Containers can be useful as a lightweight, efficient alternative to VMs and those who want containers untouched by questionable ideas should try the LXC project on which all this was based.
Any additional layer on top of this be it non standard OS environment or layers should meet technical scrutiny for end user benefits and most users will be surprised by the results.
What is Podman? Simply put: `alias docker=podman`
Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Basically, podman/podlib allow you an easy migration path from your local computer to a k8s cluster, with the same images and same concepts. Have a look here: https://github.com/containers/buildah#buildah-and-podman-rel...
Could you expand on that please? Almost everything I run locally (be it a self-hosted service or app devel) with docker is a docker-compose stack. It allows me to easily manage/monitor services via CLI or Portainer. How does Podman and other modern tools offer to solve this case, or is it proposed now to use K8s locally?
I got enthusiastic about Podman not having a daemon and running Podman containers as a non-root user[1].
[1] https://opensource.com/article/18/10/podman-more-secure-way-...
In docker-land, `apt install docker.io` gets you a working container system with image management, network management and container operation.
To get the same functionality on the RH side it is (from what I can see)
skopeo+buildah+podman+CNI for networking, then if you want to run that under Kubernetes add in CRI-O
Sure for more advanced use cases breaking that all apart could well have benefits, but for ease of getting started, Docker seems better.
Server? Use CRI-O + kube.
CI/CD (that needs to build a container)? Use buildah.
And use skopeo for copying images around when needed
You could argue this makes it more difficult to run containers on the server without kube, and you'd be right. Whether or not that is a bad of red hat to do I'll leave up to others.
build containers to confirm that your build steps all work ok, so Podman + buildah, then you might want to
... push them to a repository to collaborate with a colleague without setting up CI/CD, so Podman + Buildah + skopeo.
Then you might want to execute the containers to test to see whether your code is running ok....
the point I was making didn't relate to running containers on servers where typically things like CI/CD will be part of the process, but to new developers and devops people getting started with containers.
For debian/ubuntu users (of which there are a fair quantity) whilst podman's install process looks like that, I don't see it taking over from Docker any time soon.
Not to mention Windows/OSX users.
Ease of use should not be overlooked when it comes to developer tooling. Podman can be the most technologically advanced solution, but if it's a pain for developers to get going with it, it's not going to replace Docker any time soon...
Is buildah an alternative to Kaniko then?
Docker's got lots of runway providing enterprise support contracts, so I'm not worried about them.
I think the author's also not noticing that orchestration was really a bit of a stumbling block that would eventually be removed. Sure, you've still got to use k8s in self-hosted, GCP, and Azure, but those of us on AWS have the option to use ECS with Fargate and have many of the core features of something like Kubernetes fully managed.
So anyway, this post is a bit dramatic, and maybe has a few blinders on.
One argument is that there are no new big features. But that is completely normal when things become stable.
Why do people hate Docker, the CLI. Anyone? I mean, it's slowly going OCI, so no vendor lock-in.
Those are my biggest pain points with Docker at the moment. I have a complex build script that uses multi-stage builds and rsync to achieve this [1], but it's still a bit slow and inefficient. Would be nice if something supported this out of the box.
I've worked on a lot of projects where people just reinstall (and recompile) their entire list of dependencies (Ruby gems or NPM packages), and you have to jump through hoops to set up a caching layer, or maybe install them into a volume as a run-time step, instead of at build time. There should be a much better native solution for this, instead of needing to invent your own thing or read random blog posts.
[1] https://formapi.io/blog/posts/fast-docker-builds-for-rails-a...
I don't know if the Dockerfile format is really suitable for this, but you can now build your own format and Docker can just build it.
Basically buldkit breaks things down into a frontend format (like Dockerfile) and a frontend parser which gets specified as an image at the top of your file (`#syntax=<some image>`), the parser converts the frontend format into an intermediary language (called llb), buildkit takes the llb and passes it to a backend worker.
This all happens behind the scenes with `DOCKER_BUILDKIT=1 docker build -t myImage .`
Docker actually ships new Dockerfile features that aren't tied to a docker version this way.
Actually there are a number of new Dockerfile features that might get you what you need, even if the format isn't all that great, at least it's relatively natural to reason about. Things like cache mounts, secrets, mounting (not copying) images into a build stage's "RUN" directive, lots of great stuff.
This is all officially supported stuff.
Here's a demo of "docker build" building from a buildpack spec instead of Dockerfile: https://github.com/tonistiigi/buildkit-pack
- buildkit - https://github.com/moby/buildkit - official Docker docs - https://docs.docker.com/develop/develop-images/build_enhance... - buildkit Dockerfile docs - https://github.com/moby/buildkit/blob/master/frontend/docker...
Your use case is one I've been planning to support all along, although I think about it a bit differently - in terms of composition of (partial) images rather than multiple inheritance.
[0]: Dev blog: https://www.narrowband.org.uk/
Even more, the argument that because Redhat RHEL 8 no longer has a Yum repo for it Docker is dead in the water is a bit far fetched. According to Wiki RHEl is a fairly small % of the server market compared to Ubuntu, Debian and Windows for that matter. https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...
Podman just makes more sense because it doesn't require a big fat daemon. You launch containers like any other service: with systemd. And you can run podman without root permissions as well, which is a huge win for security.
More important, I only saw RHEL at traditional Fortune 500 companies. Not sure how their market in FANG type companies is. Probably negligible. F500 is still big of course.
There are two distributions left in Linux, RedHat derivatives and Debian derivatives. In terms of install base, it's maybe 1/3 and 2/3. In terms of money, expect the other way around, because it's F500 who pay the most for software and they are on RedHat.
RedHat is actively trying to kill docker (along Google and Amazon). RedHat removing "docker" CLI and replacing it with its own tools is a major step toward that. Docker will be de facto dead in enterprise as soon as it stops being supported by RedHat.
There is nothing that prevents RedHat to ship an alias to their own tools by default, just like java => openjdk.
It's not the responsibility of RHEL to maintain or support third party software. If case you didn't know, docker stopped shipping with Debian years ago.
The day RHEL customers stop using the docker runtime is when RHEL will stop supporting it - until then, they'll support it. Case in point: java -> openjdk.
Anyhow, this article is just click bait, and it's been done at least twice a year since Dockers inception. I'm disappointed that this community finds shitposts like this more compelling than the NSA opensourcing a reverse compiler, but I digress.
Have fun in your bubble.
There are just too many little details that have not been fixed year-on-year.
So far, the Docker for Mac is a solution that just works.
If someone have some experience, I'll gladly want to know how you make it work flawless.
As of the latest versions of Docker, the dockerd is now using containerd under the hood.
I'm not sure how the Docker CLI will exactly die. The posts seem to focus on the CLI only, and even calls out that "the viability of the company Docker is outside the scope of the post", but it failed mention my previous points.
It's true that Docker uses containerd under to hood, but that's actually part of what the author is arguing. Docker as a technology is a wrapper platform around core industry technologies that they neither own or control. That means they have to compete as a tooling company, and they have already lost ground there. The more things like Kubernetes and podman join the market, the less required Docker becomes, which means they're going to be more and more at risk of failing.
https://en.wikipedia.org/wiki/Linux_Foundation#Containerd
edit: added link for reference
A large majority of even the recent commits to containerd are made by Docker employees.
https://github.com/containerd/containerd/commits/master
> It's true that Docker uses containerd under to hood, but that's actually part of what the author is arguing. Docker as a technology is a wrapper platform around core industry technologies that they neither own or control.
I cede your point, but it's irrelevant and isn't want the author implying (even directly).
From the article: "I do not think there is any reason for us to user docker any more and therefore Docker as a technology and as a company will slowly vanish."
The end users do not care how cgroups are setup or mount points are built. The guts may be standardized, but the docker toolchain (Dockerfile, docker-compose, docker run) will continue to exist. The "runtime" is irrelevant and there just isn't a competitor in the "tool chain" arena.
Docker Swarm is the only thing that will vanish.
> The more things like Kubernetes and podman join the market, the less required Docker becomes, which means they're going to be more and more at risk of failing.
Kubernetes is an entirely different use-case. Nobody is arguing Docker Swarm will beat it.
You could say the Docker CLI isn't required with the advent of other tools, but those are incredibly big shoes to fill. Think of all that entails (Dockerfile, docker-compose, the CLI, cross-platform(-ish) support for Windows/OSX).
Also, competition leads to better tooling. Did anyone ever say "Unix isn't required any more, because with have Linux"?
The tooling of the Docker CLI is in a very good spot as-is. The guts are being opened, which I think would relieve the pressure some may feel to jump from Docker.
Where do you get this information from?
As you've noticed there's a load of solutions who make use of Dockerfile formats and store images on Docker hub.
I'd expect that there will be future developments, but that they'll be backwardly compatible with existing deployments.
Docker Engine (the daemon running on a single host) and Kubernetes (the orchestration system) largely serve different needs.
Kubernetes is good for large scale deployments where it's additional complexity is warranted.
For running groups of containers on a single host (or small number of hosts) Docker does just fine.
JavaScript comes to mind. If it’s widespread and easy to learn, it might not matter how much technically better other alternatives might be.
We’ll see
Docker played a pivotal role in creating our modern understanding of containers and we should be thankful for that. I don't understand the value this article provided beyond pointing out a few container runtimes I hadn't heard of.
I do understand the market dynamic but still there are niches for other simpler products.
They're encrypted in transit via mTLS.
https://containerjournal.com/2019/01/22/5-container-alternat...
Container orchestration is light years better than anything that we were doing on the operations side before. This is why I find it extremely hard to believe we are going back. We would need something much better to jump to and that has not been invented yet. So, Orchestration/Docker/Containers are here to stay for the foreseeable future.
The rkt image format tried early on to subvert the Docker Image format and was unsuccessful. Today, there is much more depending on the existing image standard. You would totally fragment the existing integrations if you attempted to change. I am not saying that people will not try. But, I just cannot see it happening anytime soon. You have all these Clouds betting on it, you have millions of Dockerfiles out there now, and tons of people trained on it. All these CI/CD platforms supporting it. You would need some massive reason to change. Why would they? You might see people under the hood take the Docker Image and wrap it somehow, like gvisor [5], but they will still likely accept the Docker Image.
Go look at these charts from Datadog about their customers Docker adoption [6]. Every single chart is hockey stick growth. This is a sampling of 10,000 companies running 700 million containers in real-world use. I am just offering a counter to the point that the image format is coming to its death. I do not see that.
Disclosure: Former Docker employee.
[1] https://aws.amazon.com/ecs/
[2] https://aws.amazon.com/eks/
[3] https://cloud.google.com/kubernetes-engine/
[4] https://docs.microsoft.com/en-us/azure/aks/
But the point of the article is that the part that Docker provides in that stack is not secure. There will be and already are alternative container engines underneath k8s.
One day a simpler, quicker alternative will gain enough traction with Kubernetes (and others) and Docker will wither away. As a company.
That happens all the time in tech. Websphere -> Tomcat -> Jetty, Apache httpd -> Nginx, VMs -> containers, etc.
And it will also happen to Kubernetes one day. Yes, the helmsman will also be replaced by a nimbler modern replacement.
The first line says differently.
CLI usability is close to zero. One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't.
Yes it seems their days are numbered.
What?
> One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't.
I completely disagree. Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Why don't you like it. You could always build with "--no-cache", which all CI should be using anyway.
Yes.
It's all over the place. https://docs.docker.com/engine/reference/commandline/cli/
It has no obvious separation of commands dealing with images/containers/running containers. Sometimes you refer to them by tags, sometimes by IDs.
It's non discoverable. It's non intuitive.
I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images?
Docker build has this nice example here:
'--tag , -t Name and optionally a tag in the ‘name:tag’ format'
Ok so you set a name with --tag?
Compare with 'kubectl get pods'
> Cached builds being one reason, viewing the intermediate layers is just a huge benefit.
Sure, as I said, it is useful, but you do not want to do this most of the time.
> You could always build with "--no-cache", which all CI should be using anyway.
Bad defaults are an UX problem, thanks for furthering my point.
> I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images?
I think you're using the old CLI. A couple of years ago, they added new syntax and "encouraged" its use by default [1] (though IME people still use the original).
This is definitely more discoverable and logical; the syntax would be `docker image rm` [2] or `docker container rm` [3], etc
[1] https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ [2] https://docs.docker.com/engine/reference/commandline/image_r... [3] https://docs.docker.com/engine/reference/commandline/contain...
Thanks for pointing this, and I'm glad they realized the issue as well!
We could already build chroot environments. We could already keep remote images. We could already set up app-specific networks. Having the tools wasn't what we needed: it was the confluence of all the features.
If the alternative to Docker becomes learning 50 new tools, we'll have failed as an industry, and shouldn't call ourselves engineers. You don't replace a car with a wheel barrow-lawn mower-hand held radio-portable fan. This obsession with churning out a new tool every year has to stop.
But that's the life I expect, not the one I live today. In the present day I'm much more reliant on docker than on kubernetes, and I cannot live without being able to freely mix and match go, python, or Java , really old and really new, in any host configuration I want.
I haven't heard anything about this from AWS. Certainly they've introduced EKS, but I haven't heard anything about setting their ECS orchestration out to pasture. Does anybody have information about this?
Easy to debug and lightweight would be also great. I didn't really found something good.
For everything that resembles a microservice/service -> Docker, everything else (ldap, mail) -> oldschool. So far so good.
I'm looking at k3s or minikube with rancher as ui - maybe that's better, or we just ignore the hype and run docker-compose.yml files by hand but that's also pretty shitty.
I don’t see it being switched out for any unproven technology any time soon.
I think I've seen one person use docker once, back in about 2013, to create and freeze a very particular Latex setup. Everybody sees a tiny slice of the world, but to each individual, that slice looks like all of it.
Bypassing all OS packaging systems. It’s a hack on top of our broken packaging models. That does work but it is extremly fat and not very elegant.
Next is Docker Enterprise. Can they sell it? This is where Docker is making mistake after mistake IMO. Docker does have a leg up in Windows. But does it matter? Today Swarm is your only orchestration option and while I understand k8s support is coming it still remains to be seen if GMSA is included in the first release (doubtful). If you're a Windows developer and you're deep in the Microsoft ecosystem, you won't be able to productively use Windows Server and k8s this year is my guess given the timelines.
Regardless, Docker has done a poor job capitalizing on Windows. Maybe it's that people just don't need it as much as Docker would have you to believe? Or maybe it's too jarring of a workflow change. Regardless, it isn't working.
Next is the products you get for the money: Docker Universal Control Plane (UCP), Docker Trusted Registry (DTR) and Docker Enterprise Engine (EE).
They're all OK. But the sell is, again, tough. UCP is basically a dashboard for centralizing RBAC for Swarm and UCP in the enterprise, and don't get me wrong - the enterprise needs this. But UCP feels lacking. The UI is distracting and has a lot of oddities. Managing it is a decent amount of work. It's just OK. Also Docker UCP still doesn't support k8s PaaS while competitors do. Remember that Docker hired Kal De away from VMW as CTO. In his time at Docker not much has changed externally, but Docker needs to move faster. Much faster.
DTR is interesting because everyone who's doing containers in the enterprise needs an image repository with, again, those enterprise requirements. And DTR delivers this, but Docker doesn't want to sell you DTR only. You can't buy DTR by itself like it's competitors. Docker wants you to only use all of their bits and it's dumb because Docker claims choice as a core pillar then tries to lock you into UCP+DTR+EE. Oh I see Steve... Choice as in what DOCKER defines for me as choice. Choice of bare metal or hypervisor, but not how I manage containers and orchestration? Back to DTR: it's decent, but again there are other choice and a lot of them are better standalone offerings.
Finally EE. There are about three reasons you really need EE. The first is enterprise support and long term releases. The second is runtime enforcement of signed images at the engine level. The third is oddities like FIPS support. But that's it. And, again, Docker doesn't want you to buy just Engine. They want to sell you the 'platform'.
At the end of the day Docker has good products. They're not exceptional when taken into context of other enterprise software. They're just OK. Docker doesn't realize this yet from what I've gathered. They have recently changed pricing to very VMW-esque CPU count pricing. And Docker doesn't have the market capital to make that leap, unfortunately. At the end of the day my opinion is that Docker is marred by Docker. Not by the competitive landscape. Yes, that contributes to Docker overall but Docker doesn't seem to make sure they have the best product above everything else. Docker's CEO, Steve Singh, is the wrong guy for the job. He is constantly stating cash flow positive by end of this fiscal year yet doesn't seem to care about how good or bad the product actually is or why people wouldn't buy Docker over something else.
So yeah... Docker has done great things. Those great things are all of the contributions Docker has made to the community and continues to do so. But Docker on the enterprise side feels weak, lackluster and very confused. Docker is marred by Docker management and executive ranks from within. I'll give them 2 years make or break and I think, as it stands today it's a coin flip. The acquisition of RedHat by IBM was a good thing for Docker, but may be the nail in the coffin for RHEL long term. If Docker does flounder any longer look for them to be acquired by Microsoft. And then... Docker will be set to sail off into the ether.
I ask because I'm wondering if I should care about docker in the beginning of my project which will have very few concurrent users/requests and would run fine on a single machine.
EDIT: Thank you to all the kind answers!
I use docker for a small server at work, where I know there will only ever be one container per image.
Where docker is incredibly useful is with non-free software which works on Linux. Usually, they rely on a specific version of Debian or Ubuntu. Yes, this can be achieved with VMs, but that requires running 5 or 6 kernels. So for us it's a huge resource win over VMs.
For me, Docker sits between chroot and full-blown VMs. If you drop privileges you actually do have some security advantages over chroots and separate processes – although I don't think Docker emphasises this enough. The way Docker is used and the way it is documented seem to have a disconnect.
> I ask because I'm wondering if I should care about docker in the beginning of my project which will have very few concurrent users/requests and would run fine on a single machine.
If it doesn't solve any problems you have I personally wouldn't bother – you can always "dockerize" after, which should be a relatively straightforward process. At this stage it's just a distraction. Good luck.
The other thing that Docker does is run in a namespaced environment such that apps don't have access to the local file systems on your host by default. This is also a problem that's been solved since the dawn of Unix by eg. using file permissions (though admittedly not every scenario is served well). Docker apps don't have access to the host's access control infrastructure (/etc/password, pam, etc.) though, so Dockerized apps need to invent their own ad-hoc auth.
The only problem that Docker is really solving is that you can pack more apps on a single host compared to full-blown VMs. Basically, Docker is infrastructure for cloud providers to sell you lots of pods cheaply (for them, that is). Since many images are based off Debian (pull in deps via apt on first start), it could also be argued that Docker is acting as GPL circumvention device of sorts.
More people should become hip to pkgsrc.
If all I use is Debian on my server with a file that always installs the required packages and I don't need isolation between services, should I care about docker as an "end-developer"?
It's somewhat similar to static linking, but at a higher level.
Ten years ago we build things in C#, used MSSQL and deployed to IIS. All Microsoft tech, all pretty straightforward, except it wasn’t. We never kept track of the “it works in dev, but it explodes in prod and I don’t know why” hours, but I wish we did. Because it’s in the thousands, and those thousands of hours is exactly why we use docker.
We also use docker because it lets us build things that our IT crew isn’t certified in running infrastructure for (and the lovely security issues that brings to the table) but we mainly do it because it works.
Docker might not have a monopoly on that, but they have enough of a brand that the word “docker” is to containers what “google” is to search. At least in my circles.
I know you can do this with VMs too, with tools like Vagrant, but containers start in a couple of seconds - great for integration tests.
It is amazing how many technologies get traction simply because "It lets us bypass IT."
To manage our IT had to make certain infrastructure decisions and build their competency around those. This clashes with a lot of modern development, but we manage with docker and an increasing Azure presence. It’s not optimal, but sometimes it’s just necessary. Don’t get me wrong, we’re trying to improve and build Devops that isn’t handing off a container, but it’s a challenge in sectors where digitisation and IT aren’t priorities despite being an inherent part of any business process in 2019.
There is a real danger in there of course, but we have strategic choices for our development platforms as well. They just need to move a little faster than IT.
For Linux containers there is LCoW, which uses a Linuxkit VM to host the containers.
There is also some chance that in the future Linux containers will run natively on Windows without a VM, via WSL. This is very hacky at the moment but there have been reports of people being able to run Docker engine in WSL with no VM.
Then with docker-compose you are able to instantiate custom deployments of your projects, including dbms and gateways and messa buses and IAM services, with a single command (docker-compose up).
So yes, it's very useful.
However, the point of the article is that Docker is no longer the only option, and although right now it's the default go-to container tool, there is nothing but inertia keeping the world using Docker.
Then it's trivially fast to pull and run the image on any machine with Docker or K8s installed.
Yes, you can clone the SD card, but I think it's cleaner to use a version-controlled Dockerfile. Otherwise you always need some master SD card to clone from (and keep track of a multi-GB image file), and you have to faff with resizing images if the new card is smaller.
A fresh system install is then: flash Raspbian, update system, setup some init scripts, install docker, pull the image and clone the latest version of the code from github.
This is also the approach embraced by Balena, who (conveniently) provide Docker base images for a bunch of common embedded systems.
Another reasonably big user-base is machine learning.
None of it really requires docker, but it's nice to have the whole environment encapsulated, and having a record of what I had to do to get some of these things to install is invaluable.
I have a shell script which launches the container (I just run a new one) every time the Pi boots.
That's what Docker does. It lets you wraps everything into a single isolated package (a container) that can run whatever you want without affecting anything else on the system, and then cleans up perfectly. You can connect it to networks and disks but There were APIs for most of these things already in Linux but Docker brought it all together into a simple interface.
The other big innovation is the Docker registry that makes images easily available over HTTP. No more complicated downloads or package systems, instead you could just point to a simple host/image:label address and download whatever you need. That simplicity and flexibility is what made it take off.
I have an application with a long, tedious setup process involving dozens of apt dependencies that I don’t maintain. In the past, I’ve had issues with things not updating properly, inconsistencies between versions, spontaneous breakages... Using Docker, I built an image that contains all the dependencies that are unrelated to my code or configuration, then another image relies on this and contains all of my stuff. My deployment process only needs to be concerned with updating this second image and all of the frightening dependencies are guaranteed to be consistent and reliable. This second image is deployed to each box. All of the production systems are identical and if I need a new production box, I can have it ready to go in minutes and be confident that it will work and behave reliably.
How, may I ask? I've been looking for a good way to do this for a long time; nowadays I'm using a checklist and AMIs on AWS.
Ansible is too damn slow, does not know how config files work and clutters the terminal/my home directory/my known_hosts.
Dockerfile is a badly written shell script using && instead of errexit.
FROM quay.io/my-acct/my-image:lateststart-daemon && configure-daemon-while-running && stop-daemon
The point is, I've seen far more && than RUN directives so the decision was backwards.
My company now deploys every app that can run on Linux as a Docker container, regardless of whether it needs a single instance or 50.
It's not as though it doesn't introduce its own problems for example - you might patch software on the host but you still need to patch it on the container and it can be difficult to get an inventory of that, say there's a zero-day found in nginx. You still require organisational discipline, that never goes away.
When I'm working on one service, I often depend on a few other services too. I usually need a storage layer, perhaps API calls to related services, it may even to talk some Amazon services like S3 or SQS. Having a simple way to spin up every dependency locally, even AWS (lots of great AWS API compatible images out there) is really useful if only for local development.
There isn't another runtime that is as easy to use as Docker.
The thing is that whilst various operations are shipping bits of the functionality that Docker provides in various different tools, for developers working with containers none of them (that I've seen) have an easy to use, cross-platform setup.
Cool kids are not using containers at all, they use cloud VMs and autoscaling :) Simple is not easy (tm)