Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

Post reply on HN
Print view View original

161–170 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#161

Post by sroussey »

tomas789 wrote: post #94
sroussey wrote: post #51

If you are startup that can can’t afford a DBA, then why why why are you using Kubernetes?

This is my case. I’m one man show ATM so no DBA. I’m still using Kubernetes. Many things can be automated as simply as helm apply. Plus you get the benefit of not having a hot mess of systemd services, ad hoc tools which you don’t remember how you configured, plethora bash scripts to do common tasks and so on. I see Kubernetes as one time (mental and time) investment that buys me somehow smoother sailing plus some ot…

I don’t push to implement Kubernetes until I had 100 engineers and a reason to use it.

Re: Almost every infrastructure decision I endorse or regret

#162

Post by theptip »

tw04 wrote: post #130
macNchz wrote: post #31

Earlier quoted context omitted.

> Sure, maybe if you are some sort of SaaS with a need for a small single DB, that also needs to be resilient, backed up, rock solid bulletproof.. it makes sense? But how many cases are there of this? Most software startups these days? The blog post is about work done at a startup after all. 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. If yo…

>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.

Re: Almost every infrastructure decision I endorse or regret

#163

Post by zeeZ »

guhcampos wrote: post #40

Well it's a bit unfortunate this post was published in Feb 1st, it got really outdated really fast around the "choose flux for gitops" part.

So far it seems fine, and the maintainers seem to be doing OK too.

Is the project future at risk? https://github.com/fluxcd/flux2/discussions/4544

Re: Almost every infrastructure decision I endorse or regret

#164

Post by bigstrat2003 »

jacurtis wrote: post #146
CSMastermind wrote: post #10

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…

I mostly agreed with OP's article, but you basically nailed all of the points of disagreement I did have. Jira: Its overhyped and overpriced. Most HATE jira. I guess I don't care enough. I've never met a ticket system that I loved. Jira is fine. Its overly complex sure. But once you set it up, you don't need to change it very often. I don't love it, I don't hate it. No one ever got fired for choosing Jira, so it gets…

I'm right there with you on Jira. The haters are wrong - it's a decent enough ticket system, no worse than anything else I've used. You can definitely torture Jira into something horrible, but that's not Jira's fault. Bad managers will ruin any ticket system if they have the customization tools to do so.

Re: Almost every infrastructure decision I endorse or regret

#165

Post by bigstrat2003 »

LispSporks22 wrote: post #89
ndjshe3838 wrote: post #78

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…

I think that far too many companies get sold on the vision of "it just works, you don't need to hire ops people to run the tools you need for your business". And that is true! And while you're starting, it may be that you can't afford to hire an ops guy and can't take the time to do it yourself. But it doesn't take that much scale before you get to the point it would be cheaper to just manage your own tools.

Cloud and SaaS tools are very seductive, but I think they're ultimately a trap. Keep your tools simple and just run them yourselves, it's not that hard.

Re: Almost every infrastructure decision I endorse or regret

#166

Post by [deleted] »

jrockway wrote: post #116
kccqzy wrote: post #112

Earlier quoted context omitted.

One giant codebase is fine. Monorepo is better than lots of scattered repos linked together with git hashes. And it doesn't really get in the way of each team managing when stuff gets rolled out.

I'm a big monorepo fan, but you run into that ownership problem. "It's slow to clone"; which team fixes that?

[deleted]

Re: Almost every infrastructure decision I endorse or regret

#167

Post by sgarland »

leetharris wrote: post #101
calvinmorrison wrote: post #42

Earlier quoted context omitted.

It's because I hate databases and programming separately. I would rather slow code then have to dig into some database procdure. Its just another level of separation thats too mentally hard to manage. Its like... my queries go into a VM and now I have to worry about how the VM is performing. I wish and maybe there is a programming language with first class database support. I mean really first class not just let me r…

The closest thing to what you're describing is Prisma in Node. It generates a Typescript file from your schema so you get code completion on your data. And it exists somewhere between a query builder and a traditional ORM. I have worked in many languages with many ORMs and this has been my personal favorite.

Until Prisma can manage JOINs [0] there is no way I can recommend it.

[0]: https://github.com/prisma/prisma/discussions/12715

Re: Almost every infrastructure decision I endorse or regret

#168

Post by sgarland »

dalyons wrote: post #123
sgarland wrote: post #33

Earlier quoted context omitted.

I’m a DBRE, which means it’s somehow always my fault until proven otherwise. And even then, it’s usually on me to work around the insane schema dreamt up by the devs. Multi-tenant DBs can work fine as long as every app has its own users, everyone goes through a connection pooler / load balancer, and every user has rate limits. You want to write shitty queries that time out? Not my problem. Your GraphQL BFF bullshit i…

Or, you just avoid doing multi tenet from the start and none of those become your problem to unblock. What’s the downside?

Done that as well; it still becomes my problem because teams without RDBMS knowledge eventually break it, and… then I get paged.

Full Stack is a lie, and the sooner companies accept that and allow people to specialize again, and to pay for the extra headcount, the better off everyone will be.

Re: Almost every infrastructure decision I endorse or regret

#169

Post by AznHisoka »

magicalhippo wrote: post #72
el_benhameen wrote: post #59

Earlier quoted context omitted.

Lots of interesting comments on this one. Anyone have any good resources for learning how not to fuck up schema/db design for those of us who will probably never have a DBA on the team?

Good question. We don't have a DBA either. I've learned SQL as needed and while I'm not terrible, it's still daunting when making the schema for a new module that might require 10-20 tables or more. One thing that has worked well for us is to alway include the top-most parent key in all child tables down yhe hierarchy. This way we can load all the data for say an order without joins/exists. Oh and never use natural k…

Not to pick on you, but is SQL not basic knowledge for every software engineer these days? Or have times changed?

Re: Almost every infrastructure decision I endorse or regret

#170

Post by AznHisoka »

charred_patina wrote: post #125
LispSporks22 wrote: post #74

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…

I bet Craigslist runs on much simpler infrastructure. Not sure how much they’re worth though
Post reply on HN