Interesting to see this called a Series B. Did Docker hit reset after the split?
Here's a separate thread for "Docker Series B: More Fuel To Help Dev Teams Get Ship Done" - with a bit more info on what the plan is from Scott.
Interesting to see this news on the same day that "We don't need Docker" was also on the front page of Hacker News. I think we absolutely still need Docker in 2021.
> "We don't need Docker" was also on the front page of Hacker News.
I read it as a typical "We don't need [Complex Tool] because we don't have [Complex Tool Solutions] problems". Not trivializing it, I think those articles are valuable hype-free analysis of the latest tool-of-the-day. "They don't need Docker" and "We absolutely need Docker" are non-contradictory.
There are two very different and kind of opposite "we don't need Docker" perspectives. One is that of the previous article— "we don't need docker because we don't need containerized environments since our tooling produces a single binary which somehow has no dependencies, configuration, or data files, so there's nothing to containerize."
The other is "we don't need Docker because we use tools like buildah, img, or kaniko to build OCI containers, our devs use podman, and we run this stuff in prod on a someone else's k8s PaaS that under the hood is backed by containerd."
Maybe, but it's such a balance. I'm finally getting into Kubernetes and after years of hearing how awful it was to get it going, I was shocked at how painless it was to stand up microk8s locally and sling Helm charts at it, get Jenkins generating agents on it, get metrics from it, etc. If I were deploying something to a cloud, I would absolutely do this approach with some k8s-as-a-service provider over rolling my own machine images or having to deal with remote controlling instances using something like Ansible.
Yes, it would be possible to get sucked down a rabbit hole with over-emphasizing scaling, clustering, whatever upfront, but IMO these tools are now mature enough that it's a reasonable workflow even if you're just deploying a single instance of a container with one statically-linked binary in it.
Yesterday was in a meeting discussing our build pipeline and we had this moment of introspection where we realized "wow, we do a completely containerized, micro-serviced app and it actually works really well for the most part". When Docker was very new I remember dealing with all manner of bizarre issues, mostly because the engineers just weren't used to how to use it yet. But if you have some decent idea of how to architect it then Docker is a huge boon IMO.
People are also totally right to question why some new fancy tool is needed when the old way works. Its best to just view all these things as tools at your disposal rather than necessities.
Better to think of these titles as "When you might need Docker" and "When you might not need Docker" so you can consider the tradeoffs rather than interpret it as a blanket statement, Docker is good/bad.
A lot of those articles and posts are what I think of 'exploratory' someone doesn't want / need a thing,t hey present their way of doing things and we can all learn something from them... even if we don't do things like they do.
God knows how much "don't need JavaScript" gets posted...
There's also, though, things like K8S not using Docker, podman becoming popular, etc. Neither is a definitive nail, but it does erode Docker's moat a bit.
The difference being that Google has deprecated the shimming to Docker they had been doing with the “Docker” runtime to access containerd, so now it will go straight to the source by default.
Red Hat OpenShift also switched from using Docker as its runtime with OpenShift 4 in 2019, though it was in favor of CRI-O rather than containerd.
All accurate. My point is that Kub deprecating the shimming does not affect Docker’s popularly or market share either way. The existence of the shim was an implementation detail and Docker themselves have been encouraging the switch to containerd. They clearly want the Docker brand to be attached to developer-facing tools instead of a hidden piece of increasingly commoditized infrastructure.
If a critical mass of kubernetes deployments switched from containerd to cri-o, that would be more problematic for Docker, but that seems unlikely to happen. Openshift to my knowledge is the only major kubernetes distribution not based on containerd. At this stage of the adoption cycle, cri-o is unlikely to be more than a distant second to containerd.
Yes, and I did not mean to diminish that context, more so expand upon the "k8s not using Docker" side of things from the parent you were responding to.
As a 10+ years old company / YC company + significant amount of market share, I was expecting Docket to be like series D-F or even going public. Wondering if it is actually common for companies in CA to be like that...
Doing a series H might make investors think harder about why they need 8 rounds of funding over 12 years or so and still didn't manage to turn a profit.
I had a recruiter a few years ago pitch me about an amazing opportunity at a series F company that he wouldn't name in the initial pitch email. I didn't see that as an advantage at all. That's 6 rounds of investors who are all going to need to get paid and then some before you see a penny. It also implied to me the early growth/fun stage was over and they either limping along or so big to be unrecognizable as a legit startup.
Here's a separate thread for "Docker Series B: More Fuel To Help Dev Teams Get Ship Done" - with a bit more info on what the plan is from Scott.
Interesting to see this news on the same day that "We don't need Docker" was also on the front page of Hacker News. I think we absolutely still need Docker in 2021.
https://news.ycombinator.com/item?id=26478669