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

141–150 of 251 posts

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

#141

Post by jameshart »

acabal wrote: post #56

At Standard Ebooks we serve a respectable number of page views and ebooks each month - and have been on the front page of HN three or four times - all of it done with a single 4GB VPS. And the only reason we upgraded to 4GB from 2GB is because we needed more RAM for the server to build the extremely large Decline and Fall of the Roman Empire ebook - if it weren't for that, our 2GB server would still have been just fi…

More applications should consider git as a content management database. It's great architecture. Statically serving files built by a CI process running on the server is very tidy.

But let's be clear, your serving infrastructure is able to be that simple because you outsource donation management to https://fundraising.fracturedatlas.org, contribution management to https://github.com/standardebooks, collaboration, membership and communication to https://groups.google.com/g/standardebooks, and marketing signup management to... looks like postmark.

So sure, you can run your stuff on a single server, but you're relying on a bunch of other people running much more sophisticated services on a lot more infrastructure in order to do it.

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

#142

Post by znpy »

ProblemExplorer wrote: post #137
znpy wrote: post #121

Earlier quoted context omitted.

> How did/does the devs create, test new code and debug issues? Can they do that locally on their local laptop? If so, how? All those questions are irrelevant to how software gets deployed. Do whatever you want on your laptop.

Then I assume you have a custom Kubernetes LB that can handle non-HTTP TCP and UDP traffic because you choosing Kubernetes and the design restrictions that comes with it does not affect how the dev solves problems? The underlying orchestrator definitely affects how the software needs to behave and is definitely not irrelevant .

> Then I assume you have a custom Kubernetes LB that can handle non-HTTP TCP and UDP traffic because you choosing Kubernetes and the design restrictions that comes with it does not affect how the dev solves problems?

nginx-ingress-controller does that. no custom stuff required.

https://kubernetes.github.io/ingress-nginx/user-guide/exposi...

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

#144

Post by zer00eyz »

ProblemExplorer wrote: post #119
znpy wrote: post #61

Earlier quoted context omitted.

> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" Was a devops engineer at my previous job. We already had k8s clusters setup, pre-made CI templates and pre-tailored helm charts (along with monitoring and much more). All those things you (a developer) could mostly clone…

> All those things you (a developer) could mostly clone, slightly customize and ship both to a development k8s cluster and to a prod k8s cluster (with all the safety nets already in place). How did/does the devs create, test new code and debug issues? Can they do that locally on their local laptop? If so, how?

>> How did/does the devs create, test new code and debug issues? Can they do that locally on their local laptop? If so, how?

I used to buy the idea of this when there were monoliths.

Then I had the joy of running a shop with dozens of web properties.

Local dev became untenable. My systems admin was an early adopter of Xen. That shop ran like a dream... devs could come in and have a new environment update in place and just start to work. Staying in sync with prod was never a problem.

By making systems guys keep devs fed, by making devs work closely with systems folks you get better software. Containers just hid developers shitty decision making in a wrapper that Systems folks can tolerate.

And how DO you debug... cause what you do to figure a problem out locally is not how you trouble shoot when the shit hits the fan in prod. These tools should be the same, sane and well used and loved by everyone. Local debugging is part of the problem, even more so if your service based app that lives and dies on the wire.

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

#145

Post by NorwegianDude »

master_crab wrote: post #14

Can the majority of webapps run on a single machine? Probably. Do most of your customers expect close to 100% uptime? Yes. Does one machine provide the uptime required by your customers? Most definitely not.

Servers are a lot more stable than you think.

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

#146

Post by oceanplexian »

ProblemExplorer wrote: post #100
lewisjoe wrote: 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…

> unnecessarily complicated with k8s Kubernetes is/was a way to fight off walled gardens from cloud providers. The other path would have been to learn the bespoke implementation of each cloud provider depending on what that employer ended up using. Kubernetes was at the right place, at the right time just as AWS was trying to force feed people their own proprietary solution, as Azure was trying to wall off people int…

> With Kubernetes, developers can learn one API to deploy their applications and hopefully it works on AWS, Azure, GCP, DO, OVH or a laptop at home.

That's one of the lies developers tell themselves, because at some point you're going to need to manage Accounts, VPCs and ELBs, Certificates, Security Groups, IAM policies, and everything else. All of those underlying primitives that are required and have massive differences in behavior that are expressed differently in GCP, Azure, and AWS.

On top of that Kubernetes is itself a walled garden.

You will inevitably end up cargo culting the entire ecosystem of plugins, like Cilium and Helm and so on. All of this IaC is meaningless outside of Kubernetes. Soon enough, you have 10,000 lines of YAML configuring highly proprietary infrastructure with multiple variants for each cloud. At some point you will have to rewrite controllers to add functionality or correct bugs the upstream maintainers don't want to prioritize, and so on.

Your "knowledge" of the stack ends up being the ability to orchestrate 15 levels of templated YAML. Eventually your company ends up hiring people who only know how to copy/paste YAML, and lose institutional knowledge of how underlying systems work. You didn't break out of the walled garden, you created an elaborate prison. And Amazon and GCP and Azure love you, because you're their #1 customer. The more complex you make it to deploy a CRUD app the more they profit.

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

#147

Post by PeterZaitsev »

Do not forget, for many, there is certain satsfaction and bragging rights in operating large complicated environment. Hundreds of Nodes, Thousands of Microservices is much more sexy than simple few nodes cluster

It always amazed me how efficient software can be created than excessive capital is not available

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

#148

Post by Animats »

moondev wrote: post #20
Animats wrote: post #12

Yes. You don't even need containers. Write your program as one Go executable and drive it from fcgi. Go is fast enough that you can get a lot of work done on a minimal server. Fgci provides "orchestration" of multiple processes, plus crash and restart handling. Also, there's much less attack surface. If your minimal Go program can only respond to specific requests, there's not the problem of an attacker targeting som…

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

#149

Post by barishnamazov »

Aachen wrote: post #94
barishnamazov wrote: post #71

I have been running multiple web apps with decent traffic (each ~10K requests per day) at no cost at all. Oracle Free Tier [1] for backends with Cloudflare tunneling [2] and pages [3] for frontend integration. Works fully seamless. [1] https://www.oracle.com/cloud/free/ (4 cores, 24 GB ram for free; switch to PAYG to avoid idleness shut down, but you still pay nothing) [2] https://www.cloudflare.com/products/tunnel/…

Somehow hearing of getting free hosting from Oracle makes me think of the advice to not stick your "thing" in crazy. It's probably fine, but I'd not touch it if it can be avoided, especially if I can just pay a small and fair fee at another provider (or, in my case, self host it)

It was my reaction at first too. Luckily, I am not running anything super important or something requiring much privacy there (it's mostly computational services that don't store data). Since I am a student with no residence (and bad university network uptime), I can't self-host, but will do as soon as I move-in to my own place.

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

#150

Post by ufmace »

eddd-ddde wrote: post #5

We use k8s at $JOB for literally no reason other than some engineer decided he wanted to learn k8s. It's the worst, I don't even get to see my server logs because "that would mean giving you access to the entire thing". I'm not a k8s person but surely that has to be missing something. We could literally make do with a cloudflare 5$ plan and have left to work with. With better integration, and better DX.

I dunno if k8s is actually right for your company, but it most certainly is possible to configure it to give engineers limited access, including viewing logs, pod status, services and deployments, etc, but not reading sensitive data or updating anything. In my opinion, deploying production services using devops technology nobody on the team has much understanding of is what's a bad idea, not any particular technology.
Post reply on HN