Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker's Second Death

tariqislam.com

Post reply on HN
Print view View original

71–80 of 286 posts

Re: Docker's Second Death

#71

Post by tariqislam_ »

zapita wrote: post #45

I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows. Kubernetes continues to use OCI, runc and containerd - so basically the…

Hey there. Author of the article here. I'm no longer a Red Hatter and my words are strictly my own.

I don't intend to push a narrative, rather my intent is to communicate what I experienced with Docker in an enterprise setting across time. A lot of this also comes from my time outside of Red Hat as well.

Re: Docker's Second Death

#72

Post by TuringNYC »

lima wrote: post #6

So, what's the better business model for a low-level piece of infrastructure like Docker?

Private repo host...because whatever they charge, it is cheaper than using an FTE to maintain it internally unless you want a flaky internal SLA.

I use it as a private repo host. The cost is a no-brainer. We'd probably pay 2x or 3x more compared to the value we're getting. The independence from the Cloud services (ECR, ACR, GCR) makes it a better option. Also, for now, there isnt any funny-math on multi-factor egress costs -- which become tricky to compute in real life.

We use it for containers to be run on k8s. As long as there are not super-low latency requirements for startup, I'd prefer an independent single private repo over multiple in-zone repos.

Re: Docker's Second Death

#73

Post by pm90 »

skrebbel wrote: post #11

I feel like I'm missing some key insight here. To me, the tl;dr of this post is: Kubernetes removed the need for Docker just to run container images in a k8s cluster, ergo, Docker is dead. But Kubernetes is super complicated . The author seems to assume that everybody wants to run everything in Kubernetes, but if I want to run some backend on some server (or maybe on a few servers), then it feels like extreme overkil…

Docker was always about making it easy for developers to build isolated applications. Kubernetes was about making it easy for cloud providers to support deploying these isolated applications in their systems. A lot of organizations tried to support docker swarm (or their own versions of an "ocean" of containers) but it was just too difficult, the products failed and/or were unreliable and docker didn't provide a toolkit to do this better. When they tried kubernetes, it worked (probably because kubernetes creators had experience from running an actual production system before viz. Borg).

So then cloud providers coalesced around the platform. People who learned the concepts found it easy to use and loved it and it fueled the adoption.

I still believe that despite all the hate that k8s gets on HN, its popular because it works and its users love it. There is very loud subset of users who makes their displeasure known very well but we have to look at concrete data on usage and the data points to k8s being a very popular platform for USERS.

Re: Docker's Second Death

#74

Post by goatinaboat »

skrebbel wrote: post #29
goatinaboat wrote: post #19

Earlier quoted context omitted.

But Kubernetes is super complicated. It can be, but running minikube or k3s on your laptop is trivial, and what you do with them transfers very easily to real Kubernetes.

Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? I mean, that was one of the key Docker promises, and they delivered to quite an extent.

Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert?

Yes absolutely, the YAML will just need to be updated for API keys or whatever.

Kubernetes is complicated to build a production grade cluster on bare metal but for getting started as a developer it’s no more complicated than Docker actually

Re: Docker's Second Death

#75

Post by solatic »

The writing for Docker for Mac is on the wall. It depends on a Linux VM, for which there is no business case to spend atrociously large amounts of resources to adapt for x86 container images to run on M1 ARM Macs.

For the life of me, I don't understand why Microsoft doesn't acquire Docker. Tighten the integration between Docker for Windows and WSL2, use Docker Hub to slowly push container authors onto managed Azure container registries, and use Docker Hub as a marketing channel for Azure.

Re: Docker's Second Death

#76

Post by ahnick »

skrebbel wrote: post #29
goatinaboat wrote: post #19

Earlier quoted context omitted.

But Kubernetes is super complicated. It can be, but running minikube or k3s on your laptop is trivial, and what you do with them transfers very easily to real Kubernetes.

Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? I mean, that was one of the key Docker promises, and they delivered to quite an extent.

Yes, a simple workflow is running Minikube or K3s locally for testing and then pushing it out to a managed Kubernetes platform like DigitalOcean Kubernetes. This avoids having to know any of the underlying details of setting up the Kubernetes cluster. Everything you do in terms of interacting with the cluster on Minikube will be the same as on your production managed Kubernetes.

All you really need to learn is some basics around Kubernetes terminology, the kubectl command line utility, and then some of the YAML config syntax for setting up application deployments and probably an ingress into the cluster. You can also add helm into the mix if you'd like to take advantage of pre-built packages that you can install to your cluster. For example SSL certificate management or a webserver ingress like nginx-ingress.

Re: Docker's Second Death

#77

Post by tariqislam_ »

tariqislam_ wrote: post #71
zapita wrote: post #45

I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows. Kubernetes continues to use OCI, runc and containerd - so basically the…

Hey there. Author of the article here. I'm no longer a Red Hatter and my words are strictly my own. I don't intend to push a narrative, rather my intent is to communicate what I experienced with Docker in an enterprise setting across time. A lot of this also comes from my time outside of Red Hat as well.

I'll also comment specifically on your remark: I never mentioned Docker's behavior in the community, good or bad. The story of the Summit shirts was to illustrate their entry as a competitor and how that changed the narrative. I give Docker immense credit for what they did, and I state as much toward the end of my post.

Re: Docker's Second Death

#78

Post by [deleted] »

Donckele wrote: post #46
hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

Phew, thanks for that. That article got me all agitated, thinking a core piece of tech I use is on its death bed with no alternatives.

[deleted]

Re: Docker's Second Death

#79

Post by manigandham »

andrewguenther wrote: post #7

Docker Inc's antagonistic attitude towards Red Hat and personal attacks on their engineers was the beginning of the end for them. The people who really headlined those attacks are now gone, but the damage was done. Docker made it clear from the beginning they had no desire to be part of a community and now the community is leaving them behind. Good riddance.

If you say those people are gone then what's still clear about it or why is it good riddance?
Post reply on HN