yebyen

Why not support the author's own website? It looks like a nice website

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...

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.

It makes sense if you take in context that Flux, the most visible and well-known product of Weaveworks, is a donated CNCF open source project, and that companies like Microsoft, VMWare, AWS – can all engage with it directly, or by forking, or by building support for it directly into their own products.

How do you place a value on Microsoft building Flux into Azure Arc? I know it isn't worth $0 but do they actually need a contract with anybody (at Flux or Weaveworks) in order to go on doing that - no. They don't need one.

I have been away from Jenkins for a while, that all sounds like stuff I never used, (thanks!)

> a bunch of snowflake workloads by design (or bad design).

That's a really interesting characterization of WGE, and I can't say I disagree much (my personal opinion as an ex-Wyvern/OSS Engineer DX @ weaveworks)

What does Jenkins do that you can't do with GH Actions and Flux?

It was over 100 at the peak, I'm not sure how many of us were left last month. You're not far off.

Awesome, I was fishing for open source links, I salute you thanks for sharing :)

Is this really the same 16 year old RubyFlow that authenticates against GitHub? I found a copy looking for the source but it looks like it is literally 16 years old, and I'm thinking there's just no way the OIDC flow has been standing intact for that amount of time without any update... really? :D

It looks like every software dev in the entire country is either laid off today or adjacent to someone that was. Yikes indeed.