> By poking around in Kubernetes is it deep enough for production or only broad enough to impress someone who’s deeper yet not broader? By reading the docs and

> By poking around in Kubernetes is it deep enough for production or only broad enough to impress someone who’s deeper yet not broader? By reading the docs and textbooks and learning from people, would that be enough for production? Many enterprises and companies use Kubernetes as at least _one_ of their deployment targets. So if you're a provider of software that has paying companies consuming it, does it matter if kubernetes is "deep enough for production"? It's being used in production, so I would argue, yes, from the perspective of a software provider, kubernetes is in fact deep enough for production. Though to one of your other points, define deep enough, because that statement seems like a moving target depending on who you talk to. But in general, if a piece of software doesn't work well in kubernetes, it's because the authors of that software hadn't considered any setup other than running as a monolith systemd service with an sqlite db for state. That will move me into the next quote: > Define “knowledge” you’re referring to. I have checklists for my ops. Define “really” and “good”. That sounds like perfectionist maxims without ground. Your listing of deployment targets can be extended by any BSD system, Android, iOS, IoT SoCs—what’s the point? If that’s your business requirement then you do it, if not then why bother? Knowledge is a fairly generic term, isn't it. It's a placeholder word for a series (or bucket) of facts about one or several domains. "Really" is a nuanced word that means different things depending on how it's used. For example, in my sentence fragment, "can you really write," I'm using the word 'really' to express disbelief in one's ability to perform the context. On the word "good" we can use context clues to extrapolate that I probably am using the word "good" to mean one that supports a wide variety of deployment targets with ease because you often do not know how your product consumer's infrastructure looks, but you can probably guess that if its intended deployment target is a linux server, these days, it should probably also be well supported in Docker and Kubernetes. So that is "good." There are a bucket of other concepts that make a piece of software "good" as well that I'll merely touch on for the sake of brevity, such as being well tested, generally lacking unchecked exceptions, runtime panics, is well performant when ran for long periods of time, etc. Though, to be honest, I think you probably could have used context clues to come up with rough definitions of those words yourself, and I suppose your purpose was to glean what I think those words mean. In my opinion, the exercise seemed a bit more tedious than maintaining infrastructure though.