Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Majority of web apps could just run on a single server

old.reddit.com

Post reply on HN
Print view View original

231–240 of 251 posts

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

#231

Post by bcaxis »

OhMeadhbh wrote: post #215
bcaxis wrote: post #152

Earlier quoted context omitted.

If your database is a long ways off an edge connection could end up with a worse latency situation than TLS setup. Distributed database is usually painful.

if your answer to 1 RT of 200msec latency is to add 3 RT of 200msec latency, you're using a calculus I don't understand.

Sometimes API calls make 5-10 queries to the database. So it's 600ms to setup TLS and make a call at the origin server and the number of db calls is irrelevant. Or a quick TLS connection to the edge and 1000-2000ms to fulfill because of db distance.

Maybe you can do some of the calls in parallel, but sometimes not. Session lookup plus another query after permissions are established and your edge latency savings are almost entirely gone.

Follow-up API calls will always be worse because TLS is a one time issue and db distance will continuously bite you call after call after call.

Then there's a cold start where the edge function has to link up with the database and do it's own TLS or equivalent.

Edge functions have a lot of issues you have to worry about that increase system complexity to solve.

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

#232

Post by noop_joe »

To a large extent this is true. But a lot of the complexity is introduced as a way to deal with the operational effort of running software (HA, security, platform upgrades, backup/recovery, incident response, all that stuff). That doesn't mean it shouldn't be on a single server -- but a _lot_ of the motivation is preventing the dreaded 3am call.

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

#233

Post by bcaxis »

sjducb wrote: post #219
bcaxis wrote: post #191

Earlier quoted context omitted.

You could solve this other ways. Build a new better monolith and have a reverse proxy route between them and slowly update and move routes over. You will get through a rewrite slowly one bit at a time. If you keep the same database schema this should generally work pretty well. I migrated a terribly written web app this way, it worked pretty well.

The application was written by a team of 20 over 10 years. There are over 3000 database tables. The job it does is big and complicated. It is used by teams all over the world. The problem is the inherent complexity of the business domain. Not poor quality code from devs 10 years ago.

Apparently I don't understand. If the code isn't poor, why throw it away for a new even more complex system? I don't know how code isn't poor, yet is indecipherable.

Regardless, the method works even in a complex environment.

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

#234

Post by polishdude20 »

makerdiety wrote: post #198
polishdude20 wrote: post #161

Earlier quoted context omitted.

Wait what would a PID controller do? What would it be controlling?

You're supposed to be repurposing the controller into a reporter. Since you don't need control, you can instead just use the PID portion of the PID controller. But you can also attach an actual automatic control for when the sensor reports a positive traffic influx prediction value. And I think stuff like Kubernetes includes this feature. Go figure.

What value does the reporter report? Isn't it just a measurement? In which case you don't need a PID?

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

#236

Post by LtWorf »

KronisLV wrote: post #224
LtWorf wrote: post #223

Earlier quoted context omitted.

It's not fast if you refuse to create a pre-made image and recompile everything instead. Docker won't make it any more fast.

> refuse to create a pre-made image Docker made doing the right thing really easy, to the point where doing that is a no brainer. I guess there are people out there who might still use OCI containers as glorified stateful VMs, but luckily the majority of documentation and examples out there build proper images that have everything included by the time it actually runs and you have to actively go against that if you w…

chroot and debootstrap and mkfs have existed for decades before docker.

It would have been no problem to create a ready image. The problem was the refusal to do so.

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

#237

Post by makerdiety »

polishdude20 wrote: post #234
makerdiety wrote: post #198

Earlier quoted context omitted.

You're supposed to be repurposing the controller into a reporter. Since you don't need control, you can instead just use the PID portion of the PID controller. But you can also attach an actual automatic control for when the sensor reports a positive traffic influx prediction value. And I think stuff like Kubernetes includes this feature. Go figure.

What value does the reporter report? Isn't it just a measurement? In which case you don't need a PID?

It's a sensor that informs its users of it how much control is needed for a networked server that can experience volatility in the form of network traffic spikes. The numerical calculus from PID controllers helps provide that crucial information. A bang-bang controller would, for example, provide very sub-optimal control, as volatility doesn't work under simple on-and-off models.

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

#238

Post by jauntywundrkind »

jameshart wrote: post #200
jauntywundrkind wrote: post #196

Earlier quoted context omitted.

Those other workloads don't sound particularly taxing to me. Many get very sparse traffic; hosting a donation page, web newsgroup/discussions, and user management need not drastically scale up the serving footprint here. Those hosted services mainly are about not needing to pay the human management/ownership costs.

The real win this architecture has is outsourcing its content management database to GitHub. That's where all the complicated stuff like permissions and authentication and change notifications and approval workflows, that make up the bulk of complexity in most bespoke business applications, as well as all the tricky stuff of managing the actual files that the contributors are managing, is all happening. It's a smart…

Again though, that's not actually computationally expensive. It's just hard to get right & maintain, with few do-all open-source offerings ready to stand in. It's not like having 10x the computing resources at hand would highly motivate someone to bring it onboard: it's a difficult thing to manage well, but not actually computationally expensive to do so.

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

#239

Post by pdimitar »

justsomehnguy wrote: post #226
KronisLV wrote: post #225

Earlier quoted context omitted.

> 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" A single container: Docker A few containers on the same node: Docker Compose Containers across multiple nodes with load balancing and networking: Docker Swarm (with Portainer to manage it) Alternatively, Podman is also pretty nice. If you need something tha…

I found the hard way Swarm is better than Compose even on one node. Bonus point is what you can scale it easily with just a minor forethought.

Are you willing to share your lessons learned? I'm very curious.
Post reply on HN