I once worked a job where I easily spent 4 times as much time fighting with Terraform files than actually writing features. This company got less than 1,000 hits per day. I think about this a lot
Majority of web apps could just run on a single server
51–60 of 251 posts
Re: Majority of web apps could just run on a single server
#52We 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.…
Isn't that just because Kubernetes makes it unreasonably hard to configure access to logs like that?
Re: Majority of web apps could just run on a single server
#53Earlier 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…
> cheaper than famous cloud instances
Not just cheaper, fixed cost.
Everyone who cried about exit fees on AWS needed the lesson of failing to plan ahead...
Re: Majority of web apps could just run on a single server
#54Earlier quoted context omitted.
Well if you can spin up a new environment in less than a minute – does it matter? I mean if you are Facebook yes, but having worked with a lot of people building things like web shops – having a minute downtime I would say is fine because I've seen so many of these people shoot themself in the foot trying to build high-availability solutions and having constant downtimes just because they can't handle their own compl…
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
#55Earlier quoted context omitted.
That is not strictly true and entirely depends upon the machines in question.
True, I'm assuming commodity hardware. I've never had the privilege of working on really high end systems, but my impression is that you buy or lease a cluster in a box that is simulating one reliable computer.
"The more they overthink the plumbing, the easier it is to stop up the drain." - Scotty, and good IT people everywhere.
When you add all of the necessary layers of abstraction to get three computers to act as one computer, you added dozens of new points of failure. In the conventional case, yeah, you can now shut one down and people aren't impacted. But there's now a bunch of new ways it can break and take the system down and it is much harder to figure out why.
Re: Majority of web apps could just run on a single server
#56At 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 fine for all that traffic.
I wrote a blog post about how we do it here: https://alexcabal.com/posts/standard-ebooks-and-classic-web-...
Re: Majority of web apps could just run on a single server
#57Earlier quoted context omitted.
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.
Maybe without details or knowing exactly what he means. But I've worked with people that decided you don't get to see any logs on a server except for a select few through some web ui or a log aggregator.
Re: Majority of web apps could just run on a single server
#58I 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...
I'd argue it's just as much the dogmatic nature of all things software-related, together with the attendant shiny new object syndrome.
See SPAs, NoSQL, micro-services, etc. There's generally a use case for all of these, but they tend to be too easily extrapolated into, "if you're not using these, you're not doing it right."
Re: Majority of web apps could just run on a single server
#59Earlier quoted context omitted.
Master slave failover will give you less than a second of downtime.
Pretty much any provisioned vm can be split down the middle. Got 4 cpus and 4gb of ram? Congrats you have two vms with 2 cpus and 2gb of ram. Throw them into a 50/50 load balancer and never have any downtime.
VMs going down is not an unexpected event. It's not going to happen even day, but hosts crash, network goes down, datacentres experience thermal events, etc. Your solution may work for your own system crashes, but not most of the rented platform failure modes.
Re: Majority of web apps could just run on a single server
#60Earlier quoted context omitted.
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 deploy k8s on a single machine though. This way you get the benefit of a standardized, documented API without the burden of multiple machines.
Your still setting up K8's... I have scp'd my go binary and set it up in system d.
Nothing about K8 or containers are light... they are buckets where bad devs hide the bodies in most cases.