Live data from Hacker News

A serverless email server on AWS using S3 and SES

github.com

81–90 of 266 posts

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

#81
post #74
post #60

Earlier quoted context omitted.

It is in the cloud. It's different in that you don't have access to the cloud server, just a service on it. To me it's like having one hand tied behind your back while someone else uses their hand to do what you'd have done with the one tied behind your back. It's cheaper, sometimes it works the way you want it to, but you always feel a bit restricted.

The less pessimistic interpretation is that it's like having someone else be your devops department. Unlike what people like to think, most people running traditional VMs and containers end up doing just as much devops as on a dedicated server (while doing consulting, I'd typically get more hours at higher rates out of people insisting on AWS, because getting an AWS setup right is a lot of work), so serveless is appe…

It's more than SSH access that you give up though. You have to bend to the paradigm completely or you're really fighting against it.

For one example, I keep running up against wanting to delay an execution of one lambda from another. There are some truly horrible hacks out there to try and achieve that.

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

#82

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

Serverless = Managed Server

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

#84

Earlier quoted context omitted.

The term serverless is such a misnomer. While this is a cool project, you'd use 3 different servers at a minimum here.

Do you also complain when people say they have a “bug” in their code or that they have a “server farm”? Are they literally watering the server floor and waiting for computers to grow?

Not at all. It's in this case, using the term serverless is akin to calling cloud based software (Google Docs, TurboTax, etc) softwareless. It's closer to calling a stop sign a "go sign" than descriptors from your example. Calling managed servers "serverless" is distinctively misleading.

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

#85

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

Serverless = Managed Server

Managed on-demand server, specifically.

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

#86
post #69

Earlier quoted context omitted.

The benefits to using this approach over a traditional server are: 1. Someone else maintains the software running these services, including OS upgrades, security upgrades and patches, uptime monitoring, etc. 2. Since every logical component is an independent service, each scaling independently, any one single component is unlikely to become a bottle-neck while scaling. In traditional monolithic servers, you'll have t…

> 1. Someone else maintains the software running these services, including OS upgrades, security upgrades and patches, uptime monitoring, etc. This is the standard marketing phrase echoed to promote serverless. By experience, I don't think is valid. Packages like unattended-upgrades automates all this stuff. Also, not being able to verify what the software is doing is scary and looks like a 10 steps backwards to me.…

The long and short of it is that “serverless” is all done on a pay-per-use basis. So is running a VM to host an email server — let’s say $5/month on the low end. With this setup you’d be paying pennies a month assuming normal personal usage. If you were running an email server for your Fortune 500 company, yeah this wouldn’t make sense. But for personal usage? Assuming SES isn’t on the shit list of Google et al this is fire-and-forget, and dirt cheap.

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

#87

Earlier quoted context omitted.

It’s no more “misleading” than having a “bug” in your code. Does anyone with even an iota of computer experience think “Serverless” means that their software is being run by leprechrauns? Nowhere else on HN is willfully not taking the time to learn about technology celebrated except when it comes to cloud concepts.

The more you understand the architecture, the more absurd it sounds to call it serverless. Edit: Replying to the below comment... No, it's like calling produce you didn't grow yourself but came from a farm, farmless produce.

Imagine if someone said

“the more you understand about farming, the more absurd it is to call them server farms.”

“the more you understand about biology, the more absurd it is to call them bugs”

“The more you understand about meteorology the more absurd it is to call it ‘the cloud’”

Yes, if it weren’t for people on Hn educating the poor unwashed masses we would all think that our software running “Serverless” was being run by elves at the North Pole.

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

#88
post #12

> This stack was created out of frustration due to the fact that to this day there's no easy way to have a full email server without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages. Interesting approach, though I solved this frustration by the use of a Docker and kept "my data is mine" + "no vendor lock-in" + "I control all the gears" approach. (Though, it's not…

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 haproxy to load balance thousands of messages a second).

For your user-facing side you need a bit more resiliency, but nothing stops you from using a service like SES to back a traditional setup for sending either. Reliably scaling outbound mail is the easy bit - the hard part is the reputation management that managed mail services provides, and no specific deployment mechanism will solve that.

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

#89

Earlier quoted context omitted.

The term serverless is such a misnomer. While this is a cool project, you'd use 3 different servers at a minimum here.

Do you also complain when people say they have a “bug” in their code or that they have a “server farm”? Are they literally watering the server floor and waiting for computers to grow?

There is a huge difference between a metaphor (resemblance) and contradiction (stating it is and isn't something at the same time).

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

#90
post #4

What about email signing?

After surrendering all your data to a cloud provider?

Signing e-mail servers two different purposes:

Authenticating the actual sender vs. authenticating the server or service controlling the domain for reputation purposes.

If you trust Amazon enough to use their cloud services, there's little reason not to trust them for the latter. Doesn't mean trusting them with respect to the former.

Things like DKIM makes no assertion that the content was sent by the right person; just that whomever controls the domain has trusted the service in question to send e-mail on their behalf.

Post reply on HN