The complexity you introduce trying to achieve 100% uptime will often undermine that goal. Most businesses can tolerate an hour or two of downtime or data loss occasionally. If you set this expectation early on, you can engineer a much simpler system. Simpler systems are more reliable.
Use One Big Server (2022)
151–160 of 330 posts
Re: Use One Big Server (2022)
#152Regardless of the cost and capacity analysis, it's just hard to fight the industry trends. The benefits of "just don't think about hardware" are real. I think there is a school of thought that capex should be avoided at all costs (and server hardware is expensive up front). And above all, if an AWS region goes down, it doesn't seem like your org's fault, but if your bespoke private hosting arrangement goes down, then…
> I think there is a school of thought that capex should be avoided at all costs
Yep, and it's mostly caused by the VC funding model - if your investors are demanding hockey-stick growth, there is no way in hell a startup can justify (or pay for) the resulting Capex.
Whereas a nice, stable business with near-linear growth can afford to price in regular small Capex investments.
Re: Use One Big Server (2022)
#153The complexity you introduce trying to achieve 100% uptime will often undermine that goal. Most businesses can tolerate an hour or two of downtime or data loss occasionally. If you set this expectation early on, you can engineer a much simpler system. Simpler systems are more reliable.
Much less expensive too.
I think in general that expectation is NOT acceptable though especially around data loss. Because the non engineering stakeholders don't believe it is.
Engineers don't make decisions in a vacuum, if you can manage the expectations, good for you. But in most cases that's very much an uphill battle which might make you look incompetent because you cannot guarantee no data loss.
Re: Use One Big Server (2022)
#154Earlier quoted context omitted.
> you get alot of stuff inside that $200/mo EC2 device. The product is more than the VM. What are you getting, and do you need it?
Probably not for $200/mo EC2, but AWS/GCP in general * Centralized logging, log search, log based alerting * Secrets manager * Managed kubernetes * Object store * Managed load balancers * Database HA * Cache solutions ... Can I run all these by myself? Sure. But I'm not in this business. I just want to write software and run that. And yes, I have needed most of this from day 1 for my startup. For a personal toy proje…
> For a personal toy project,
which in reality is any project under a few hundred thousand users
Re: Use One Big Server (2022)
#155Don't forget the cost of managing your one big server and the risk of having such single point of failure.
The predictable cost, you mean, making business planning way easier? And you usually have two, because sometimes kernels do panic or whatever.
Re: Use One Big Server (2022)
#156Earlier quoted context omitted.
don't you think it's highly unlikely that someone will stumble over the power cable in a hosted datacenter like hetzner? and even if, you could just run a provisioned secondary server that jumps in if the first becomes unavailable and still be much cheaper.
> don't you think it's highly unlikely that someone will stumble over the power cable in a hosted datacenter like hetzner? You're not getting the point. The point is that if you use a single node to host your whole web app, you are creating a system where many failure modes, which otherwise could not even be an issue, can easily trigger high-severity outages. > and even if, you could just run a provisioned secondary…
Do you actually think dead simple failover is comparable to elastic kubernetes whatever?
Re: Use One Big Server (2022)
#157Earlier quoted context omitted.
no PITB, but mostly just 'it's hassle' for the application server I literally don't need backups, just automated provisioning/docker container etc. Adding postgres then means I need full backups including PITB because I don't even want to lose an hours data.
Or use SQLite and your backups are literally a copy of a file. You can abuse git for it if you really want to cut corners.
Only if you can freeze your application for that long, in which case your statement is true for all non-broken databases.
Re: Use One Big Server (2022)
#158Earlier quoted context omitted.
Strong disagree here. Lambda is significantly more expensive per vCPU hour and introduces tight restrictions on your workflow and architecture, one of the most significant being maximum runtime duration. Lambda is a decent choice when you need fast, spiky scaling for a lot simple self-contained tasks. It is a bad choice for heavy tasks like transcoding long videos, training a model, data analysis, and other compute-h…
> significantly more expensive per vCPU hour It's almost exactly the same price as EC2. What you don't get to control is the mix of vCPU and RAM. Lambda ties those two together. For equivalent EC2 instances the cost difference is astronomically small, on the order of pennies per month. > like transcoding long videos, [...] data analysis, and other compute-heavy tasks If you aren't breaking these up into multiple smal…
This article (from Nov. 2022) shows that "utilizing Lambda is preferable until Lambda is utilized about 40 to 50 % of the time"
https://medium.com/life-at-apollo-division/compare-the-cost-...
Re: Use One Big Server (2022)
#159Earlier quoted context omitted.
> You can't do the opposite though, make a monolith and spread it out on 10 servers. Yes you can. Its called having multiple applications servers. They all run the same application, just more of them. Maybe they connect to the same DB, maybe not, maybe you shard the DB.
That’s obviously not what I meant. I meant running different aspects of the monolith on different servers.
That's not a problem in a well designed ASP.NET project. Just create a new web API project, move a controller into it and copy/paste the necessary boilerplate into Program.cs, set up config etc for it and configure cicd to deploy it separately, there you go. Less than a days work.
You can also publish libraries as nuget packages (privately if necessary) to share code across repos if you want the new app in it's own repo.
I've worked on projects with multiple frontends, multiple backbends, lots of separately deployed Azure functions etc, it's no problem at all to make significant structural changes as long as the code isn't a big ball of mud.
I always start with a monolith, we can easily make these changes when necessary. No point complicating things until you actually have a reason to.
Re: Use One Big Server (2022)
#160One of the more detrimental aspects of the Cloud Tax is that it constrains the types of solutions engineers even consider. Picking an arbitrary price point of $200/mo, you can get 4(!) vCPUs and 16GB of RAM at AWS. Architectures are different etc., but this is roughly a mid-spec dev laptop of 5 or so years ago. At Hetzner, you can rent a machine with 48 cores and 128GB of RAM for the same money. It's hard to overstat…
On AWS if you want raw computational capacity you use Lambda and not EC2. EC2 is for legacy type workloads and doesn't have nearly the same scaling power and speed that Lambda does. I have several workloads that just invoke Lambda in parallel. Now I effectively have a 1000 core machine and can blast through large workloads without even thinking about it. I have no VM to maintain or OS image to consider or worry about…
Hetzner does not charge any provisioning fees for VMs and never has.