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

121–130 of 247 posts

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

#121

Post by AIorNot »

mettamage wrote: post #105

As a non infra guy I'll say this. I'm curious about Linear. At my own company I vibecoded my own project management app against the JIRA API because I can't stand our version of JIRA. It's too many clicks, too many things to remember and it's unintuitive.

As everyone knows JIRA sucks but some perfect implementation of it exists in the ether at some company you will never work at :)

Theses days AI in doc, spec and production lifecycle means we need AI first ticket tooling - haven’t used Linear but I suspect that works far better with AI then JIRA

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

#122

Post by AIorNot »

bruce343434 wrote: post #115
CodesInChaos wrote: post #109

Earlier quoted context omitted.

What's the issue with logging? I would have expected stdout/stderr to get automatically transferred to the providers managed logging solution (e.g. cloudwatch). Though I never really understood the appeal of FaaS over something like Google-Cloud-Run.

As a developer who spent a couple months developing a microservice using aws lambda functions: it SUCKS. There's no interactive debugging. Deploy for a minute or 5 depending on the changes, then trigger the lambda, wait another 5 minutes for all the logs to show up. Then proceed with printf/stack trace debugging. For reasons that I forgot, locally running the lambda code on my dev box was not applicable. Locally depl…

Lol exactly

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

#123

Post by YetAnotherNick »

MrDarcy wrote: post #60
kstrauser wrote: post #8

> Picking Terraform over Cloudformation: Endorse I, too, prefer McDonald's cheeseburgers to ground glass mixed with rusty nails. It's not so much that I love Terraform (spelled OpenTofu) as that it's far and away the least bad tool I've used in the space.

CDK is far better than Terraform.

CDK is better when it works. Terraform has so many escape hatches it scales better with edge cases over time.

There are all sort of requirements that pops up, specially in times of downtime or testing infra migration in production etc. and it's much easier to manually edit the terraform states.

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

#125

Post by gchamonlive »

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.

Ansible and terraform have some overlap, but they do tend to serve different purposes. The consequences of terraform having a state file should steer your decision.

However, I often find ansible modules to be confusing to use. Maybe with LLMs it's now easier to draft ansible roles and maintain them, but I always had agro whenever I needed to go to the docs for something I've done many times just because the modules are that much inconsistent.

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

#126

Post by Lucasoato »

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

Self managing a database vs getting RDS isn't an easy choice. It depends on the scale, it depends on the industry... if you're locked in already in AWS, the price difference between the bare machines vs RDS usually aren't enough to pay for another person.

If you're starting everything from scratch, you might think that going to other providers (like Hetzner) is a good idea, and it may definitely be! But then you need to set up a Site2Site VPN because the second big customer of your B2B SaaS startup uses on-premises infrastructure and AWS has that out of the box, while you need an expert networking guy to do that the right way on Hetzner.

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

#128

Post by nijave »

gib444 wrote: post #88

Infra guys doing DBA is a nightmare in my experience (usually clueless and it gets loved less than more sexy parts of infra). Devs too Hire a DBA ASAP. They need to reign in also the laziness of all other developers when designing and interacting with the DB. The horrors a dev can create in the DB can take years to undo

I'm a little afraid to say it but LLMs are getting quite good at query optimization. They can also read slow query logs and use extensions like pg_stat_statements

Doesn't necessarily prevent a terrible schema but it's become a lot easier to fix abomination queries at least

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

#129

Post by happymellon »

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

The last startup I was with that used AWS didn't spend anything on premium support. We were given startup credits to apply to our accounts, and they were always happy to hand out more to get us hooked.

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

#130

Post by nijave »

themafia wrote: post #61

> “This EC2 instance type running 24/7 at full load is way less expensive than a Lambda running”. For the same amount of memory they should cost _nearly_ identical. Run the numbers. They're not significantly different services. Aside from this you do NOT pay for IPv4 when using Lambda, you do on EC2, and so Lambda is almost always less expensive.

I'm curious how that plays out when you factor in other infrastructure components like DB and load balancers.

On Lambda, load balancing is handled out of the box but you may need to introduce things like connection poolers for the DB you could have gotten away without on EC2

Think it also depends if you're CPU or memory constrained. Lambda seemed more expensive for CPU heavy workloads since you're stuck with certain CPU:mem ratios and there's more flexibility on EC2 instance types

Post reply on HN