18 ms·

How Docker broke in half

302 points by pauljonas 5y ago

NortySpock 5y ago
I really enjoyed reading this history of the creation of Docker and the company that supports it (Docker, Inc., previously dotCloud, Inc.)
- randombits0 5y ago
  I almost enjoyed it. I need a better ad blocker. That site sucks on mobile.
  - mikestew 5y ago
    I have a better ad blocker, so now it's just white rectangles chasing me down the page, with a big white banner at the top that also chases page scrolls. Were it not for reader view, I wouldn't even have bothered with reading it. I'm dead serious when I say that I think I'll start using InfoWorld as my pi-hole test bed rather cafemom.com (which used to be my egregiously obnoxious go-to for ad-laden sites).
  - WolfeReader 5y ago
    Using Firefox/Fennec with uBlock Origin works just fine for me! https://f-droid.org/packages/org.mozilla.fennec_fdroid/ https://f-droid.org/packages/org.mozilla.fennec_fdroid/ https://play.google.com/store/apps/details?id=org.mozilla.firefox https://play.google.com/store/apps/details?id=org.mozilla.fi...
  - threatofrain 5y ago
    Do you have reader mode, which is available on many browsers?
  - sorokod 5y ago
    Or use Firefox Focus.
quantumwoke 5y ago
Good read, and touches on a lot of the pain points from that era. As someone who was lurking on HN at the time during the containerization boom, I think that the key failing of dotCloud/Docker was not capitalising on Docker Swarm almost immediately. Docker Swarm was touted almost from the start but the repeated delays gave it a reputation of smoke and mirrors left people scrambling for solutions. I also clearly remember the multiple high profile spats that 'shykes had on HN which burned a lot of bridges. At the time he had a reputation for answering lots of questions on HN which helped a lot with community building. After those bridges were burned there was no one to speak for Docker as the developer mindsets shifted slowly towards Kubernetes. IIRC the Github PRs were also a source of contention as dotCloud corporatised. To be fair, Kubernetes was a real slog to understand at the start and had a lot of competition; it was definitely not the same level of simple, direct technical solution that Docker was. Interesting trip down memory lane and what a pivotal technology! Regardless of the rest Docker is a true cultural phenomenon and a testament to the insight of the creators working outside of the myopia of big tech.
- bcantrill 5y ago
  Yes. Anyone who wants to relive an early ignition of one bridge should read the HN thread on the Rocket announcement.[0] No one is sympathetic with respect to the Rocket/Docker spat; both companies behaved poorly -- and it was increasingly clear that the energy at Docker, Inc. was going to spent fighting others rather than building a business. Speaking personally, the fate of Docker, Inc. was clear to me when they took their $40M Series C round in 2014. I had met with Solomon in April 2014 (after their $15M Series B) and tried to tell him what I had learned at Joyent: that raising a ton of money without having a concrete and repeatable business would almost inevitably lead to poor decision making. I could see that I was being too abstract, so I distilled it -- and I more or less begged him to not take any more money. (Sadly, Silicon Valley's superlative, must-watch "Sand Hill Shuffle" episode[1] would not air until 2015, or I would have pointed him to it.) When they took the $40M round -- which was an absolutely outrageous amount of capital to take into a company that didn't even have a conception of what they would possibly sell -- the future was clear to me. I wasn't at all surprised when the SVP washouts from the likes of VMware and IBM landed at Docker -- though still somehow disappointed when they behaved predictably, accelerating the demise of the company. May Docker, Inc. at least become a business school case study to warn future generations of an avoidable fate! [0] https://news.ycombinator.com/item?id=8682525 https://news.ycombinator.com/item?id=8682525 [1] https://www.hbo.com/silicon-valley/season-02/1-sand-hill-shuffle https://www.hbo.com/silicon-valley/season-02/1-sand-hill-shu...
cdrini 5y ago
Very well written article! Personally, I'm still waiting for docker swarm. The thing is enterprise doesn't care about developer experience. They don't need to; they pay developers so much, they have over qualified developers who can grok Kubernetes, and can hire more at a moment's notice. They care much more about whether it meets their goals. Smaller companies/orgs are what care about DX. They have likely very few, potentially not super highly qualified developers, and very limited resources. To them, something that their developers can set up, understand, and maintain, that's reliable and resilient, is a HUGE win.
- clipradiowallet 5y ago
  > Personally, I'm still waiting for docker swarm. What are you waiting for, is there something new in the works wrt swarm? I was a swarm fan early on(and secretly still am), but otherwise k8s is where I spend all my time at work.
  - cdrini 5y ago
    It never quite felt "ready"; it's development and docs always felt like an after thought. I guess it's more to do with marketing than the actual service. And I'm always afraid they're going to axe the thing. It probably is ready enough to give it a whirl.
- zaphar 5y ago
  I think you vastly overestimate the skill level of enterprise developers. Enterprise may pay a lot but they also hamstring developers in some interesting ways which tends to attract people who are better at the political game than the tech. The high pay attracts skill just the wrong skill in many cases.
threatofrain 5y ago
> The truth is, Docker had the chance to work closely with the Kubernetes team at Google in 2014 and potentially own the entire container ecosystem in the process. “We could have had Kubernetes be a first-class Docker project under the Docker banner on GitHub. In hindsight that was a major blunder given Swarm was so late to market,” Stinemates said. > Craig McLuckie, Kubernetes cofounder and now vice president at VMware, says he offered to donate Kubernetes to Docker, but the two sides couldn’t come to an agreement. “There was a mutual element of hubris there, from them that we didn’t understand developer experience, but the reciprocal feeling was these young upstarts really don’t understand distributed systems management,” he told InfoWorld. The article criticizes Docker Swarm as myopic, but IMO, there were only two possibilities for Docker to move forward; either they acquired Kubernetes, which was a possibility in this telling of events, or they won with their own Docker Swarm.
- heavenlyblue 5y ago
  “Didn’t understand developer experience” I am wondering if anyone ever actually properly used docker swarm in any proper way? Especially as a small-scale developer.
  - doctor_eval 5y ago
    Yeah we used it in production, I’m not there any more but as far as I know it’s still running. Swarm was good, easy to set up and run, but it had a lot of networking bugs. More than once we had to cycle the docker daemon on all machines which basically resulted in a rolling outage. We’re trialling nomad at our new co, I was put off by the opaqueness and complexity of K8s, but apparently that’s just me.
    - wpietri 5y ago
      It is definitely not just you.
- deleted 5y ago
  [deleted]
- 5y ago
zzyzxd 5y ago
> “The biggest mistake was to miss Kubernetes. We were in that collective thought bubble where internally we thought Kubernetes was way too complicated and Swarm would be much more successful,” Jérôme Petazzoni, one of Docker’s first and longest serving employees, said. “It was our collective failure to not realize that.” They were not wrong on saying that Kubernetes was very complicated, at least in some sense. In the beginning no one wanted to use it because they could easily setup Docker Swarm with minimal effort. This argument still pops up frequently on HN when there's a new post about Kubernetes. I guess the problem was they didn't realize why Kubernetes needs to be that complicated. And if a system is complicated for good reasons, that's actually good business opportunity and tons of people and companies will be willing to make the effort to fill that gap.
- gizdan 5y ago
  On this note, HN users and several HC employees (including some enterprise architects) I've spoken to love to mention Nomad and how it's much lighter and simpler to run, completely oblivious that many with bigger names have tried and failed to go up against K8s. Kubernetes has become a speeding bullet, it won't be easy to catch and it has to run through a lot of walls to slow down for a competitor to do any damage to it's dominance.
  - schmichael 5y ago
    > completely oblivious that many with bigger names have tried and failed to go up against K8s Ha, I can at least assure you we're not oblivious. Nomad has a product manager from Mesosphere and most of HashiCorp's products integrate deeply with Kubernetes. We're well aware Kubernetes is the juggernaut to which every other scheduler has succumbed. I believe there's room for both Nomad and Kubernetes. Whether as competitors or complements, having more than one vibrant project in the orchestration space will hopefully make all the projects better for users. Any one project has to make tradeoffs that improve the user experience for some while degrading it for others. For example Kubernetes has an IP-per-Pod network abstraction which provides an excellent out of the box PaaS-like experience for microservices in the cloud. On the other hand Nomad's more flexible network model more easily supports networks outside of flat cloud topologies whether it's small home raspberrypi clusters or globally distributed edge compute.
awinter-py 5y ago
ugh docker only ever did one thing right, allowed me to run postgres + mysql on my laptop without the DBs shitting on the rest of the laptop if they had just released a chroot database runner, would have been as good as what they did it has never been good at build or deployment. it has definitely never been good at cloud. even kube is still awful at most things these systems have never been sure if they're configuration languages, buildsystems, plugin hosts, or operating systems, and so they've been bad at all 4
morpheos137 5y ago
If software development was a real engineering discipline docker wouldn't exist. The idea that you need isolated environments to run/develop programs that need different versions of libraries is regressive. Way back in the 80s and 90s Microsoft had backwards compatiblity down. Now in the 2010s and 2020s every couple months we can expect a breaking change in the webdev, linux, python ecosystem. Try running a 3 year old python app outside a container. This foot gunning is dumb. But it sure does make work for software developers. Who go on HN and crow about how much value they create while messing around in docker or whatever.
- rualca 5y ago
  > The idea that you need isolated environments to run/develop programs that need different versions of libraries is regressive. Containerization's value proposition isn't really the isolation part. That's nice and all, but it's not their main selling point. The main selling point of containers is the fact that they solve the problems of packaging, deploying applications, and configuration, and they do so in a perfectly auditable and observable way.
  - morpheos137 5y ago
    Again if backwards compatibility were respected then packaging and deployment wouldn't be so complicated.
    - AlexMoffat 5y ago
      If wishes were horses beggars would ride.
    - doctor_eval 5y ago
      C’mon, compatibility with the host OS is just one of many deployment issues that need to be solved. Deployment covers a ton of problems including resource allocation, traffic routing, discoverability, health checks, secrets management and heaps more. Containerisation just provides a unit of management. I work in Go which has great backwards compatibility, builds static binaries, and since //go:embed you can release a single binary containing literally all resources needed to run an application. We don’t technically need to use docker to deploy our services but we still need an orchestration platform. Ironically given the discussion, we’ve chosen nomad over K8s, but nevertheless we needed something, and “backwards compatibility” didn’t really even register.
boucher 5y ago
I am a huge fan of Docker the tool, and during the prime of Docker the company they were doing some really impressive stuff. Swarm was dramatically easier to use than Kubernetes. The people working on Docker both in and outside of the company were top notch and they should be proud of what they accomplished. It's too bad they didn't make the business side of things work, though I agree that at the time there was a certain feeling of too much money chasing an uncertain future for an open source project. I hope this next iteration of the company works out for them.
- mountainriver 5y ago
  Swarm may have been easier to get going but from what I heard it had a lot of operational problems and lacked a complete feature set
debarshri 5y ago
But did kubernetes really won the orchestration war or is it still an ongoing thing?
- aynyc 5y ago
  It won. Right now it's a speeding train. To compete with it, you better come up with something that's mind blowing, or a culturally shift in development.
  - debarshri 5y ago
    I am not sure. almost 80% of the customer we talk to have troubles with kubernetes. They might be too small to operate it or something.
    - aynyc 5y ago
      K8s aren't easy, but if you have enough workloads that you can't keep track of on a single spreadsheet, you probably could use K8s. I haven't seen really true alternative to manage large enough and variable enough workloads successfully. One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases, apps, etc.. K8s might be too much.
      - magicalhippo 5y ago
        > One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases That's our situation soon. We're about to start migrating away from a desktop win32 application. Any good deployment options for such a scenario? We're talking 4-500 customers with their own db, less than 10k users. On-premise installation must be possible (though "give us a VM" is what we currently do, so that might not be to different).
        jiggawatts 5y ago
        Depends a lot on what the new application architecture looks like, but one option is this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/overview https://docs.microsoft.com/en-us/azure/azure-resource-manage... You could use the same templates to deploy both the vendor-hosted and customer-hosted version of the app. The physical architecture can be anything. A single container, the PaaS App Service, VMs, etc...
endisneigh 5y ago
I'm curious - does anyone have a story on how they used Docker Swarm for something at scale (>100 nodes), but later migrated to K8s successfully at the same scale?
technicolorwhat 5y ago
There is no mention on LXC/jails which is ofcourse the biggest inspiration for docker, if I am not mistaken it also used lxc under the hood. That was already a good'ish product and but hard to configure and not for the mainstream at the time. Docker introduced AUFS and downloading of images which was added. I always saw docker as a properly marketed nicely ribboned lxc but mediocre implemented since they removed a lot of options at that time that were super useful like cpu limiting etc from std lxc.
stuff4ben 5y ago
Wow this was a great read! I remember taking a kubernetes class in late 2015 and the instructor then was saying that Kubernetes had already won over Docker Swarm and Mesos. If I were at the helm of Docker today, I'd focus on Enterprise customers. Provide an on-prem version of DockerHub and you'll convince thousands of companies tired of Artifactory to switch immediately. Don't get me wrong Artifactory is pretty nice, but it's a bear to run at scale on an enterprise level. DockerHub already is handling that traffic, so there's no reason to think they can't port that to an on-prem offering.
- schipplock 5y ago
  Nexus3 can be a docker registry. It’s built-in.
- merb 5y ago
  why even bother? there is quay, which is way better than dockerhub or the open source integration. and even than there is also harbor, nexus3 and as you mentioned artifactory. ALL of them can be bought with support from way bigger companies than docker inc. so why even bother?! Docker Inc. basically failed by trying to do everything on their own.
IneffablePigeon 5y ago
We used Tutum before it was acquired by Docker and turned into Docker Cloud. Whilst it probably would never have scaled to our complexity needs indefinitely as we grew, it was very clear that as soon as it was purchased the product stopped going in a positive direction. The only changes that they really rolled out were replacing the older, perfectly functional UI with something superficially shinier but much, much harder to use. Not only was it just hard to see what you wanted to see once they'd halved the information density and got rid of any visual hierarchy, you had absolutely crazy things like a slider for the number of instances of a service that would instantly apply with no confirmation and, even crazier, responded to the scroll wheel. We once doubled our number of production pods and didn't notice for a few hours, because someone scrolled up the page and their cursor went over the slider. Lucky they weren't scrolling the other way. Anyway, I lost a lot of trust in Docker as an organisation that knows what people value about their products as a part of that.
sbmthakur 5y ago
> The combination of huge amounts of venture funding, a quickly growing competitive landscape, and the looming shadow of cloud industry giants all wanting a piece of the pie created a pressure cooker environment for the young company to operate within. I actually got an AWS ad on the same page while reading this comment. It's definitely hard to compete when your competitors(with lot of capital) can easily integrate your tech into theirs in no time.
swlkr 5y ago
I wonder if there's more room for things like fly dot io but with things like minio/s3 or lambda included as well for bandwidth savings, kind of an "aws lite"
jokethrowaway 5y ago
The real problem is that docker swarm is nowhere close to being production ready and it's full of gotchas and design decisions that make little sense as an end user. They simply couldn't make a product good enough for the enterprise, like k8s did. I have similar reservations towards docker; sure it was a mostly novel concept (I saw live when Solomon announced docker and relatively few people knew at the time about Linux native containers or about bsd jails) but it so full of quirks and gotchas and bad APIs that it's not smooth sailing. Unfortunately they couldn't make docker into a product (or they would have faced the wrath of the OSS community) so they probably felt stripped for time on both docker and on swarm, which made for an unpolished experience. I've been using swarm for a small project for funz and because I didn't want to run the full k8s (even k0s or k3s would have been heavy for my use case) and because I had bad experiences with nomad. My list of complaints: - Stacks are not working 1-1 with Compose - docker machine is a separate binary - You can't pull the latest of a docker image or the cache hit will just fail to redeploy your changes (you're forced to do a sort of blue-green deployment or just update a tag everytime) - You have to configure, run, garbage collect a registry from scratch - docker-flow-proxy should be included out of the box - I need a way to integrate secrets Don't get me wrong, there's an amazing amount of progress in docker swarm (and I'm running it in production, for free, on a 5$ machine). Years ago it was even worse but it's not something I would ever recommend to my employer. I hope we'll get there eventually.
rejectedandsad 5y ago
> Hykes does acknowledge that there were tensions between the Docker and Google teams at the time. “There was a moment when egos prevailed. A lot of smart and experienced people at Google were blindsided by the complete outsiders at Docker,” Hykes said. “We didn’t work at Google, we didn’t go to Stanford, we didn’t have a PhD in computer science. I found this passage interesting. Are these tensions common?
- Fiahil 5y ago
  Yes, I graduated from the same school as Salomon a few years later, and I got a lot of “you’re just a random dude from nowhere, go back to the playground” vibe during my time in California. It’s quite an American attitude to judge your entire life and skills solely based on the college you went to. I didn’t encounter such attitude with my fellow European and Australian colleagues. Nowadays, I don’t care that much because I’m not the little, defenseless, graduate student I was, and I do enjoy bringing a Google-Standford-Californian down to earth when they are bragging about something they have no idea about.
  - rejectedandsad 5y ago
    Depressing. I went to a basic state school and work at a normal company (not Google) and it feels like I’ll be destined to stay a failure forever.
    - int_19h 5y ago
      For what it's worth, I have no degree at all, and that didn't preclude Microsoft from hiring me - nor have I ever been discriminated or disparaged for this reason in the decade since. So it might be something that varies from company to company. I wouldn't be surprised that Google, in particular, has these attitudes, as they're known to be picky about degrees when hiring.
    - davidwf 5y ago
      You aren't! I'm a state-school bachelor's-only don't-even-have-a-CS-degree person; neither of my parents have a 4-year-degree. I had a FAANG job, left it for a better one, own a house in 2/5 of the most expensive cities of the world, etc., etc. Elitist assholes definitely exist everywhere, but in my experience a lot of what I viewed as "showing off" when I was younger was really just "being normal" for a different "normal". When a 25-year-old software developer talks all the time about Stanford and Lambos, he's not trying to show off, he's just talking about what he knows, just like the guy talking about tail-gating at <insert SEC school here> and then going four-wheeling all the time. I don't want to devalue experience and education in any way; those things have value! But time is linear and the past has happened -- you just have to move forward with what you have and go after what you want, and don't get distracted by the fact that others started out with a lot more than you. I double-pinky-promise you that if you are good at something, keep getting better at it, and aren't an asshole yourself, you can work at any company you want. :-)
mikesabbagh 5y ago
kubernetes makes simple deployments look complex, and complex deployments look simple. Docker would be my choice for a simple deployment (like server + db) Only use kubernetes when you need to do complex stuff, it does make things look simple then.
greatgib 5y ago
I don't like so much the idea pushed by the article author that it is partly the fault of the software to be open source! At least, the founders of Docker are honest and clear in my opinion: << Hykes disagrees with this assessment. “I think that is wrong and generally speaking the core open source product created massive growth which created the opportunity to monetize in the first place,” he said. “Lots of companies monetize Docker successfully, just not Docker. There was plenty to monetize, just Docker failed to execute on monetizing it.>> There is still a thing that is missing there: the article let think that docker was an innovation out of nowhere and they had an unique idea that was kind of spoiled. But, one has to remember the context of the period when Docker was created: It was a time were cgroups and "namespaces" of network, process, ... were the hot new things inside the Linux and everyone was thinking about the concept of "container", one way or another. There were already chroots and a lot of persons were already working on "app"/"module"/"package" systems using aufs/overlaysfs layers. So, this was the moment and a few competitor were emerging like lxc and docker. Docker was very good to take the of the media cover and hype and so to become the dominant way to have "containers". But, at the beginning, there was nothing particular in the technology and lots of competitors could have done it if it was not Docker.
- meatmanek 5y ago
  Certainly my recollection is that containers didn't enter the zeitgeist until Docker came around. LXC and OpenVZ had existed for years before Docker, and Jails/Zones had existed in BSD/Solaris for years before that. Mentioning the long-standing existence of these tools was a favorite pastime of Docker detractors in the early days. Really, Docker's innovation wasn't the ability to run processes in a container (as mentioned before, that technology had existed for years already); it was the Dockerfile and the Docker hub/container registry. Prior to Docker, the way you'd build a container was by running debootstrap or unpacking a tarball/zip file of a root image. Take a look at https://developer.ibm.com/tutorials/l-lxc-containers/ https://developer.ibm.com/tutorials/l-lxc-containers/ . As far as I recall, there was no LXC equivalent to `docker build` or the registry except maybe wiring up Packer or home-grown shell script and throwing a tarball in S3 or something.
  - 5y ago
manishsharan 5y ago
I am surprised everyone is blaming K8s for eating Docker's lunch but from my experience in the banking industry.. it was cloudfoundry that stole the market away from Docker swarm.I don't think I ever saw a Docker swarm in production; IT departments standardized on cloudfoundry to manage their "private/on-prem cloud".
- mixmastamyk 5y ago
  There's a lot of "dark" matter and energy in this industry that doesn't get much attention, even when it may be the majority of mass in a particular area.
jrochkind1 5y ago
How many employees does Docker has/had? I feel like if I got a couple hundred million dollars in funding, I could make it last many many years, producing what Docker has produced. But of course this feeling isn't based on any entrepeneurial experience, so I'm probably wrong. But that seems like an awful lot of money to shoot through.
- AlexCoventry 5y ago
  VC investors don't give you that money to sit on it. They want you to scale, and quickly.
ilaksh 5y ago
I think what happened with Docker is that it was just too good at what it was originally intended to do and too easy to use for that. Programmers hate things that are easy to use (by the way I am a programmer, and no I don't feel that way) because if they admit they use them then they might be accused of being users. And of course no programmer will admit this. They don't realize it because it's actually a subconscious psychological issue. And so what programmers started to do was immediately make it much more complicated and at the same time, take it completely for granted. It was so useful it was like a floor to walk on. And so people started giving it the same level of respect they give a floor. So for those reasons, Docker became very uncool. But at the same time it was incredibly useful. Solution: make something just like Docker but not Docker, which hip people will be allowed to use without any shame. Make it a bit more complicated and only run on the cool expensive hardware.
jrm4 5y ago
As someone only casually knowledgable in this area (e.g. I use docker for some of my home automation thingies, I still haven't wrapped my head fully around what Kubernetes is beyond something like a way to manage a bunch of similar containers? VMs? eg).. Docker, the kabillion dollar company, never had a chance. We all recognize the potential and actual problems when some very crucial piece of infrastructure is only free/open source and not maintained -- but this is what happens when it is "overmaintained" I.e. it makes sense to invest big in something that is good and could be crucial; but only if you can both keep up quality AND stave off competitors -- and in this case, competitors aren't just other companies, but free software in general. It's kind of funny, in a way, Docker made itself a target for "good competition" by being so visible, in a way that e.g. "curl" didn't. Either way, I always knew "Docker the kabillion dollar company" was a stupid stupid bet. Small company, great bet. But this? Destined to fail.
jeffthechimp 5y ago
Happened to a pair of my Dockers once.
fulafel 5y ago
Anyone know any good metrics or analysis about trends of Kubernetes vs other ways to run containers in the not-huge-scale dev world which is 99% of software?
zxcvbn4038 5y ago
My issue with Docker Inc has been with the support. I started to give them money once but pulled back after it became clear the support experience was essentially “customer support thyself”. I don’t have to pay anyone to have my support ticket ignored, I can do that myself for free. Anyway they are past the point of no return now. Their creations will undoubtedly outlive them - probably Queen Elizabeth also. Anything they pull back will be replaced by the community. Anything new will get aped by everyone else trying to make a name for themselves. Containers are more or less a generic commodity now.
korginator 5y ago
Use the right tools for the job. I continue to run small to medium scale deployments with a couple dozen containers with Swarm. It's smooth, and just works. Kubernetes would work too, and I use it for newer deployments. Heck, I use plain old docker-compose to manage production servers with half a dozen containers, trouble-free for a few years now. Compose v2 seems promising, I've been using it for a while and it's pretty stable too. Swarm could have been an industry in itself, a de-facto standard for orchestration if it had been marketed and supported right. It was a lot more stable than Kubernetes in the early days and things just worked with docker while you'd have to kludge a few things to get Kubernetes doing its thing right.
say_it_as_it_is 5y ago
The desire to change the world was stronger than the desire to make money while doing it
bacan 5y ago
Kubernetes is an absolute joke. Even after being set-up right, it rarely works as it is supposed too.
hnarn 5y ago
I have always been somewhat skeptical of Docker, for example due to how horribly it has always worked on Windows. My first real exposure to containers was when getting into Red Hat certifications and being introduced to Podman, and with the benefit of hindsight I don't really understand the benefit of Docker today when comparing the two. Podman seems just as easy, more restricted and more in line with what some might call "Unix philosophy". Of course when it comes to distributed environments I'm sure Kubernetes still reigns supreme, but for relatively simple container setups I don't think there's a need to even run Docker anymore on Linux. Obviously, I'm still not well versed in containers so this might all be overlooking something.
- mixmastamyk 5y ago
  Yes, it's common for better designs to come along after insight has been gained by trial and error.
- hda111 5y ago
  Docker has with no doubt much better UX. It just works and it’s very easy to use. For podman is seems you need a bit more knowing what you are doing. You need to know iptables. With Docker your database container is reachable in the Internet automatically. Not possible to lock it down with iptables rules. (Could be a disadvantage too.)

302 points by pauljonas 5y ago

I really enjoyed reading this history of the creation of Docker and the company that supports it (Docker, Inc., previously dotCloud, Inc.)

randombits0 5y ago
I almost enjoyed it. I need a better ad blocker. That site sucks on mobile.
- mikestew 5y ago
  I have a better ad blocker, so now it's just white rectangles chasing me down the page, with a big white banner at the top that also chases page scrolls. Were it not for reader view, I wouldn't even have bothered with reading it. I'm dead serious when I say that I think I'll start using InfoWorld as my pi-hole test bed rather cafemom.com (which used to be my egregiously obnoxious go-to for ad-laden sites).
- WolfeReader 5y ago
  Using Firefox/Fennec with uBlock Origin works just fine for me! https://f-droid.org/packages/org.mozilla.fennec_fdroid/ https://f-droid.org/packages/org.mozilla.fennec_fdroid/ https://play.google.com/store/apps/details?id=org.mozilla.firefox https://play.google.com/store/apps/details?id=org.mozilla.fi...
- threatofrain 5y ago
  Do you have reader mode, which is available on many browsers?
- sorokod 5y ago
  Or use Firefox Focus.

quantumwoke 5y ago

Good read, and touches on a lot of the pain points from that era. As someone who was lurking on HN at the time during the containerization boom, I think that the key failing of dotCloud/Docker was not capitalising on Docker Swarm almost immediately. Docker Swarm was touted almost from the start but the repeated delays gave it a reputation of smoke and mirrors left people scrambling for solutions. I also clearly remember the multiple high profile spats that 'shykes had on HN which burned a lot of bridges. At the time he had a reputation for answering lots of questions on HN which helped a lot with community building. After those bridges were burned there was no one to speak for Docker as the developer mindsets shifted slowly towards Kubernetes. IIRC the Github PRs were also a source of contention as dotCloud corporatised. To be fair, Kubernetes was a real slog to understand at the start and had a lot of competition; it was definitely not the same level of simple, direct technical solution that Docker was. Interesting trip down memory lane and what a pivotal technology! Regardless of the rest Docker is a true cultural phenomenon and a testament to the insight of the creators working outside of the myopia of big tech.

bcantrill 5y ago
Yes. Anyone who wants to relive an early ignition of one bridge should read the HN thread on the Rocket announcement.[0] No one is sympathetic with respect to the Rocket/Docker spat; both companies behaved poorly -- and it was increasingly clear that the energy at Docker, Inc. was going to spent fighting others rather than building a business. Speaking personally, the fate of Docker, Inc. was clear to me when they took their $40M Series C round in 2014. I had met with Solomon in April 2014 (after their $15M Series B) and tried to tell him what I had learned at Joyent: that raising a ton of money without having a concrete and repeatable business would almost inevitably lead to poor decision making. I could see that I was being too abstract, so I distilled it -- and I more or less begged him to not take any more money. (Sadly, Silicon Valley's superlative, must-watch "Sand Hill Shuffle" episode[1] would not air until 2015, or I would have pointed him to it.) When they took the $40M round -- which was an absolutely outrageous amount of capital to take into a company that didn't even have a conception of what they would possibly sell -- the future was clear to me. I wasn't at all surprised when the SVP washouts from the likes of VMware and IBM landed at Docker -- though still somehow disappointed when they behaved predictably, accelerating the demise of the company. May Docker, Inc. at least become a business school case study to warn future generations of an avoidable fate! [0] https://news.ycombinator.com/item?id=8682525 https://news.ycombinator.com/item?id=8682525 [1] https://www.hbo.com/silicon-valley/season-02/1-sand-hill-shuffle https://www.hbo.com/silicon-valley/season-02/1-sand-hill-shu...

cdrini 5y ago

Very well written article! Personally, I'm still waiting for docker swarm. The thing is enterprise doesn't care about developer experience. They don't need to; they pay developers so much, they have over qualified developers who can grok Kubernetes, and can hire more at a moment's notice. They care much more about whether it meets their goals. Smaller companies/orgs are what care about DX. They have likely very few, potentially not super highly qualified developers, and very limited resources. To them, something that their developers can set up, understand, and maintain, that's reliable and resilient, is a HUGE win.

clipradiowallet 5y ago
> Personally, I'm still waiting for docker swarm. What are you waiting for, is there something new in the works wrt swarm? I was a swarm fan early on(and secretly still am), but otherwise k8s is where I spend all my time at work.
- cdrini 5y ago
  It never quite felt "ready"; it's development and docs always felt like an after thought. I guess it's more to do with marketing than the actual service. And I'm always afraid they're going to axe the thing. It probably is ready enough to give it a whirl.
zaphar 5y ago
I think you vastly overestimate the skill level of enterprise developers. Enterprise may pay a lot but they also hamstring developers in some interesting ways which tends to attract people who are better at the political game than the tech. The high pay attracts skill just the wrong skill in many cases.

threatofrain 5y ago

> The truth is, Docker had the chance to work closely with the Kubernetes team at Google in 2014 and potentially own the entire container ecosystem in the process. “We could have had Kubernetes be a first-class Docker project under the Docker banner on GitHub. In hindsight that was a major blunder given Swarm was so late to market,” Stinemates said. > Craig McLuckie, Kubernetes cofounder and now vice president at VMware, says he offered to donate Kubernetes to Docker, but the two sides couldn’t come to an agreement. “There was a mutual element of hubris there, from them that we didn’t understand developer experience, but the reciprocal feeling was these young upstarts really don’t understand distributed systems management,” he told InfoWorld. The article criticizes Docker Swarm as myopic, but IMO, there were only two possibilities for Docker to move forward; either they acquired Kubernetes, which was a possibility in this telling of events, or they won with their own Docker Swarm.

heavenlyblue 5y ago
“Didn’t understand developer experience” I am wondering if anyone ever actually properly used docker swarm in any proper way? Especially as a small-scale developer.
- doctor_eval 5y ago
  Yeah we used it in production, I’m not there any more but as far as I know it’s still running. Swarm was good, easy to set up and run, but it had a lot of networking bugs. More than once we had to cycle the docker daemon on all machines which basically resulted in a rolling outage. We’re trialling nomad at our new co, I was put off by the opaqueness and complexity of K8s, but apparently that’s just me.
  - wpietri 5y ago
    It is definitely not just you.
deleted 5y ago
[deleted]
5y ago

zzyzxd 5y ago

> “The biggest mistake was to miss Kubernetes. We were in that collective thought bubble where internally we thought Kubernetes was way too complicated and Swarm would be much more successful,” Jérôme Petazzoni, one of Docker’s first and longest serving employees, said. “It was our collective failure to not realize that.” They were not wrong on saying that Kubernetes was very complicated, at least in some sense. In the beginning no one wanted to use it because they could easily setup Docker Swarm with minimal effort. This argument still pops up frequently on HN when there's a new post about Kubernetes. I guess the problem was they didn't realize why Kubernetes needs to be that complicated. And if a system is complicated for good reasons, that's actually good business opportunity and tons of people and companies will be willing to make the effort to fill that gap.

gizdan 5y ago
On this note, HN users and several HC employees (including some enterprise architects) I've spoken to love to mention Nomad and how it's much lighter and simpler to run, completely oblivious that many with bigger names have tried and failed to go up against K8s. Kubernetes has become a speeding bullet, it won't be easy to catch and it has to run through a lot of walls to slow down for a competitor to do any damage to it's dominance.
- schmichael 5y ago
  > completely oblivious that many with bigger names have tried and failed to go up against K8s Ha, I can at least assure you we're not oblivious. Nomad has a product manager from Mesosphere and most of HashiCorp's products integrate deeply with Kubernetes. We're well aware Kubernetes is the juggernaut to which every other scheduler has succumbed. I believe there's room for both Nomad and Kubernetes. Whether as competitors or complements, having more than one vibrant project in the orchestration space will hopefully make all the projects better for users. Any one project has to make tradeoffs that improve the user experience for some while degrading it for others. For example Kubernetes has an IP-per-Pod network abstraction which provides an excellent out of the box PaaS-like experience for microservices in the cloud. On the other hand Nomad's more flexible network model more easily supports networks outside of flat cloud topologies whether it's small home raspberrypi clusters or globally distributed edge compute.

awinter-py 5y ago

ugh docker only ever did one thing right, allowed me to run postgres + mysql on my laptop without the DBs shitting on the rest of the laptop if they had just released a chroot database runner, would have been as good as what they did it has never been good at build or deployment. it has definitely never been good at cloud. even kube is still awful at most things these systems have never been sure if they're configuration languages, buildsystems, plugin hosts, or operating systems, and so they've been bad at all 4

morpheos137 5y ago

If software development was a real engineering discipline docker wouldn't exist. The idea that you need isolated environments to run/develop programs that need different versions of libraries is regressive. Way back in the 80s and 90s Microsoft had backwards compatiblity down. Now in the 2010s and 2020s every couple months we can expect a breaking change in the webdev, linux, python ecosystem. Try running a 3 year old python app outside a container. This foot gunning is dumb. But it sure does make work for software developers. Who go on HN and crow about how much value they create while messing around in docker or whatever.

rualca 5y ago
> The idea that you need isolated environments to run/develop programs that need different versions of libraries is regressive. Containerization's value proposition isn't really the isolation part. That's nice and all, but it's not their main selling point. The main selling point of containers is the fact that they solve the problems of packaging, deploying applications, and configuration, and they do so in a perfectly auditable and observable way.
- morpheos137 5y ago
  Again if backwards compatibility were respected then packaging and deployment wouldn't be so complicated.
  - AlexMoffat 5y ago
    If wishes were horses beggars would ride.
  - doctor_eval 5y ago
    C’mon, compatibility with the host OS is just one of many deployment issues that need to be solved. Deployment covers a ton of problems including resource allocation, traffic routing, discoverability, health checks, secrets management and heaps more. Containerisation just provides a unit of management. I work in Go which has great backwards compatibility, builds static binaries, and since //go:embed you can release a single binary containing literally all resources needed to run an application. We don’t technically need to use docker to deploy our services but we still need an orchestration platform. Ironically given the discussion, we’ve chosen nomad over K8s, but nevertheless we needed something, and “backwards compatibility” didn’t really even register.

boucher 5y ago

I am a huge fan of Docker the tool, and during the prime of Docker the company they were doing some really impressive stuff. Swarm was dramatically easier to use than Kubernetes. The people working on Docker both in and outside of the company were top notch and they should be proud of what they accomplished. It's too bad they didn't make the business side of things work, though I agree that at the time there was a certain feeling of too much money chasing an uncertain future for an open source project. I hope this next iteration of the company works out for them.

mountainriver 5y ago
Swarm may have been easier to get going but from what I heard it had a lot of operational problems and lacked a complete feature set

debarshri 5y ago

But did kubernetes really won the orchestration war or is it still an ongoing thing?

aynyc 5y ago
It won. Right now it's a speeding train. To compete with it, you better come up with something that's mind blowing, or a culturally shift in development.
- debarshri 5y ago
  I am not sure. almost 80% of the customer we talk to have troubles with kubernetes. They might be too small to operate it or something.
  - aynyc 5y ago
    K8s aren't easy, but if you have enough workloads that you can't keep track of on a single spreadsheet, you probably could use K8s. I haven't seen really true alternative to manage large enough and variable enough workloads successfully. One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases, apps, etc.. K8s might be too much.
    - magicalhippo 5y ago
      > One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases That's our situation soon. We're about to start migrating away from a desktop win32 application. Any good deployment options for such a scenario? We're talking 4-500 customers with their own db, less than 10k users. On-premise installation must be possible (though "give us a VM" is what we currently do, so that might not be to different).
      - jiggawatts 5y ago
        Depends a lot on what the new application architecture looks like, but one option is this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/overview https://docs.microsoft.com/en-us/azure/azure-resource-manage... You could use the same templates to deploy both the vendor-hosted and customer-hosted version of the app. The physical architecture can be anything. A single container, the PaaS App Service, VMs, etc...

endisneigh 5y ago

I'm curious - does anyone have a story on how they used Docker Swarm for something at scale (>100 nodes), but later migrated to K8s successfully at the same scale?

technicolorwhat 5y ago

There is no mention on LXC/jails which is ofcourse the biggest inspiration for docker, if I am not mistaken it also used lxc under the hood. That was already a good'ish product and but hard to configure and not for the mainstream at the time. Docker introduced AUFS and downloading of images which was added. I always saw docker as a properly marketed nicely ribboned lxc but mediocre implemented since they removed a lot of options at that time that were super useful like cpu limiting etc from std lxc.

stuff4ben 5y ago

Wow this was a great read! I remember taking a kubernetes class in late 2015 and the instructor then was saying that Kubernetes had already won over Docker Swarm and Mesos. If I were at the helm of Docker today, I'd focus on Enterprise customers. Provide an on-prem version of DockerHub and you'll convince thousands of companies tired of Artifactory to switch immediately. Don't get me wrong Artifactory is pretty nice, but it's a bear to run at scale on an enterprise level. DockerHub already is handling that traffic, so there's no reason to think they can't port that to an on-prem offering.

schipplock 5y ago
Nexus3 can be a docker registry. It’s built-in.
merb 5y ago
why even bother? there is quay, which is way better than dockerhub or the open source integration. and even than there is also harbor, nexus3 and as you mentioned artifactory. ALL of them can be bought with support from way bigger companies than docker inc. so why even bother?! Docker Inc. basically failed by trying to do everything on their own.

IneffablePigeon 5y ago

We used Tutum before it was acquired by Docker and turned into Docker Cloud. Whilst it probably would never have scaled to our complexity needs indefinitely as we grew, it was very clear that as soon as it was purchased the product stopped going in a positive direction. The only changes that they really rolled out were replacing the older, perfectly functional UI with something superficially shinier but much, much harder to use. Not only was it just hard to see what you wanted to see once they'd halved the information density and got rid of any visual hierarchy, you had absolutely crazy things like a slider for the number of instances of a service that would instantly apply with no confirmation and, even crazier, responded to the scroll wheel. We once doubled our number of production pods and didn't notice for a few hours, because someone scrolled up the page and their cursor went over the slider. Lucky they weren't scrolling the other way. Anyway, I lost a lot of trust in Docker as an organisation that knows what people value about their products as a part of that.

sbmthakur 5y ago

> The combination of huge amounts of venture funding, a quickly growing competitive landscape, and the looming shadow of cloud industry giants all wanting a piece of the pie created a pressure cooker environment for the young company to operate within. I actually got an AWS ad on the same page while reading this comment. It's definitely hard to compete when your competitors(with lot of capital) can easily integrate your tech into theirs in no time.

swlkr 5y ago

I wonder if there's more room for things like fly dot io but with things like minio/s3 or lambda included as well for bandwidth savings, kind of an "aws lite"

jokethrowaway 5y ago

The real problem is that docker swarm is nowhere close to being production ready and it's full of gotchas and design decisions that make little sense as an end user. They simply couldn't make a product good enough for the enterprise, like k8s did. I have similar reservations towards docker; sure it was a mostly novel concept (I saw live when Solomon announced docker and relatively few people knew at the time about Linux native containers or about bsd jails) but it so full of quirks and gotchas and bad APIs that it's not smooth sailing. Unfortunately they couldn't make docker into a product (or they would have faced the wrath of the OSS community) so they probably felt stripped for time on both docker and on swarm, which made for an unpolished experience. I've been using swarm for a small project for funz and because I didn't want to run the full k8s (even k0s or k3s would have been heavy for my use case) and because I had bad experiences with nomad. My list of complaints: - Stacks are not working 1-1 with Compose - docker machine is a separate binary - You can't pull the latest of a docker image or the cache hit will just fail to redeploy your changes (you're forced to do a sort of blue-green deployment or just update a tag everytime) - You have to configure, run, garbage collect a registry from scratch - docker-flow-proxy should be included out of the box - I need a way to integrate secrets Don't get me wrong, there's an amazing amount of progress in docker swarm (and I'm running it in production, for free, on a 5$ machine). Years ago it was even worse but it's not something I would ever recommend to my employer. I hope we'll get there eventually.

rejectedandsad 5y ago

> Hykes does acknowledge that there were tensions between the Docker and Google teams at the time. “There was a moment when egos prevailed. A lot of smart and experienced people at Google were blindsided by the complete outsiders at Docker,” Hykes said. “We didn’t work at Google, we didn’t go to Stanford, we didn’t have a PhD in computer science. I found this passage interesting. Are these tensions common?

Fiahil 5y ago
Yes, I graduated from the same school as Salomon a few years later, and I got a lot of “you’re just a random dude from nowhere, go back to the playground” vibe during my time in California. It’s quite an American attitude to judge your entire life and skills solely based on the college you went to. I didn’t encounter such attitude with my fellow European and Australian colleagues. Nowadays, I don’t care that much because I’m not the little, defenseless, graduate student I was, and I do enjoy bringing a Google-Standford-Californian down to earth when they are bragging about something they have no idea about.
- rejectedandsad 5y ago
  Depressing. I went to a basic state school and work at a normal company (not Google) and it feels like I’ll be destined to stay a failure forever.
  - int_19h 5y ago
    For what it's worth, I have no degree at all, and that didn't preclude Microsoft from hiring me - nor have I ever been discriminated or disparaged for this reason in the decade since. So it might be something that varies from company to company. I wouldn't be surprised that Google, in particular, has these attitudes, as they're known to be picky about degrees when hiring.
  - davidwf 5y ago
    You aren't! I'm a state-school bachelor's-only don't-even-have-a-CS-degree person; neither of my parents have a 4-year-degree. I had a FAANG job, left it for a better one, own a house in 2/5 of the most expensive cities of the world, etc., etc. Elitist assholes definitely exist everywhere, but in my experience a lot of what I viewed as "showing off" when I was younger was really just "being normal" for a different "normal". When a 25-year-old software developer talks all the time about Stanford and Lambos, he's not trying to show off, he's just talking about what he knows, just like the guy talking about tail-gating at <insert SEC school here> and then going four-wheeling all the time. I don't want to devalue experience and education in any way; those things have value! But time is linear and the past has happened -- you just have to move forward with what you have and go after what you want, and don't get distracted by the fact that others started out with a lot more than you. I double-pinky-promise you that if you are good at something, keep getting better at it, and aren't an asshole yourself, you can work at any company you want. :-)

mikesabbagh 5y ago

kubernetes makes simple deployments look complex, and complex deployments look simple. Docker would be my choice for a simple deployment (like server + db) Only use kubernetes when you need to do complex stuff, it does make things look simple then.

greatgib 5y ago

I don't like so much the idea pushed by the article author that it is partly the fault of the software to be open source! At least, the founders of Docker are honest and clear in my opinion: << Hykes disagrees with this assessment. “I think that is wrong and generally speaking the core open source product created massive growth which created the opportunity to monetize in the first place,” he said. “Lots of companies monetize Docker successfully, just not Docker. There was plenty to monetize, just Docker failed to execute on monetizing it.>> There is still a thing that is missing there: the article let think that docker was an innovation out of nowhere and they had an unique idea that was kind of spoiled. But, one has to remember the context of the period when Docker was created: It was a time were cgroups and "namespaces" of network, process, ... were the hot new things inside the Linux and everyone was thinking about the concept of "container", one way or another. There were already chroots and a lot of persons were already working on "app"/"module"/"package" systems using aufs/overlaysfs layers. So, this was the moment and a few competitor were emerging like lxc and docker. Docker was very good to take the of the media cover and hype and so to become the dominant way to have "containers". But, at the beginning, there was nothing particular in the technology and lots of competitors could have done it if it was not Docker.

meatmanek 5y ago
Certainly my recollection is that containers didn't enter the zeitgeist until Docker came around. LXC and OpenVZ had existed for years before Docker, and Jails/Zones had existed in BSD/Solaris for years before that. Mentioning the long-standing existence of these tools was a favorite pastime of Docker detractors in the early days. Really, Docker's innovation wasn't the ability to run processes in a container (as mentioned before, that technology had existed for years already); it was the Dockerfile and the Docker hub/container registry. Prior to Docker, the way you'd build a container was by running debootstrap or unpacking a tarball/zip file of a root image. Take a look at https://developer.ibm.com/tutorials/l-lxc-containers/ https://developer.ibm.com/tutorials/l-lxc-containers/ . As far as I recall, there was no LXC equivalent to `docker build` or the registry except maybe wiring up Packer or home-grown shell script and throwing a tarball in S3 or something.
- 5y ago

manishsharan 5y ago

I am surprised everyone is blaming K8s for eating Docker's lunch but from my experience in the banking industry.. it was cloudfoundry that stole the market away from Docker swarm.I don't think I ever saw a Docker swarm in production; IT departments standardized on cloudfoundry to manage their "private/on-prem cloud".

mixmastamyk 5y ago
There's a lot of "dark" matter and energy in this industry that doesn't get much attention, even when it may be the majority of mass in a particular area.

jrochkind1 5y ago

How many employees does Docker has/had? I feel like if I got a couple hundred million dollars in funding, I could make it last many many years, producing what Docker has produced. But of course this feeling isn't based on any entrepeneurial experience, so I'm probably wrong. But that seems like an awful lot of money to shoot through.

AlexCoventry 5y ago
VC investors don't give you that money to sit on it. They want you to scale, and quickly.

ilaksh 5y ago

I think what happened with Docker is that it was just too good at what it was originally intended to do and too easy to use for that. Programmers hate things that are easy to use (by the way I am a programmer, and no I don't feel that way) because if they admit they use them then they might be accused of being users. And of course no programmer will admit this. They don't realize it because it's actually a subconscious psychological issue. And so what programmers started to do was immediately make it much more complicated and at the same time, take it completely for granted. It was so useful it was like a floor to walk on. And so people started giving it the same level of respect they give a floor. So for those reasons, Docker became very uncool. But at the same time it was incredibly useful. Solution: make something just like Docker but not Docker, which hip people will be allowed to use without any shame. Make it a bit more complicated and only run on the cool expensive hardware.

jrm4 5y ago

As someone only casually knowledgable in this area (e.g. I use docker for some of my home automation thingies, I still haven't wrapped my head fully around what Kubernetes is beyond something like a way to manage a bunch of similar containers? VMs? eg).. Docker, the kabillion dollar company, never had a chance. We all recognize the potential and actual problems when some very crucial piece of infrastructure is only free/open source and not maintained -- but this is what happens when it is "overmaintained" I.e. it makes sense to invest big in something that is good and could be crucial; but only if you can both keep up quality AND stave off competitors -- and in this case, competitors aren't just other companies, but free software in general. It's kind of funny, in a way, Docker made itself a target for "good competition" by being so visible, in a way that e.g. "curl" didn't. Either way, I always knew "Docker the kabillion dollar company" was a stupid stupid bet. Small company, great bet. But this? Destined to fail.

jeffthechimp 5y ago

Happened to a pair of my Dockers once.

fulafel 5y ago

Anyone know any good metrics or analysis about trends of Kubernetes vs other ways to run containers in the not-huge-scale dev world which is 99% of software?

zxcvbn4038 5y ago

My issue with Docker Inc has been with the support. I started to give them money once but pulled back after it became clear the support experience was essentially “customer support thyself”. I don’t have to pay anyone to have my support ticket ignored, I can do that myself for free. Anyway they are past the point of no return now. Their creations will undoubtedly outlive them - probably Queen Elizabeth also. Anything they pull back will be replaced by the community. Anything new will get aped by everyone else trying to make a name for themselves. Containers are more or less a generic commodity now.

korginator 5y ago

Use the right tools for the job. I continue to run small to medium scale deployments with a couple dozen containers with Swarm. It's smooth, and just works. Kubernetes would work too, and I use it for newer deployments. Heck, I use plain old docker-compose to manage production servers with half a dozen containers, trouble-free for a few years now. Compose v2 seems promising, I've been using it for a while and it's pretty stable too. Swarm could have been an industry in itself, a de-facto standard for orchestration if it had been marketed and supported right. It was a lot more stable than Kubernetes in the early days and things just worked with docker while you'd have to kludge a few things to get Kubernetes doing its thing right.

say_it_as_it_is 5y ago

The desire to change the world was stronger than the desire to make money while doing it

bacan 5y ago

Kubernetes is an absolute joke. Even after being set-up right, it rarely works as it is supposed too.

hnarn 5y ago

I have always been somewhat skeptical of Docker, for example due to how horribly it has always worked on Windows. My first real exposure to containers was when getting into Red Hat certifications and being introduced to Podman, and with the benefit of hindsight I don't really understand the benefit of Docker today when comparing the two. Podman seems just as easy, more restricted and more in line with what some might call "Unix philosophy". Of course when it comes to distributed environments I'm sure Kubernetes still reigns supreme, but for relatively simple container setups I don't think there's a need to even run Docker anymore on Linux. Obviously, I'm still not well versed in containers so this might all be overlooking something.

mixmastamyk 5y ago
Yes, it's common for better designs to come along after insight has been gained by trial and error.
hda111 5y ago
Docker has with no doubt much better UX. It just works and it’s very easy to use. For podman is seems you need a bit more knowing what you are doing. You need to know iptables. With Docker your database container is reachable in the Internet automatically. Not possible to lock it down with iptables rules. (Could be a disadvantage too.)