Classic case of "focus on building your app, not infrastructure". Here's another multi-million dollar idea: put this cache directly inside your own video processing server and upload there.
We saved $500k per year by rolling our own "S3"
201–210 of 261 posts
Re: We saved $500k per year by rolling our own "S3"
#202Earlier quoted context omitted.
It's the verbose writing style. I can see why you would be accused as well.
going to my last page of comments at this time https://news.ycombinator.com/threads?id=bryanrasmussen I have 4 comments of more than 3 sentences and 3 comments of 2 or 3 sentences and 5 comments of 1 sentence. The sentences were generally pretty short.
Verbosity isn't just about the length of your comments. It's about using more words than necessary. Sometimes a 'yes' is enough instead of two sentences. It just seems that you like to express your thought process in words. It's not a critique on your writing style it's just a trait that your writing sharea with LLMs.
Re: We saved $500k per year by rolling our own "S3"
#203Tbh I feel this in one of those that would be significantly cleaner without serverless in first place. Sticking something with 2 second lifespan on disk to shoehorn it into aws serverless paradigm created problems and cost out of thin air here Good solution moving at least partially to a in memory solution though
Yeah, so now you're basically running a heavy instance in order to get the network throughput and the RAM, but not really using that much CPU when you could probably handle the encode with the available headroom. Although the article lists TLS handshakes as being a significant source of CPU usage, I must be missing something because I don't see how that is anywhere near the top of the constraints of a system like thi…
TLS being a bottleneck when doing image processing is very-very weird.
Re: We saved $500k per year by rolling our own "S3"
#204What a great and helpful write-up, love when people share things like this so I can learn.
It's less about whether I would have a use case for this exact thing (or whether or not it was appropriate for this use case, i dunno, prob don't have enough context to know).
More just seeing what is possible, how they thought about it and analyzed it, what they found unexpected and how, etc. I learned a lot!
Re: We saved $500k per year by rolling our own "S3"
#205In HN style, I'm going to diverge from the content and rant about the company: Nanit needs this storage because they run cloud based baby cameras. Every Nanit user is uploading video and audio of their home/baby live to Nanit without any E2EE. It's a hot mic sending anything you say near it to the cloud. Their hardware essentially requires a subscription to use, even though it costs $200/camera. You must spend an add…
> You must spend an additional $200 on a Nanit floor stand if you want sleep tracking. This is purely a software limitation since there's plenty of other ways to get an overhead camera mount. (I'm curious how they even detect if you're using the stand since it's just a USB-C cable. Maybe etags?)
I made a simple wood mount and painted it to match the crib. It worked well. There was no software enforcement requiring you to buy their mount at the time. Has this changed recently?
Re: We saved $500k per year by rolling our own "S3"
#206Earlier quoted context omitted.
He missed the opportunity to mention the reverse proxy, firewall with geo blocking, VPS and WireGuard, Grafana and Loki setup.
You joke but wireguard and, very easily, tailscale, solves most crap you normally need to fix. Close everything with ufw and put tailscale, and then you trivially have access from any device / desktop.
"and you trivially have access from any device / desktop"
My definition of "trivial" seems to be different.
Re: We saved $500k per year by rolling our own "S3"
#207They didn’t actually do what the headline claims. They made a memory cache which sits in front of S3 for the happy path. Cool but not nearly rolling your own S3
True, but, if i'm following, the memory cache has to clone S3 API for existing clients that can't be easily altered. Regardless of what you title it, it's an interesting project report!
Re: We saved $500k per year by rolling our own "S3"
#208Earlier quoted context omitted.
What do you see about this comment that seems particularly LLM generated?
LLMs are incredibly prone towards producing examples and reasons in groups of 3, in an A, B, C pattern. The comment in question does so almost every paragraph. > We found that implementing proper data durability (3+ replicas, corruption detection, automatic repair) > The engineering time spent building and maintaining custom tooling for multi-region replication, access controls, and monitoring ended And so on. On top…
When I’m giving examples I also aim to give three if at all practical. Language generally flows more naturally that way.
Re: We saved $500k per year by rolling our own "S3"
#209Earlier quoted context omitted.
The "point" of the cloud service is that it's sadly usually the easiest way to create a [on-premise-device] [user's smartphone/laptop] for B2C/residential deployments of appliances (like the baby monitor in this case). It's much easier to create a device internet connection + a smartphone internet connection that it is to deal with the myriad of issues that occur if you try to do local device smartphone connections i…
Why is it hard for a local device to expose a REST API from home —a DDNS updater could update IP address for a cname — and then access all the local data local_device(REST API) Smartphone?
I would imagine these were the reasons:
- most people want to build lovely structures in the cloud, as it's hard to fix bugs in software on devices
- you'd need to open up a firewall on the home router
- auth might be tricky
- can't bolt on value added "enhancements"
Re: We saved $500k per year by rolling our own "S3"
#210So, you want a place to store many files in a short period of time and when there's a new file, somebody must be notified? Have you ever thought of using a postgresql db (also on aws) to store those files and use CDC to publish messages about those files to a kafka topic? In your original way, we need 3 aws services: s3, lambda and sqs. With this way, we need 2: postgresql and kafka. I'm not sure how well this method…
Like put the video blobs themselves in postgres data columns? Does putting very large (relative to what you normally put in postgres) files in pg work well? Genuine question, i do not know, I've been considering it too and hesitant about it.