canto

yeah, apologies, i shouldn't be doing that but it's just... doh

and only 23% on iOS. Now while those can initially seems significant, it's still a web app, doh, a web page, that loads non deterministic stuff. Even in their tests, the page that loads native vs RN is simply... different. Different things take different time to load, yeah, who would have though. Not even mentioning that this "performance" is only app startup, lol. Ah, sorry, my bad, 120fps when browsing items on the web.

Don't get me wrong I don't have anything against AI, I'm a heavy user myself, but refactoring everything just for the sake of it and bragging on HN with little to no tangible effects - that's a whole different story.

So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake. Instead of optimising, creating more with less, they will create the same with more. Yeah, that's smart. Super smart.

Nice flex, lol.

One taco and one slice of pizza.

I mean, technically correct but...

They're just all in mobile and fsck you Diablo and Fallout fans. That's pretty much it.

Because plenty of people share your POV and kinda - a little bit - behave like there was no life before k8s, I will try to address your points.

>What happens if a container in the VM goes down or the app inside of it crashes, how do you recover?

Docker will restart container automatically. You don't have to do anything. Docker-compose will restart after VM restart. You don't have to do anything. If a VM goes down - I do have a HA (another VM at another provider) and DNS load balancing.

>Now you need some self-recovery mechanism via systemD or whatever, which will grow in complexity and fickleness over time. Congrats, you are now doing your own version of kubernetes.

While I don't like systemd, it does this automatically, while, it's not really used here.

> What happens when you need to upgrade/restart your VM? Ok, make a standby VM as backup that will mostly sit idle, or require a full-app redeploy any time you need to do anything to the first VM. Now you need to design a blue/green mechanism between them, and probably some networking layer work. Congrats, you are now doing your own version of kubernetes.

This has been pretty much answered already but, upgrades does not affect containers (unless docker engine upgrade). Restarts - docker will handle these automatically - nothing to do here.

> What happens, if running in cloud, you have a regional outage or degradation? Stand up another VM in another region and manage the networking layer between them. Or, if running locally, your ISP has an outage because of a backhoe or something. Ok, we'll rent rack space in another data center as backup. Own all the mechanisms between cutting between those two now. Congrats, you are now doing your own version of kubernetes.

This actually handles way better w/o managed kubernetes, as it's usually a single region and your cluster and workloads would simply be completely down, while mine would work, because of provider redundancy.

> What happens if your app gets huge volume during peak times, and very little volume during non-peak, and you find yourself overprovisioning to the point your CFO/CTO freaks out about the bill? Well, we'll make our own dynamic scaling mechanism. Congrats, you are now doing your own version of kubernetes.

Kubernetes with autoscaling wins hands down here, but, it's not automatic, nor hassle free. You are also assuming overprovisiong which is usually not the case for traffic spikes.

> What happens when your app traffic gets so large you start running into OS limitations, like file descriptor limits? Start trying some of the aforementioned solutions. Congrats, you are now doing your own version of kubernetes.

This also affects k8s, exactly the same way.

> What happens if you need service discovery, monitoring, or ensure network isolation between various services? Different VM's + your own hacked together service mesh, or wire something in the VM. Congrats, you are now doing your own version of kubernetes.

I do have service discovery and network isolation built into docker, thanks.

> What happens when you need to guarantee secret isolation between containers? Congrats, you are now doing your own version of kubernetes.

Believe it or not, it's the default with docker.

> Let's say you don't actually need any of this or think you never will. Fine! That's valid. But what you don't want, is to suddenly hit some scale and any of these things (I could list way more but I feel I am belaboring the point), migrating off these setups can become a year+ project, if not way longer. I know because I have had to do this twice now. I cannot possibly understate how painful it is.

All my workloads are containerized and I can just move them to a k8s cluster whenever I want, if needed.

2) the risk of the VM + container spiraling into complexity is perceived. as way more than going more complex at the start.

The risk of your k8s ecosystem spiraling into operators madness and argoapps over helmfiles all while trying to accommodate for ci/cd and costs offing the chart is - IMHO - way higher.

This or there's a lot of fresh blood ;-)

If all you have is a hammer, everything looks like a nail.

While I agree with you I'm not sure the rest of the world does.

Over the past decade, I'm seeing k8s used everywhere for everything, companies setting up clusters to run literally one simple app with couple of hundred requests per hour.

Not in my projects it seems. Perhaps you can share your best practices? Moreover, avoiding these should be the default behaviour. Currently the default is to drain your pockets.

P.S CLAUDE.md is sometimes useful but, it's a yet another token drain. Especially that it can grow exponentially.

q() { local output output=$("$@" 2>&1) local ec=$? echo "$output" | tail -5 return $ec }

There :)