Comment by twistedpair | Hacker News Reader

Comment by twistedpair | Hacker News Reader

@ mabl (mabl.com) we've been running a serverless backend on Google Cloud Functions for over a year. It's handled 600M function calls/month without much trouble. Our findings are:

* Eventually you need to promote a function to legitimate service for cost savings (e.g. GCF ️ AppEngine Node service)

• You need a buffer (e.g. GCF outscales services it calls) such as Pub/Sub

• Multi-repo/project layout is best for deployment speed, but needs extra dev/CI tooling to simplify boilerplate

• Minimizing costs can be creative/tricky compared to legacy services

• GCF is great for automatic stats and logging (Stackdriver) and "it just works" configs, compared to Lambda

• Don't go cloud functions everything, just the parts that are a good fit

We've gotten a good uptime using cloud functions, but we're always pushing for more nines. Since the functions tie together a bunch of backend Pub/Sub queues and services/stores, a brief cold start or queue backup has no notable impact on the overall system latency or throughput.

BTW, the coolest feature of AWS Lambda I've found is tying it to SES/SNS for inbound and outbound email routing. I've been running my personal email for years through a Lambda function for a few cents a year.

Overall the space is rapidly evolving and we'll see lots more features on Azure Functions, AWS Lambda, and Google Cloud Functions. See our learnings [1].

[1] https://www.slideshare.net/JosephLust/going-microserverless-...

Any links on how to implement your email routing setup?

You just have to verify your email address in SES (https://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify...) and then you can use SES to send emails on your behalf. You might also want to send a support ticket to get you out of their sandbox environment as it has a lot of restrictions. And then its very simple with Boto3 for example: https://pastebin.com/raw/hC6ihZZx

I'm curious about that as well. Does he have a Lambda that sends email he gets to a spool file somewhere? What does that workflow look like? Whats the advantage over just using a regular email client or Gmail?

The advantage is collecting email from disparate addresses (e.g. admin@your-domain.com) and forwarding them all to your preferred Gmail accounts. You can't setup ACM or other certs services without that to prove ownership. Previously I paid ~$100/yr to get all these mail forwarding routes setup. You can also capture inbound mail directly to a queue (e.g. unsubscribe@your-domain.com) and feed it to a Lambda to take action.

Here is the script I've been using [1].

[1] https://github.com/arithmetric/aws-lambda-ses-forwarder

If you need simple email forwarding you can use this https://forwardemail.net (it's FOSS)

So yeah basically serverless is just too expensive. It's cheap or free for low volume, to get you hooked, but for any "serious" service it is too expensive.

That just isn't true. For many companies the cost of their IT infrastructure is a very small fraction of their annual turnover. It all depends on the economics of your particular case whether or not this makes sense. For some companies it does, for some it doesn't.

At some point the fixed cost of real servers does become appealing.

That point comes way further along, assuming you're talking about bare metal and not simply cloud instances.

For my workloads, serverless functions would end up costing 4-5x more than operating the infrastructure myself. Given that my infrastructure costs exceed the salary of some number of developers, that's a very real difference.

Probably makes a lot of sense for early-stage, though.

Developer time is the highest cost. Building and deploying a function in an hour minimizes time to market and opportunity cost. Lifting and shifting to a dedicated service like AppEngine is a "good problem to have" once the function's usage exceeded specific thresholds. However, if you never reach said thresholds (e.g. only a few thousand calls a day), you didn't spend the time/money setting up a service backed by dedicated services.

wow, this is great insight on the economics. Thanks!

Spinning up an app engine service is incredibly easy and, if using standard environment, is basically free until you have load. It auto scales from zero very quickly (milliseconds).

It is literally tech debt, in the credit card sense. You get to validate the market faster, but if it takes off then you incur a higher interest rate (it gets expensive quickly after a point)

If you're really iterating quickly, much of the code may have a short shelf life, so you can also see it as leveraging tech debt, since a fail amount of the code may not be needed in 3mo.

Reply on news.ycombinator.com