181–190 of 247 posts
> 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...
> 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.
Any opinion on Pulumi?
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.
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 datace…
Earlier quoted context omitted.
Curious from you or others when FaaS isn’t possible? What criteria do you look for to decide or migrate off?
not possible: - workloads over 15m for lambda last time I checked, unsure on other providers - if you are looking to do anything stateful possible but not ideal/inconveniences: - cold starts can hamper latency sensitive apps (language dependant + there are things you can do) - if you have consistent traffic its not very good value for money - if you value local debugging
(2024) past discussion: https://news.ycombinator.com/item?id=39313623
Earlier quoted context omitted.
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.
Granted, DB size isn't the best metric to be using here in terms of performance, but it's the one you used.
Pagerduty: They haven't yet hit that point where PD doubles the prices for them. Or they don't have everyone on the platform, it will be their next Datadog (too expensive)
> 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...
- Crud accumulates in the [infrastructure thingie], and it’s unclear if it can be deleted.
- When there are performance issues, infrastructure (without deep product knowledge) has to debug the [infrastructure thingie] and figure out who to redirect to
- [infrastructure thingie] users can push bad code that does bad things to the [infrastructure thingie]. These bad things may PagerDuty alert the infrastructure team (since they own the [infrastructure thingie]). It feels bad to wake up one team for another team’s issue. With application owned [infrastructure thingies], the application team is the first responder.
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.