16 ms·

Why doesn’t anyone weep for Docker?

222 points by jumpingdeeps 7y ago

lioeters 7y ago
Ugh, Google in the middle, please change the following URL: https://www.google.com/url?sa=i&source=web&cd=&ved=0ahUKEwiShovJrrvkAhU8FzQIHe7GCHEQzPwBCAM&url=https%3A%2F%2Fwww.techrepublic.com%2Farticle%2Fwhy-doesnt-anyone-weep-for-docker%2F&psig=AOvVaw3uqDkT8mg8UfnHaiOmd7aL&ust=1567830683958295 https://www.google.com/url?sa=i&source=web&cd=&ved=0ahUKEwiS... ..to: https://www.techrepublic.com/article/why-doesnt-anyone-weep-for-docker/ https://www.techrepublic.com/article/why-doesnt-anyone-weep-... EDIT: The article itself is quite interesting, on the rise of Kubernetes, its adoption by VMWare, and the reason why Docker failed to capture market value as much as it could have.
- greglindahl 7y ago
  Yes, it would be smart for HN to reject links that are google search engine tracking links.
jimmymcsales 7y ago
No, nobody weeps for Docker. But, everybody cheers for `docker`.
newnewpdro 7y ago
Docker shit so hard on the established linux community with such arrogance Jessie Frazelle, a Docker employee at the time, would gloat about closing systemd-specific PRs. She wore a name tag @ DockerCon.EU 2015 proudly showing "I say no to systemd specific PRs". Docker's plight? Good riddance.
- blaerk 7y ago
  To be fair, arrogance seems to be quite popular in systemd as well
  - Fnoord 7y ago
    Sure, but saying "I won't merge this because I don't want my software to be compatible" seems to be strange. Would you not accept say changes to your Makefile to support BSD or Windows or Linux?
    - anoncake 7y ago
      It depends. Trying to avoid being compatible with Systemd would be strange. Simply not valuing at all -- if it works, that's okay, but you won't add any Systemd-specific code -- is a different thing.
      - Fnoord 7y ago
        I see parallels with discrimination. If it is some obscure compatibility we are talking about, I can understand it. If it is a defacto or official standard, then no. Regardless of whether I use Systemd or not (my primary OS uses launchd...), its usage in Linux distributions is currently widespread. Not wanting to develop compatibility yourself, I can understand. No discussion about it. Not wanting to include compatibility PRs is a recipe for hostility, and ultimately, a fork. There's a nuance here that it could lead to a lead dev importing PRs for software they don't use or understand but other than that, it seems the way to go if you want an inclusive and gentle environment.
      - dagw 7y ago
        Simply not valuing at all -- if it works, that's okay, but you won't add any Systemd-specific code -- is a different thing. That's a fair stance to take if you're just a group hackers hacking away on this cool open source project in you free time. It's a very bad look when you're trying to present yourself as a serious company that other serious companies can depend upon for some of their most critical infrastructure components.
- peterwwillis 7y ago
  Well, systemd sucks balls, so I kind of agree with not having PRs specific to it, but I see your point that wearing that on a name tag isn't very nice.
  - dagw 7y ago
    I've seen this happen quite a lot in the Open Source and hacker world. The sort of glib bravado that goes down so well with your friends on mailing lists and at your local meetups just doesn't translate well when you're trying to convince Fortune500 companies to give you millions of dollars. I bet the person in question had gotten nothing but cheers and support for their anit-systemd rhetoric from their immediate peers and was shocked and surprised to find that it didn't go down just as well in the wider world.
  - otabdeveloper4 7y ago
    > systemd sucks balls No it doesn't. Shell scripts in your init system sucks balls. Systemd is great.
    - raxxorrax 7y ago
      I am in favor of a new discussion about existential philosophical differences again. Almost missed the systemd drama. I use systemd on pretty much any linux machine but am very sympathetic to the arguments of its detractors, which to a significant degree results from the behavior of its proponents and the inability to see that you actually do loose flexibility in theory. You could argue taht GNU/linux could be called GNU/systemd/linux. I couldn't write a better init system than systemd, but I like the idea that some people could. And I am pretty sure there are people like that.
      - sergiosgc 7y ago
        > I couldn't write a better init system than systemd, but I like the idea that some people could. And I am pretty sure there are people like that. But they did not. Functionally, systemd is great. I don't like the architecture, for its monolithic non unix characteristics. I begrudgingly started to use it when Debian switched to systemd. After some time, I must admit it is leaps and bounds better than sysv init, and better than the alternatives that appeared before it.
- de_watcher 7y ago
  And that perpetually refused PR to disable connecting to the central repository every time.
joshpadnick 7y ago
This article seems to be arguing that Docker’s primary downfall was being hostile to its open source community. Without having an opinion on whether that’s true, I suspect the core issue was not that but their business model and execution. Before Kubernetes was the dominant container tech, they were pushing Swarm but I remember being confused about where Docker “standalone” stopped and where Swarm began. Perhaps it would have been better as a separate tool with a more clear open core model? Then there was Docker Hub, whose UI was never great and which always seemed light on features. I don’t recall seeing any kind of container introspection tool from them for a while either, despite others coming out. Meanwhile, they represented a threat to the cloud providers if you could truly run anything in a container on any cloud. But the cloud providers all neutralized that threat by the classic “commoditizing the complement” strategy where the Docker cluster and registry tech were all either open source or commoditized. Once Kubernetes emerged as the winner and de-valued Swarm while the cloud providers all offered their own Kubernetes and Docker registry offerings, I’m not sure how much more profit there was for Docker to claim. Honestly, startups are hard. Sometimes really hard. It’s hard to know if a different team would have gotten different results in this space.
- brutus1213 7y ago
  Totally agree with your first paragraph. Regarding execution, I'm not sure what Docker could have done differently that did not lead to the outcome we have today. I don't think that playing nice with other opensource devs would have made a difference (as the article claims). Also .. the K was hardened at Google is BS. The ideas, maybe. But I am quite skeptical about the amount of prod internal google code went into early K (pls don't point at the Borg paper .. I'm talking about actual working code). I recall doing a deep comparison of swarm vs K circa 2015 and Swarm was clearly superior in both design and implementation. Today, K is better and has an ecosystem .. maybe the issue isn't that core Docker containers played nice with opensource .. rather .. swarm should have focused much more on playing well with others. One point of contrast is Hashicorp .. they are in the workload orchestration and mgmt space and seem to be doing really well. Kudos to them!
  - smarterclayton 7y ago
