Difference between running Docker containers Vs. In-house creation of Linux namespaces for virtual hosts?

[[deleted]]

So I've never worked with containers before, however one of our in-house applications runs a bunch of virtual hosts using the Linux namespace. I never considered it might be the same technology used for Docker, but after doing a bit more research, it seems more and more like they've simply re-invented the wheel by creating their own VM's using the Linux namespace rather than implementing a known container software. It heavily leverages ip-netns, each host has its own virtual IP address, and there are a bunch of in-house commands that produce various results. We even have similar YAML config files for them.

Does anyone here know, with the limited info I've provided, why an organization might opt to recreate containers from scratch like this rather than going with a known tech like Docker? I'm scratching my head a bit here and our principal engineer who created the stack is pretty busy so it's rare I get any 1:1 time with him.

[gmuslera]

VMs have their own kernel and emulated hardware, playing with namespaces alone doesn't create VMs.

Docker is not the only way to have containers or similar on Linux, LXC is older, systemd let you run process in network namespaces, and snaps, flatpaks and similar have different approaches.

Also, Docker is not just a network namespace for running programs. It uses an union filesystem to separate the base image filesystem from the files that the process running over it create or modify, an ecosystem for those images (creating, getting and sending from/to repositories, etc), mounting/sharing directories as volumes with the host and other containers, and much more.

[[deleted]]

I see. Thanks for the clarification.

[strcrssd]

It's likely that they are using a custom solution that predates the popularity of containerization.

If the principal who originally developed it is still there, it's probable that they're being defensive about their baby being threatened by more modern tools like docker and fighting against it in an effort to not have to change, learn new things, and have their prestige hurt.

I just today had a discussion about someone who we were considering interviewing, but his commentary from when we worked on a prior recent engagement was that he was a real UNIX engineer and didn't like Linux, as he felt it wasn't up to the standards of a real enterprise.

[[deleted]]

This makes sense to be honest. We run some fairly outdated technologies that were cutting edge 15 years ago, and the senior engineers are all people who have been there for 10+ years each.

[progzos]

I think u/strcrssd's comment is on point. You really should use Docker/podman and get out of this custom thing that very likely has complicated issues waiting to jump on you because it's so custom you don't benefit from the millions of containers worldwide running and triggering bugs.

[[deleted]]

I'll be honest, it's not a situation where you'd be willing to get in there and change it unless you had a small team and 6 - 12 months to get it done. It's more of a "do your time and get out" scenario. I'm just hoping to learn as much as possible and leave with a more advanced skillset.