Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A serverless email server on AWS using S3 and SES

github.com

Post reply on HN
Print view View original

241–250 of 266 posts

Re: A serverless email server on AWS using S3 and SES

#241

Post by danenania »

kortilla wrote: post #229
danenania wrote: post #25

Earlier quoted context omitted.

Another drawback is that while yes, you can scale up fairly easily with terraform, your server can also fall over if you get a heavy burst of traffic, and you'll return errors until you're able to provision more machines. Depending on what you're doing, how fast you're growing, and how much tolerance your users have for downtime, that might be a pretty big deal.

It’s a mail server. Traffic bursts aren’t really a thing unless you’re servicing thousands of users.

Right, I'm looking at this more as a potential backend for an email-heavy saas, in which case I think handling bursts without downtime could be pretty important. If you just need a mail server for yourself or a small company, I agree it's not an issue.

Re: A serverless email server on AWS using S3 and SES

#243

Post by danenania »

vidarh wrote: post #88
danenania wrote: post #25

Earlier quoted context omitted.

Another drawback is that while yes, you can scale up fairly easily with terraform, your server can also fall over if you get a heavy burst of traffic, and you'll return errors until you're able to provision more machines. Depending on what you're doing, how fast you're growing, and how much tolerance your users have for downtime, that might be a pretty big deal.

You can set up autoscaling groups via terraform just fine, with a little bit of care taken to ensure that you trigger on the right metrics. If anything mail is pretty much the easiest thing you can possibly pick to scale, because the inbound mail will be automatically retried. And haproxy in front of SMTP servers works just fine (really, any load balancer that can load balance raw TCP connections, but I've used hapro…

Sure, but for heavy/bursty traffic, you can still have downtime while new VMs spin up. Retries might save you or they might make the problem worse, depending on the size and pattern of the burst and how your auto-scaling config interacts with the retry config of various hosts.

It may seem like a nitpick or something not worth worrying about, and for most that's probably the case. But for some businesses it could be a crucial difference. My point is simply that this is a legitimate benefit of serverless that wasn't mentioned above--I didn't think that would be a controversial point.

Re: A serverless email server on AWS using S3 and SES

#244

Post by Can_Not »

tuldia wrote: post #54
abjKT26nO8 wrote: post #5

I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers. [1]: " rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...

Indeed. I suspect the "serverless" word was created due to the emotional appeal to a specific (majority) group that is strongly opinionated against having servers at all. Reading from the README.md file: There are two major limitations with SES: For security reasons, AWS defaults to 200 emails sent per 24 hour period at a rate of 1 email/second. If you need to send more than that, you'll need to ask AWS to increase y…

SES sending email pricing:

> $0.10 per 1,000

I don't think a single send email API counts as "vendor lock-in".

Re: A serverless email server on AWS using S3 and SES

#245

Post by reaperducer »

abjKT26nO8 wrote: post #5

I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers. [1]: " rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...

to this day I fail to understand what this word is even supposed to mean

It means the same thing as "cloud:" You're renting someone else's server.

Re: A serverless email server on AWS using S3 and SES

#246

Post by mypalmike »

rumanator wrote: post #130
scarface74 wrote: post #114

Earlier quoted context omitted.

As if the time to manage servers is free. But lambda is far from expensive. If you’re spending even $100 a month on lambda, you probably have a successful business. And everything is “complex” if you don’t know how to do it optimally.

> 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.

Re: A serverless email server on AWS using S3 and SES

#247

Post by scarface74 »

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.

You’re right. If my print statements cause CloudWatch logs to fill up. AWS has bigger issues....

I refuse to work for any company at this point in my career that expects me to be on call to manage a bunch of pets.

Re: A serverless email server on AWS using S3 and SES

#248

Post by corobo »

rumanator wrote: post #116
corobo wrote: post #38

Earlier quoted context omitted.

I've found that "I don't even get what the word is supposed to mean" is someone's first experience with tech fear. In my experience (including my own personal anecdata) they tend to mean "I don't want to learn this new thing and because of that I'm worried I'll be left behind if everyone switches to this"

> I've found that "I don't even get what the word is supposed to mean" is someone's first experience with tech fear. This is a gross misrepresentation of the actual problem affecting the "serverless" fad, which is the buzzword overload accompanied by a lack of objective definitions. Function-as-a-service (FaaS) is an objective, clear-cut concept, but "serverless computing" is supposed to be a more general term where…

Folks were saying the same about "the cloud" but we got used to that too.

Re: A serverless email server on AWS using S3 and SES

#250

Post by chrismorgan »

Boulth wrote: post #64
chrismorgan wrote: post #44

Earlier quoted context omitted.

JMAP is a radically different beast. The similarities between this thing’s JSON format for sending and JMAP’s Email data type are superficial only: they’re both JSON and are representing the same thing, so it should be no surprise that they look similar. But that’s a quite tiny part of what JMAP is: JMAP is an object synchronisation protocol. (And this is why JMAP so much more complex than the typical REST API. And w…

Thank you for your detailed in depth response! For the record it seems this seems to do some basic processing: > The Inbox or Sent folder triggers another Lambda function that loads the raw email, converts it to a .html and .txt file, and stores it alongside the original message, while storing any attachments in the attachments. This looks OK for me having clients do indexing and processing. From your description it…

This project seems to be designed more for a process-and-delete workflow, whereas JMAP is designed as a general-purpose object synchronisation protocol on which you can build arbitrary email clients.
Post reply on HN