Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

581–590 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#581
post #389
post #266

Earlier quoted context omitted.

I do that. In fact I've been doing it for years, because every time I do the math, AWS is unreasonably expensive and my solo-founder SaaS would much rather keep the extra money. I think there is an unreasonable fear of "doing the routing and everything". I run vpncloud, my server clusters are managed using ansible, and can be set up from either a list of static IPs or from a terraform-prepared configuration. The same…

When talking about Hetzner pricing, please don’t change the subject to AWS pricing. The two have nothing in common, and intuition derived from one does not transfer to the other.

> the two have nothing in common

Well, in my case at least, what they have in common is that I can choose to run my business on one or the other. So it's not about intuition, but rather facts in my case: I avoid spending a significant amount of money.

I (of course) do realize that if you design your software around higher-level AWS services, you can't easily switch. I avoided doing that.

Re: Almost every infrastructure decision I endorse or regret

#582

I’m imagining a developer in the 90s/00s reading this list and being baffled by the complexity/terminology

I am 10s developer/systems engineer and my eyes kept getting wider with each new technology on the list. I don't know if its overkill or just the state of things right now.

There is no way one person can thoroughly understand so many complex pieces of technology. I have worked for 10 years more or less at this point, and I would only call myself confident on 5 technical products, maybe 10 if I being generous to myself.

Re: Almost every infrastructure decision I endorse or regret

#583

Earlier quoted context omitted.

I did this myself for a good 15 years or so, but eventually with a family, money became a bit more of a priority, and it's hard to get a good job if all you've worked at is small shops. Any next role in a larger tech company will likely be a downgrade until you can prove yourself out, which of course you may not be able to because things are so different, and motivation will run low because you're being tasked with a…

I think that my work is honestly the most important factor in my happiness. I spend 8 hours a day (probably for the rest of my life) at work so it's going to be the thing that impacts me the most psychologically in my life. After realizing that, I decided I'd try as hard as I possibly could to never have to work at a job that I didn't like. I already didn't want kids so that part is easy. The other part of the equati…

Sounds like a good approach to me. I think you'll do fine. Best of luck!

Re: Almost every infrastructure decision I endorse or regret

#584
post #313

Earlier quoted context omitted.

> Automating a database backup and testing it works takes half a day unless you’re doing something weird True story bro I'm sure that's possible if you're storing the backup on the same server you're restoring on and everything is on top of the line nvme storage. Otherwise your backup just started to run and will need another few days to finish. And that's only if you're running single master. You're massively undere…

I worked at a place with its own colo where they ran several multi TB MySQL database servers. We did weekly backups and it could take days. Our backups were stored on external USB disks. The I/O performance was abysmal. Taking a filesystem snapshot and copying it to USB could take days. The disks would occasionally lock up and someone would have to power cycle them. Total clown show. I would rather pay for RDS. Datab…

[deleted]

Re: Almost every infrastructure decision I endorse or regret

#585

Earlier quoted context omitted.

I don’t have as much experience with aws but I do hate gcp. The ui is slow and buggy. The way they want things to authenticate is half baked and only implemented in some libraries and it isn’t always clear what library supports it. The gcloud command line tool regularly just doesn’t work; it just hangs and never times out forcing you to kill it manually wondering if it did anything and you’ll mess something up runnin…

Oh, friend, you have not known UI pain until you've used portal.azure.com. That piece of junk requires actual page reloads to make any changes show up. That Refresh button is just like the close-door elevator button: it's there for you to blow off steam, but it for damn sure does not DO anything. I have boundless screenshots showing when their own UI actually pops up a dialog saying "ok, I did what you asked but it's…

I do use azure a bit so I know what you mean. Googles ui is significantly more buggy in Firefox which I use. On chrome/edge it’s a bit better.

Re: Almost every infrastructure decision I endorse or regret

#586

> The markup cost of using RDS (or any managed database) is worth it. Every so often I price out RDS to replace our colocated SQL Server cluster and it's so unrealistically expensive that I just have to laugh. It's absurdly far beyond what I'd be willing to pay. The markup is enough to pay for the colocation rack, the AWS Direct Connects, the servers, the SAN, the SQL Server licenses, the maintenance contracts, and a…

This is because you are using SQL Server. Microsoft has intentionally made cloud pricing for SQL server prohibitively expensive for non-Azure cloud workloads by requiring per-core licensing that is extremely punitive for the way EC2 and RDS is architected. This has the effect of making RDS vastly more expensive than running the same workload on bare metal or Azure.

Frankly, this is anti-competitive, and the FTC should look into it, however, Microsoft has been anti-competitive and customer hostile for decades, so if you're still using their products, you must have accepted the abuse already.

Re: Almost every infrastructure decision I endorse or regret

#587
post #267

Utter insanity. So much cost and complexity, and for what? Startups don’t think about costs or runway anymore, all they care about is “modern infrastructure”. The argument for RDS seems to be “we can’t automate backups”. What on earth?

I agree but also I'm not entirely sure how much of this is avoidable. Even the most simple web applications are full of what feels like needless complexity, but I think actually a lot of it is surprisingly essential. That said, there is definitely a huge amount of "I'm using this because I'm told that we should" over "I'm using this because we actually need it"

As the famous quote goes, "If I'd had more time, I would've written a shorter letter".

Re: Almost every infrastructure decision I endorse or regret

#588

Earlier quoted context omitted.

I spent zero hours on a MySQL server on bare hardware for seven years. Admittedly, I was afraid of ever restarting as I wasn’t sure it would reboot. But still…

You still need to get mysql installed and configured though. On AWS, it's 30 lines of terraform for RDS on an internal subnet with a security group only allowing access from your cluster. For that, you get automated backups, very simple read proxies, managed updates of you ever need them. You can vertically scale down, or uo to the point of "it's cheaper to hire a DBA to fix this".

There was no AWS, and there was no Terraform. I did have a shell script that would install what was needed, compile my own version of Mysql, configure it, and go.

Re: Almost every infrastructure decision I endorse or regret

#589
post #393
post #247

Earlier quoted context omitted.

Aurora supports standard Postgres clients. So moving to/from Aurora/RDS/own EC2/on-prem should be a matter of networking and changing connection strings in the clients. Your operational requirements and processes (backup/restore, failover, DR etc) will change, but that's because you're making a deliberate decision weighing up those costs vs benefits.

Pro tip side note: You can use DNS to mitigate the pain of changing those connection strings, decoupling client change management from backend change process, or if you had foresight, not having to change client connection strings at all.

Nope, nope, nope! When you change DNS entries, they will take effect at some point in the future when the cache expires and when your app decides to reconnect. (Possibly after a restart) At that point, why not be sure and change the config?

I mean, DNS change can work, but when you're doing that one-in-years change, why risk the extra failure modes.

Re: Almost every infrastructure decision I endorse or regret

#590

Earlier quoted context omitted.

Is R2 a sensible option for hosting data? I understand egress is chesp.

R2 is great. Our GCS bill (almost all egress) jumped from a few hundred dollars a month to a couple thousand dollars a month last year due to a usage spike. We rush-migrated to R2 and now that part of the bill is $0. I've heard some people here on HN say that it's slow, but I haven't noticed a difference. We're mainly dealing with multi-megabyte image files, so YMMV if you have a different workload.

awesome. I remember reading about this a while ago, but never tried. Since it has the same API i can imagine its not daunting as a multi-cloud infrastructure.

I guess permissions might be more complex, as in EC2 instance profiles wouldnt grant access, etc.

Post reply on HN