I'm fully aware this is pedantic, but you can't save 10x. You can pay 1/10. You can save 90%. Your previous costs could have been 10x your current costs. But 10x is more by definition, not less. You can't save it.
I took all my projects off the cloud, saving thousands of dollars
141–150 of 406 posts
Re: I took all my projects off the cloud, saving thousands of dollars
#142Earlier quoted context omitted.
You don't actually need any of those things until you no longer have a "project", but a business which will allow you to pay for the things you require. You'd be amazed by how far you can get with a home linux box and cloudflare tunnels.
You can get quite far without that box, even, and just use Cloudflare R2 as free static hosting.
Re: I took all my projects off the cloud, saving thousands of dollars
#143Earlier quoted context omitted.
Just one of the couple dozen databases we run for our product in the dev environment alone is over 12 TB. How could I not use the cloud?
https://www.seagate.com/products/enterprise-drives/exos/exos...
I guess this is one of those use cases that justify the cloud. It's hard to host that reliably at home.
Re: I took all my projects off the cloud, saving thousands of dollars
#144I'm fully aware this is pedantic, but you can't save 10x. You can pay 1/10. You can save 90%. Your previous costs could have been 10x your current costs. But 10x is more by definition, not less. You can't save it.
I could care less.
Re: I took all my projects off the cloud, saving thousands of dollars
#145Both of these trucks can technically be used to pick up groceries and commute. But, uh, if you bought the semi-truck to get groceries and commute? Nobody scammed you; you bought the wrong truck. You don't have to buy the biggest, most expensive truck to do small jobs. But also, just because there's a cheaper truck available, doesn't mean the semi-truck is overpriced or a scam. The semi is more expensive for a reason.
I wonder about people who write articles like these. I imagine at one point he believed he had to use the cloud, so he started using it without understanding what he was doing. As a result, he was charged a ton of money. He then found out there were cheaper, simpler ways to do what he wanted. And so, feeling hurt, embarrassed, and deceived, he writes this long screed, accusing people of scamming him - I mean scamming you - because you (not him!) could not possibly need to use the cloud, even though you (not him!) assumed you had to use the cloud.
Yes, dude. The cloud is expensive. Sorry you found out the hard way. And for what it's worth, you don't need a datacenter either; stick a 1U in your closet and call it a day.
Re: I took all my projects off the cloud, saving thousands of dollars
#146Cheap shot maybe, but the fact that the page takes 10 seconds to load when it hits the HN front page is a great, inadvertant illustration of why you might want to use the cloud sometimes.
OP here. As others have said, it loads immediately for me (tested on desktop + on mobile data + incognito) The entire site is cached + Cloudflare sits on top of everything. I just ran a couple performance tests under the current HN traffic (~120 concurrent visitors) and everything looks good, all loads under 1 second. The server is quite happy at an average load of 0.06 right now, not even close to start breaking a s…
Re: I took all my projects off the cloud, saving thousands of dollars
#147Earlier quoted context omitted.
> A few clicks. Getting through AWS documentation can be fairly time consuming.
Figuring out how to do db backups _can_ also be fairly time consuming. There's a question of whether you want to spend time learning AWS or spend time learning your DB's hand-rolled backup options (on top of the question of whether learning AWS's thing even absolves you of understanding your DB's internals anyways!) I do think there's value in "just" doing a thing instead of relying on the wrapper. Whether that's eas…
Re: I took all my projects off the cloud, saving thousands of dollars
#148Earlier quoted context omitted.
Figuring out how to do db backups _can_ also be fairly time consuming. There's a question of whether you want to spend time learning AWS or spend time learning your DB's hand-rolled backup options (on top of the question of whether learning AWS's thing even absolves you of understanding your DB's internals anyways!) I do think there's value in "just" doing a thing instead of relying on the wrapper. Whether that's eas…
Hmmm, I think you have to figure out how to do your database backups anyway as trying to get a restorable backup out of RDS to use on another provider seems to be a difficult task. Backups that are stored with the same provider are good, providing the provider is reliable as a whole. (Currently going through the disaster recovery exercise of, "What if AWS decided they didn't like us and nuked our account from orbit."…
Re: I took all my projects off the cloud, saving thousands of dollars
#149For me, it is a lot simpler to host at Linode (or simpler) than figure out the AWS/GCP crazy complex IAM stuff. However, there are cases where being able to spin down the server, and not pay for downtime is useful - like 36-core Yocto build machines.
For personal projects, honestly, the built in roles AWS provides are okay enough for some semblance of least privilege x functionality IMO.
Plus, most of AWS's documentation tells you the specific policy JSON to use if you need to do XYZ thing, just fill in the blanks.
Re: I took all my projects off the cloud, saving thousands of dollars
#150Earlier quoted context omitted.
On this site, I've seen these kind of takes repeatedly over the past years, so I went ahead and built a little forum that consists of a single Rust binary and SQLite. The binary runs on a Mac Mini in my bedroom with Cloudflare tunnels. I get continuous backups with Litestream, and testing backups is as trivial as running `litestream restore` on my development machine and then running the binary. Despite some pages is…
Just one of the couple dozen databases we run for our product in the dev environment alone is over 12 TB. How could I not use the cloud?
However, I think there's an implicit point in TFA; namely, that your personal and side projects are not scaling to a 12 TB database.
With that said, I do manage approximately 14 TB of storage in a RAIDZ2 at my home, for "Linux ISOs". The I/O performance is "good enough" for streaming video and BitTorrent seeding.
However, I am not sure what your latency requirements and access patterns are. If you are mostly reading from the 12 TB database and don't have specific latency requirements on writes, then I don't see why the cloud is a hard requirement? To the contrary, most cloud providers provide remarkably low IOPS in their block storage offerings. Here is an example of Oracle Cloud's block storage for 12 TB:
Max Throughput: 480 MB/s
Max IOPS: 25,000
https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bl...Those are the kind of numbers I would expect of a budget SATA SSD, not "NVMe-based storage infrastructure". Additionally, the cost for 12 TB in this storage class is ~$500/mo. That's roughly the cost of two 14 TB hard drives in a mirror vdev on ZFS (not that this is a good idea btw).
This leads me to guess most people will prefer a managed database offering rather than deploying their own database on top of a cloud provider's block storage. But 12 TB of data in the gp3 storage class of RDS costs about $1,400/mo. That is already triple the cost of the NAS in my bedroom.
Lastly, backing up 12 TB to Backblaze B2 is about $180/mo. Given that this database is for your dev environment, I am assuming that backup requirements are simple (i.e. 1 off-site backup).
The key point, however, is that most people's side projects are unlikely to scale to a 12 TB dev environment database.
Once you're at that scale, sure, consider the cloud. But even at the largest company I worked at, a 14 TB hard drive was enough storage (and IOPS) for on-prem installs of the product. The product was an NLP-based application that automated due diligence for M&As. The storage costs were mostly full-text search indices on collections of tens of thousands of legal documents, each document could span hundreds to thousands of pages. The backups were as simple as having a second 14 TB hard drive around and periodically checking the data isn't corrupt.