In 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 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?)
Of course Nanit is a popular and successful product that many parents swear by. It just pains me to see cloud based in-home audio/video storage being so normalized. Self-hosted video isn't that hard but no one makes a baby-monitor centric solution. I'm sure the cloud based video storage model will continue to be popular because it's easy, but also because it helps justifies a recurring subscription.
edit: just noticed an irony in my comment. I'm ranting about Nanit locking users into their 3rd party cloud video storage, and the article is about Nanit's engineering team moving off a 3rd party (S3) and self-hosting their own storage. Props to them for getting off S3.
As a happy customer, I picked nanit because it actually worked. We didn’t even use the “smart” features, but “you can turn on the app from anywhere you happen to be and expect the video feed to work” is unfortunately a bar that no competitor I tried could meet. The others were mostly made by non-software companies with outsourced apps that worked maybe 50% of the time.
I wish we could have local-first and e2ee consumer software for this sort of thing, but given the choice of that or actually usable software, I am going to pick the latter.
I self host my "baby monitor" with UniFi Protect on UCG-Max and a G6 Instant wireless camera. It's more work to setup, but pretty easy for a techie. It has the "turn on the app anywhere and it works" feature, and with a 2TB SSD I get a month+ of video storage. Because storage is local, it doesn't need to compress the video and I get a super clear 4K image. And I use Homebridge to expose the camera over Apple HomeKit which is a convenient and a more user friendly way to access it. And HomeKit also gives you out-of-home access with a hub. I love my setup, but I couldn't in good conscience recommend it to a non-techie friend, especially if they're sleep deprived from their infant.
But I do miss the lack of any baby-specific features like sleep tracking. It has support for crying detection, but that's it.
It's pretty cool! But homebridge is another service to run in a Docker container.. so even less user friendly. But it's definitely the primary way everyone that's not me accesses the baby camera. The out-of-home access requires a "HomeKit Hub" which can just be an Apple TV that's always plugged in. And HomeKit also has "HomeKit Secure Video" feature which is cloud based video storage, but with E2EE. But don't recommend their video storage really.
Alternatively you can setup a vpn with rules that automatically enable vpn when you try to connect to specific addresses. Works with Tailscale and on-demand VPN for me. This will work with any IP webcam.
My £15 TP-Link camera that we use as a baby monitor works 100% of the time. I can use it completely locally too with nothing sent to their servers at all, or use it through the internet if I want to. Got 4+ years of continuous use and counting, with zero issues.
What competitor have you actually tried? My girlfriend’s parents have a few cheap TPlink solar powered CCTV and they work flawlessly since setup. I used to jerryrig an Android phone for Alfred and that too worked well.
I tried a high end Philips one and a Nest camera. Both were way less reliable than the Nanit. Possibly because they didn’t play nicely with my mesh WiFi at home. But regardless I just wanted to vouch for Nanit’s software, whatever they are doing with their networking and UX is really good.
Their networking is awful in my experience. The WiFi chip is cheap crap, extremely sensitive, cuts out a lot, and doesn’t support WPA3.
I had to set up a dedicated Nanit-only AP in my house in order to stabilize the connection. It would not work any other way, tried many different configurations, even other APs.
I have 2 free-roaming rabbits in one room of the house, we've been using Eufy camera to access live feed and found no issues with it, definitely would buy again. And the SD card recording allows us to seek a couple days into the past - it is pretty fun to watch the rabbits scramble to the automatic feeder at the set time.
The vtech camera is working well enough for me for what it’s worth. But any such app solution generally implies transfer through the company’s servers.
Yeah that’s fair, we had one of those too which absolutely did everything it advertised. The nanit is a different product that doubles as a home camera that lets you monitor your home while you’re away. Its software/networking is impressively reliable.
> 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.
Your way of phrasing it makes it sound like it would be fine to upload the video if it were end-to-end-encrypted. I think this is worth clarifying (since many don’t really understand the E2EE trade-off): E2EE is for smart clients that do all the processing, plus dumb servers that are only used for blind routing and storage. In this instance, it sounds like Nanit aren’t doing any routing or (persistent) storage: the sole purpose of the upload is offloading processing to the cloud. Given that, you can have transport encryption (typically TLS), but end-to-end encryption is not possible.
If you wanted the same functionality with end-to-end encryption, you’d need to do the video analysis locally, and upload the results, instead of uploading the entire video. This would presumably require more powerful hardware, or some way of offloading that to a nominated computer or phone.
Technically there are two clients: The camera and whatever device is used to access the feed.
I can absolutely imagine an architecture where video can be streamed in an encrypted manner, or stored in encrypted time-stamped blobs, allowing the server to provide rough searching, and then the client can perform fine-grained scanning.
This obviously doesn't enable any kind of processing of the video data on the server side, and doing it on the receiving client would require the feed to be active This means that any kind of processing would almost necessarily have to happen on the sending device, which would probably increase the power and compute requirements by a lot.
No, this doesn't get at the point of end-to-end encryption. Better to look at it in terms of the parties involved -- E2EE implies that there are two or more parties, and that only some of those parties should have unencrypted access.
In the case in point, the parent (camera owner) is one party and Nanit is another party. (Prior to the work in the linked post, AWS S3 was another party). The goal of E2EE is to deny plaintext access to some of these parties. So, in an E2EE deployment, Nanit (and AWS) would not have unencrypted access to the video content, even though they're storing it.
As chrismorgan pointed out, if Nanit did not have access to the unencrypted data, they could not do server-side video processing.
(Also, FWIW, there are multiple clients in this scenario -- the parents' phones are clients, and need unencrypted access to the video stream.)
(As an aside, where I used to work, we did some cool stuff with granting conditional access to certain server-side subsystems, so that the general data flow was all end-to-end encrypted, but customers could allow certain of our processes to be "ends" and have key access. This was really elegant; customers could dial in the level of server-side access that we had, and could see via the key authorization metadata which services had that access.)
I actually don’t really get the point of a cloud service for this. Aren’t babies usually left in situations where there’s at least one trusted adult locally available?
Yeah but the reality of the microSD card is weird. E.g. Eufy puts the video on the card but encrypts it so you have to pull it through the camera through the app to your phone.
It's hilariously crazy but we were given the cams as a gift so we stuck with them.
My parents bought a camcorder in 1995 and "self-hosted" the video just fine. But you're right it shouldn't even be something consumers should consider, because it should be the default and should be easy. You can get low power SSD-powered NAS devices now so hopefully this will change soon.
The baby monitor could have its own SD card and webserver and then you provide a smartphone app which uses local network discovery to find the server and talk to it.
In that case no parent needs to know about Synology or even IP addresses.
There is no technical requirement for an easy-to-use baby monitor to be cloud-connected. If there is no easy-to-use baby monitor which is not cloud-connected, that is a market problem, not a technical problem.
It's more that a typical parent has not thought of the need to have a baby monitor, until they have a baby (in which case, they're too busy to build out their own baby monitor stack).
Pay money to solve a problem and time-save as a parent is a valid business idea/strategy. The externalities that the parents might suffer if these businesses do not completely adhere to good security practices don't seem to come back to bite them (and most parents get lucky and not have any bad consequences - yet).
We've used an offline Infant Optics baby camera for three kids and have never wished for any of the smart features that online cameras offer. You really just want to know whether they are asleep and when they are crying. I just don't see a good use case for recording all that video for most kids. (I'm sure there are special needs situations where it is helpful)
We just used ipcams with our kids. Now with ubiquity it is dead simple to setup also storage for it. I think synology supports anything that emits rtsp.
Baby monitors around here -Alecto is a popular brand - cost twice as much and have only half the capabilities.
Of course you don't _need_ it, but it's a useful convenience. Due to the layout of our house it was quite hard to hear my toddler if he was crying in the middle of the night - we often wouldn't wake up to it. So the monitor was very helpful.
Why on earth do you need an app and a camera? The same basic VTech audio monitors that are basically the same for many decades now work great, don't cost a fortune and there's no question of "where is this data going?" It's all just a big cash grab for people who need chincy tech toys for a non-problem that's better solved with way more simple kit.
I used to work with my laptop, sitting near my baby. Also, I used a timer to follow 45m sleep patterns, so technically there’s no need to react to anything within first 45m, but most times first 1h30m (45+45m).
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 this.
Regardless, I enjoyed the article and I appreciate that people are still finding ways to build systems tailored to their workflows.
They 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
My first thought is, why bother with local storage if your turnaround on video chunks is 2 seconds? What's disk going to add besides a little bit more resiliency in that 2 second time frame? This at the cost of having slower pod startups given you have to mount the PVC, and a small performance hit of writing to a filesystem instead of memory.
All moot anyway given that the cameras/proxy allegedly has retries built-in, but interested to hear your thoughts.
I suspect it's a massive amount, as S3 is one of the cheaper services. As we evaluate moving all of our compute off of AWS, S3 (and SQS) are probably services we'll retain because they are still amazing values.
This feels like they were using the wrong architecture from the start, and are now papering over that problem with additional layers of cache.
The only practical reason to put a video in S3 for an average of 2 seconds is to provide additional redundancy, and replacing that with a cache removes most of the redundancy.
Feels like if you uploaded these to an actual server, the server could process them on upload, and you could eliminate S3, the queue in SQS, and the lambdas all in one fell swoop...
> I'm curious how many engineers per year this costs to maintain
The end of the article has this:
> Consider custom infrastructure when you have both: sufficient scale for meaningful cost savings, and specific constraints that enable a simple solution. The engineering effort to build and maintain your system must be less than the infrastructure costs it eliminates. In our case, specific requirements (ephemeral storage, loss tolerance, S3 fallback) let us build something simple enough that maintenance costs stay low. Without both factors, stick with managed services.
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() !
> 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.
>> No risk of leaking files due to misconfigured cloud services.
> One misconfigured .htaccess file for example, could result in leaking files.
I don't think you are making a compelling case here, since both scenarios result in an undesirable exposure. Unless your point is both cloud services and local file systems can be equally exploited?
It sounds like you’re not at the scale where cloud storage is obviously useful. By the time you definitely need S3/GCS you have problems making sure files are accessible everywhere. “Grep” is a ludicrous proposition against large blob stores
I inherited an S3 bucket where hundreds of thousands of files were written to the bucket root. Every filename was just a uuid. ls might work after waiting to page though to get every file. To grep you would need to download 5 TB.
It's probably going to be dog slow. I dealt with HDDs where just iterating through all files and directories takes hours, and network storage is going to be even slower at this scale.
>> Without cloud, saving a file is as simple as "with open(...) as f: f.write(data)" + adding a record to DB.
> 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...
Most of these concerns can be addressed with ZFS[0] provided by FreeBSD systems hosted in triple-A data centers.
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.
Bro were you off grid last week. Your questions equally apply to AWS, you just magically handwave away all those questions as if AWS/GCP/Azure outages aren’t a thing.
Ah that is where logging and traceability comes in! But not to worry, the cloud has excellent tools for that! The fact that logging and tracing will become half your cloud cost, oh well let's just sweep that under the rug.
> 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.
There may be some additional features that S3 has over a direct filesystem write to a SSD in your closet. The people paying for cloud spend are paying for those features.
What I notice, that large companies use their own private cloud and datacenters. At their scale, it is cheaper to have their own storage. As a side business, they also sell cloud services themselves. And small companies probably don't have that much data to justify paying for a cloud instead of buying several SSDs/HDDs or creating SMB share on their Windows server.
I’m sufficiently old / sensible (you decide) to think that uploading video of your baby (to anywhere) is fucking weird and fucking spooky and not needed anyway. This is a solution that doesn’t have a problem. Worse: it prays on parental / young parental fears. There’s nothing here - this is not a product that’s needed. You don’t need to “track” your baby, ffs. You don’t need to watch it while it sleeps. You don’t need “every breath, seen”. People have been having babies for fucking centuries without entering them into this hyper weird surveillance state at birth.
What an appalling screwed up world we seem to have manufactured for ourselves.
Of all the hills to die on w.r.t. how the world is screwed up, this seems like the silliest.
Different folks parent differently, culture evolves. You're free to have your "old school" thoughts as are people who use services like this.
Its not like they're publishing it in public. The service in discussion especially just stores it in the server only temporarily to use ML to detect things such as sleeping or crying. Sounds innocuous to me.
Many of us can do the math ourselves and choose to make choices based on our own beliefs. That's true freedom.
> Different folks parent differently, culture evolves.
You are framing it as if every change is in a positive direction, which it clearly isn't. Risking at sounding like an old man yelling at clouds, look at the kids these days. They are so dependent, and so sensitive to negative stimuli or emotions.
Parents need to realise that they need to grow adults, not perpetual kids.
> look at the kids these days. They are so dependent, and so sensitive to negative stimuli or emotions.
I think many of us have found people writing comments like this are not interacting with children very much. More just reading the takes of others who also don't interact with children.
And if this was a legitimate problem to address, you would not address it by taking away baby monitors.
The topic of the conversation widened a bit from baby monitors. I of course do not advocate that taking away baby monitors will fix our dilapidated societies.
And while it is certainly true that I don't interact with young children a lot, the case is different for older ones or "young adults".
So, 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 works though :-)
S3 certainly saves a lot of hassle, but in certain use cases, it really is prohibitively expensive.
Has anyone tried self-hosted alternatives like MinIO or SeaweedFS? Or taken even more radical approaches?
How do you balance between stability, maintenance overhead, and cost savings?
MinIO has moved away from having a free community fork, and I think it's base cost is close to $100k a year. I've been using Garage and been happy, but as a single dev and orders of magnitude smaller than the OP, so there are certainly edge cases I'm missing to compare the two.
I'm a fellow new Garage user. I have had a great time so far - but I also don't need much. My use case is to share data analysis results with a small team. I wanted something simple to manage that can provide an s3 like interface to work with off the shelf data analysis tools.
Their architecture is internet bandwidth heavy and storage heavy; these are some of the most expensive things in AWS. You probably want to use a different provider for those things.
> It turns out that when AWS says an instance can do “Up to 12.5 Gbps”, that’s burstable networking backed by credits; when you’re below the baseline, you accrue credits and can burst for short periods.
Yes, AWS has a burst rating and a sustained/baseline rating for both EBS types as well as instance types. Use https://instances.vantage.sh/ (and make sure you choose specific columns) to compare specific criteria and then export as a CSV to find the lowest price that matches your performance/feature/platform criteria. Design to the baseline if you need guaranteed performance. Do sustained performance testing.
> When we Terminated connections idle >10 minutes, memory dropped by ~1 GB immediately; confirming the leak was from dangling sockets. Fix: make sockets short-lived and enforce time limits.
We used to do that with Apache 20 years ago. Config option forces a forked subchild to exit after N requests to avoid the inevitable memory leaks. AKA the Windows 95 garbage collector (a reboot a day keeps the slowness at bay).
FWIW, if the business feasibility of your architecture depends on custom stuff, performance enhancements, etc, you will find that you eventually have harder and harder problems to solve to keep your business functioning. It's more reliable to waste money on a solution that is brainless, than invest human ingenuity/technical mastery in a solution that is frugal.
They're very ingest heavy compared to how much of it is actually streamed out and to a very small/local audience so probably don't even need a cdn. And ingest on aws is free.
On the other hand, S3 is kind of ridiculously expensive compared to even more expensive on-prem options like a PureStorage SSDs array. With spindles on Ceph you can probably get quite a bit lower than AWS's 2c/Gig/mo. Or you can just use R2 with colocated servers for ingest.
Video processing is one of those things that need caution when doing serverlessly. This solution makes sense, especially because S3s durability guarantees aren't needed.
Having gone through S3 cost optimization ourselves, I want to share some important nuances around this approach. While the raw storage costs can look attractive, there are hidden operational costs to consider:
We found that implementing proper data durability (3+ replicas, corruption detection, automatic repair) added ~40% overhead to our initial estimates. The engineering time spent building and maintaining custom tooling for multi-region replication, access controls, and monitoring ended up being substantial - about 1.5 FTE over 18 months.
For high-throughput workloads (>500 req/s), we actually saw better cost efficiency with S3 due to their economies of scale on bandwidth. The breakeven point seems to be around 100-200TB of relatively static data with predictable access patterns. Below that, the operational overhead of running your own storage likely exceeds S3's markup.
The key is to be really honest about your use case. Are you truly at scale? Do you have the engineering resources to build AND maintain this long-term? Sometimes paying the AWS premium is worth it for the operational simplicity.
Right. Having worked on a commercial S3 compatible storage I can tell y'all that there's a lot more to it then just sticking some files on JBOD. It does depend on your specific requirements though. 1.5 FTE over 18 months sounds on the low side for everything you've described.
That said the article seems to be more about an optimization of their pipeline to reduce the S3 usage by holding some objects in memory instead. That's very different than trying to build your own object store to replace S3.
Why do all your comments seem LLM generated? You do clearly have something to contribute, but it’s probably better to just write what you’re talking about than going through a LLM.
They do not have anything to contribute. It's all made up.
> Having worked extensively with battery systems, I think the grid storage potential of second-life EV batteries is more complex than it appears
> Having worked extensively with computer vision models for our interview analysis system,
> Having dealt with similar high-stakes outages in travel tech, the root cause here seems to be their dependency
> Having gone through S3 cost optimization ourselves,
> The surgical metaphor really resonates with my experience building real-time interview analysis systems
The sad news is that very soon it will be slightly less obvious and then when I call them out just like now I'll be slapped by dang et. al with such accusations being against the HN guidelines. Right now most, like this one, don't care enough so it's still beyond doubt to an extent where that doesn't happen.
Unfortunately they're clearly already good enough to fool you and many here.
I don't know about the commenter specifically but in general, using LLMs to format text is a game changer in the ability for English-as-Second-Language folks to contribute to tech conversations. While I get where some of the bias against anything LLM generated comes from, I would keep it for editorial content and not community comments to be fair to a global audience.
I’m worried that LLMs could facilitate cheap, scaled astroturfing.
I understand that people encounter discrimination based on English skill, and it makes sense that people will use LLMs to help with that, especially in a professional context. On the other hand, I’d instinctively be more trusting of the authenticity of a comment with some language errors than one that reads like it was generated by ChatGPT.
I tried that, but you end up sounding so bland and generic. It feels like the textual equivalent of the Corporate Memphis art style. I'm comfortable doing this at work because I exist outside of slack/emails, but in here I am what I write. If I delegate this to a LLM, then I do not exist anymore.
What I found useful is to use LLMs as a fuzzy near-synonym search engine. "Sad, but with a note of nostalgia", for example. It's a slower process, which in itself isn't bad.
I’m not sure if that’s a realistic ask. There is ample abuse of LLM generated content, and there are plenty of ESL publishers.
Personally I would recommend including a note that English is not your native language and you had an LLM clean things up. I think people are willing to give quite a bit of grace, if it’s disclosed.
Personally, I’d rather see a response in your native language with a translation, but I’m fairly certain I’m the odd one out in that situation XD
This commenter is making everything up and a 3 second look at their profile puts this beyond any doubt. Regardless, the benefit of the doubt should no longer be given. Too bad for my fellow ESLers, I'm one myself, but we better get just writing in English. It's already a daily occurrence now to see these bots on HN.
It just makes everything sound bland and soulless. You don't know which part of the message actually comes from the user's brain and which part has been added/suggested by the LLM. The latter is not an original thought and it would be disingenuous to include it, but people do because it makes them look smarter. Meanwhile, on the other side, you might as well be talking to a LLM...
> For high-throughput workloads (>500 req/s), we actually saw better cost efficiency with S3 due to their economies of scale on bandwidth. The breakeven point seems to be around 100-200TB of relatively static data with predictable access patterns. Below that, the operational overhead of running your own storage likely exceeds S3's markup.
I just spent 5 minutes reading this over and over, but it still doesn't make any sense to me. First it says that high throughput = s3, low throughput = self hosted. Then it says low throughput = s3, (therefore high throughput = self hosted).
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 of this a 5 second look at the profile confirms that it's a bot.
They're using a very structured and detailed prompt. The upside of that for them is that their comment looks much more "HN-natural" than 99% of LLM comments on here. The downside is that their comments look even much more similar to each other than other bots, which display more variety. That's the tradeoff they're making. Other bots' comments are much more obviously sloppy, but there's more variety across their different comments.
I wondered myself, as it seemed ok, but I went through the poster's history as I was interested.
Firstly, they have a remarkably consistent style. Everything is like this. There's not very many examples to choose from, so that's maybe also to be expected, and perhaps it is just also their personality.
I worry, as I've been accused myself, that there is perhaps something in the style the accuser dislikes or finds off-putting and nowadays the suspected cause will be LLM.
Secondly, they have "extensive experience" in various areas of technology, that don't seem to be especially related to each other. I too have extensive experience in several areas of technology but there is something of a connector between them.
Perhaps it is just because of their high level of technical expertise that they have managed to move between these areas and gain this extensive experience. And because of the high level of technical expertise and their interest in only saying very technical things all the time, their communications seem less varying and human, and more LLM.
There are more options than using S3 or completely rolling your own on JBOD. For example, you could use a cheaper S3-compatible cloud (such as Backblaze) or you can deploy a project such as Ceph.
S3 does more than 3x replica durability, as well, they use a form of erasure coding. They can lose several hard drives/servers/racks before your data becomes at risk, and have sufficient spare capacity to very quickly reproduce any missing shards before things become a problem.
That said, S3 seems like a really odd fit for their workload, plus their dependency on lifecycle rules seems utterly bizarre.
> Storage was a secondary tax. Even when processing finished in ~2 s, Lifecycle deletes meant paying for ~24 h of storage.
They decided not to implement the deletion logic in their service, so they'd just leave files sitting around for hours instead needlessly paying that storage cost? I wonder how much money they'd have saved if they just added that deletion logic.
I’m mostly just impressed that some janky baby monitor has racked up server fees on this scale. Amazing example of absolutely horrible engineering.
Also, just take an old phone from your drawer full of old phones, slap some free camera app on it, zip tie a car phone mount to the crib, and boom you have a free baby monitor.
I mean the "S3" could be replaced with object storage. I guess thats the technical term anyway. Having said that just goes to show how cheap S3 is, if after all of this, the savings are just $500k. Definitely money saved but not a lot.
Storing the data in a foreign cloud would allow foreign nation to play funny tricks on the country. What they need is not the cloud but sane backup system.
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 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?)
Of course Nanit is a popular and successful product that many parents swear by. It just pains me to see cloud based in-home audio/video storage being so normalized. Self-hosted video isn't that hard but no one makes a baby-monitor centric solution. I'm sure the cloud based video storage model will continue to be popular because it's easy, but also because it helps justifies a recurring subscription.
edit: just noticed an irony in my comment. I'm ranting about Nanit locking users into their 3rd party cloud video storage, and the article is about Nanit's engineering team moving off a 3rd party (S3) and self-hosting their own storage. Props to them for getting off S3.
I wish we could have local-first and e2ee consumer software for this sort of thing, but given the choice of that or actually usable software, I am going to pick the latter.
But I do miss the lack of any baby-specific features like sleep tracking. It has support for crying detection, but that's it.
My impression is live feed is a solved problem.
I had to set up a dedicated Nanit-only AP in my house in order to stabilize the connection. It would not work any other way, tried many different configurations, even other APs.
Your way of phrasing it makes it sound like it would be fine to upload the video if it were end-to-end-encrypted. I think this is worth clarifying (since many don’t really understand the E2EE trade-off): E2EE is for smart clients that do all the processing, plus dumb servers that are only used for blind routing and storage. In this instance, it sounds like Nanit aren’t doing any routing or (persistent) storage: the sole purpose of the upload is offloading processing to the cloud. Given that, you can have transport encryption (typically TLS), but end-to-end encryption is not possible.
If you wanted the same functionality with end-to-end encryption, you’d need to do the video analysis locally, and upload the results, instead of uploading the entire video. This would presumably require more powerful hardware, or some way of offloading that to a nominated computer or phone.
In the case of this product, there is only one client (and a server).
E2EE bills then down to having the traffic encrypted like you have with a https website.
I can absolutely imagine an architecture where video can be streamed in an encrypted manner, or stored in encrypted time-stamped blobs, allowing the server to provide rough searching, and then the client can perform fine-grained scanning.
This obviously doesn't enable any kind of processing of the video data on the server side, and doing it on the receiving client would require the feed to be active This means that any kind of processing would almost necessarily have to happen on the sending device, which would probably increase the power and compute requirements by a lot.
In the case in point, the parent (camera owner) is one party and Nanit is another party. (Prior to the work in the linked post, AWS S3 was another party). The goal of E2EE is to deny plaintext access to some of these parties. So, in an E2EE deployment, Nanit (and AWS) would not have unencrypted access to the video content, even though they're storing it.
As chrismorgan pointed out, if Nanit did not have access to the unencrypted data, they could not do server-side video processing.
(Also, FWIW, there are multiple clients in this scenario -- the parents' phones are clients, and need unencrypted access to the video stream.)
(As an aside, where I used to work, we did some cool stuff with granting conditional access to certain server-side subsystems, so that the general data flow was all end-to-end encrypted, but customers could allow certain of our processes to be "ends" and have key access. This was really elegant; customers could dial in the level of server-side access that we had, and could see via the key authorization metadata which services had that access.)
That’s not what most people expect though.
Self-hosting video is not something the typical user of a baby monitor would ever even consider.
From the product description though it sounds like sleep analysis is what you're paying for, which they do on servers analyzing the video.
It's hilariously crazy but we were given the cams as a gift so we stuck with them.
I'm not leaving a baby at home while I go on vacation. I would never be on another network, even. Why need the cloud?
The typical parent has never heard of Synology or Ubiquiti, doesn’t have a NAS, and gets whatever tech their ISP gave/rents them.
In that case no parent needs to know about Synology or even IP addresses.
Pay money to solve a problem and time-save as a parent is a valid business idea/strategy. The externalities that the parents might suffer if these businesses do not completely adhere to good security practices don't seem to come back to bite them (and most parents get lucky and not have any bad consequences - yet).
I don't understand this attitude, sure its easy for some people but MOST people want an easy out of the box solution
its nothing wrong with that
Baby monitors around here -Alecto is a popular brand - cost twice as much and have only half the capabilities.
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
Regardless, I enjoyed the article and I appreciate that people are still finding ways to build systems tailored to their workflows.
My first thought is, why bother with local storage if your turnaround on video chunks is 2 seconds? What's disk going to add besides a little bit more resiliency in that 2 second time frame? This at the cost of having slower pod startups given you have to mount the PVC, and a small performance hit of writing to a filesystem instead of memory.
All moot anyway given that the cameras/proxy allegedly has retries built-in, but interested to hear your thoughts.
The only practical reason to put a video in S3 for an average of 2 seconds is to provide additional redundancy, and replacing that with a cache removes most of the redundancy.
Feels like if you uploaded these to an actual server, the server could process them on upload, and you could eliminate S3, the queue in SQS, and the lambdas all in one fell swoop...
> We used S3 even though it wasn’t the right service
The end of the article has this:
> Consider custom infrastructure when you have both: sufficient scale for meaningful cost savings, and specific constraints that enable a simple solution. The engineering effort to build and maintain your system must be less than the infrastructure costs it eliminates. In our case, specific requirements (ephemeral storage, loss tolerance, S3 fallback) let us build something simple enough that maintenance costs stay low. Without both factors, stick with managed services.
Seems they were well aware of the tradeoffs.
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.
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() !
> 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.
You do need to care when you move beyond a single server in a closet that runs your database, webserver and storage.
> No risk of leaking files due to misconfigured cloud services.
One misconfigured .htaccess file for example, could result in leaking files.
First, I hope nobody is using Apache anymore, second, you typically store files outside of web directory.
> One misconfigured .htaccess file for example, could result in leaking files.
I don't think you are making a compelling case here, since both scenarios result in an undesirable exposure. Unless your point is both cloud services and local file systems can be equally exploited?
> 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...
Most of these concerns can be addressed with ZFS[0] provided by FreeBSD systems hosted in triple-A data centers.
See also iSCSI[1].
0 - https://docs.freebsd.org/en/books/handbook/zfs/
1 - https://en.wikipedia.org/wiki/ISCSI
There may be some additional features that S3 has over a direct filesystem write to a SSD in your closet. The people paying for cloud spend are paying for those features.
Question: How do you save a small fortune in cloud savings?
Answer: First start with a large fortune.
I think you mean a small fraction of 3 engineers. And small fractions aren't that small.
What an appalling screwed up world we seem to have manufactured for ourselves.
Different folks parent differently, culture evolves. You're free to have your "old school" thoughts as are people who use services like this.
Its not like they're publishing it in public. The service in discussion especially just stores it in the server only temporarily to use ML to detect things such as sleeping or crying. Sounds innocuous to me.
Many of us can do the math ourselves and choose to make choices based on our own beliefs. That's true freedom.
You are framing it as if every change is in a positive direction, which it clearly isn't. Risking at sounding like an old man yelling at clouds, look at the kids these days. They are so dependent, and so sensitive to negative stimuli or emotions.
Parents need to realise that they need to grow adults, not perpetual kids.
I think many of us have found people writing comments like this are not interacting with children very much. More just reading the takes of others who also don't interact with children.
And if this was a legitimate problem to address, you would not address it by taking away baby monitors.
And while it is certainly true that I don't interact with young children a lot, the case is different for older ones or "young adults".
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 works though :-)
We could just use something like that
Or there is that other Object storage solution called R1 from Cloudflare.
just sounded less attractive
> It turns out that when AWS says an instance can do “Up to 12.5 Gbps”, that’s burstable networking backed by credits; when you’re below the baseline, you accrue credits and can burst for short periods.
Yes, AWS has a burst rating and a sustained/baseline rating for both EBS types as well as instance types. Use https://instances.vantage.sh/ (and make sure you choose specific columns) to compare specific criteria and then export as a CSV to find the lowest price that matches your performance/feature/platform criteria. Design to the baseline if you need guaranteed performance. Do sustained performance testing.
> When we Terminated connections idle >10 minutes, memory dropped by ~1 GB immediately; confirming the leak was from dangling sockets. Fix: make sockets short-lived and enforce time limits.
We used to do that with Apache 20 years ago. Config option forces a forked subchild to exit after N requests to avoid the inevitable memory leaks. AKA the Windows 95 garbage collector (a reboot a day keeps the slowness at bay).
FWIW, if the business feasibility of your architecture depends on custom stuff, performance enhancements, etc, you will find that you eventually have harder and harder problems to solve to keep your business functioning. It's more reliable to waste money on a solution that is brainless, than invest human ingenuity/technical mastery in a solution that is frugal.
On the other hand, S3 is kind of ridiculously expensive compared to even more expensive on-prem options like a PureStorage SSDs array. With spindles on Ceph you can probably get quite a bit lower than AWS's 2c/Gig/mo. Or you can just use R2 with colocated servers for ingest.
We found that implementing proper data durability (3+ replicas, corruption detection, automatic repair) added ~40% overhead to our initial estimates. The engineering time spent building and maintaining custom tooling for multi-region replication, access controls, and monitoring ended up being substantial - about 1.5 FTE over 18 months.
For high-throughput workloads (>500 req/s), we actually saw better cost efficiency with S3 due to their economies of scale on bandwidth. The breakeven point seems to be around 100-200TB of relatively static data with predictable access patterns. Below that, the operational overhead of running your own storage likely exceeds S3's markup.
The key is to be really honest about your use case. Are you truly at scale? Do you have the engineering resources to build AND maintain this long-term? Sometimes paying the AWS premium is worth it for the operational simplicity.
That said the article seems to be more about an optimization of their pipeline to reduce the S3 usage by holding some objects in memory instead. That's very different than trying to build your own object store to replace S3.
> Having worked extensively with battery systems, I think the grid storage potential of second-life EV batteries is more complex than it appears
> Having worked extensively with computer vision models for our interview analysis system,
> Having dealt with similar high-stakes outages in travel tech, the root cause here seems to be their dependency
> Having gone through S3 cost optimization ourselves,
> The surgical metaphor really resonates with my experience building real-time interview analysis systems
The sad news is that very soon it will be slightly less obvious and then when I call them out just like now I'll be slapped by dang et. al with such accusations being against the HN guidelines. Right now most, like this one, don't care enough so it's still beyond doubt to an extent where that doesn't happen.
Unfortunately they're clearly already good enough to fool you and many here.
But yeah this won’t make it any easier.
I understand that people encounter discrimination based on English skill, and it makes sense that people will use LLMs to help with that, especially in a professional context. On the other hand, I’d instinctively be more trusting of the authenticity of a comment with some language errors than one that reads like it was generated by ChatGPT.
What I found useful is to use LLMs as a fuzzy near-synonym search engine. "Sad, but with a note of nostalgia", for example. It's a slower process, which in itself isn't bad.
Personally I would recommend including a note that English is not your native language and you had an LLM clean things up. I think people are willing to give quite a bit of grace, if it’s disclosed.
Personally, I’d rather see a response in your native language with a translation, but I’m fairly certain I’m the odd one out in that situation XD
I just spent 5 minutes reading this over and over, but it still doesn't make any sense to me. First it says that high throughput = s3, low throughput = self hosted. Then it says low throughput = s3, (therefore high throughput = self hosted).
> 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 of this a 5 second look at the profile confirms that it's a bot.
They're using a very structured and detailed prompt. The upside of that for them is that their comment looks much more "HN-natural" than 99% of LLM comments on here. The downside is that their comments look even much more similar to each other than other bots, which display more variety. That's the tradeoff they're making. Other bots' comments are much more obviously sloppy, but there's more variety across their different comments.
Firstly, they have a remarkably consistent style. Everything is like this. There's not very many examples to choose from, so that's maybe also to be expected, and perhaps it is just also their personality.
I worry, as I've been accused myself, that there is perhaps something in the style the accuser dislikes or finds off-putting and nowadays the suspected cause will be LLM.
Secondly, they have "extensive experience" in various areas of technology, that don't seem to be especially related to each other. I too have extensive experience in several areas of technology but there is something of a connector between them.
Perhaps it is just because of their high level of technical expertise that they have managed to move between these areas and gain this extensive experience. And because of the high level of technical expertise and their interest in only saying very technical things all the time, their communications seem less varying and human, and more LLM.
> and nowadays the suspected cause will be LLM.
It's very unlike the original person, who is a bot indeed.
That said, S3 seems like a really odd fit for their workload, plus their dependency on lifecycle rules seems utterly bizarre.
> Storage was a secondary tax. Even when processing finished in ~2 s, Lifecycle deletes meant paying for ~24 h of storage.
They decided not to implement the deletion logic in their service, so they'd just leave files sitting around for hours instead needlessly paying that storage cost? I wonder how much money they'd have saved if they just added that deletion logic.
Also, just take an old phone from your drawer full of old phones, slap some free camera app on it, zip tie a car phone mount to the crib, and boom you have a free baby monitor.
I got a new phone because I thought my battery was cooked, but turns out it was just the app.
[0] https://www.techradar.com/pro/security/the-south-korean-gove...