hadsed 7y ago
Whenever the topic of building online open source communities comes up I feel compelled to share the work of the great Pieter Hintjens, the guy who wrote zero MQ. He wrote a book about this topic which I thought was quite good: https://www.goodreads.com/book/show/30121783-social-architecture https://www.goodreads.com/book/show/30121783-social-architec...
- dguaraglia 7y ago
  Pieter was an outstanding writer. Everything I've read from him was top notch, from his ZeroMQ guide to the last blog posts explaining how he was dealing with the unthinkable process of getting his affairs in order because he know he'd die soon. I'll definitely add this to my reading list.
kjgkjhfkjf 7y ago
Google doesn't actually use Kubernetes much, so the "operation hardened internally" argument isn't valid.
- s_Hogg 7y ago
  source?
  - Legogris 7y ago
    Anecdotal, but I know a guy working as a senior Engineer at Google with some central server-side components for the Android ecosystem. He had barely heard the word Kubernetes when we last spoke, let alone knew what it was.
    - aflag 7y ago
      For the record, the Google developers I know also don't use it and generally don't care about it. But it's a big company, I'm sure they have a few users
- hilem 7y ago
  Kubernetes is based on Borg which Google uses extensively internally.
  - ahupp 7y ago
    "inspired by" borg. It's not the same codebase.
    - hilem 7y ago
      I didn't say it was the same codebase. "Inspired" may be more accurate but the point still remains that the concepts in Kubernetes have a direct path to the concepts in Borg.
- flukus 7y ago
  This reminds me of Joel Spolsky's fire and motion piece (https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/). To paraphrase a little bit: > Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you. ... The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Google. People get worried about kubernetes and decide to rewrite their whole architecture for kubernetes because they think they have to. Google is shooting at you, and it’s just cover fire so that they can move forward and you can’t
orthoxerox 7y ago
The only thing Docker is now useful for is Docker Desktop. Unlike other desktop container software, it actually works on locked down machines in enterprise environments. K8s can run on any CRI-compatible runtime, and IBM/RedHat don't even want you to install Docker on RHEL8.
- raesene9 7y ago
  Whilst k8s can run on any CRI compliant runtime, I've never actually seen a prod. deployment use anything other than Docker.
paule89 7y ago
The problem i have with cubernetes is the following: I as a small developer and small server owner don't have the ressources to even get started. The first thing i see at cubernetes is a cluster. Why a cluster. Do i need to cluster my Raspberry pi's to get something out of it? Do i need to buy 3 servers just to run 5 containers? In docker its easy. Download Docker. Start container. Install container manager like platformio. Done. But true to the article. Docker seems very hostile towards the community and towards getting revenue. If i think about Kubernetes and Revenue i hear IBM, Red Hat. And i am too cheap of a person and too small of a customer to ever need those guys. So i will still keep using Docker. And because i know more about Docker i will probably try to use it at work as well. Easy as that. But i am open to suggestions.
- Majestic121 7y ago
  You don't need a whole cluster to get started, you can use Minikube locally for example : https://minikube.sigs.k8s.io/docs/ https://minikube.sigs.k8s.io/docs/
  - katsura 7y ago
    Have they solved the high CPU usage problem while it is running (even when no containers are inside)? I don't like my laptop hot, so never could make a switch.
    - ngrilly 7y ago
      Yes, it's a real issue. Kubernetes burns too much RAM and CPU even with no workload.
      - Fnoord 7y ago
        Docker on macOS also suffers from that issue though.
        mschuster91 7y ago
luckylittle 7y ago
I also feel sorry for Docker, in a way. Was it their arrogance, or just incompetence? The came up with this amazing tool, that lot of companies started using, but they did not have a business strategy on how to make money in a long term. They tried to keep up (Docker Swarm, Docker Hub Premium, Tutum, Moby, Docker Community vs Docker Enterprise etc). But at the end they just seem like they don't really know how to approach it.
- budhajeewa 7y ago
  What did Moby try to do anyway?
  - de_watcher 7y ago
    A rebrand that made things more confusing.
    - budhajeewa 7y ago
      Is it dead now? It's still in GitHub, so as Docker.
      - de_watcher 7y ago
        AFAIK it's a different name for the same Docker.
        budhajeewa 7y ago
        Hmm hmm...
dasyatidprime 7y ago
Maybe this isn't quite the perspective the article's taking—but damn near no one visibly wept for LXC when Docker stomped all over it in terms of “what people think containers just Are”. And now the news asks why I don't weep for them? Live by the stomp, die by the stomp.
- de_watcher 7y ago
  LXC feels more UNIXy. Docker command line tools and formats feel awkward in that regard (which helped to popularize the thing by pushing this one specific view).
  - cuspycode 7y ago
    I agree. I had some VMs that I wanted to turn into containers. With LXC it was a breeze, and the result is very much like a "lightweight VM". Docker seems more like putting a single application process in a container, which is a very different thing. And if I want to do that, I'll seriously consider running the application in a unikernel (e.g. OSv) instead.
    - de_watcher 7y ago
      By the way, the lightweight VM project is currently the LXD by Ubuntu/Canonical.
      - cuspycode 7y ago
        Yeah, LXD is what I have been using. Maybe I should have said "LXC/LXD" instead of just "LXC".
    - lunchables 7y ago
      If you are trying to use docker to build lightweight VMs you are really swimming upstream. In the (docker, etc) container world they use the phrase "pets not cattle". Containers are designed to be stateless (nothing is stored in the container) and to be spun up and down as demand changes. https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets https://devops.stackexchange.com/questions/653/what-is-the-d... If you want to build a mini-VM using containers, LXC is a great choice. If you want to deploy software, easily, with CI/CD and [auto-]scaling, then containers are what you want.
goatinaboat 7y ago
For a very long time there was a gaping security hole in Docker: anyone who could run a container could mount anything on the underlying host as root. This says to me that Docker (the company) don’t really consider any use cases beyond “fooling around on a personal laptop”. Meanwhile other container projects took seriously from day 1 that they would need to run in production. Docker (the company) certainly helped to raise the profile of containerisation but they invented very little of it and did a poor job of implementing what they did do. Good riddance to them.
- aflag 7y ago
  That's only a problem if you allow untrusted users operate the docker daemon.
  - goatinaboat 7y ago
    That's only a problem if you allow untrusted users operate the docker daemon. Sure, if you trust every developer in your company with the root password anyway, why not? That might be true at Docker (the company), I don’t know. Certainly wasn’t true at one company I worked at with 30,000 devs... By the way, this problem does not exist with competing container tools like Podman/Buildah.
    - raesene9 7y ago
      Why would you be allowing devs to directly deploy to production in a company with 30,000 developers? Surely you'd have proper release management where Ops teams would review deployment artifacts before deploying them?
      - goatinaboat 7y ago
        You wouldn’t but you wouldn’t give every dev root access to every dev box either... would you?
        raesene9 7y ago
