[0xbadcafebee]

IMO that's an overly reductive take, which is very common for tools in this space, but (I think) needs to be addressed so people stop repeating it.

It reduces what "most orgs" are (as if 80% of businesses are the same, or solve the same problems, or have the same challenges, or use the same approaches, or have the same customers, have the same staff or expertise, budgets, timelines, etc, etc, etc.). Clearly there is no such thing as "most orgs", as there are many different kinds of businesses and how they approach solving problems varies from business to business. Their use of technology to solve problems also can't be easily reduced; the way the business chooses to solve problems doesn't necessarily dictate what technology they should use.

It correlates the need for complexity with whether an organization is in some 20% minority of organizations, as if only a minority of orgs should or shouldn't use a complex tool.

It reduces a given tool down to "complex or not", as if complexity is the only consideration of whether to use a tool or not. There may be many different reasons to use a tool regardless of whether it's complex.

It assumes that a given tool has some inherent complexity that isn't comparable to other tools. Other tools might have less inherent complexity, but their lack of complexity may then create new problems that have to be solved, which just moves the complexity from the tool to a bunch of other places.

Overall, it correlates the way you solve problems, with how complex a tool is, with whether your organization is of one of two large generic groups. This is such a sweeping conclusion that it would be impossible to prove or demonstrate.

Based on your comment about them "using Fargate" instead, I'm assuming what you're actually saying is you think people should be using a managed product which uses containerization [and possibly k8s], rather than managing a complex technology themselves. I agree. But that doesn't mean we can generalize about who should be using what and when.

[nprateem]

I wasn't writing a critiqued essay. It's perfectly reasonable to assume 80% of orgs don't have the scale, core competencies or justifiable need to be managing container clusters themselves.

Also, no need to assume. I specifically said "use something managed".

[yebyen]

IMO "use something managed" gets reduced to "we shan't run Kubernetes on-premises" which ends up meaning "we won't learn anything about failure modes until it's too late to think about mitigating them"

Which might be in line with what you said about

> 80% of orgs don't have the scale, core competencies or justifiable need to be managing container clusters themselves.

But also, would at least have some potential to be solved and much more cost effectively, or maybe at least grown past, if they would just spend some energy on deploying Kubernetes internally; even if we can't or won't afford an entire team dedicated to doing only that, (and even if we commit to using only managed services for production anywhere and everywhere.)

In my experience the way some places reflexively avoid it like it's a trap to be stayed out of, winds up being a bit like a self-fulfilling prophecy "we're not doing Kubernetes" - I empathize with the person who you triggered, even if now we're up to two walls of text from just a simple comment, I feel triggered too.

[nprateem]

This is basically a build vs buy discussion. Businesses have generally concluded they should only build things that give them a strategic advantage and buy other services to maintain focus on their sources of competitive advantage. Eg in the case of k8s, it's not just spinning it up, it's securing it, patching, monitoring, etc. It's for this reason the majority of orgs shouldn't run it themselves.

However some balance is needed. Orgs may want to do exploration since it may not be obvious where competitive advantage can come from, or like you say perhaps hybrid makes sense, using it only in non prod.

[yebyen]

I agree that it makes more sense to buy your Kubernetes on an organizational basis because one should not reinvent the wheel, and taking advantage of a commoditized service is only possible if you work with a competent broker.

However I am wary of the capacity of skills vendors to take advantage when you come to depend on them, even when their intentions are good and all ideals aligned. Being able to deliver the limited Kubernetes experience for yourself in low-stakes contexts, where you can depend on it because you know how it works, well enough to administer in a pinch, but availing that also in a pinch you're not the bottleneck to solve a problem, because you use the managed broker in all the places where it matters, feels like a sweet spot to me.

I don't want to pay money to a broker every time I spin up a new experiment for the duration of the experiment =/= I don't want to perform experiments.

That's where I see the disconnect that "Leadership" may fail to understand. You can provide a service at low marginal cost to take some of the load off your people, and that might also have the effect of stopping any experiments that fall beneath a certain threshold as "not worth the cost" - all because we settled on getting something for cheap that should have been free.

Then again, dodging all those diversions might have been a part of the strategy...