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.
They made a separate article on why, which they linked to. Performance is significantly better. The native Android app launches twice as fast for example
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.
Ridiculous, the amount of energy saved from a faster native application over how ever many million users will be far greater than the amount spent to generate the tokens to do so
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.
Thanks. People are really acting like we were cavemen before kubernetes, but I guess that those people just never tried to run anything without k8s and because that's the only thing they know they are biased toward it
I’m one of those top commenters who used to be a K8 naysayer. I’m also definitely not young blood.
The reason my position has changed is because:
1. The tooling has gotten better for setting up and managing K8.
2. In two of the last 3 jobs where we opted for a simplified alternative to k8, we came to regret that decision within a couple of years of that decision being made. If you’re core architecture is changing on a timescale of months (not years) then you picked the wrong foundations to build from.
That all said, I still think there is a pragmatic decision that needs to be made. And if I were in the author of this articles position I probably wouldn’t have picked k8s for this task either, despite what I said above. But, and as I said in my comment dismissing this article, they are dealing with low traffic and none of the problems that lend themselves to the benefits of k8. So my criticism of this article is that it’s misleading because their problem is easy but they’re writing as if they’re having to deal
With problems of scale when they’re actually not.
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.
reply