Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The 250mb redis instance on Azure costs $0.055 an hour[1], so nearly $500 p/year

Going down the small hosting a 100 line Go program route, the cheapest "B1" instance type with 1GiB of RAM costs $105.12 a year, and then if you want the service to be HA you need probably another instance in a different zone, maybe a load balancer as well.

I suspect Azure Functions + Blob Storage costs a lot less. Although he didn't mention how much CloudFlare was costing him.

[1] https://azure.microsoft.com/en-us/pricing/details/cache/ [2] https://azure.microsoft.com/en-us/pricing/details/virtual-ma...



You could host this whole thing on the cheapest Digitalocean droplet if it were written as the person you're replying to described.


And then it's a single server that has none of the scaling, ease of maintenance, or high availability of just using functions and table storage. This is the perfect scenario for serverless, why would you want to run a VM instead?

The current system works great, most of the hits will be cached, and optimizing the origin to be that milliseconds faster isn't worth it at all.


It's actually NOT a perfect system for serverless, because it's a read-only (no writes), simple search "web app". The one thing that you don't get from a VM in your list is high availability I'll give you that, but otherwise this solution is an overengineered monstrosity for a simple problem if done in a more traditional way, as many many other people are calling out here.

If the only reason your web app is fast is when its data is cached, you need to take a long hard look at how your web app is built. It's not that hard to build a performant query system like this even with that amount of data.


Read vs write has nothing to do with serverless, it's about well-encapsulated logic that doesn't need any server management and has granular pay-per-use billing.

It doesn't get much simpler than a function that does a key/value lookup or returns a text file; what exactly is over-engineered about that? The app is fast, it's < 100ms which is perfectly fine for non-cached access. This isn't mission critical real-time, it's a completely free service to lookup a password hash.

Everyone here is caught up in the usual "we can do better" perspective without actually thinking about why it was done this way. In reality the current method is cheaper, more reliable, more scalable and has 0 maintenance compared to anything else suggested so far.


I'm guessing he didn't do that because he's a prominent .NET/Azure guy and I don't think that stuff is well-supported in that environment.


He mentioned that Cloudflare is free for him.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: