A serverless email server on AWS using S3 and SES

Post by rumanator » Sun, Jan 05, 2020, 5:58 PM UTC

mypalmike wrote: post #246

rumanator wrote: post #130

Earlier quoted context omitted.

> As if the time to manage servers is free. I work in projects which make heavy use of function-as-a-service, and I have first-hand accounts of how FaaS offerings have lead developers to waste a couple of weeks getting FaaS to do what could have been done in a couple of hours with a tried-and-true web service. > But lambda is far from expensive. Relatively to the cost of a VM instance? Yes, it's expensive. We're in a…

I'd rather be on call for a serverless system than otherwise. Getting paged at 2am because some log file filled up a disk, or a million other details that your "couple of hours" solution didn't take into account? No thanks.

Post by laurentl » Mon, Jan 06, 2020, 7:50 AM UTC

cyberferret wrote: post #231

statictype wrote: post #145

Earlier quoted context omitted.

We accidentally had ses credentials set up on our QA server and quickly got banned for sending too many sdf@sdf.com emails. Took quite some time to get it unbanned. Since then we switched to Mailgun for email delivery but ses is still useful for processing incoming email via Lambda

We are careful to use throwaway email addresses like randomusername @mailinator.com on our dev and staging servers so they still get delivered, but we can just forget about them. Really interested to learn about the SES simulator address though (posted as a reply on this thread) - don't know how we missed that, and it would have really helped with early testing when we were developing the email queueing system on our…

Post by arno1 » Mon, Jan 06, 2020, 10:50 PM UTC

danenania wrote: post #239

arno1 wrote: post #53

Earlier quoted context omitted.

Yep, but how can you be sure the serverless provider will never go down? I've witnessed multiple times when AWS's services went down. > If you're running a saas and the increased traffic comes from paying customers, you likely prefer a huge bill to downtime. Well, in such situation, I would probably run more advanced container orchestrators such as Kubernetes which you will then configure to automatically spawn the a…

The serverless provider can go down just like the VM provider can go down, but the key difference is that it won't go down due to traffic bursts. Auto-scaling helps, but it still takes awhile to spin up new VMs, and you'll have downtime in the meantime for sufficiently large bursts. On lock-in, in my experience with any non-trivial infrastructure you end up tied to your provider anyway. You're still going to need IAM…