In the ancient times of containers (really more like 4 years ago) Docker was the only player in the container game. That's not the case anymore tho...
For further actions, you may consider blocking this person and/or reporting abuse
Docker is very similar to
npm, as it's basically a package-manager, and package-hosting-platform.Monolithic systems seem complex and annoying, but they usually win out as they have an integrated and smooth workflow for developers...
I think
npmandDockerare great tools and aren't going away any time soon...I have so many questions about first two paragraphs... 😕
Happy to answer any questions, was it unclear?
A package manager or package-management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer's operating system in a consistent manner.[1]
A package manager deals with packages, distributions of software and data in archive files. Packages contain metadata, such as the software's name, description of its purpose, version number, vendor, checksum (preferably a cryptographic hash function), and a list of dependencies necessary for the software to run properly.
Dependencies... install in OS... hmmmm
Containerd is probably not going anywhere, but if docker isn't able to find a way to turn a profit I don't think they'll be staying around...
how does npm profit?
They don't afaik. They got acquired by microsoft, before that they were using investor money to keep the lights up.
Npm have enterprise plans (private registries and other tools), but I'm not sure if they actually make a profit
NPM has not only enterprise plan also personal plans.
npmjs.com/products
The fact they have paid plans does not mean they're making a profit. I've never worked at a company which pays for their products - the offering is not worthwhile since you can just use ssh packages.
company, i had worked at, has been subscribing private plan. they don't want sharing their technique and skills.
I don't understand... if these tools are literally drop-in replacements for docker to the point where you can alias them on the CLI to docker... how is this signaling the end of docker? Especially since these replacements lack the foundational tooling, like 'compose' that actually make docker worth doing in the first place... I am not only unconvinced but not sure what you're even getting at.
The main thing that was missing was docker-compose. I honestly rarely, if ever, use docker without a compose file. It's what is used to run a stack and link containers together, define networks, volumes etc.
UPDATE: I did run into this project it might be of use to others: github.com/containers/podman-compose podman's implementation of docker-compose.
Everything in this article provides alternatives but I really don't see any of them proving the point the article is trying to convey.
Sure, you can use a different engine. Podman would be cool to not require root. Doing sidecar patterns is very useful, but if you don't have a compose equivalent there's little appeal to it either.
Alternatives that build a docker image? Sure but why when docker does that already? I mean if your ecosystem is in language X and there are tools that integrate better in that ecosystem you may benefit from using different tools, but for the most part, I think i'll stick to docker and their build files.
Splitting the ecosystem so much just makes it IMO overly complicated for no reason. I remember trying to use hbase/hadoop ages ago and their components were so dependent on one another and so overly complicated that they started shipping 'distros' where they had all of their stack bundled together.
I would never use docker if it wasn't a single install that does all of these things and if I had to figure out how to build images, how to pick my container engine and so on. I appreciate having the choices but I'll stick to docker personally.
Till some alternative comes out that is a true drop in replacement for docker which includes (API, engine, build, runtime AND service orchestration ie. docker-compose) none of these seem like legitimate contenders.
Also.. the BIGGEST win is that it's Simple and 'just works' across every ecosystem, linux, windows and mac. There are several containers alternative but many of them are Linux only which is basically worthless for the problem I'm trying to solve from Dev workflow to Production.
Why not use Terraform rather than Docker Compose?
There are multiple use cases for docker. Keep in mind that the developer path is just as important. I would never expect a developer to run terraform to setup their dev environment. That seems a bit overkill.
thanks for this. haven't had the need for containers yet in my work. but I'll surely skip docker and try out podman. 🙏🙏🙏
I didn't see a strong case against Docker here. Just that it can do a lot and requires root privileges. Is that really a reason to abandon the industry standard and go with a lesser-known alternative? What is your main reason you think podman is better just from reading the article?
I don't really pay much attention to what the herd is saying (industry standards). I try things out and if they work good enough for my purpose with good enough stability, security, performance and ease of use I use them for my projects.
some stuff I've chosen over the herd recommendations would be: svelte over vue/react, .net core over node, mongodb over postgres/mysql, vertical slice architecture over layered, servicestack over web api, monoliths with good caching over microservices, etc. and I'm extremely happy with my choices.
personally I like bare metal deployments compared to containers because currently my ci/cd pipelines takes care of pushing my builds out to my servers without much hassle. in the future when theres a need to manage clusters with hundreds of nodes, I'll start using k8s or something. needing root privileges is a huge no-no for docker in my book. so I'll be looking for alternatives.
The ’herd’ = industry standards? We have and need industry standards for a reason. The term ’herd’ has negative connotations and is not an effective or positive term to describe standardization, IMO.
okaaay, let me try and rephrase then... "the widely accepted popular choices/ beliefs/ patterns, etc." basically what i'm trying to say is: question and evaluate everything for yourself. don't just blindly follow what the masses are doing. i believe that's the herd mentality, yes? i have no problems with the industry coming up with standards so that everybody's on the same page. hope i've explained my intentions clearly.
I think one of the main parts here is the word standard. Docker is not the standard, standard is OCI. Docker complies with OCI, Podman complies with OCI. Both are just some of the tools that implement the current container standards. And the main problem, in my opinion, is that we currently view one particular technology as a standard. It's similar if instead of HTTP requests we would be talking about "Focus-Pocus requests", simply because "Focus-Pocus" would be the very popular tool that implements the HTTP standard.
yes 👍
The reason most experienced devs will ONLY go with things that are widely used, is because we've lived long enough to get burned by using some less popular tool or framework where if you try to google some specific problem or issue you find "zero search results".
If you go with the standards all the bugs will be worked out, you'll interoperate with the rest of the world better, you'll find much more resources, and others will want to join you in whatever you're doing. If you go with the oddball framework, you'll have more trouble, less quality, less support, less interoperability, higher maintenance costs, as a 'general rule'.
Just like most products (from guns to cars) if you buy the oddball product, you're just asking for difficulties that otherwise are easy to avoid.
Like any rule, there are exceptions. What I just stated is all "on average", "rule of thumb" type of advice. Take it or leave it. :)
thank you for your opinion ♥️🙏
It's an important point about lack of support, community, and Google/Stack Exchange results. A long time ago, I worked in a department where we used Borland (later Embarcadero) C++ Builder and Ingres database, and an ancient version of RedHat Linux on the backend. There were many problems that we had to overcome that existed because of that particular combination of technologies, for which we could find no outside help because I don't think anyone else used that combination of technologies. Whilst trying to figure out how to deal with one of these problems one day, I wondered out loud: "I wonder how many people in the world use C++ Builder, Ingres and RedHat together?". I began to count the number of people in the office: "1, 2, 3, 4..." and everyone laughed.
I've been coding 30 years (in my 50s) and used Borland C++ a lot too. Your example sounds familiar to a lot of what I've seen many times. I've seen junior developers download random libraries from the old sourceforge and put it directly into a commercial product with no permission asked for, no discussions had, etc. And it was a name-brand company you'd know.
I think the fact that docker requires root is a big enough concern to switch. It does have experimental support for rootless but its very limited and has performance issues (looking at you, vfs). Podman provides a solution to precisely what has been my biggest gripe about docker.
another gripe I have with docker is the loss of performance. when I benchmarked a docker container on my local dev machine the RPS for a REST app dropped ~30% compared to running it bare metal. maybe I did it wrong. but I'd like to stay away from containers for as long as I humanly can. I feel all the extra work I need to do managing docker is not worth my while (yet).
There are several factors that could be at play. If you aren't running docker natively on Linux that will have some overhead (virtualization, proxying, sync files in bind mount to vm, etc). If you forgot to add a volume somewhere and there's some IO-heavy operations being done inside the container there will be some overhead. If you're on a RHEL-based distro and didn't configure devicemapper to use a proper thin pool there will be some overhead. Et cetera.
If you get things right though there shouldn't be any measurable performance difference with running containers. Also worth noting that orchestrators such as Kubernetes have their own overhead.
yeah I've been reading about those. maybe I'll have another crack at it with podman sometime soon. thanks for the input 🙏🙏🙏
I'd also note that rootless is going to have a greater overhead since there's a couple of extra things which need to run in userspace (e.g., slirp4netns). It isn't something specific to podman though.
yeah nothing is perfect in our world and I guess I'll have to evaluate the cost/benefits of using or not using containers. hopefully it's many months or years in the future for me 😜
runc is an OCI industrial standard, podman and libpod are implementations of OCI standard. It is prudent to know about these alternatives as Industry is moving to such open source alternatives.
One of the most complete and helpful article on alternatives to docker. I have been using docker for some time now and I do not like it and happy to see so many alternatives.
You didn't really provided us with any pros/cons for the other tools in compare to Docker.
Your article mentions that for each feature that Docker has there is an alternative (engine/image/runtime) but you didn't really provided us with any information on why we should use any of the other tools (except for the root privileges that Docker requires).
This articles feels a bit like a "fanboy wars" like "IPhone is better than Android", "XBox is better than Playstation"...
My biggest issue with podman has been the lack of decent replacement for compose. Compose is able to automatically build images and re-create containers if the configuration was changed for example. The podman-compose project has quite a few issues last time I tried it.
Also checkout the Dockerless series here (including deep dive into runc): mkdev.me/en/posts/dockerless-part-... and some of the ways to live without Docker in production: youtube.com/watch?v=aViKsSEGwOc&li...
Very nice article👏👏👏. I want to share two articles of June. Hope this help someone.
Why hackers 'first love' a docker container? Hacking Docker
manish srivastava ・ Jun 4 ・ 21 min read
TIME TO SAY BYE BYE DOCKER !!! Era of Docker is over...
manish srivastava ・ May 28 ・ 6 min read
This is a very nice article. I'm convinced there is going to be more than one way to build the exact same dockerfile.
I wish I knew how to exactly pick one image build tool. IMHO the image that is the least chubby possibly wins. Just kidding. What I'm trying to say that more than one way is going to confuse both junior and senior engineers. Why? Selecting a build tool is going to come down to opinionated architectures unless we all start to see selection the same way.
I'm starting to use rootless Podman and managed to deploy a simple Kafka Pub/Sub example if you want to take a look.
The only issue I'm having with rootless Podman is the inter-pod communication. Currently I have to create a bridged network to make pods able to communicate with each other.
How about Cloud Native Buildpacks?
buildpacks.io/
I used buildpacks in my project and while it takes away some control from the developers, it does liberate them from understanding how to write good Dockerfiles.
Docker has been pretty reliable for me except for one container recently where the health check never worked (even though the healthz endpoint was working fine) and docker refused to stop the container unless I restarted the entire docket service. Really frustrating. Might give podman a look sometime.
These OCI tools are amazing, I loved your article and saved it for reference because I intendo to use it in my personal projects. It is really hard to go against the default and use other tools when working in an organization project where docker just works and then we focus on tackling business problems. It would require a lot of seniority and "ops" knowledge from the team (in my case we have a focus on FE development). I hope to see a future where podman becomes the standard for running containers! Again, incredible article!
This just seems like a "I'm promoting Docker's competitors" post.
Really interesting, I didn't know some of them!
Shouldn't this article be tagged with 'shill'?
Wow this is really a comprehensive guide.
Hey! Great job.
The title is total clickbait - come on, deny it!
So net-net, if you don't want to use Docker, Redhat has a set of eqiuvalent tools. If you don't want to use Docker or Redhat, or Kubernetes, you're SOL.
Docker, I love you. Let me put my arms around you. I would never date LXD again, even is ex-container.
Great Post Martin. What's your views on UNIX socket which may not available in podman compare to docker
"It's Time to Say Goodbye to Docker"
So it was click bait essentially ;-) But interesting none the less :P