Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

381–390 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#381
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"

Re: Almost every infrastructure decision I endorse or regret

#383
post #115

Earlier quoted context omitted.

I think a lot of startups have a set of requirements that is something like: - I want to spin up multiple redundant instances of some set of services - I want to load balance over those services - I want some form of rolling deploy so that I don’t have downtime when I deploy - I want some form of declarative infrastructure, not click-ops Given these requirements, I can’t think of an alternative to managed k8s that is…

A startup with no DBA does not need redundant anything. Too small.

This is a sweeping generalization to make, and I think you underestimate how easy it is to achieve redundancy with modern tools these days.

My company uses redundant services because we like to deploy frequently, and our customers notice if our API breaks while the service is restarted. Running the service redundantly allows us to do rolling deploys while continuing to serve our API. It’s also saved us from downtime when a service encounters a weird code path and crashes.

Re: Almost every infrastructure decision I endorse or regret

#384

So by and large I agree with the things in this article. It's interesting that the points I disagree with the author on are all SaaS products: > Moving off JIRA onto linear I don't get the hype. Linear is fine and all but I constantly find things I either can't or don't know how to do. How do I make different ticket types with different sets of fields? No clue. > Not using Terraform Cloud No Regrets I generally recom…

Why gitlab? GitHub actions are a mess but gitlab online's ci cd is not much better at all, and for self hosted it opens a whole different can of worms. At least with GitHub actions you have a plugin ecosystem that makes the super janky underlying platform a bit more bearable.

I've found GitLab CI's "DAG of jobs" model has made maintenance and, crucially for us, optimisation relatively easy. Then I look into GitHub Actions and... where are the abstraction tools? How do I cache just part of my "workflow"? Plugins be damned. GitLab CI is so good that I'm willing to overlook vendor lock-in and YAML, and use it for our GitHub project even without proper integration. (Frankly the rest of GitLab seems to always be a couple features ahead, but no-one's willing to migrate.)

Re: Almost every infrastructure decision I endorse or regret

#386

Earlier quoted context omitted.

Because I can go from main.go to a load balanced, autoscaling app with rolling deploys, segeregated environments, logging & monitoring in about 30 minutes, and never need to touch _any_ of that again. Plus, if I leave, the guy who comes after me can look at a helm chart, terraform module + pipeline.yml and figure out how it works. Meanwhile, our janq shell script based task scheduler craps out on something new every…

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 better invest some time in migrating away from your 5.7 (or earlier) in that case, because it's EOL already ;)

Re: Almost every infrastructure decision I endorse or regret

#388

I feel like this is overkill for a startup. Why not dump your application server and dependencies into rented data center (or EC2 if you must) and setup a coarse DR? Maybe start with a monolith in PHP or Rails. None of that word salad sounds like startup to me, but then again everyone loves to refer to themselves as a startup (must be a recruiting tool?), so perhaps muh dude is spot on.

I don't want to be negative, but this post reads like a list of things that I want to avoid in my career. I did a brief stint in cloud stuff at a FAANG and I don't care to go back to it. Right now I'm engineer No. 1 at a current startup just doing DDD with a Django monolith. I'm still pretty Jr. and I'm wondering if there's a way to scale without needing to get into all of the things the author of this article mentio…

Currently working at a $100M valuation tech company that fundamentally is built on a Django monolith with some other fluffy stuff lying around it. You can go far with a Django monolith and some load balancing.

Re: Almost every infrastructure decision I endorse or regret

#389
post #266

Earlier quoted context omitted.

Keep in mind, there is an in between.. I would have a hard time doing servers as cheap as hetzner for example including the routing and everything

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.

Re: Almost every infrastructure decision I endorse or regret

#390
post #130

Earlier quoted context omitted.

>By the time your db is big enough to cost an unreasonable amount on RDS, you’re likely a big enough team to have options. By the time your db is big enough to cost an unreasonable amount on RDS, you've likely got so much momentum that getting off is nearly impossible as you bleed cash. You can buy a used server and find colocation space and still be pennies on the dollar for even the smallest database. If you're doi…

That’s just another way of saying the opportunity cost isn’t worth paying to do the migration. Optionality and flexibility are extremely valuable, and that is why cloud compute continues to be popular, especially for rapidly/burstily growing businesses like startups.

On the other hand cloud platforms can be hard to migrate off, which is very much taking away options.
Post reply on HN