Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

241–250 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#241

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

I agree. I’m afraid I’m one of those 00s developers and can relate. Back then many startups were being launched on super simple stacks. With all of that complexity/word salad from TFA, where’s the value delivered? Presumably there’s a product somewhere under all that infrastructure, but damn, what’s left to spend on it after all the infrastructure variable costs? I get it’s a list of preferences, but still once you’v…

> Do we ever seek simplicity in software engineering products?

Doubtfully. Simplicity of work breakdown structure - maybe. Legibility for management layers, possibly. Structural integrity of your CYA armor? 100%.

The half-life of a software project is what now, a few years at most these days? Months, in webdev? Why build something that is robust, durable, efficient, make all the correct engineering choices, where you can instead race ahead with a series of "nobody ever got fired for using ${current hot cloud thing}" choices, not worrying at all about rapidly expanding pile of tech and organizational debt? If you push the repayment time far back enough, your project will likely be dead by then anyway (win), or acquired by a greater fool (BIG WIN) - either way, you're not cleaning up anything.

Nobody wants to stay attached to a project these days anyway.

/s

Maybe.

Re: Almost every infrastructure decision I endorse or regret

#242

Earlier quoted context omitted.

I think most people who’ve never experienced native NVMe for a DB are also unaware of just how blindingly fast it is. Even io2 Block Express isn’t the same.

Yes. We have it 4x striped on those same machines. Burns like lightning.

Ha, I did just the same thing - and also optimized for an extremely fast per-thread CPU (which you never get from managed service providers).

The query times are incredible.

Re: Almost every infrastructure decision I endorse or regret

#243
post #130

Earlier quoted context omitted.

>By the time your db is big enough to cost an unreasonable amount on RDS, you’re likely a big enough team to have options. By the time your db is big enough to cost an unreasonable amount on RDS, you've likely got so much momentum that getting off is nearly impossible as you bleed cash. You can buy a used server and find colocation space and still be pennies on the dollar for even the smallest database. If you're doi…

In the small SaaS startup case, I’d say the production database is typically the most critical single piece of infra, so self hosting is just not a compelling proposition unless you have a strong technical reason where having super powerful database hardware is important, or a team with multiple people who have sysadmin or DBA experience. I think both of those cases are unusual. I’ve been the guy managing a critical…

I like fiddling with databases, but I totally agree with this. Unless you really need a big database and are going to save 100k+ per year by going self managed then RDS or similar just saves you so much stress. We've been using it for the best part of 10 years and uptime and latency have consistently been excellent, and functionality is all rock solid. I never have to think about it, which is just what I want from something so core to the business.

Re: Almost every infrastructure decision I endorse or regret

#244

> There are no great FaaS options for running GPU workloads This hits hard. Someone please take my (client's) money and provide sane GPU FaaS. Banana.dev is cool but not really enterprise ready. I wish there was a AWS/GCP/Azure analogue that the penny pinchers and MBAs in charge of procurement can get behind.

I am confused. Doesn't Modal Labs solve this?

Re: Almost every infrastructure decision I endorse or regret

#245

Earlier quoted context omitted.

If you’re paying list price at scale you are doing it very wrong.

Interesting how cloud services are sold like used cars.

It's more interesting how cloud services are sold like any other consumables or corporate services.

No one runs their own electricity supply (well until recently with renewables/storage), they buy it as a service, up to a pretty high scale before it becomes more economic to invest the capex and opex to run your own.

Re: Almost every infrastructure decision I endorse or regret

#246

It is a shame karpenter is AWS only. I was thinking about how our k8s autoscaler could be better and landed on the same kind of design as karpenter where you work from unschedulable pods backwards. Right now we have an autoscaler which looks at resource utilization of a node pool but that doesn’t take into account things like topology spread constraints and resource fragmentation.

https://github.com/Azure/karpenter-provider-azure there is this in the works for karpenter on aks

It’s actually released in preview, they called it Node Auto Provisioning. Doesn’t work with Azure Linux unfortunately.

Re: Almost every infrastructure decision I endorse or regret

#247

Earlier quoted context omitted.

Lots of cases. It doesn't even have to be a tiny database. Within Also, Aurora gives you the block level cluster that you can't deploy on your own - it's way easier to work with than the usual replication.

Once you commit to more deeply Amazon flavored parts of AWS like Aurora, aren't you now fairly committed to hoping your scale never exceeds the cost-benefit tradeoff?

Aurora supports standard Postgres clients.

So moving to/from Aurora/RDS/own EC2/on-prem should be a matter of networking and changing connection strings in the clients.

Your operational requirements and processes (backup/restore, failover, DR etc) will change, but that's because you're making a deliberate decision weighing up those costs vs benefits.

Re: Almost every infrastructure decision I endorse or regret

#248
post #112

Earlier quoted context omitted.

One giant codebase is fine. Monorepo is better than lots of scattered repos linked together with git hashes. And it doesn't really get in the way of each team managing when stuff gets rolled out.

I'm a big monorepo fan, but you run into that ownership problem. "It's slow to clone"; which team fixes that?

some bored guy at $trillion_dollar_company

https://github.com/martinvonz/jj https://github.com/facebook/sapling

Re: Almost every infrastructure decision I endorse or regret

#249

> The markup cost of using RDS (or any managed database) is worth it. Every so often I price out RDS to replace our colocated SQL Server cluster and it's so unrealistically expensive that I just have to laugh. It's absurdly far beyond what I'd be willing to pay. The markup is enough to pay for the colocation rack, the AWS Direct Connects, the servers, the SAN, the SQL Server licenses, the maintenance contracts, and a…

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 to generate it?

Re: Almost every infrastructure decision I endorse or regret

#250

Earlier quoted context omitted.

Heii On-Call is $32 per month total for your team — not per user. https://heiioncall.com/ (Full disclosure: part of the team building it)

Looks super interesting, and that $3/month for hobbyists is just low enough to meet my budget for hobby services, but please, for on-call stuff, you gotta have alerts that make phone calls. Nothing else is going to wake me in the middle of the night. This is the #1 feature I expect from an on-call service - you're on-call because you will be called .

We are building a great and affordable incident escalation tool as well:

https://allquiet.app

With SMS, Phone Calls and Critical Alerts / DnD override.

We're 5 USD/user.

We try to build as close to our users as possible. Happy for any new try outs! :)

(I am co founder)

Post reply on HN