Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

261–270 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#261
post #249

Earlier quoted context omitted.

Some orgs are looking at moving back to on prem because they're figuring this out. For a while it was vogue to go from capex to opex costs, and C suite people were incentivized to do that via comp structures, hence "digital transformation" ie: migration to public cloud infrastructure. Now, those same orgs are realizing that renting computers actually costs more than owning them, when you're utilizing them to a signif…

i would imagine that cloud infrastructure has the ability for fast scale up, unlike self-owned infrastructure. For example, how long does it take to rent another rack that you didnt plan for? And not to mention that the cost of cloud management platforms that you have to deploy to manage these owned assets is not free. I mean, how come even large consumers of electricity does not buy and own their own infrastructure…

>I mean, how come even large consumers of electricity do not buy and own their own infrastructure to generate it?

They sure do? BASF has 3 power plants in Hamburg, Disney operate Reedy Creek Energy with at least 1 power plant and I could list a fair bit more...

>For example, how long does it take to rent another rack that you didnt plan for?

I mean, you can also rent hardware a lot cheaper then on AWS. There certainly are providers where you can rent out a rack for a month within minutes

Re: Almost every infrastructure decision I endorse or regret

#262
post #16

Who's using Pulumi here and how mature is it in comparison to terraform?

IaaC is one of the worst acronyms ever.

Infrastructure should be declared, not coded.

Say what you want. The tool then builds that, or changes whats there to match.

I've tried Pulumi and understanding the bit that runs before it tries to do stuff and the bit that runs after it tries to do stuff and working out where the bugs are is a PITA. It lulls you into a false sense of security that you can refer to your own variables in code, but that doesn't get carried over to when it is actually running the plan on the cloud service (ie actually creating the infrastructure) because you can only refer to the outputs of other infrastructure.

CFN is too far in the other direction, primarily because it's completely invisible and hard to debug.

Terraform has enough programmability (eg for_each, for-expressions etc) that you can write "here is what I want and how the things link together" and terraform will work out how to do it.

The language is... sometimes painful, but it works.

The provider support is unmatched and the modules are of reasonable quality.

Re: Almost every infrastructure decision I endorse or regret

#263
post #12

Earlier quoted context omitted.

Definitely--I recommend this after you've reached the point where you're writing huge checks to AWS. Maybe this is just assumed but I've never seen anyone else add that nuance to the "just use RDS" advice. It's always just "RDS is worth it" full stop, as in this article.

To some extend that is probably true, because when you’ve built a business that needs a 500k/year database fully on RDS it’s already priced into your profits, and switching to a self-hosted database will seem unacceptably risky for something that works just fine.

> it’s already priced into your profits

Assuming you have any. You might not, because of AWS.

Re: Almost every infrastructure decision I endorse or regret

#264

If you are startup that can can’t afford a DBA, then why why why are you using Kubernetes?

Because I can go from main.go to a load balanced, autoscaling app with rolling deploys, segeregated environments, logging & monitoring in about 30 minutes, and never need to touch _any_ of that again. Plus, if I leave, the guy who comes after me can look at a helm chart, terraform module + pipeline.yml and figure out how it works. Meanwhile, our janq shell script based task scheduler craps out on something new every…

If you can do all that in 30 minutes (or even a few hours), I would love to read an article/post about your setup, or any resources you might recommend.

Re: Almost every infrastructure decision I endorse or regret

#265
post #249

Earlier quoted context omitted.

Some orgs are looking at moving back to on prem because they're figuring this out. For a while it was vogue to go from capex to opex costs, and C suite people were incentivized to do that via comp structures, hence "digital transformation" ie: migration to public cloud infrastructure. Now, those same orgs are realizing that renting computers actually costs more than owning them, when you're utilizing them to a signif…

i would imagine that cloud infrastructure has the ability for fast scale up, unlike self-owned infrastructure. For example, how long does it take to rent another rack that you didnt plan for? And not to mention that the cost of cloud management platforms that you have to deploy to manage these owned assets is not free. I mean, how come even large consumers of electricity does not buy and own their own infrastructure…

Ordering that amount of amount of servers takes about one hour with hetzner. If you truly want a complete rack on your own maybe a few days as they have to do it manually.

Most companies don‘t need to scale up full racks in seconds. Heck, even weeks would be ok for most of them to get new hardware delivered. The cloud planted the lie into everyone‘s head that most companies dont have predictable and stable load.

Re: Almost every infrastructure decision I endorse or regret

#266

Earlier quoted context omitted.

Some orgs are looking at moving back to on prem because they're figuring this out. For a while it was vogue to go from capex to opex costs, and C suite people were incentivized to do that via comp structures, hence "digital transformation" ie: migration to public cloud infrastructure. Now, those same orgs are realizing that renting computers actually costs more than owning them, when you're utilizing them to a signif…

Keep in mind, there is an in between.. I would have a hard time doing servers as cheap as hetzner for example including the routing and everything

I do that. In fact I've been doing it for years, because every time I do the math, AWS is unreasonably expensive and my solo-founder SaaS would much rather keep the extra money.

I think there is an unreasonable fear of "doing the routing and everything". I run vpncloud, my server clusters are managed using ansible, and can be set up from either a list of static IPs or from a terraform-prepared configuration. The same code can be used to set up a cluster on bare-metal hetzner servers or on cloud VMs from DigitalOcean (for example).

I regularly compare this to AWS costs and it's not even close. Don't forget that the performance of those bare-metal machines is way higher than of overbooked VMs.

Re: Almost every infrastructure decision I endorse or regret

#268

I’m imagining a developer in the 90s/00s reading this list and being baffled by the complexity/terminology

Yeah, I read the " My general infrastructure advice is “less is better”.", and was like "when did this list of stuff become the definition of 'less'"

My reaction exactly. I don't know their footprint but this is a long list of stuff.

Re: Almost every infrastructure decision I endorse or regret

#269

I’m imagining a developer in the 90s/00s reading this list and being baffled by the complexity/terminology

I’ve used most of these technologies and the sum value add over a way simpler monolith on a single server setup is negligible. It’s pure insanity

Re: Almost every infrastructure decision I endorse or regret

#270
post #120

Earlier quoted context omitted.

Most databases expressly say don’t run storage over a network.

To be fair, most networked filesystems are nowhere near as good as EBS. That’s one AWS service that takes real work to replicate on-prem. OTOH, as noted, EBS does not perform as well as native NVMe and is hilariously expensive if you try. And quite a few use cases are just fine on plain old NVMe.

Thats because EBS is a network block device and not a network filesystem - that would be EFS. And with network block devices you get the same perf and better compared to EBS.
Post reply on HN