Earlier quoted context omitted.
I think that the $5 tier is a little tight for a web app as opposed to a crud app, but 2x $40 tiers is enough for a decent amount of traffic, with one as a failover. The problem is that containers are excellent, and IMO there's a gap in the market between "I want to run one container" and "I want a fully managed k8s cluster"
For my personal projects (that right now seem to revolve around April 1st jokes for people in my industry) - I've found a good middle ground to be K3s on a single Hetzner VM that I scale up and down if I think more/less people are going to be looking at it (i.e. between the 5 - 10 dollar/month price range) I set this up with Terraform and some bash scripts. Infra as code is just too convenient to pass up on for somet…
Majority of web apps could just run on a single server
181–190 of 251 posts
Re: Majority of web apps could just run on a single server
#182Earlier quoted context omitted.
You don't even need to write your program in go or configure and deploy with fcgi. Write it in whatever you want and stick it in a container.
Right, but the interpreted languages will be on the slow side, which matters with the limited resources of shared hosting.
Re: Majority of web apps could just run on a single server
#183Earlier quoted context omitted.
I'm convinced it's the hiring that has shaped the scene. If you're hiring, you want to be able to add/replace people as easily as possible. If you're being hired, you want to charge as much as you can. And to satisfy those two demands, the current web stack is great. Almost like it's been built for it. It's got very little to do with the tech itself, a lot more to do with market dynamics. That's the problem it's tryi…
The root cause is the decade of zero interest rates which led to companies intentionally overcomplicating their stacks to justify neverending VC rounds. Early prospective employees took notice and adjusted their skills as a result. The dangerous part is that in the meantime we've got brand new and budding talent that actually took this charade seriously and effectively got high on their own supply, seeing this perfor…
So clearly the underlying cause of this squandering of resources must come from somewhere else.
I point the finger at the rising class of super rich who don't know what to do with their money. Why do they exist? Why is taxation seemingly not applying to them any longer?
Re: Majority of web apps could just run on a single server
#184Re: Majority of web apps could just run on a single server
#185Gonna throw out an anti-cirlcenjerk take: We know. Absolutely no one has ever said that your super basic webapp that has the latency requirements of "make sure it works", an SLO of "it's fine most of the time", and a code base under 10k lines of code worked on by one guy, needs these super complicated systems. Even FAANG will run internal services and dashboards on a single binary, but when every second of downtime c…
I wouldn't say complexity and reliability are correlated, worse, it's an inverse correlation.
Re: Majority of web apps could just run on a single server
#186Earlier quoted context omitted.
If you guys don't see the value of being able to click on a button on a website to deploy, perfectly, everytime over some guy sshing into the box and running git pull I dunno what to tell you.
The discussion here is not the method of deployment, but the infra architecture. You don't need k8s, containers, and multiple cloud instances to automate deployment. It's perfectly possible and simple to implement a button to deploy on a single machine. Heck, on OVH or Hetzner, you can have a dedicated bare metal machine with many cores and RAM exclusive to you, cheaper than famous cloud instances. These bare metals…
This isn’t any better than Joe sysadmin and could be worse since the complexity is higher and there’s a greater chance to do more damage with one change. Adding complexity makes bad process worse.
Re: Majority of web apps could just run on a single server
#187Earlier quoted context omitted.
If you have the ability to spin up a new machine when the old one fails, and deploy your app onto it in one minute, it’s not a big leap to also run your app on two machines and avoid that downtime altogether.
Running two instances of a stateful application in parallel forces you to consider nasty and hard problems such as CAP theorem, etc. If your requirements allow, it's much easier to have an active-standby architecture over active-active.
Re: Majority of web apps could just run on a single server
#188I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…
The irony was that the cloud was supposed to be the simplest bit. All the computation and cryptography occurred on the mobile clients, the cloud was really just to provide storage. The same team then rewrote the mobile clients to have a "beautiful" API that took 100s of times more resource than the original code.
I guess they just loved complexity for the sake of it.
Re: Majority of web apps could just run on a single server
#189Earlier quoted context omitted.
Dont deploy docker in production. Podman. You could but why all the extra overhead?
Docker has no overhead on the Linux kernel. It just runs things for you via LXC. The overhead is no different from any other process.
Libcontaier lxc all use the same api calls to the kernel... so in effect your still correct (mostly)
They all have overhead, if you're starting to use their features... cgroups can have some very funny impacts on app performance more so if your running containers ontop of a linux install over a hypervisor vs nix on hardware.
Re: Majority of web apps could just run on a single server
#190Earlier quoted context omitted.
Running two instances of a stateful application in parallel forces you to consider nasty and hard problems such as CAP theorem, etc. If your requirements allow, it's much easier to have an active-standby architecture over active-active.
Totally. But most applications are not stateful.