More and more teams are adopting cloud-native architectures, but not everyone wants (or can) use Docker. Alternatives like Podman or Containerd are often marketed as "Docker-free" options. Is the switch really worth it? How do you handle it when certain tools or workflows rely on Docker images or its CLI? I find the question of compatibility and learning curve particularly interesting—especially for teams just starting out with containers. What are your experiences or concerns?
Does it make sense to use container orchestration without Docker?
👁️ 5 views💬 4 replies❤️ 0 likes
4 Replies
Why not just use pure scripts for container orchestration instead of dealing with Podman or Containerd?
I completely agree with what you're saying. I've worked on a couple of projects where I migrated from Docker to Podman for security and licensing reasons, and the truth is the change was smoother than expected. Compatibility with Dockerfiles is almost total (at least in terms of functionality), and the CLI is actually very similar, so I didn't have to rewrite scripts or anything like that. That said, where I did have to adjust was with some CI/CD tools that assumed the presence of `docker build` in the PATH; there, an alias like `alias docker="podman"` resolved 90% of the issues.
In the end, for teams that already have Dockerized pipelines, switching to Podman or even containerd is usually viable, but you always have to validate external dependencies. I used containers with rootless Podman for development environments and haven’t had any issues with permissions or storage. That said, if your stack relies heavily on Docker Compose... that’s where it gets more complicated, because Podman doesn’t have a native 1:1 tool, though there are already alternatives like `podman-compose` or Kubernetes manifests that make up for it.
I actually had similar experiences a few years back when I was planning to switch to Podman for a project. The CLI compatibility with Docker is really solid, but there are a few nuances—like with rootless containers or handling Dockerfiles. It worked well for us because we used Buildah for image creation and then Podman as the runtime.
Another interesting point was workflow adjustments: tools like Compose initially caused issues until we switched to Podman’s built-in Compose extension or Podman-Compose. The learning curve was manageable, but for teams with heavily Docker-centric pipelines, a pilot project to identify dependencies is worth it.
Switching to Docker alternatives is less about "does it make sense?" and more about "how well does it fit your needs?". Docker has built up a massive ecosystem over the years—from images and CLI tools to CI/CD integration. If your stack heavily depends on it, switching to Podman or Containerd overnight won’t work. But that’s where the leverage lies: these tools are API-compatible enough to adopt many Docker workflows without changes. The real advantage comes down to the details—Podman’s rootless namespaces, built-in Buildah support, or the ability to manage containers directly as systemd services.
Compatibility isn’t an all-or-nothing deal. Many teams start gradually: first replacing just the runtime (e.g., Docker with Containerd), then testing image builds with Buildah instead of Dockerfiles. Tools like `skopeo` or `crane` help mirror images. The learning curve stays manageable if you rely on CLI compatibility—but watch out for Docker-specific features like Swarm modes or certain plugins.
Things get interesting in cloud-native environments. Kubernetes, for example, accepts Containerd as a runtime almost out-of-the-box. Here, switching can even make sense for performance reasons, especially in high-throughput container environments. But be careful: some managed Kubernetes providers restrict the runtime, which complicates things.
Bottom line: The switch is worth it if you want to become more independent from Docker—whether for licensing reasons, security (rootless!), or architectural needs. But plan enough time for testing and don’t expect everything to work perfectly right away. The community (e.g., Red Hat with Podman) is actively closing the gap, but legacy tools and workflows often still require manual tweaks.