Three machines get you availability that one machine can't.
That is not strictly true and entirely depends upon the machines in question.
Majority of web apps could just run on a single server
11–20 of 251 posts
Re: Majority of web apps could just run on a single server
#12Yes.
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 some unused feature of the site. Go has subscript checking, so you don't have buffer overflow vulnerabilities.
Re: Majority of web apps could just run on a single server
#13We 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.
Current project I work on sees:
* everything running in docker containers, but you aren't supposed to run that locally, only local dev\test is through unit and component tests.
* all k8s is maintained by a separate group pulling in those images through a seemingly very over engineered solution
* when it is all combined in a deployment, things break, or more scary, they don't and you need to manually test and hope it's working.
Issues take too long to track down and resolve and the reasons are very obvious to everyone but technical leadership who are constantly high fiving each other over their amazing creation that is already collapsing under it's own weight.
Re: Majority of web apps could just run on a single server
#14Can 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.
Re: Majority of web apps could just run on a single server
#15I 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…
> 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?"
It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It
Re: Majority of web apps could just run on a single server
#16I 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 problem with devops replacing the old title “sysadmin” was that the dev part dragged in the worst thing about developer culture: the love of complexity and the tendency to build massive towers of it.
Sysadmins usually avoided complexity because their attitude toward it was more sensible: it’s expensive, fragile, and tends to actually multiply failure modes.
I also blame cloud marketing. This stuff is a gigantic money printer for cloud companies. It’s in their interest to encourage as much over engineering as possible, especially if it locks you into things like Kubernetes that are hard to run and thus usually used as services.
Re: Majority of web apps could just run on a single server
#17We 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.
That's not a k8s thing. It's an idealistic DevOps thing. You'd probably deal with that in alot of places.
That for sure is not "idealistic devops", but someone missing fixing RBAC to let devs have access to logs of their workload.
Re: Majority of web apps could just run on a single server
#18Can 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.
Make it two machines then.
Re: Majority of web apps could just run on a single server
#19We 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.
> 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.
I'm pretty sure it's possible to configure access to logs, not to the entire thing (whatever that means). He's probably lazy and does not want to bother.
Besides, you should have centralized logging using loki or something similar. Kubernetes logging is not enough for any reasonable use-case.
Re: Majority of web apps could just run on a single server
#20Yes. 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.