Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

351–360 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#351
post #303

Earlier quoted context omitted.

All that infra doesn’t integrate itself. Everywhere I’ve worked that had this kind of stack employed at least one if not a team of DevOps people to maintain it all, full time, the year round. Automating a database backup and testing it works takes half a day unless you’re doing something weird

Setting up a multi-az db with automatic failover, incremental backups and PiTR, automated runbooks and monitoring all that doesn't take half a day, not even with RDS.

No, but again, that sounds like a lot of complexity your average startup does not need. Multi-az? Why?

Re: Almost every infrastructure decision I endorse or regret

#352

The Bazel one made me chuckle - I worked at a company with an scm & build setup clearly inspired by Google’s setup. As a non-ex-Googler, I found it obviously insane, but there was just no way to get traction on that argument. I love that the rest of this list is pretty cut and dry, but Bazel is the one thing that the author can’t bring themself to say “don’t regret” even though they clearly don’t regret not using it.

I've seen Bazel reduce competent engineers to tears. There was a famous blog post a half-decade ago called something like "Bazel is the worst build system, except for all the others" and this still seems to ring true for me today. There are some teams I work with that we'll never bother to make use Bazel because we know in advance that it would cripple them.

Having led a successful Bazel migration, I'd still recommend many projects to stick to the native or standard supported toolchain until there's a good reason to migrate to a build system (And I don't consider GitHub actions to be a build system).

Re: Almost every infrastructure decision I endorse or regret

#353

Disagree on the point and reasoning about the single database. Sounds like they experienced badly managed and badly constrained database. The described fks and relations: that's what the key constraints and other guard rails and cascades are for - so that you are able to manage a schema. That's exactly how you do it: add in new tables that reference old data. I think the regret is actually not managing the database,…

Reading further

> Endorse-ish: Schema migration by Diff

Well that explains it... What a terrible approach to migrations for data integrity.

Re: Almost every infrastructure decision I endorse or regret

#354
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…

100% agree. People still think that maintaining infrastructure is very hard and requires lot of people. What they disregard is that using cloud infrastructure also requires people.

Re: Almost every infrastructure decision I endorse or regret

#355

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

I agree. I’m afraid I’m one of those 00s developers and can relate. Back then many startups were being launched on super simple stacks. With all of that complexity/word salad from TFA, where’s the value delivered? Presumably there’s a product somewhere under all that infrastructure, but damn, what’s left to spend on it after all the infrastructure variable costs? I get it’s a list of preferences, but still once you’v…

That's for slower projects.

You know the old adage "fast, cheap, good: pick two"? With startups, you're forced to pick fast. You're still probably not gonna make it, but if you don't build fast, you definitely won't.

Re: Almost every infrastructure decision I endorse or regret

#356
post #276

Earlier quoted context omitted.

Could you please explain what you mean by "physical backbone connection", as I can't think of a meaning that fits the context. If you mean dealing with the physical dedicated servers that can be rented from Hetzner, that's what the person you replied to was talking about being not so difficult. If you mean everything else at the data centre that makes having a server there worthwhile (networking, power, cooling, etc.…

With "routing" I meant the backbone connection, which is included in the hetzner price. Aka if I add up power (including backup) + backbone connection rental + server deprication I can not do it for the hetzner price.. That was quite imprecise, sorry about that.

I think no one talked about having physical server on their own premises but colocating servers in a data center or renting servers in a data center.

Re: Almost every infrastructure decision I endorse or regret

#357
post #249

Earlier quoted context omitted.

Some orgs are looking at moving back to on prem because they're figuring this out. For a while it was vogue to go from capex to opex costs, and C suite people were incentivized to do that via comp structures, hence "digital transformation" ie: migration to public cloud infrastructure. Now, those same orgs are realizing that renting computers actually costs more than owning them, when you're utilizing them to a signif…

i would imagine that cloud infrastructure has the ability for fast scale up, unlike self-owned infrastructure. For example, how long does it take to rent another rack that you didnt plan for? And not to mention that the cost of cloud management platforms that you have to deploy to manage these owned assets is not free. I mean, how come even large consumers of electricity does not buy and own their own infrastructure…

One other appealing alternative for smaller startups is to run Docker on one burstable vm. This is a simple setup and allows you to go beyond the cpu limits and also scale up the vm.

Might be other alternatives than using Docker so if anyone has tips for something simpler or easier to maintain, appreciate a comment.

Re: Almost every infrastructure decision I endorse or regret

#358

> Startups don’t have the luxury of a DBA … I understand, but I think they don’t have the luxury of not having a DBA. Data is important; it’s arguably more important than code. Someone needs to own thinking about data, whether it is stored in a hierarchical, navigation-based database such as a filesystem, a key-value stored like S3 (which, sure, can emulate a filesystem), or in a relational database. Or, for that mat…

Early on, depending on what you're building, you don't need a fully fleshed DBA and can get away with at least one person that knows DB fundamentals.

But if you only want to hire React developers (or swap for the framework of the week) then you'll likely end up with zero understanding of the DB. Down the line you have a mess with inconsistent or corrupted data that'll come back with a vengeance.

It's short-sighted for serious endeavors.

Re: Almost every infrastructure decision I endorse or regret

#359

Earlier quoted context omitted.

BigQuery - Athena Pub/Sub - Kinesis Cloud CDN - CloudFront Cloud Domains - Route 53 ...

I thought you meant API and parameters. Blaming them for product names is weird to me.

why is that?

Re: Almost every infrastructure decision I endorse or regret

#360
post #265

Earlier quoted context omitted.

Ordering that amount of amount of servers takes about one hour with hetzner. If you truly want a complete rack on your own maybe a few days as they have to do it manually. Most companies don‘t need to scale up full racks in seconds. Heck, even weeks would be ok for most of them to get new hardware delivered. The cloud planted the lie into everyone‘s head that most companies dont have predictable and stable load.

What would be the cost/time of scaling down a rack on Hetzner?

rental period is a month you can also use hetzner cloud, which is still roughly 10x less expensive then aws and that does not take into account the vastly cheaper traffic
Post reply on HN