3 ms·

Yeah, there are a lot of misconceptions about how containers work, and partly that’s due (IMO and experience) to the earlier days of containers, before we had t

Yeah, there are a lot of misconceptions about how containers work, and partly that’s due (IMO and experience) to the earlier days of containers, before we had things like standard formats and interfaces. It’s also partly complicated by higher level abstractions like Kubernetes, Mesos, Racher, et al. So at the minimum, pushing these workloads to containers with existing codebases would likely just replace the “certified on RHEL X” with “certified for use in RHEL X containers on RHEL X hypervisors, managed by container orchestration platform X version Y” and so on. Epic has been working on an implementation of their client application (Hyperspace) as a web app (Hyperweb), and that’s probably where we’ll see any new abstraction from incumbent players with large install bases for quite a long time. Edit: typo

oneplane 3y ago
As long as you have a complete userland in your image and a compatible kernel and no extra CAP or binds, it really doesn't matter at all what else the host is doing. That's true for most mainstream architectures and distros of the past 5 years (and more, but I can't be bothered to look it up). If you add orchestration tools in to the mix, that's a different story, but even then you can argue that the orchestrator is your API and not the host OS. A bare kubeadm setup vs. EKS vs. AKS vs. GKE all have the same base API, which means as long as you don't extend past this API it doesn't matter where you run. Again, that breaks as soon as you start including hard dependencies on StorageClass configurations for PVCs, CNIs or CSIs. The only real reason a specific host OS matters is the case where someone writes software against the specific userland of that OS. If you use the same syscalls that are available everywhere, the host OS no longer matters as long as it complies. In a way, if you didn't need the host OS userland, you could just build a single static binary. Or if the software really has special needs, build it as a unikernel. As a concept the 'we build the software, you install the OS' deal is critically flawed and a bad point to abstract an interface between a third party vendor and a server they don't supply.

oneplane 3y ago

As long as you have a complete userland in your image and a compatible kernel and no extra CAP or binds, it really doesn't matter at all what else the host is doing. That's true for most mainstream architectures and distros of the past 5 years (and more, but I can't be bothered to look it up). If you add orchestration tools in to the mix, that's a different story, but even then you can argue that the orchestrator is your API and not the host OS. A bare kubeadm setup vs. EKS vs. AKS vs. GKE all have the same base API, which means as long as you don't extend past this API it doesn't matter where you run. Again, that breaks as soon as you start including hard dependencies on StorageClass configurations for PVCs, CNIs or CSIs. The only real reason a specific host OS matters is the case where someone writes software against the specific userland of that OS. If you use the same syscalls that are available everywhere, the host OS no longer matters as long as it complies. In a way, if you didn't need the host OS userland, you could just build a single static binary. Or if the software really has special needs, build it as a unikernel. As a concept the 'we build the software, you install the OS' deal is critically flawed and a bad point to abstract an interface between a third party vendor and a server they don't supply.