1. 20
  1.  

  2. 7

    Kubernetes is just not the right abstraction for many applications. If you are building a stateless HTTP application either serverless technology or knative / cloud run is more suitable, since they provide a higher abstraction (i.e. no nodes). If you are building software that does require a more advanced operations model (e.g. scheduling tasks), Kubernetes is potentially still too low level. Consider whether it is more suitable for your platform team to leverage Kubernetes to build a platform runtime tailored for your domain.

    1. 5

      I think complaints around Kubernetes being difficult are well-founded - and I think the average line-of-business backend engineer would say the same about using only libc and Linux syscalls. Using Kubernetes today is like (what I imagine) Linux was like before the major distros stabilized and evolved standard tools like coreutils, package management like dpkg, apt, etc. Even something as basic as the common layout of a cluster’s resources - analogous to the directory hierarchy of a Unix system - varies wildly between implementations.

      1. 2

        Containers are not virtual machines. Think of containers as stripped-down, lonely processes.

        This only applies to a single type of containers: application containers. There are also full blown systems that run isolated, which then act exactly like VMs, just without the hypervision layer (think LXC, LXD, OpenVZ).

        This way, you’ll make your image as a single binary, and maybe some configuration, but nothing else. No shell, no package manager, etc.

        This only fit a special use case, where people want to isolate an application. What if I’m some sort of cloud provider that want to provide a full system to my clients? Containers can solve this problem by providing a whole operating system that is isolated from the host. This provides the same features as a VM (isolation, resource limitations) just without the hypervisor, thus gaining perfs, and perhaps transparency from the host point of view.

        I strongly disagree with the author point of view depicting containers as a single isolated process. They are much more than that, and this aspect should not be forgotten just because there’s no “ultra-hyped” cool tools to back it up.

        1. 1

          There are also full blown systems that run isolated, which then act exactly like VMs, just without the hypervision layer (think LXC, LXD, OpenVZ).

          Yes, and those will still be normal processes launched into a namespace + cgroups. The author is simplifying, but he’s right, no matter the size of your container.

          1. 1

            Well, the isolation technique is different from the one of a VM, but the end result is similar: a full blown operating system totally isolated from the host system.

            The point of the author is that makes no sense to run containers as full-blown OSes with a shell, pack manager or daemons:

            This way, you’ll make your image as a single binary, and maybe some configuration, but nothing else. No shell, no package manager, etc.

            I disagree with that, because I think that you can run containers for the exact same reason you would spin a VM. The way it works is different of course, but the end result is the same.

        2. 1

          Containers are not virtual machines. Think of containers as stripped-down, lonely processes.

          This is somewhere between confusing and wrong. Each container is an isolated group of processes.