There’s some interesting ideas in this blog, but also a bunch of weird logic assertions which sound like the type of statements you’d get from somebody trying to sell their thing.

    In case that wasn’t clear,
    you can’t containerize an 
    appliance. That means you
    cannot orchestrate an 
    appliance. That means you
    cannot adopt Kubernetes if
    you keep buying appliances.

Why do you need to containerise an appliance? Containerisation is useful for abstraction of hardware, but that presumes the goal of a homogenous fleet. In the cloud you don’t care and in a datacenter you separate the workload. So long as there’s an API you can poke to manage the thing, you’re fine.

Likewise, you don’t need to containerise something to have kube orchestrate it. You simply need an api object and a controller which can work with that.

Also, the idea that you somehow can’t use kubernetes if you have storage appliances is just plain wrong. Perhaps it’s true that can’t do _some_ things, but the idea that you throw the whole thing out because one workload doesn’t fit seems very extreme to me (although not surprising from a company who sells a Kubernetes based solution).

Why does _everything_ need to be on Kubernetes?