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

211–220 of 247 posts

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

#211

Post by zie »

darth_avocado wrote: post #207
zie wrote: post #163

Earlier quoted context omitted.

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…

> If you know what you're doing you don't need AWS support. Some big companies have massive monolith code bases. This is not a generalization you could apply universally. There are a lot of other considerations. What kind of features are we talking about, what kind of I/o patterns are planned, what is the scale of data expected, etc.

I think you are responding to the wrong comment. I never said that.

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

#213

Post by esoterae »

Honestly, this is a reasonable itemization of experience with individual tools, but this reads like a recipe for Company Cake instead of a case-by-case statement of need, selection, and then evaluation. Cargo culting continues to wrap its tendrils around the industry and try to drag it into the depths of mediocrity, and this largely reads to me like a primer for how to saddle yourself with endless SaaS bills. I recognize that every situation has its nuances, but I think approaching running a company from "what tools do you use" is pretty much the biggest possible example of ignoring that maxim.

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

#215

Post by easterncalculus »

Tostino wrote: post #146
SkiFire13 wrote: post #84

Earlier quoted context omitted.

> on a set of VPS provided by some terraform scripts You ended up needing Terraform too for the infrastructure though. At that point why not just use Terraform?

Terraform was just for interacting with the cloud provider and spinning up the servers. Ansible was responsible for deploying all dependencies and getting the servers actually ready for use. Remember, none of this architecture was dockerized. I had originally used Ansible to interact with the cloud provider and do the provisioning too, but someone on the corporate infrastructure team wanted to use terraform for that…

I also have experience with using Terraform and Ansible like this. Once I realized that most of the work actually performing the setup beyond blank VM creation was in Ansible, I was much more interested in just using Ansible for everything.

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

#217

Post by bwilliams18 »

Hovertruck wrote: post #209

Much of this matches my own experience. A few thoughts: 1. Cost tracking meetings with your finance team are useful, but for AWS and other services that support it I highly recommend setting billing alarms. The sooner you can know about runaway costs, the sooner you can do something about it. 2. Highly recommend PGAnalyze ( https://pganalyze.com/ ) if you're running Postgres in your stack. It's really intuitive, and…

There's a big difference between runaway costs and these costs over here, which are 10-20% higher than we think makes sense, especially compared to what we're spending over here. Let's spend some time figuring out how to reduce those costs. You should be doing both - belt and suspenders.

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

#218

Post by JamesBarney »

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

The issue wasn't sharing a database, it was not being clear about who owns what.

Having multiple teams with one code base that has one database is fine. Every every line of code, table and column needs to be owned by exactly ONE team.

Ownership is the most important part of making an organization effective.

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

#219

Post by h1fra »

JoeBOFH wrote: post #173
h1fra wrote: post #150

Earlier quoted context omitted.

I never got this in the comparison of aws between gcp. Why do people need direct support that much? In 8 years, I had to reach out to GCP maybe twice and still got an answer anyway.

With my experience it’s the edge cases. The few times I had to reach out to AWS support were due to some weird edge case we couldn’t fix but AWS had to. And having a rep involved made it so much smoother.

I had to reach AWS because of a bug in Aurora last year; they replied quickly but said that they couldn't understand the bug...

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

#220

Post by JamesBarney »

austinsharp wrote: post #195
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...

Highly recommend reading Designing Data-Intensive Apps [1] and Monolith to Microservices [2]. I can't remember which (maybe both?) but I definitely took away the idea that if services share a DB, that DB's schema is now a public interface and becomes much more difficult to evolve with new requirements. [1] https://www.amazon.com/Designing-Data-Intensive-Applications... [2] https://www.amazon.com/Monolith-Microservice…

The old school solution to this is have different schema in your database, and have views as the cross team public interface.
Post reply on HN