Live data from Hacker News

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

cep.dev

141–150 of 247 posts

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

#141
post #69

Sure, let's take advices about infrastructure from that guy wo needs a tool to automate postmortems.

Can you expand? Have you never worked at a tech company that has incidents?

In which world does a large tech company exist without problems, if so how big, how many customers etc?

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

#143

I think we're making a mistake by shoving all of this into the cloud rather than building tooling around local agents (worktrees, containers, as mentioned as "difficult" in the post). I think as an industry we just reach for cloud like our predecessors reached for IBM, without critical thought about what's actually the right tool for the job. If you can manage docker containers in a cloud, you can manage them on your…

You also get all the risk of exposing your network and the cost of maintenance for your own datacenter.

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

#144
post #83

Earlier quoted context omitted.

I meant failure blast radius. Having isolated regions is a core part of the AWS reliability design. AWS has had entire regions fail but these failure have always been isolated to a single region. Global VPCs must rely on globally connected routers that can all fail in ways AWS regional VPCs can't.

If you need global HA to the extent that you're worried about global VPC failure modes, you're going to have to spend a lot of effort to squeeze uptime to the max regardless of where you deploy. Undersea cable failures are probably more likely than a google core networking failure. In AWS a lot of "global" things are actually just hosted in us-east-1.

On the other hand, when they say something is in us-west-2 they mean it, so if another region has an outage your workloads aren't impacted unless your code is reaching out to that region.

Guessing that's similar on the other clouds.

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

#145
post #97

Earlier quoted context omitted.

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 a…

Setting aside the turing completeness of them, in practice Ansible is a complete superset of Terraform. From experience, the only times you appreciate the state file is when you have uncontrolled changes, in which case you are in for a bad time anyway.

Ansible modules are trivial to write and more people should. Most are trivial in practice and just consists of a few underlying API calls. A dozen line snippet you fully understand is generally not a maintenance burden. A couple of thousand someone else wrote might be.

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

#146
post #66

Earlier quoted context omitted.

I have mixed feelings about it. On my first startup, I used ansible to automate all of the manual workflows and server setup that we had done. Everything was just completely manual and in people's heads before, and translating it to ansible was a pain in the ass to say the least. I don't think it would have been any easier to translate it to something else though. It ended up working fine and we had a solid system th…

> 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 instead, so they did the migration.

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

#147
post #6

I would love to read more about the pros and cons of using a single database, if anyone has pointers to articles

SRE here who has dealt with this before. Everything in article is excellent point but other big point is schema changes become extremely difficult because you have unknown applications possibly relying on that schema. It's also at certain point, the database becomes absolutely massive and you will need teams of DBAs care and feeding it.

This is true. But at the same time people need to understand that most companies will never hit that certain point. It's a matter of if, not when.

Everyone tries to plan for a world where they've become one of the hyperscalers. Better to optimize for the much more likely scenarios.

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

#149
post #26

Earlier quoted context omitted.

As a counterpoint, I find our AWS super team to be a mix of 40% helpful, 40% “things we say are going over their head,” 20% attempting to upsell and expand our dependence. It’s nice that we have humans but I don’t think it’s a reason to choose it or not. GCP’s architecture seems clearly better to me especially if you are looking to be global. Every organization I’ve ever witnessed eventually ends up with some kind of…

There's a very large gap between "seems" and reality. GCP is a huge PITA. It's not even stable to use, as the console is constantly unresponsive and buggy, the UX is insane, finding documentation is like being trapped in hell. Know how you find all the permissions a single user in GCP has? You have to make 9+ API calls, then filter/merge all the results. They finally added a web tool to try and "discover" the permiss…

I’m sure anyone willing to read through a 1,000 page document can make a well-architected GCP environment, too.

The problem is that no company I’ve ever worked for implemented the well architected framework with their AWS environment, and not one company will ever invest the time to make their environment match that level of quality.

I think what you describe with the web tool to discover user permissions sounds a lot like the AWS VPC Reachability Analyzer which I had to live in for quite a while because figuring out where my traffic was getting blocked between an endless array of AWS accounts and cross-region transit gateways was such a nightmare that wouldn’t exist with GCP global VPCs and project/folder based permissions.

I don’t like the GCP console, but I also wouldn’t consider a lot of the AWS console to be top tier software. Slow/buggy/inconsistent are words I would use with the AWS console. I can concede that AWS has better documentation, but I don’t think it’s a standout, either.

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

#150
post #3

It's weird that one of the reasons that you endorse AWS is that you had regular meetings with your account manager but then you regret premium support which is the whole reason you had regular meetings with your account manager.

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.
Post reply on HN