Hacker News new | ask | show | jobs
by toomuchtodo 1979 days ago
If you've got funding (or immediate profitability due to traction) and a hockey stick growth rate, the cloud makes sense. It's just the cost of business to support rapidly scaling and developer velocity to try to capture as much of the market as fast as possible. As long as your profit stays ahead of your cloud costs, mission accomplished.

If the above does not apply, of course you're going to be better off using a combination of Cloudflare (CDN, networking), Backblaze (object store, also has S3 compatibility layer), and either dedicated service providers (OVH) or VPS providers (Digital Ocean). Perhaps even colocation if you've got the experience in house (Stackoverflow and Wikipedia, for example).

AWS and other cloud providers are designed for the price insensitive, who prefer having a single vendor, more abstraction away from the metal, or require support for bursty workloads. Shop around and model your run rate based on expected workloads. There is no best or worst solution, only a scale of solutions for your use case(s), ranging from suboptimal to optimal.

3 comments

I've talked* to a number of bootstrapped and non-profit companies who are all-in on cloud and I think there are a few use-cases you're missing beyond just "we value dev velocity over cost savings." The biggest one is ease of scaling vs something like colocation. I talked to a non-profit with incredibly spiky traffic based around whenever they get mentioned in the news. Since every dollar matters for them, being able to scale down to a minimal infrastructure between spikes is key to their survival. Another company I talked to has traffic that's reliably 8x larger during US business hours vs night time and uses both autoscaling and on-demand services (dynamodb, aurora serverless) to pay ~1/3 of what they'd have to if they needed to keep that 8x capacity online all the time.

I agree that the velocity/cost tradeoff is one of the better reasons to go cloud, it's far from the only one, and it's certainly not the case that cloud is only for the price insensitive. If nothing else, the proliferation of cloud cost management tools shows plenty of companies care about their cloud spend.

* I work on an aws cost management tool and am doing a lot of customer research interviews this month.

> I talked to a non-profit with incredibly spiky traffic based around whenever they get mentioned in the news. Since every dollar matters for them, being able to scale down to a minimal infrastructure between spikes is key to their survival.

Frankly, I don't understand this point. For €40 a month with Hetzner you'll get an i7 with 64GB RAM and 2x512 SSD that will easily handle any traffic spike (we're talking about a website, right?). €40 is not a lot of money, even for a non profit, and especially for one experiencing a huge spike after being mentioned in the news.

On the contrary, I would advise against AWS here as they're completely unpredictable. You can be charged any amount, and the costs only partly depend on you. Developers have been demanding hard caps for over a decade to no avail.

My comment is not meant to be a comprehensive analysis of cost/benefit for cloud use cases, but only examples for a thread with a half life of ~24 hours.

Please consider publishing your research findings in the future if it doesn't put you at a competitive disadvantage. A rising tide lifts all boats, and cloud spend tracking and modeling is a pain in the ass (as your success demonstrates).

This advice holds if you have a stock based compensation or a bonus based on profitability. Here wasting money on cloud directly impacts the profitability (and by extension, the worth of your stock).

If you are a dev that's paid to churn out features, and your compensation isn't stock based, just use whatever allows you the greater flexibility and velocity.

Cloud venders also help by keeping all the network chatter internal and you not paying in/egress fees to connect to your external object store, to your external managed database, to your. The bandwidth costs can be a significant chunk of hosting.

Thankfully, I've never had a popular enough service that made the bandwidth a meaningful cost.

I assume you're using Backblaze to host static assets you're rendering from your compute, and using Cloudflare to front and cache those static assets. You'd also use Backblaze for backups. Most network chatter would remain within your compute, and you'd want Redis, Mongo, Elastic, or Postgres as close to the compute (maybe k8s, maybe VMs, up to you) as possible, while shipping the snapshots to your object store. To your point about bandwidth costs, I recommend Backblaze and Cloudflare because they have an arrangement in that regard [1].

Reliably decouple whenever possible.

[1] https://www.cloudflare.com/bandwidth-alliance/ (Control-F "partners")

For a couple of projects I use the b2/cloudflare "free bandwidth", but I have to pay egress from my droplet to b2 on user uploads, its well within the 1TB that you get for a $5 droplet, and smaller than a rounding error against my total bandwidth bucket of 9TB. So as I said, I'm fine.
Thanks for sharing your use case. I will submit a feature request with Backblaze to support request signing to support user uploads directly to the B2 object store, similar to what S3 supports [1].

[1] https://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrl...