1. 5
  1.  

  2. 16

    This may perhaps be an unpopular opinion, but >90% of companies should not be using k8s anyway. So, no.

    You know those old “Hello world according to programmer skill” jokes that start with printf("hello, world\n") for junior programmer and end with some convoluted Java OOP solution for senior software architect engineer? This is kind of like that.

    • Junior sysops: ./binary
    • Experienced sysops: ./binary in the cloud.
    • Senior sysops: Self-deployed CI pipeline to run ./binary on a VPS.
    • Senior devops: Self-deployed CI pipeline to run ./binary on AWS E2C platform.
    • Senior cloud orchestration engineer: k8s orchestrated self-deployed CI pipeline to run ./binary on AWS E2C platform.

    🤷

    That doesn’t mean that Java or OOP is bad per se, but rather that they’re horribly misapplied to a hello world program, as it’s far too complex of a solution. I think most companies sysops requirements fundamentally not very hard problems, and while tools such as k8s definitely have their uses, applying them to simple sysops requirements makes little sense.

    Complexity, by its very nature, creates work, and I’m skeptical that using k8s is a time-saver for most users. It’s like spending a day on a script to automate something 10-minute task that you do once a month. That’s not a good time investment (especially since the chances are you’ll have to invest further time in the future by expanding or debugging that script at some point).

    Looking at our own sysops team, they spent a lot of time setting up all this k8s stuff. They also had to spend a lot of time on updating to a newer version a while ago (1.6 -> 1.8, IIRC). And the result is something no one really understands without really diving in to k8s (those YAML files, yikes!)

    Before, I could debug and fix deploy issues and such myself. Now, that’s a lot harder. I understand some of the concepts, but that’s not all that useful when actually debugging practical issues. I don’t deal with k8s often enough to justify learning this.

    The article kind of recognizes these problems:

    Kubernetes is really complicated, potentially distracting, and because of its complexity, easy for the inexperienced to mess up in unpredictable ways. However, it’s also the best way to make your infrastructure explicit — and these days developers are dealing with more infrastructure, not less.

    The two unspoken assumptions here are that “dealing with more infrastructure” is some sort of axiom, and that k8s is the solution to this. Perhaps if you “need” complex confusing tools to deal with your infrastructure, then perhaps the infrastructure isn’t that great, after all? Or perhaps there are better ways to deal with it?

    The idea what adding another layer (tilt) on top of k8s will “fix” strikes me as, ehh, unwise? It’s not like that complexity disappears; you’ve just wrapped it. I have said this many times before: when determining if something is “easy” then my prime concern is not how easy something is to write, but how easy something is to debug when things fail. I would be surprised if wrapping k8s will make things easier.

    1. 0

      I flagged this as off-topic, because in my opinion this has nothing to do with the article. The article though perhaps not so well titled takes place in a world where your company is using k8s, and asks whether a developer of that company should learn k8s in that world.

      Also regarding your first remark:

      This may perhaps be an unpopular opinion, but >90% of companies should not be using k8s anyway. So, no.

      This is actually quite a popular opinion here. There’s been many posts that had exactly the same opinion, and many comments as well.

      1. 3

        The article though perhaps not so well titled takes place in a world where your company is using k8s, and asks whether a developer of that company should learn k8s in that world.

        That’s not completely unreasonable, although on the other hand the article does seem to (subtly) make the assumption that most companies should be running k8s, specifically in the “Looking to history” section for example, with statements such as:

        Today we need a similarly simple way to express service dependencies. Even for a basic LAMP app

        And several others. If it wouldn’t have contained that, I probably wouldn’t have bothered to reply, and instead just ignored it as a k8s article for people interested in k8s.

        This may perhaps be an unpopular opinion, but >90% of companies should not be using k8s anyway. So, no.

        This is actually quite a popular opinion here. There’s been many posts that had exactly the same opinion, and many comments as well.

        Oh, okay. I’m kind of new here :-) Most of my experience in general is with, eh, let’s call it “overly enthusiastic” k8s evangelicalism from people when I’m a bit critical of it :-)

    2. 8

      Should developers know about platform X they’re writing their software for?

      Yes.

      1. 2

        Probably? I’ve found that understanding and investment from both the development and operation side is what you need to get things done.

        1. 1

          True, but Kubernetes is quite a few steps up, in my opinion. I think anything that sticks to twelve-factor won’t have issues with Kubernetes or Docker? And that’s a well-written document that’s not too difficult to follow or teach. On the other hand, Kubernetes and Docker are beasts.

        2. 2

          All the major cloud providers will happily manage all the cluster backend issues for you. So the same way no one worries about hypervisor management when they spin up VMs they shouldn’t have to worry about k8s management when spinning up containers.