Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

461–470 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#461

Earlier quoted context omitted.

Eh? I've never had a problem moving data out of AWS. Have people lost the ability to write export and backup scripts?

My (peripheral) experience is that it is much cheaper to get data in than to get data out. When you have the amount of data being discussed — "Enterprise data. Going back years." — that can get very costly. It's the amount of data where it makes more sense to put hard drives on a truck and drive across the country rather than send it over a network, where this becomes an issue (actually, probably a bit before then).

AWS actually has a service for this - Snowmobile, a storage datacenter inside of a shipping container, which is driven to you on a semi truck. https://aws.amazon.com/snowmobile/

Re: Almost every infrastructure decision I endorse or regret

#462
post #297

Earlier quoted context omitted.

Discount rates are actually much better too on the bigger instances. Therefore the "sticker price" that people compare on the public site is no where close to a fair comparison. We technically aren't supposed to talk about pricing publically, but I'm just going to say that we run a few 8XL and 12Xl RDS instances and we pay ~40% off the sticker price. If you switch to Aurora engine the pricing is absurdly complex (its…

> but I'm just going to say that we run a few 8XL and 12Xl RDS instances and we pay ~40% off the sticker price. Genuinely curious, how do you that? We pay a couple of million dollars per year and the biggest spend is RDS. The bulk of those are 8xl and 12xl as you mention and we have a lot of these. We do have savings plans, but those are nowhere near 40%.

At least according to: https://instances.vantage.sh/rds/?selected=db.r6g.16xlarge,d...

It looks like a reserved instance is 35% off sticker price? Add probably a discount and you'd be around 40% off.

Re: Almost every infrastructure decision I endorse or regret

#463

Earlier quoted context omitted.

> There's nothing hidden about the fact that they will push us to use AWS services. Our account team don't even do that. We use a lot of AWS anyway and they know it, so they're happy to help with competitor offerings and integrating with our existing stack. Their main push on us has been to not waste money.

When I was at AWS, I watched SAs get promoted for saving customers money all the time. AWS wants happy customers to stick around for a long time, not one month of goosed income

Yep. Pay us less every month and stick around for a long time. Getting low prices makes it really difficult to move away.

If you still decided to move away, and want to take data with you, yeah... there is a cost. Heck there is a cost to delete the data you have with them (like S3 content).

Its a good way to do business.

Re: Almost every infrastructure decision I endorse or regret

#464

Earlier quoted context omitted.

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 agree, but I also classify some of these as "learn them once and you're all set". Maybe it takes you a month the first time around and a week the 10th time around. First product suffers, the other products not so much. Now it just takes a week of your time and does not require you to pay large AWS fees, which means you are not bleeding money I like to set up scrappy products that do not rack up large monthly fees.…

Learning it all is what gave me an appreciation for RDS! I’ve self managed a number of Postgres and MySQL databases, including a 10TB Postgres cluster with all of the HA and backup niceties.

While I generally agree as far as initial setup time goes, I favor RDS because I can forget about it, whereas the hand rolled version demands ongoing maintenance, and incurs a nonzero chance of simple mistakes that, if made, could result in a 100% dataloss unrecoverable scenario.

I’m also mostly talking about typical, funded startups here, as opposed to indie/solo devs. If you’re flying solo launching a tiny proof of concept that may only ever have a few users, by all means run it yourself if you’d like, but if you’ve raised money to grow faster and are paying employees to iterate rapidly searching for PMF…just pay for RDS and make sure as much time as possible is spent on product features that provide actual business value. It starts at like $15/month. The cost of simply not being laser-focused on product is far greater.

Re: Almost every infrastructure decision I endorse or regret

#465
post #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

It's a hedge.

There's an easy bent towards designing everything for scale. It's optimistic. It's feels good. It's safe, defendable, and sound to argue that this complexity, cost, and deep dependency is warranted when your product is surely on the verge of changing the course of humanity.

The reality is your SaaS platform for ethically sourced, vegan dog food is below inconsequential and the few users that you do have (and may positively affect) absolutely do not not need this tower of abstraction to run.

Re: Almost every infrastructure decision I endorse or regret

#466
post #438

Reading this I couldn’t help but think: yeah all of these points make sense in isolation, but if you look at the big picture, this is an absurd level of complexity. Why do we need entire teams making 1000s of micro decisions to deploy our app? I’m hungry for a simpler way, and I doubt I’m alone in this.

It smells like ZIRP is not over yet. VCs are still burning money in the AWS fire pit.

ZIRP was never the root problem.

The problem was: too much money, too few consequences for burning it.

The existence of the uber-wealthy means that markets can no longer function efficiently. Every market remains irrational longer than anyone who's not uber-wealthy can remain solvent.

Welcome to the new normal.

Re: Almost every infrastructure decision I endorse or regret

#467

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

I'd add another criticism to the whole quote:

> Data is the most critical part of your infrastructure. You lose your network: that’s downtime. You lose your data: that’s a company ending event. The markup cost of using RDS (or any managed database) is worth it.

You need well-run, regularly tested, air gapped or otherwise immutable backups of your DB (and other critical biz data). Even if RDS was perfect, it still doesn't protect you from the things that backups protect you from.

After you have backups, the idea of paying enormous amounts for RDS in order to keep your company from ending is more far fetched.

Re: Almost every infrastructure decision I endorse or regret

#468
I see homebrew in here as a way to distribute internally.

We have non-developers (artists, designers) on our team, and asking them to manage homebrew is a non-starter. We're also on windows.

We current just shove everything (and I mean everything) in perforce. Are there any better ways of distributing this for a small team?

Re: Almost every infrastructure decision I endorse or regret

#469

Earlier quoted context omitted.

That's completely opposite to my experience. Do you have any examples of AWS naming that you think is "teenage boy trying to be cool"? I am genuinely curious.

BigQuery - Athena Pub/Sub - Kinesis Cloud CDN - CloudFront Cloud Domains - Route 53 ...

Perfect list, also:

Google Cloud Run - Lambda

Sure I get the reference to the underlying algebraic representation of coding but come on, Lambda tells us nothing of what it does.

Products (not brands, products) should be named in a way that means something to the customer afaic.

Re: Almost every infrastructure decision I endorse or regret

#470

> Picking AWS over Google Cloud I know this is an unpopular opinion but I think google cloud is amazing compared to AWS. I use google cloud run and it works like a dream. I have never found an easier way to get a docker container running in the cloud. The services all have sensible names, there are fewer more important services compared to the mess of AWS services, and the UI is more intuitive. The only downside I ha…

> I have never found an easier way to get a docker container running in the cloud I don't have a ton of Azure or cloud experience but I run an Unraid server locally which has a decent Docker gui. Getting a docker container running in Azure is so complicated. I gave up after an hour of poking around.

Oh I disagree - we migrated from azure to AWS, and running a container on Fargate is significantly more work than Azure Container Apps [0]. Container Apps was basically "here's a container, now go".

[0] https://azure.microsoft.com/en-gb/products/container-apps

Post reply on HN