Did you ever wonder how much traffic can a site get from Hacker News?
Here's the number after 10 hours on the front page: http://imgur.com/1AJcYij
I think its the responsibility of Docker users to understand the technologies they are using.
Docker has got into the bad habit of wrapping open source Linux technologies and promoting them in a way that makes it feel like Docker invented it. They did it to LXC and they are doing it to aufs and overlayfs. The HN community is far too vested in Docker to offer any real scrutiny and is very much a part of this hijack.
What is a Docker overlayfs driver? How is simply mounting a ready made overlayfs filesytem already present in the kernel or aufs a driver? These terms not only mislead but prevent recognition of the work of the authors of overlayfs and aufs.
They also require scrutiny as layered filesystems have tons of issues and the only way these can be resolved is engaging with the developers who most dockers users don't even know about. Docker can't solve these issues only work around them.
We build all our images on top of rhel containers that have undergone hardening to meet internal + regulatory compliance. The end result is that to some extent we can say to developers "dont worry about getting your applications production ready right away, just write reasonably stable code quickly and we'll strip out all the stuff we dont trust you to do and handle it at the infrastructure level".
End result is that we can start to eliminate some of the unsuitable uses for traditional middleware systems like our datapower infrastructure that, while being great for specific use cases, is usually to difficult to work with for your average front end developer who doesnt give a damn about soap headers and broker clusters.
As far as our architecture leads are concerned, and I'm inclined to agree, docker is a great packaging format for developer outputs because it puts everything you need to run an application naked (ie no complex logging, HA, Networking etc.) Into a single versionable, reviewable, very much disposable asset. But it is not, and should not, be a replacement for proper systems of record that require any measure of stability.
That said, there are quite a few mainframes that aren't going to be replaced any time soon, by either of OpenShift or Cloud Foundry.
So far, this has been stable for us, and based on your post it sounds like it will continue to be a viable strategy as we move to kernel 3.x or 4.x.
http://www.slideshare.net/aspyker/netflix-and-containers-tit...
Maybe you had trouble, but I think that those that aren't using containers need to be aware that many are using them successfully. Use of containers vs. VMs/dedicated servers can also result in reduced energy usage and can be less expensive.
I think people get hung up on what containers aren't and where they fail, rather than where they exceed.
The CDN that is actually pushing the traffic runs FreeBSD and would be using, if anything, jails.
On 28 Oct 2016 https://twitter.com/aspyker/status/792137233264418820 mentions "Lots of changes in the big cloud providers and container related leadership as of late."
Containers are becoming a big thing in the enterprise, which means they are here to stay.
Rackspace CDN-enables containers: https://support.rackspace.com/how-to/differences-between-rac...
Azure: https://azure.microsoft.com/en-us/documentation/articles/cdn...
etc.
For what it's worth, I agree with you that a lot of the value of Container Engine comes from having a team ensure the bits all work together. That should be (one of) the positives of any managed service, but I think the Container Engine team has done a particularly good job in a fast moving and often bumpy space.
Disclosure: I work on Google Cloud ;).
We have stuff that must stay on AWS, too dangerous to make a move now :(
We'll ignore the "switch to auto scaling" bit. Teammates have already started testing CoreOS & Kubernetes (on AWS) while I was writing the article. We'll figure it out and get it in production soon, hopefully.
We have a subsidiary which has no locking on AWS and could use an infra refreshing. They already have google accounts and use one or two products. They'll be moved to GCE in the coming months, hopefully.
Why drop autoscaling though? Note that you can use Autoscaling Groups with Kubernetes on EC2: https://github.com/kubernetes/contrib/blob/master/cluster-au... and the team would happily take bug reports (either as GH Issues or just yelling at them on slack/IRC).
(Sadly http://kubernetes.io/docs/getting-started-guides/aws/ doesn't point to this...)
I suppose that auto scaling will be back on the table later, to auto scale kubernetes instances. Maybe.
As others (including downthread) have pointed out, Google definitely has a bad overall support reputation, but that's because nearly every (traditional) Google service is free and lacks this structured support model. Just like Cloud, if you're even a moderately large Ads customer, you get pretty good support!
Disclosure: I work on Google Cloud and want your business ;).
One thing often not considered ("Why not just have someone keep it running?") is that you really have to keep a team of people on it (in case there's a CVE or something) or at least familiar enough with the code to fix it. There's also the double standard of "you haven't added new features in forever!" (Maybe this wouldn't have applied to Reader though).
But, I agree if we could have kept it on life support somehow, we wouldn't have (as many) people asking "What if they shut down Cloud?!?". Conveniently, as people get a sense of how serious Google Cloud is about this business, even on HN I'm seeing this less.
tl;dr it makes money, will make a lot more, they're going to support it.
A bit of context missing from the article. We are a small shop with a few hundreds servers. At core, we're running a financial system moving around multi-million dollars per day (or billions per year).
It's fair to say that we have higher expectations than average and we take production issues rather (too?) seriously.
I updated and fixed a few points mentioned in the comments. (Notably: CoreOS).
Overall, it's "normal" that you didn't experience all of these issues if you're not using docker at scale in production and/or if you didn't use it for long.
I'd like to point out that these are issues and workarounds happening over a period of [more than] a year, summarized all together in a 10 minutes read. It does amplify the dramatic and painful aspect.
Anyway, the issues from the past are already in the past. The most important section is the Roadmap. That's what you need to know to run Docker (or use auto scaling groups instead).