Live data from Hacker News

Majority of web apps could just run on a single server

old.reddit.com

181–190 of 251 posts

Re: Majority of web apps could just run on a single server

#181
post #74

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…

The other great thing about containers is that you can have entire isolated stacks for your projects, and you can stand the entire thing up with `docker compose up -d` in a matter of seconds. Gone are the days of accidentally connecting to the wrong database with WAMP.

Re: Majority of web apps could just run on a single server

#182
post #20

Earlier 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.

Then write C++ if you want fast :D

Re: Majority of web apps could just run on a single server

#183

Earlier 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…

Except zero interest rates stopped almost four years ago, but we're still seeing vcs ape into ai this last year.

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

#184
post #173

Earlier quoted context omitted.

Why use k8s over just a docker container?

Just use a base OS that has what you need? :D

Was asking seriously. Haven't had the opportunity to use k8s but I've used container hosting elsewhere so I'm curious why k8s specifically.

Re: Majority of web apps could just run on a single server

#185

Gonna 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.

Yes, programs that don't need to do anything can be very reliable.

Re: Majority of web apps could just run on a single server

#186
post #43

Earlier 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…

You can also have ugly manual ad hoc Kubernetes workflows where random devs hack YAML in prod directly. I’ve even seen people ssh into running containers and change things.

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

#187
post #38

Earlier 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.

Totally. But most applications are not stateful.

Re: Majority of web apps could just run on a single server

#188
post #9

I 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…

Not so unpopular. I worked at a startup where they wasted huge amounts of money on a massively complex set up using kubernetes (and this was the early days of kubernetes). Despite this, or maybe because of it, our AWS bill was killing us.

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

#189

Earlier 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.

The last time I checked docker was libcontainer and not running lxc any longer.

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

#190

Earlier 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.

Is it really an application if it’s not stateful? Maybe you’re managing the state client-side which makes it easier but I wouldn’t call a plain website an application, or am I missing something?
Post reply on HN