Live data from Hacker News

We saved $500k per year by rolling our own "S3"

engineering.nanit.com

11–20 of 261 posts

Re: We saved $500k per year by rolling our own "S3"

#11

Earlier quoted context omitted.

And I am curious how many engineer years it requires to port code to cloud services and deal with multiple issues you cannot even debug due to not having root privileges in the cloud. Without cloud, saving a file is as simple as "with open(...) as f: f.write(data)" + adding a record to DB. And no weird network issues to debug.

> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !

With s3, you cannot use ls, grep and other tools.

> Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and...

Wow that's a lot to learn before using s3... I wonder how much it costs in salaries.

> With what network topology?

You don't need to care about this when using SSDs/HDDs.

> With what access policies?

Whichever is defined in your code, no restrictions unlike in S3. No need to study complicated AWS documentation and navigate through multiple consoles (this also costs you salaries by the way). No risk of leaking files due to misconfigured cloud services.

> With what backup strategy?

Automatically backed up with rest of your server data, no need to spend time on this.

Re: We saved $500k per year by rolling our own "S3"

#12

Earlier quoted context omitted.

And I am curious how many engineer years it requires to port code to cloud services and deal with multiple issues you cannot even debug due to not having root privileges in the cloud. Without cloud, saving a file is as simple as "with open(...) as f: f.write(data)" + adding a record to DB. And no weird network issues to debug.

> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !

You can't ever definitively answer most of those questions on someone else's cloud. You just take Amazons word for whatever number of nines they claim it has.

Re: We saved $500k per year by rolling our own "S3"

#14

Earlier quoted context omitted.

And I am curious how many engineer years it requires to port code to cloud services and deal with multiple issues you cannot even debug due to not having root privileges in the cloud. Without cloud, saving a file is as simple as "with open(...) as f: f.write(data)" + adding a record to DB. And no weird network issues to debug.

> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !

I don't think any of those mattered for their use case. That's why they didn't actually need S3.

Re: We saved $500k per year by rolling our own "S3"

#15
post #4

I'm curious how many engineers per year this costs to maintain

And I am curious how many engineer years it requires to port code to cloud services and deal with multiple issues you cannot even debug due to not having root privileges in the cloud. Without cloud, saving a file is as simple as "with open(...) as f: f.write(data)" + adding a record to DB. And no weird network issues to debug.

Variation on an old classic.

Question: How do you save a small fortune in cloud savings?

Answer: First start with a large fortune.

Re: We saved $500k per year by rolling our own "S3"

#16

Earlier quoted context omitted.

> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !

With s3, you cannot use ls, grep and other tools. > Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Wow that's a lot to learn before using s3... I wonder how much it costs in salaries. > With what network topology? You don't need to care about this when using SSDs/HDDs. > With what ac…

I mean you can easily mount the S3 bucket to the local filesystem (e.g. using s3fs-fuse) and then use standard command line tools such as ls and grep.

Re: We saved $500k per year by rolling our own "S3"

#17
post #4

I'm curious how many engineers per year this costs to maintain

A small fraction of 1, probably? It sounds like a fairly simple service that shouldn't require much ongoing development

You're going to run a production system with a bus number of 1?

I think you mean a small fraction of 3 engineers. And small fractions aren't that small.

Re: We saved $500k per year by rolling our own "S3"

#18
post #4

I'm curious how many engineers per year this costs to maintain

Yes, that was my thought as well. Breakeven might be like 1 (give or take 2x)?

Anything worth doing needs three people. Even if they also are used for other things.

Re: We saved $500k per year by rolling our own "S3"

#19
post #4

I'm curious how many engineers per year this costs to maintain

A small fraction of 1, probably? It sounds like a fairly simple service that shouldn't require much ongoing development

Especially if you have access to LLMs.
Post reply on HN