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.
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.
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).
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...
Reminiscent of Adrian Cockcroft “Gigalith” architecture.
Not sure on the economy of scale though - if you need redundancy on a scale up architecture you essentially need to have parity compute sitting idle (likely in another location/region/data centre).
If you have an HA requirement your infra spend has just doubled, and the ROI on your DR tends to nothing (unless you can do something clever with on demand DR)? You’re also replicating everything your write to DR (so network and storage there).
Also more practically, you’re just less flexible. Waiting 30 minutes for a machine to checksum 1TB of memory before loading the OS is painful in an outage scenario (every reboot hurts, replenishing cache hurts, losing a massive instance hurts). Do like the sentiment around simplicity though!
We're seeing the drive to Internal Development Platforms and Platform Engineering teams who are charged with eliminating developer toil and creating golden paths (ironically coined by Spotify engineering)/paved roads to production as a response to the complexity inherent to modern apps and the modern app SDLC.
Not so much an abstraction over public cloud as it is an opinionated consolidation of DevOps, SRE and cloud engineering.
The Shannon number doesn't exist for a middle management role, which could consist of so many variations from organization to organization. I don't disagree that AI assisted decision making is a thing that's happening, but I think the author is naively understating just how far away we are from 1:1 human to AI replacement.
The 'anabolic window' has largely been disproven. Depending on your goals though, from a resistance training perspective you typically need to be in a caloric surplus (although not an excessive one) to put on muscle.
We've been using K8s to scale incredibly high user and revenue generating services across banks, telcos, insurers for the last half decade. Works pretty well in our opinion ;)
Couldn't agree more here. The amount of complexity involved in running moderately complex apps at scale on native compute and the cost to maintain over time vs. the ops savings from the standardization of most of that from Kubernetes is incomparable
Yeah also a doubter, you can get to pretty DRY workflows with GitLab extends, caching is great, built in artifact repositories (including image registry), workflows/rules on when to build (i.e. run certain tasks specifically off MRs), granular approval rules, review environments and the paid for version has pretty awesome security primitives that are really easy to incorporate (sast/dast/container scanning et al.). I may be a bit biased but having kicked the tyres on actions my feeling is GL is miles ahead on the CI front.