zimbatm 7y ago
Companies don't have feelings. The only ones weeping are the VCs that invested into Docker :-D Docker played its role and introduced the majority developers to containerization. This is a major success for the industry.
deleted 7y ago
[deleted]
FreeHugs 7y ago
Weep? Docker's downfall? What happened? As far as I can tell, everybody and his grandmother is using Docker. Why should we weep about it?
- dagw 7y ago
  'Everybody' is using docker the software, 'nobody' is using (ie paying) Docker the company. The article makes it clear they're talking about the company.
  - budhajeewa 7y ago
    My small company pays for private image storage there. We actually used Google Cloud Platform's Docker Image hosting service, and that was expensive. Yay!? What else can we pay them for? All the stuff we need are available from them for free, except private storage. If they had a container hosting solution, we'd pay for it.
    - bvm 7y ago
      yeh we pay them like $15/month for Hub/Cloud/Private Image Storage/whatever it's called this week. It actually seems quite cheap...we have something like 2TB of tags up there, and they don't charge for network I/O. I did feel slightly bad when a hidden crash looping pod set to always download lay undiscovered for a month...that's a LOT of I/O.
  - eeZah7Ux 7y ago
    > 'Everybody' is using docker the software Not at all - thanks goodness.
- pjmlp 7y ago
  Nah, plain old VMs over here.
tofflos 7y ago
I jumped on the container bandwagon late and immediately fell in love with Docker. It built on my existing skill set so I was quickly able to get something up and running. Then I started tinkering with Docker Compose and for a while things were great. But after a while I started running into issues. Compose felt artificially crippled. No secrets? No health checks? Pushing me towards Docker Swarm? Eventually I just sucked it up and switched to Kubernetes even though I think it's overkill for my applications.
- orthoxerox 7y ago
  My thoughts exactly. You cannot scale Docker. You can to a point, but there's always k8s looming ahead of you, saying, "sooner or later you will have to learn me instead". So most people learn it sooner than later to migrate to it while their workloads are still small. Of course, they often don't grow large enough for the benefits of k8s to kick in, but that's another story.
raesene9 7y ago
What's interesting, to me, about Docker as a company perhaps not doing well is how that'll impact Microsoft. Microsoft have done a load of work on getting containers running well on Windows servers and that work relies on Docker EE as the container runtime engine (you get a free Docker EE license to run on Windows servers AFAIK) If Docker get bought up (by someone other than Microsoft), then that would seem to possibly place Microsoft's container efforts at risk...
- praseodym 7y ago
  Microsoft has already heavily invested in getting Kubernetes running on Windows as a fist-class citizen: https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/getting-started-kubernetes-windows https://docs.microsoft.com/en-us/virtualization/windowsconta...
psv1 7y ago
Can anyone offer a good guide to DevOps for people who don't directly use these tools but work with engineers who do and would like to learn more? The whole ecosystem of servers, cloud infrastructure (and all of the different offerings there), Docker, Kubernetes, CICD tools etc is a bit overwhelming to get into.
- marsrover 7y ago
  I think the only way to learn them is to use them. You can do that locally or purchase a VPS and work there.
- dsr_ 7y ago
  Sure. None of the things you mentioned are DevOps. DevOps is two things: 1. Applying the methods of modern software development (version control, automation, DSLs...) to operations (provisioning, config, deployment, monitoring, backups...). 2. Reducing silo barriers between devs and ops groups so that everyone is working together as a team, rather than blaming each other for poor communication and the resulting messes. Then there are all the DevOps hijacking attempts, such as equating it to Agile or Scrum or XP, or insisting that it's a way to stop paying for expensive operations experts by making devs do it, or a way to stop paying for expensive devs by making ops do it, or a way to stop paying for expensive hardware by paying Amazon/Google/$CLOUD to do it. No matter what your software-as-a-service company actually does, it will need to execute certain things: - have computers to run software - have computers to develop software - have computers to run infrastructure support You can outsource various aspects of these things to different degrees. Anywhere you need computers, you have a choice of buying computers (and figuring out where to put them and how to run them and maintain them), or leasing computers (just a financing distinction), or renting existing computers (dedicated machines at a datacenter) or renting time on someone else's infrastructure. If you rent time, you can do so via virtual machines (which pretend to be whole servers) or containers (which pretend to be application deployments) or "serverless", which is actually a small auto-scaled container. Docker is a management scheme for containers. VMWare provides management schemes for virtual machines. Kubernetes is an extensive management scheme for virtual machines or containers. A continuous integration tool is, essentially, a program that notes that you have committed changes to your version control system and tries to build the resulting program. A continuous deployment system takes the CI's program and tries to put it into production (or, if you're sensible, into a QA deployment first).
redwood 7y ago
This article is real rich coming from a guy who works at AWS. The amount of absurd hubris and doublespeak entering this community unchecked is shocking to me.
i386 7y ago
In my experience having worked at two developer tools companies where we wanted to partner and co-market products, Docker would never pick up the phone. There was definitely a “we don’t need you attitude” whenever I approached them and I had the same experience repeated to me by friends at other companies trying to do the same thing.
- wolco 7y ago
  This is the core reason why they are where they are. They acted like you were bothering them and in fairness you probably were. Even today they wouldn't pick up. When you start believing the hype reality becomes distorted.
  - i386 7y ago
    The kind of activities we were approaching about were for integrations, conferences, blog posts and webinars - great methods to get leads and remain in the zeitgeist.
