Live data from Hacker News

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

cep.dev

171–180 of 247 posts

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

#172

Earlier quoted context omitted.

Not an opinion on Pulumi specifically, but an opinion on using imperative programming languages for infrastructure configuration: don't do it. (This includes using things like CDKTF) Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates…

> Particularly, they allow you to write code whose output is unpredictable Is that an easy mistake to make and a hard one to recover from, in your experience? The way you have to bend over backwards in Terraform just to instantiate a thing multiple times based on some data really annoys me..

Agreed, I'm fine with a declarative format in one file as long as I can control the imperative bits on which it depends.

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

#173
post #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.

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.

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

#174
post #147

Earlier quoted context omitted.

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.

We were not a hyperscaler, we were boring company that you never heard of.

Database is still 40TB with 3200 stored procedures.

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

#175
I'll switch in Cloudflare Zero Trust for Okta simply for the fact that Cloudflare Access and Tunnels + An identity provider (we use M365) give you so much value (and it's free upto 50 users). It is even better if you are already running DNS on Cloudflare, you can securely deploy access-controlled apps on the internet without too much of a hassle and management. And with the recent addition for Infrastructure for SSH you can securely extend SSH access just as seamlessly.

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

#176
post #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.

if you need to bump a quota above the predetermined range of what googlers think is "normal" usage (which is far too low to run anything at scale)you have to talk to a human to negotiate the quota bump. why? because googlers in their infinite engineering wisdom use "gcp quotas" not as a cost optimization guardrail for customers benefit, but to inform google on when and how much metal they need to buy for their datacenter region you are running in.

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

#177
post #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.

One day, you will need support and when you do, you will realise why every week there's a top voted post on HN on someone complaining about not reaching Google Support

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

#178

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…

The thing is that startups often don't have the time or capital to build a data center even though public cloud is just more expensive. If you're bootstrapping a business then it makes sense. My advice would be to always use only those features of the public cloud that you can also use on your private cloud, such as Kubernetes.

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

#179

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.

Baffling piece of software. It's a task manager and every time I use it I flail around for ages trying to figure out how to mark a task completed. No idea why people like it.

Because the customers are hordes of PMs and other types who can use as tool to be taskmaster over hordes of developers.

It's Amazon warehouse worker tracking software for developers and thus we hate it.

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

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

googlers in their infinite wisdom have built a startup ecosystem for gcp that assigns "startups" to entry level new hires who are scrambling to figure out how to be managers of accounts while learning how to talk to humans, because googlers are generally not used to interacting with humans, just code, and that is the result of the programmatic hiring/screening process. each newly hired 20-something is also assigned 3,000 gcp accounts to manage.

what is the engineering used to determine a weak startup from a growing company you ask? well....googlers again use random numbers not logic (human interaction avoidance firewall) to determine that and set the floor at $30M "publicly declared investment capital". so what happens when you the gcp architect consultant hired to help this successful startup productionalize their gcp infra but their last round was private? google tells the soon to be $100M success company they are not real yet.....so they go get their virtual cpu,ram,disk from aws who knows how to treat customers right by being able to talk to humans by hiring account managers who pick up the phone and invite you to lunch to talk about your successful startup growing on aws. googlers are the biggest risk factor to the far superior gcp infrastructure for any business, startup or fortune 10.

Post reply on HN