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

Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

cep.dev

Post reply on HN
Print view View original

161–170 of 247 posts

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#161

Post by OJFord »

consumer451 wrote: post #155

> Multiple applications sharing a database [0] > Regret Thanks for this data point. I am currently trying to make this call, and I was still on the fence. This has tipped me to the separate db side. Can anyone else share their experience with this decision? [0] https://cep.dev/posts/every-infrastructure-decision-i-endors...

What's the DBMS? We moved in the other direction with postgres, merged multiple databases to simply have a schema per service/application instead. All the advantages with none of the disadvantages, imo. (We then had a single database per running test/dev environment, rather than multiple.) Of course, that's a pg thing, if you use MySQL for example it's not an option.

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#162

Post by OJFord »

xorcist wrote: post #97
orwin wrote: post #24

Earlier quoted context omitted.

Terraform/openTofu is more than OK. The fact that you can use to to configure your Cisco products as well as AWS is honestly great for us. It's also a bit like ansible: if you don't manage it carefully and try to separate as much as possible early, it starts bloating, so you have to curate early. Terragrunt is the only sane way to deploy terraform/openTofu in a professional environment though.

I never understood this. Why not use Ansible instead, especially if you already use it? Doubly so when you have Cisco config to manage. The experience is generally so much better it's not comparable, and it is much easier to infer running state.

Because one's a language & tool for infrastructure as code, and the other's essentially a low-code ops scripting framework?

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#163

Post by zie »

consumer451 wrote: post #155

> Multiple applications sharing a database [0] > Regret Thanks for this data point. I am currently trying to make this call, and I was still on the fence. This has tipped me to the separate db side. Can anyone else share their experience with this decision? [0] https://cep.dev/posts/every-infrastructure-decision-i-endors...

My advice: One code base and one database.

In my experience, it's easier to take schema out into a new DB in the off-chance it makes sense to do so.

The big place I'd disagree with this is when "your" data is actually customer data, and then you want 1 DB per customer whenever you can and SQLite is your BFF here. You have 1 DB for your stuff(accounting, whatever) and then 1 SQLite file per customer, that holds their data. Your customer wants a copy, you run .backup and send the file, easy peasy. They get pissed, rage quit and demand you delete all their data, easy!

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#164

Post by zie »

rf15 wrote: post #102

> Startups don’t have the luxury of a DBA but... you are spending so much on AWS and premium support... surely you can afford that

They have a DBA in their infrastructure team, they just didn't bother to tell anyone and let them own it.

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#166

Post by dfee »

OJFord wrote: post #161
consumer451 wrote: post #155

> Multiple applications sharing a database [0] > Regret Thanks for this data point. I am currently trying to make this call, and I was still on the fence. This has tipped me to the separate db side. Can anyone else share their experience with this decision? [0] https://cep.dev/posts/every-infrastructure-decision-i-endors...

What's the DBMS? We moved in the other direction with postgres, merged multiple databases to simply have a schema per service/application instead. All the advantages with none of the disadvantages, imo. (We then had a single database per running test/dev environment, rather than multiple.) Of course, that's a pg thing, if you use MySQL for example it's not an option.

i think this is aligned with the author's choice. a separate schema is effectively a separate database (from a product eng perspective) with shared infra.

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#167

Post by perrygeo »

yakkomajuri wrote: post #127

> "Like most tech debt, we didn’t make this decision, we just did not not make this decision." This is an important point.

I agree with the sentiment, that most non-decisions are really implicit decisions in disguise. They have implications whether you thought about them up front or not. And if you need to revisit those non-decisions, it will cost you.

But I don't like calling this tech debt. The tech debt concept is about taking on debt explicitly, as in choosing the sub-optimal path on purpose to meet a deadline then promising a "payment plan" to remove the debt in the future. Tech debt implies that you've actually done your homework but picked door number 2 instead. A very explicit choice, and one where decision makers must have skin in the game.

A hurried, implicit choice has none of those characteristics - it's ignorance leading (inevitably?) to novel problems. That doesn't fit the debt metaphor at all. We need to distinguish tech debt from plain old sloppy decision making. Maybe management can even start taking responsibility for decisions instead of shrugging and saying "Tech debt, what can you do, amirite?"

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#168

Post by consumer451 »

OJFord wrote: post #161
consumer451 wrote: post #155

> Multiple applications sharing a database [0] > Regret Thanks for this data point. I am currently trying to make this call, and I was still on the fence. This has tipped me to the separate db side. Can anyone else share their experience with this decision? [0] https://cep.dev/posts/every-infrastructure-decision-i-endors...

What's the DBMS? We moved in the other direction with postgres, merged multiple databases to simply have a schema per service/application instead. All the advantages with none of the disadvantages, imo. (We then had a single database per running test/dev environment, rather than multiple.) Of course, that's a pg thing, if you use MySQL for example it's not an option.

Yes, we are using postgres and my plan was to use separate schemas, if going the single db route.

The only thing that worried me is that one product might need SOC 2 sooner than another. I thought separate databases would give a smaller compliance surface to worry about. However, this will be my first time going through this process, so I am pretty uninformed here.

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#169

Post by dfee »

intrasight wrote: post #160
consumer451 wrote: post #155

> Multiple applications sharing a database [0] > Regret Thanks for this data point. I am currently trying to make this call, and I was still on the fence. This has tipped me to the separate db side. Can anyone else share their experience with this decision? [0] https://cep.dev/posts/every-infrastructure-decision-i-endors...

Accept that eventually you'll have multiple databases, so it makes sense to plan from that from the start and get in place the mechanisms for the databases to talk to each other.

the method for databases to talk to each other is via?

if we're not talking about replicas, we're talking about coordination at the app level, right?

Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)

#170

Post by dogleash »

kolja005 wrote: post #37

>Since the database is used by everyone, it becomes cared for by no one. Startups don’t have the luxury of a DBA, and everything owned by no one is owned by infrastructure eventually. This post was a great read. Tangent to this, I've always found "best practices" to be a bit of a misnomer. In most cases in software and especially devops I have found it means "pay for this product that constrains the way that you do t…

> In most cases in software and especially devops I have found it means "pay for this product that constrains the way that you do things so you don't shoot yourself in the foot". It's not really a "practice" if you're using a product that gives you one way to do something.

The good thing about a lot of devops saas is that you're not paying anyone on staff to understand the problem domain and guide your team. The bad thing is that you're not paying anyone on staff to understand the problem domain and guide your team.

Post reply on HN