alias_neo 7y ago
My experience agrees with this. I'm a huge fan of Docker, I've actively taken part since the early days, attending meetups and using it actively day to day. Unfortunately, when I brought several issues to GitHub, or +1'd other people's issues that were affecting the usability within our company, the attitude was very much "f* you and your problems" because Docker want things to be one way and that's how it'll be. There were issues raised 4+ years ago and are still open, for solutions to problems that would have mooted a need for us to use something like K8s (which doesn't work anyway for our requirements). I believe Docker locking the community out of valuable features had also done harm and (possibly) failed to be the monitiser they'd hoped for. After so long, I no longer go to Docker to solve problems that could be solved in Docker (secrets anyone? without the "hacks"), and just look towards the other tools solving the problems. I'll continue to use Docker, but I don't consider it a friend.
- NotAnEconomist 7y ago
  Docker has had a surprisingly quick turn from "new community software that's worth supporting" to "clearly sabotaged for 'enterprise' sales".
- pacala 7y ago
  I wonder how much of that attitude was caused by an overstretched team with no effective scaling mechanism in place. No, "open source" does not automatically mean "scalable team". Part of Kubernetes success is its ability to scale up the community, empowering multiple entities to meaningfully contribute.
  - 0xDEFC0DE 7y ago
    At the same time, I gather it's really, really hard to write software that satisfies a lot of use cases across a lot of businesses without having to be somewhat opinionated.
    - pacala 7y ago
      True! Another part of Kubernetes success is the fact that it's core architecture is sound, scalable for both workloads and features.
notyourday 7y ago
For the same reason that no one weeps for a company that markets hammers even if it invented a new way to hold a hammer and raised lots of money because of it. We do not care about hammers, we just use them when we need to hit something. Our customers do not care about hammers either, they care about the result that we deliver.
dangerface 7y ago
I think the reason they failed is that they tried to make a platform for micro services but micro services is an anti pattern, people really just wanted containerisation.
alexandercrohde 7y ago
Why cry at all? Isn't this the point of open source? Can't the same be said for Git? Linux? Python? (That they didn't make the creator billions, and the creator is fine with that)
octosphere 7y ago
https://i.imgflip.com/24ac74.jpg https://i.imgflip.com/24ac74.jpg
ben_jones 7y ago
Docker sold its soul for money at the cost of its core product. The second you take as much money as they did so you can have your luxury box at AT&T or whatever else I’m going to find it increasingly hard to sympathize with your future mistakes.
thrower123 7y ago
I regret the time and money I spent thinking about learning Docker. I'm sure containers solve somebody's problems, but it's not any problems that I have.
derefr 7y ago
K8s is a “datacenter operating system”, just like VMWare’s own VSphere, or Mesos, Mosix, etc. These solutions also compete for mindshare with mainframe solutions like IBM’s; and with “control planes” like OpenStack, Canonical’s Landscape, or (I think?) Microsoft’s System Center. This space is very, very profitable. None of this applies to Docker itself. Docker is “just” a virtualization technology. Sure, Docker Swarm exists, but at this point it’s mostly used as a shimming UI for connecting the Docker client and daemon to the abstractions mentioned above, not a clustering solution in its own right. Swarm lost in the DCOS market. And the market for pure virtualization solutions isn’t anywhere near the market for DCOSes.
- Blackstone4 7y ago
  Doesn't K8s typically run on virtual machines? In which case it's K8s + VMs to get to the “datacenter operating system” model?
  - gtaylor 7y ago
    It can run on VMs but doesn't have to. There are many bare metal k8s users out there doing some really neat things with the stack.
013a 7y ago
There's this prevalent false position that Kubernetes is successful because of Google. Yeah, Kubernetes initially learned a ton because of Borg and Google's deep investment into containers dating back a very long time. But, arguably, Kubernetes is successful because Google Let It Go. Its a true open source project, with governance by a wide number of industry advocates, underneath the Linux Foundation. By comparison, Docker is a VC-backed profit-minded startup. Of course it was going to lose this race, for the same reason Windows isn't the dominant OS in the cloud. Fundamentally: You can't build a hyperscale startup based on a technology. It doesn't appear to work anymore. The best case is the Docker/Kubernetes or Oracle/Postgres/MySQL case: someone else does it, maybe better, open sources it, community forms around it, you're toast. The worst case is the MongoDB/AWS or Elastic/AWS case; a cloud provider copies you, probably does it worse, but its cheaper and more integrated with the cloud, so they still win. Docker was doomed; they could have been a very nice business, but the issue is taking on huge valuations and capital, scaling like mad, and then finding out you have no ground underneath your feet to support that valuation.
- jjtheblunt 7y ago
  Parenthetically, Linux being an open source reincarnation of Solaris seems also an example, no?
  - orbifold 7y ago
    Versions of Solaris are open source aswell (Illumos)
    - lazyguy2 7y ago
      Illumos and friends are effectively dead, except as hobbies for enthusiasts. Sun Microsystems, now Oracle, didn't like the reception Open Solaris got so they packed up their source code and went home. Which is really a shame. All 'True' Unixes are just closed source versions of what originally were open source operating systems. By taking copyright seriously and having the misconception that there is intrinsic value in 'IP' they effectively sentenced their operating systems and investors to a long term grave. But I doubt most of them feel bad about it. They got their millions and their nice fat retirements. It doesn't matter now if customers now view their once dominate systems as a sort of technical debt cancer. If it wasn't for the destructive power that copyright has on technology and the demands of board members to monetize Unix.. we would all be using BSD right now. Unfortunately the tech people from 30 years ago didn't understand the power of 'letting go' and thus allowed them to destroy Unix. As far as docker goes it has a lot of momentum as a daemon and it'll probably stay that way for a long time despite some technically superior solutions for running containers that have cropped up in the past few years. The newer container solutions just don't have the community backing them and that matters.
nova22033 7y ago
>Kubernetes "was operation hardened internally at Google Is this true? Isn't kubernetes "based" on work done at google but also a complete rewrite.
windsurfer 7y ago
The first and only experience I had with Docker as a company was requiring me to sign up to download their mac osx client. They seem to have since changed that policy but it really made me resent them, and made them feel pretty unfriendly.
- choward 7y ago
  Are you sure they changed it? https://github.com/docker/docker.github.io/issues/6910 https://github.com/docker/docker.github.io/issues/6910
dgoog 7y ago
Cause it's useless and so is k8s. When the recession comes all these coding bootcamp ppl are going to have to go back to their barista jobs and we won't have to deal with docker or kubernetes bullshit.
dgoog 7y ago
Mods I think it's time to start flagging kubernetes/docker posts. They are heavily marketing driven and come off as spam.
djsumdog 7y ago
I don't get why k8s is the dominant scheduler. If you have a 3 ~ 6 person platform team that can set one up, or build a secure terraform of CFN codebase to establish an AWS/EKS system, they can be nice. But I've also worked at DCOS/marathon shops where it worked just as well. The trouble with all these schedulers is they can't go from just one node (where scheduling and processes run on the same node .. and minikube is a hack; not a production system) to 100. You can't just setup a small k8s, and then add a node, and another node, and scale up. You go from a single docker system, to a big managed k8s system. There needs to be more competition. It's the same deal with the dominance of systemd as the only system layer. Only the small startups seem to be using more lightweight stuff like Nomad, k3s, RancherOS (Rancher is mostly going the managed k8s solution anyway; even though they have their own k3s implementation). A running k8s system can be okay, but there is a lot of room for improvement (in terms of making it simpler). Both DCOS and k8s seem to waste a lot of resources. Docker could have competed in this space, but everyone complained about all the bugs in Swarm and it never really went anywhere. I did a writeup on container orchestration systems late last year: https://penguindreams.org/blog/my-love-hate-relationship-with-docker-and-container-orchestration-systems/ https://penguindreams.org/blog/my-love-hate-relationship-wit...
mmanfrin 7y ago
It's minor and maybe I'm being petty, but my sympathy for Docker ended the moment they forced you to register an account and log in to download Docker CE.
GordonS 7y ago
A little OT, but is there anything remotely competitive with k8s these days? By "competitive", I mean: good feature set, thriving community, active development. I still use Docker Swarm for small scale stuff, and am pretty happy with it - it's simple, easy to use and doesn't eat resources. But it very much feels like Docker have given up on it. I'm particularly interested to know if there is anything simpler than k8s that's competitive?

222 points by jumpingdeeps 7y ago

Ugh, Google in the middle, please change the following URL: https://www.google.com/url?sa=i&source=web&cd=&ved=0ahUKEwiShovJrrvkAhU8FzQIHe7GCHEQzPwBCAM&url=https%3A%2F%2Fwww.techrepublic.com%2Farticle%2Fwhy-doesnt-anyone-weep-for-docker%2F&psig=AOvVaw3uqDkT8mg8UfnHaiOmd7aL&ust=1567830683958295 https://www.google.com/url?sa=i&source=web&cd=&ved=0ahUKEwiS... ..to: https://www.techrepublic.com/article/why-doesnt-anyone-weep-for-docker/ https://www.techrepublic.com/article/why-doesnt-anyone-weep-... EDIT: The article itself is quite interesting, on the rise of Kubernetes, its adoption by VMWare, and the reason why Docker failed to capture market value as much as it could have.

greglindahl 7y ago
Yes, it would be smart for HN to reject links that are google search engine tracking links.

jimmymcsales 7y ago

No, nobody weeps for Docker. But, everybody cheers for `docker`.

newnewpdro 7y ago

Docker shit so hard on the established linux community with such arrogance Jessie Frazelle, a Docker employee at the time, would gloat about closing systemd-specific PRs. She wore a name tag @ DockerCon.EU 2015 proudly showing "I say no to systemd specific PRs". Docker's plight? Good riddance.

blaerk 7y ago
To be fair, arrogance seems to be quite popular in systemd as well
- Fnoord 7y ago
  Sure, but saying "I won't merge this because I don't want my software to be compatible" seems to be strange. Would you not accept say changes to your Makefile to support BSD or Windows or Linux?
  - anoncake 7y ago
    It depends. Trying to avoid being compatible with Systemd would be strange. Simply not valuing at all -- if it works, that's okay, but you won't add any Systemd-specific code -- is a different thing.
    - Fnoord 7y ago
      I see parallels with discrimination. If it is some obscure compatibility we are talking about, I can understand it. If it is a defacto or official standard, then no. Regardless of whether I use Systemd or not (my primary OS uses launchd...), its usage in Linux distributions is currently widespread. Not wanting to develop compatibility yourself, I can understand. No discussion about it. Not wanting to include compatibility PRs is a recipe for hostility, and ultimately, a fork. There's a nuance here that it could lead to a lead dev importing PRs for software they don't use or understand but other than that, it seems the way to go if you want an inclusive and gentle environment.
    - dagw 7y ago
      Simply not valuing at all -- if it works, that's okay, but you won't add any Systemd-specific code -- is a different thing. That's a fair stance to take if you're just a group hackers hacking away on this cool open source project in you free time. It's a very bad look when you're trying to present yourself as a serious company that other serious companies can depend upon for some of their most critical infrastructure components.
peterwwillis 7y ago
Well, systemd sucks balls, so I kind of agree with not having PRs specific to it, but I see your point that wearing that on a name tag isn't very nice.
- dagw 7y ago
  I've seen this happen quite a lot in the Open Source and hacker world. The sort of glib bravado that goes down so well with your friends on mailing lists and at your local meetups just doesn't translate well when you're trying to convince Fortune500 companies to give you millions of dollars. I bet the person in question had gotten nothing but cheers and support for their anit-systemd rhetoric from their immediate peers and was shocked and surprised to find that it didn't go down just as well in the wider world.
- otabdeveloper4 7y ago
  > systemd sucks balls No it doesn't. Shell scripts in your init system sucks balls. Systemd is great.
  - raxxorrax 7y ago
    I am in favor of a new discussion about existential philosophical differences again. Almost missed the systemd drama. I use systemd on pretty much any linux machine but am very sympathetic to the arguments of its detractors, which to a significant degree results from the behavior of its proponents and the inability to see that you actually do loose flexibility in theory. You could argue taht GNU/linux could be called GNU/systemd/linux. I couldn't write a better init system than systemd, but I like the idea that some people could. And I am pretty sure there are people like that.
    - sergiosgc 7y ago
      > I couldn't write a better init system than systemd, but I like the idea that some people could. And I am pretty sure there are people like that. But they did not. Functionally, systemd is great. I don't like the architecture, for its monolithic non unix characteristics. I begrudgingly started to use it when Debian switched to systemd. After some time, I must admit it is leaps and bounds better than sysv init, and better than the alternatives that appeared before it.
de_watcher 7y ago
And that perpetually refused PR to disable connecting to the central repository every time.

joshpadnick 7y ago

This article seems to be arguing that Docker’s primary downfall was being hostile to its open source community. Without having an opinion on whether that’s true, I suspect the core issue was not that but their business model and execution. Before Kubernetes was the dominant container tech, they were pushing Swarm but I remember being confused about where Docker “standalone” stopped and where Swarm began. Perhaps it would have been better as a separate tool with a more clear open core model? Then there was Docker Hub, whose UI was never great and which always seemed light on features. I don’t recall seeing any kind of container introspection tool from them for a while either, despite others coming out. Meanwhile, they represented a threat to the cloud providers if you could truly run anything in a container on any cloud. But the cloud providers all neutralized that threat by the classic “commoditizing the complement” strategy where the Docker cluster and registry tech were all either open source or commoditized. Once Kubernetes emerged as the winner and de-valued Swarm while the cloud providers all offered their own Kubernetes and Docker registry offerings, I’m not sure how much more profit there was for Docker to claim. Honestly, startups are hard. Sometimes really hard. It’s hard to know if a different team would have gotten different results in this space.

brutus1213 7y ago
Totally agree with your first paragraph. Regarding execution, I'm not sure what Docker could have done differently that did not lead to the outcome we have today. I don't think that playing nice with other opensource devs would have made a difference (as the article claims). Also .. the K was hardened at Google is BS. The ideas, maybe. But I am quite skeptical about the amount of prod internal google code went into early K (pls don't point at the Borg paper .. I'm talking about actual working code). I recall doing a deep comparison of swarm vs K circa 2015 and Swarm was clearly superior in both design and implementation. Today, K is better and has an ecosystem .. maybe the issue isn't that core Docker containers played nice with opensource .. rather .. swarm should have focused much more on playing well with others. One point of contrast is Hashicorp .. they are in the workload orchestration and mgmt space and seem to be doing really well. Kudos to them!
- smarterclayton 7y ago

hadsed 7y ago

Whenever the topic of building online open source communities comes up I feel compelled to share the work of the great Pieter Hintjens, the guy who wrote zero MQ. He wrote a book about this topic which I thought was quite good: https://www.goodreads.com/book/show/30121783-social-architecture https://www.goodreads.com/book/show/30121783-social-architec...

dguaraglia 7y ago
Pieter was an outstanding writer. Everything I've read from him was top notch, from his ZeroMQ guide to the last blog posts explaining how he was dealing with the unthinkable process of getting his affairs in order because he know he'd die soon. I'll definitely add this to my reading list.

kjgkjhfkjf 7y ago

Google doesn't actually use Kubernetes much, so the "operation hardened internally" argument isn't valid.

s_Hogg 7y ago
source?
- Legogris 7y ago
  Anecdotal, but I know a guy working as a senior Engineer at Google with some central server-side components for the Android ecosystem. He had barely heard the word Kubernetes when we last spoke, let alone knew what it was.
  - aflag 7y ago
    For the record, the Google developers I know also don't use it and generally don't care about it. But it's a big company, I'm sure they have a few users
hilem 7y ago
Kubernetes is based on Borg which Google uses extensively internally.
- ahupp 7y ago
  "inspired by" borg. It's not the same codebase.
  - hilem 7y ago
    I didn't say it was the same codebase. "Inspired" may be more accurate but the point still remains that the concepts in Kubernetes have a direct path to the concepts in Borg.
flukus 7y ago
This reminds me of Joel Spolsky's fire and motion piece (https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/). To paraphrase a little bit: > Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you. ... The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Google. People get worried about kubernetes and decide to rewrite their whole architecture for kubernetes because they think they have to. Google is shooting at you, and it’s just cover fire so that they can move forward and you can’t

orthoxerox 7y ago

The only thing Docker is now useful for is Docker Desktop. Unlike other desktop container software, it actually works on locked down machines in enterprise environments. K8s can run on any CRI-compatible runtime, and IBM/RedHat don't even want you to install Docker on RHEL8.

raesene9 7y ago
Whilst k8s can run on any CRI compliant runtime, I've never actually seen a prod. deployment use anything other than Docker.

paule89 7y ago

The problem i have with cubernetes is the following: I as a small developer and small server owner don't have the ressources to even get started. The first thing i see at cubernetes is a cluster. Why a cluster. Do i need to cluster my Raspberry pi's to get something out of it? Do i need to buy 3 servers just to run 5 containers? In docker its easy. Download Docker. Start container. Install container manager like platformio. Done. But true to the article. Docker seems very hostile towards the community and towards getting revenue. If i think about Kubernetes and Revenue i hear IBM, Red Hat. And i am too cheap of a person and too small of a customer to ever need those guys. So i will still keep using Docker. And because i know more about Docker i will probably try to use it at work as well. Easy as that. But i am open to suggestions.

Majestic121 7y ago
You don't need a whole cluster to get started, you can use Minikube locally for example : https://minikube.sigs.k8s.io/docs/ https://minikube.sigs.k8s.io/docs/
- katsura 7y ago
  Have they solved the high CPU usage problem while it is running (even when no containers are inside)? I don't like my laptop hot, so never could make a switch.
  - ngrilly 7y ago
    Yes, it's a real issue. Kubernetes burns too much RAM and CPU even with no workload.
    - Fnoord 7y ago
      Docker on macOS also suffers from that issue though.
      - mschuster91 7y ago

luckylittle 7y ago

I also feel sorry for Docker, in a way. Was it their arrogance, or just incompetence? The came up with this amazing tool, that lot of companies started using, but they did not have a business strategy on how to make money in a long term. They tried to keep up (Docker Swarm, Docker Hub Premium, Tutum, Moby, Docker Community vs Docker Enterprise etc). But at the end they just seem like they don't really know how to approach it.

budhajeewa 7y ago
What did Moby try to do anyway?
- de_watcher 7y ago
  A rebrand that made things more confusing.
  - budhajeewa 7y ago
    Is it dead now? It's still in GitHub, so as Docker.
    - de_watcher 7y ago
      AFAIK it's a different name for the same Docker.
      - budhajeewa 7y ago
        Hmm hmm...

dasyatidprime 7y ago

Maybe this isn't quite the perspective the article's taking—but damn near no one visibly wept for LXC when Docker stomped all over it in terms of “what people think containers just Are”. And now the news asks why I don't weep for them? Live by the stomp, die by the stomp.

de_watcher 7y ago
LXC feels more UNIXy. Docker command line tools and formats feel awkward in that regard (which helped to popularize the thing by pushing this one specific view).
- cuspycode 7y ago
  I agree. I had some VMs that I wanted to turn into containers. With LXC it was a breeze, and the result is very much like a "lightweight VM". Docker seems more like putting a single application process in a container, which is a very different thing. And if I want to do that, I'll seriously consider running the application in a unikernel (e.g. OSv) instead.
  - de_watcher 7y ago
    By the way, the lightweight VM project is currently the LXD by Ubuntu/Canonical.
    - cuspycode 7y ago
      Yeah, LXD is what I have been using. Maybe I should have said "LXC/LXD" instead of just "LXC".
  - lunchables 7y ago
    If you are trying to use docker to build lightweight VMs you are really swimming upstream. In the (docker, etc) container world they use the phrase "pets not cattle". Containers are designed to be stateless (nothing is stored in the container) and to be spun up and down as demand changes. https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets https://devops.stackexchange.com/questions/653/what-is-the-d... If you want to build a mini-VM using containers, LXC is a great choice. If you want to deploy software, easily, with CI/CD and [auto-]scaling, then containers are what you want.

goatinaboat 7y ago

For a very long time there was a gaping security hole in Docker: anyone who could run a container could mount anything on the underlying host as root. This says to me that Docker (the company) don’t really consider any use cases beyond “fooling around on a personal laptop”. Meanwhile other container projects took seriously from day 1 that they would need to run in production. Docker (the company) certainly helped to raise the profile of containerisation but they invented very little of it and did a poor job of implementing what they did do. Good riddance to them.

aflag 7y ago
That's only a problem if you allow untrusted users operate the docker daemon.
- goatinaboat 7y ago
  That's only a problem if you allow untrusted users operate the docker daemon. Sure, if you trust every developer in your company with the root password anyway, why not? That might be true at Docker (the company), I don’t know. Certainly wasn’t true at one company I worked at with 30,000 devs... By the way, this problem does not exist with competing container tools like Podman/Buildah.
  - raesene9 7y ago
    Why would you be allowing devs to directly deploy to production in a company with 30,000 developers? Surely you'd have proper release management where Ops teams would review deployment artifacts before deploying them?
    - goatinaboat 7y ago
      You wouldn’t but you wouldn’t give every dev root access to every dev box either... would you?
      - raesene9 7y ago

zimbatm 7y ago

Companies don't have feelings. The only ones weeping are the VCs that invested into Docker :-D Docker played its role and introduced the majority developers to containerization. This is a major success for the industry.

deleted 7y ago

[deleted]

FreeHugs 7y ago

Weep? Docker's downfall? What happened? As far as I can tell, everybody and his grandmother is using Docker. Why should we weep about it?

dagw 7y ago
'Everybody' is using docker the software, 'nobody' is using (ie paying) Docker the company. The article makes it clear they're talking about the company.
- budhajeewa 7y ago
  My small company pays for private image storage there. We actually used Google Cloud Platform's Docker Image hosting service, and that was expensive. Yay!? What else can we pay them for? All the stuff we need are available from them for free, except private storage. If they had a container hosting solution, we'd pay for it.
  - bvm 7y ago
    yeh we pay them like $15/month for Hub/Cloud/Private Image Storage/whatever it's called this week. It actually seems quite cheap...we have something like 2TB of tags up there, and they don't charge for network I/O. I did feel slightly bad when a hidden crash looping pod set to always download lay undiscovered for a month...that's a LOT of I/O.
- eeZah7Ux 7y ago
  > 'Everybody' is using docker the software Not at all - thanks goodness.
pjmlp 7y ago
Nah, plain old VMs over here.

tofflos 7y ago

I jumped on the container bandwagon late and immediately fell in love with Docker. It built on my existing skill set so I was quickly able to get something up and running. Then I started tinkering with Docker Compose and for a while things were great. But after a while I started running into issues. Compose felt artificially crippled. No secrets? No health checks? Pushing me towards Docker Swarm? Eventually I just sucked it up and switched to Kubernetes even though I think it's overkill for my applications.

orthoxerox 7y ago
My thoughts exactly. You cannot scale Docker. You can to a point, but there's always k8s looming ahead of you, saying, "sooner or later you will have to learn me instead". So most people learn it sooner than later to migrate to it while their workloads are still small. Of course, they often don't grow large enough for the benefits of k8s to kick in, but that's another story.

raesene9 7y ago

What's interesting, to me, about Docker as a company perhaps not doing well is how that'll impact Microsoft. Microsoft have done a load of work on getting containers running well on Windows servers and that work relies on Docker EE as the container runtime engine (you get a free Docker EE license to run on Windows servers AFAIK) If Docker get bought up (by someone other than Microsoft), then that would seem to possibly place Microsoft's container efforts at risk...

praseodym 7y ago
Microsoft has already heavily invested in getting Kubernetes running on Windows as a fist-class citizen: https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/getting-started-kubernetes-windows https://docs.microsoft.com/en-us/virtualization/windowsconta...

psv1 7y ago

Can anyone offer a good guide to DevOps for people who don't directly use these tools but work with engineers who do and would like to learn more? The whole ecosystem of servers, cloud infrastructure (and all of the different offerings there), Docker, Kubernetes, CICD tools etc is a bit overwhelming to get into.

marsrover 7y ago
I think the only way to learn them is to use them. You can do that locally or purchase a VPS and work there.
dsr_ 7y ago
Sure. None of the things you mentioned are DevOps. DevOps is two things: 1. Applying the methods of modern software development (version control, automation, DSLs...) to operations (provisioning, config, deployment, monitoring, backups...). 2. Reducing silo barriers between devs and ops groups so that everyone is working together as a team, rather than blaming each other for poor communication and the resulting messes. Then there are all the DevOps hijacking attempts, such as equating it to Agile or Scrum or XP, or insisting that it's a way to stop paying for expensive operations experts by making devs do it, or a way to stop paying for expensive devs by making ops do it, or a way to stop paying for expensive hardware by paying Amazon/Google/$CLOUD to do it. No matter what your software-as-a-service company actually does, it will need to execute certain things: - have computers to run software - have computers to develop software - have computers to run infrastructure support You can outsource various aspects of these things to different degrees. Anywhere you need computers, you have a choice of buying computers (and figuring out where to put them and how to run them and maintain them), or leasing computers (just a financing distinction), or renting existing computers (dedicated machines at a datacenter) or renting time on someone else's infrastructure. If you rent time, you can do so via virtual machines (which pretend to be whole servers) or containers (which pretend to be application deployments) or "serverless", which is actually a small auto-scaled container. Docker is a management scheme for containers. VMWare provides management schemes for virtual machines. Kubernetes is an extensive management scheme for virtual machines or containers. A continuous integration tool is, essentially, a program that notes that you have committed changes to your version control system and tries to build the resulting program. A continuous deployment system takes the CI's program and tries to put it into production (or, if you're sensible, into a QA deployment first).

redwood 7y ago

This article is real rich coming from a guy who works at AWS. The amount of absurd hubris and doublespeak entering this community unchecked is shocking to me.

i386 7y ago

In my experience having worked at two developer tools companies where we wanted to partner and co-market products, Docker would never pick up the phone. There was definitely a “we don’t need you attitude” whenever I approached them and I had the same experience repeated to me by friends at other companies trying to do the same thing.

wolco 7y ago
This is the core reason why they are where they are. They acted like you were bothering them and in fairness you probably were. Even today they wouldn't pick up. When you start believing the hype reality becomes distorted.
- i386 7y ago
  The kind of activities we were approaching about were for integrations, conferences, blog posts and webinars - great methods to get leads and remain in the zeitgeist.

alias_neo 7y ago

My experience agrees with this. I'm a huge fan of Docker, I've actively taken part since the early days, attending meetups and using it actively day to day. Unfortunately, when I brought several issues to GitHub, or +1'd other people's issues that were affecting the usability within our company, the attitude was very much "f* you and your problems" because Docker want things to be one way and that's how it'll be. There were issues raised 4+ years ago and are still open, for solutions to problems that would have mooted a need for us to use something like K8s (which doesn't work anyway for our requirements). I believe Docker locking the community out of valuable features had also done harm and (possibly) failed to be the monitiser they'd hoped for. After so long, I no longer go to Docker to solve problems that could be solved in Docker (secrets anyone? without the "hacks"), and just look towards the other tools solving the problems. I'll continue to use Docker, but I don't consider it a friend.

NotAnEconomist 7y ago
Docker has had a surprisingly quick turn from "new community software that's worth supporting" to "clearly sabotaged for 'enterprise' sales".
pacala 7y ago
I wonder how much of that attitude was caused by an overstretched team with no effective scaling mechanism in place. No, "open source" does not automatically mean "scalable team". Part of Kubernetes success is its ability to scale up the community, empowering multiple entities to meaningfully contribute.
- 0xDEFC0DE 7y ago
  At the same time, I gather it's really, really hard to write software that satisfies a lot of use cases across a lot of businesses without having to be somewhat opinionated.
  - pacala 7y ago
    True! Another part of Kubernetes success is the fact that it's core architecture is sound, scalable for both workloads and features.

notyourday 7y ago

For the same reason that no one weeps for a company that markets hammers even if it invented a new way to hold a hammer and raised lots of money because of it. We do not care about hammers, we just use them when we need to hit something. Our customers do not care about hammers either, they care about the result that we deliver.

dangerface 7y ago

I think the reason they failed is that they tried to make a platform for micro services but micro services is an anti pattern, people really just wanted containerisation.

alexandercrohde 7y ago

Why cry at all? Isn't this the point of open source? Can't the same be said for Git? Linux? Python? (That they didn't make the creator billions, and the creator is fine with that)

octosphere 7y ago

https://i.imgflip.com/24ac74.jpg https://i.imgflip.com/24ac74.jpg

ben_jones 7y ago

Docker sold its soul for money at the cost of its core product. The second you take as much money as they did so you can have your luxury box at AT&T or whatever else I’m going to find it increasingly hard to sympathize with your future mistakes.

thrower123 7y ago

I regret the time and money I spent thinking about learning Docker. I'm sure containers solve somebody's problems, but it's not any problems that I have.

derefr 7y ago

K8s is a “datacenter operating system”, just like VMWare’s own VSphere, or Mesos, Mosix, etc. These solutions also compete for mindshare with mainframe solutions like IBM’s; and with “control planes” like OpenStack, Canonical’s Landscape, or (I think?) Microsoft’s System Center. This space is very, very profitable. None of this applies to Docker itself. Docker is “just” a virtualization technology. Sure, Docker Swarm exists, but at this point it’s mostly used as a shimming UI for connecting the Docker client and daemon to the abstractions mentioned above, not a clustering solution in its own right. Swarm lost in the DCOS market. And the market for pure virtualization solutions isn’t anywhere near the market for DCOSes.

Blackstone4 7y ago
Doesn't K8s typically run on virtual machines? In which case it's K8s + VMs to get to the “datacenter operating system” model?
- gtaylor 7y ago
  It can run on VMs but doesn't have to. There are many bare metal k8s users out there doing some really neat things with the stack.

013a 7y ago

There's this prevalent false position that Kubernetes is successful because of Google. Yeah, Kubernetes initially learned a ton because of Borg and Google's deep investment into containers dating back a very long time. But, arguably, Kubernetes is successful because Google Let It Go. Its a true open source project, with governance by a wide number of industry advocates, underneath the Linux Foundation. By comparison, Docker is a VC-backed profit-minded startup. Of course it was going to lose this race, for the same reason Windows isn't the dominant OS in the cloud. Fundamentally: You can't build a hyperscale startup based on a technology. It doesn't appear to work anymore. The best case is the Docker/Kubernetes or Oracle/Postgres/MySQL case: someone else does it, maybe better, open sources it, community forms around it, you're toast. The worst case is the MongoDB/AWS or Elastic/AWS case; a cloud provider copies you, probably does it worse, but its cheaper and more integrated with the cloud, so they still win. Docker was doomed; they could have been a very nice business, but the issue is taking on huge valuations and capital, scaling like mad, and then finding out you have no ground underneath your feet to support that valuation.

jjtheblunt 7y ago
Parenthetically, Linux being an open source reincarnation of Solaris seems also an example, no?
- orbifold 7y ago
  Versions of Solaris are open source aswell (Illumos)
  - lazyguy2 7y ago
    Illumos and friends are effectively dead, except as hobbies for enthusiasts. Sun Microsystems, now Oracle, didn't like the reception Open Solaris got so they packed up their source code and went home. Which is really a shame. All 'True' Unixes are just closed source versions of what originally were open source operating systems. By taking copyright seriously and having the misconception that there is intrinsic value in 'IP' they effectively sentenced their operating systems and investors to a long term grave. But I doubt most of them feel bad about it. They got their millions and their nice fat retirements. It doesn't matter now if customers now view their once dominate systems as a sort of technical debt cancer. If it wasn't for the destructive power that copyright has on technology and the demands of board members to monetize Unix.. we would all be using BSD right now. Unfortunately the tech people from 30 years ago didn't understand the power of 'letting go' and thus allowed them to destroy Unix. As far as docker goes it has a lot of momentum as a daemon and it'll probably stay that way for a long time despite some technically superior solutions for running containers that have cropped up in the past few years. The newer container solutions just don't have the community backing them and that matters.

nova22033 7y ago

>Kubernetes "was operation hardened internally at Google Is this true? Isn't kubernetes "based" on work done at google but also a complete rewrite.

windsurfer 7y ago

The first and only experience I had with Docker as a company was requiring me to sign up to download their mac osx client. They seem to have since changed that policy but it really made me resent them, and made them feel pretty unfriendly.

choward 7y ago
Are you sure they changed it? https://github.com/docker/docker.github.io/issues/6910 https://github.com/docker/docker.github.io/issues/6910

dgoog 7y ago

Cause it's useless and so is k8s. When the recession comes all these coding bootcamp ppl are going to have to go back to their barista jobs and we won't have to deal with docker or kubernetes bullshit.

dgoog 7y ago

Mods I think it's time to start flagging kubernetes/docker posts. They are heavily marketing driven and come off as spam.

djsumdog 7y ago

I don't get why k8s is the dominant scheduler. If you have a 3 ~ 6 person platform team that can set one up, or build a secure terraform of CFN codebase to establish an AWS/EKS system, they can be nice. But I've also worked at DCOS/marathon shops where it worked just as well. The trouble with all these schedulers is they can't go from just one node (where scheduling and processes run on the same node .. and minikube is a hack; not a production system) to 100. You can't just setup a small k8s, and then add a node, and another node, and scale up. You go from a single docker system, to a big managed k8s system. There needs to be more competition. It's the same deal with the dominance of systemd as the only system layer. Only the small startups seem to be using more lightweight stuff like Nomad, k3s, RancherOS (Rancher is mostly going the managed k8s solution anyway; even though they have their own k3s implementation). A running k8s system can be okay, but there is a lot of room for improvement (in terms of making it simpler). Both DCOS and k8s seem to waste a lot of resources. Docker could have competed in this space, but everyone complained about all the bugs in Swarm and it never really went anywhere. I did a writeup on container orchestration systems late last year: https://penguindreams.org/blog/my-love-hate-relationship-with-docker-and-container-orchestration-systems/ https://penguindreams.org/blog/my-love-hate-relationship-wit...

mmanfrin 7y ago

It's minor and maybe I'm being petty, but my sympathy for Docker ended the moment they forced you to register an account and log in to download Docker CE.

GordonS 7y ago

A little OT, but is there anything remotely competitive with k8s these days? By "competitive", I mean: good feature set, thriving community, active development. I still use Docker Swarm for small scale stuff, and am pretty happy with it - it's simple, easy to use and doesn't eat resources. But it very much feels like Docker have given up on it. I'm particularly interested to know if there is anything simpler than k8s that's competitive?