jb_gericke

So first off, don’t use Python in prod. Second off, don’t use async because of complexities in multi-threading?

A lot of the world runs just find on Python (see Django), async is mature and stable.

It sounds like the author makes a blanket claim to avoid asynchronous functions, even when using an inherently asynchronous web framework (FastAPI), which would negate any FastAPI asynchronous concurrency gains.

WASM solves a very different problem to Kubernetes, and you can happily run, scale and orchestrate WASM binaries on Kube.

I don’t think scale is the only consideration for using Kubernetes. The ops overhead in managing traditional infrastructure, especially if you’re a large enterprise, drops massively if you really buy into cloud native. Kubernetes converges application orchestration, job scheduling, scaling, monitoring/observability, networking, load balancing, certificate management, storage management, compute provisioning - and more. In a typical enterprise, doing all this requires multiple teams. Changes are request driven and take forever. Operating systems need to be patched. This all happens after hours and costs time and money. When properly implemented and backed by the right level of stakeholder, I’ve seen orgs move to business day maintenance, while gaining the confidence to release during peak times. It’s not just about scale, it’s about converging traditional infra practices into a single, declarative and eventually consistent platform that handles it all for you.

Can you qualify this statement? It’s 2024, Kubernetes is old tech and bullet proof at that.

Having watched the infrastructure side of things evolve from the late 90s/early 2000s, where every HP/IBM rackmount was a snowflake, configuration and releases were hand rolled and debugging server / OS / package dependency issues (not to mention scaling and managing load balancers) were exclusively manual to where we are today with Kubernetes, I would select Kube all day everyday. A consistent and now very stable substrate and API I can expect pretty much everywhere, which handles rollouts, resources, health checking/auto healing and scaling for me, and pretty much lets me sleep while infra is failing? Good luck debugging that hand rolled bash script to pull a container after whoever wrote it has left (and good luck scaling it).

Which doesn’t really make sense, as drinking ACV alone will definitely not result in a body recomp/the addition of muscle (every meat head lifter, myself included, would be drinking a few bottles a day in that case).

Yeah, especially with containerisation and orchestration / Kubernetes, I get that perhaps not everything is viable to containerise, but in 2023 this feels archaic and like a lot of (potentially unnecessary) engineering work.

We had our main GCP account suspended because we were running a Lightning node, and some Google automata flagged us as mining.

We couldn’t get hold of any actual person at Google, and were told by our Google reseller to buy a fairly expensive support package to have our issue expedited after raising multiple appeals/objections. Suffice it to say, we run out of AWS now. I’ve heard GCP support (in terms of reaching an actual human support person/engineer has only gotten worse since then, and our experience occurred a good few years back).

I can see these popping up all over the show at Burning Man. Maybe the guru dude just knows his audience?

So TL/DR, the author works for a large org with a less than perfect culture? I’d simply move. Even in keeping to companies of similar scale, there are definitely highly successful enterprises out there that wouldn’t entertain entire departments doing meaningless work, and have a generally good culture of accountability and feedback. This before even considering smaller businesses and startups where there’s simply no room to have these sorts of inefficiencies.

Rancher price increases over the last few years have made it prohibitive for a good number of our customers. Personally, I don't think SUSE has done much to evolve the lifecycle side of Rancher - I want a platform that updates my node operating systems when I upgrade Kubernetes (this has been in OpenShift for years and is in Tanzu). Rancher OS was silently killed off, forcing us to rebase certain customer environments, at the time RKE and Micro OS didn’t play well together, that seems to have changed somewhat but the lifecycle side is still seemingly immature. Harvester looks interesting but we haven’t found many uses-cases for hyperconverged Kube (or perhaps more accurately, appetite within enterprises). Neuvector though is pretty damn awesome. I wonder how this plays out against the Red Hat foot gun, and if it’ll allow SUSE to aggressively go out to displace RHEL (My feeling is most of the high paying enterprise customers don’t really care about what Red Hat has done).

Kubernetes not required, just tons and tons of hand rolled Actions and env files and compose files and spaghetti bash. I don't understand the Kubernetes resistors, for a little bit of a learning curve all of this is taken care of for you - throw in GitOps for CD and you have the panacea of service orchestration and release automation...