A serverless email server on AWS using S3 and SES • Hacker News Board

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

#211

Post by m4rtink » Sat, Jan 04, 2020, 8:39 PM UTC

brazzledazzle wrote: post #198

Canada wrote: post #137

Earlier quoted context omitted.

> 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. Yeah, I totally understand the desire. And even hosting this on a cloud, you benefit from SMTP TLS sometimes, presuming no active MITM and the cloud service not actively abusing its privileges on your VM or storage. Which is probably not happening widel…

Fraud detection is such a frustrating double edged sword. They can’t share what was detected or why because the bad guys will start taking it into account. That leaves us with manual human review as the only means to address false positives. But that doesn’t scale so it’s either backlogged, low quality or nonexistent.

Rather seems likely laziness hiding behind the guise of "security". Such a bad user experience is inexcusable.

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

#212

Post by jdminhbg » Sat, Jan 04, 2020, 8:48 PM UTC

bathtub365 wrote: post #165

anonu wrote: post #47

Earlier quoted context omitted.

Serverless is beautiful. You just need to try some basic serverless concepts. Like run a website on S3. But to your second point, I agree. the technical hurdle required to learn all the configuration and moving parts ... And then to know that this language is vendor specific... Makes it less palatable. That's why I expect the cloud vendors to normalize their offerings over time. I should be able to take a CloudFormat…

How is running a website on S3 different from uploading your website to a shared hosting provider 20 years ago? How is it “beautiful”?

My shared hosting provider 20 years ago didn't have a CDN and would fall over if I got too popular.

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

#213

Post by wishinghand » Sat, Jan 04, 2020, 8:56 PM UTC

arno1 wrote: post #15

coder1001 wrote: post #14

Earlier quoted context omitted.

Do you mind writing a blog post somewhere explaining to noobs how this can be done? This will be a great post with lots of traffic I imagine! Thanks, great work!

I am actually thinking on writing it since long ago... But not motivated enough... :/

Another vote for a blog post, please.

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

#214

Post by xmly » Sat, Jan 04, 2020, 9:14 PM UTC

arno1 wrote: 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…

I think his solution is serverless, no need to maintain the servers.

But both solutions are kind for developers, not for end-users.

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

#215

Post by rumanator » Sat, Jan 04, 2020, 9:15 PM UTC

cddotdotslash wrote: post #183

tuldia wrote: post #175

Earlier quoted context omitted.

You are missing the point. (the "tired responses") No, there only very few cases, such as shaving video encoding time (the one that started all this mess around "serverless") For majority of other cases, using "(human) resource efficient" or "time saved managing servers" to justify the use of "serverless" is a plain bogus argument, since you end up shifting (best case scenario) OR spending more (worst case) time "man…

The poster above me does a better job of articulating the points I had, but at the end of the day, it seems to me like you are discounting an entire model of compute, part of an industry, the work that tons of developers are doing, not to mention new and interesting ways of developing new things, simply because you either don't want to learn something new or because you're attached to an existing way. Note that I've…

> The poster above me does a better job of articulating the points I had, but at the end of the day, it seems to me like you are discounting an entire model of compute, part of an industry, the work that tons of developers are doing, not to mention new and interesting ways of developing new things, simply because you either don't want to learn something new or because you're attached to an existing way.

This mix of appeal to authority with the sunken cost fallacy makes no sense at all and does nothing to show any merit or present any technical case. Your argument boils down to launching personal attacks on anyone who has the gall to not jump onto the bandwagon you've jumped on. Yet, if you wish to make a case for a tool then you have to obligation to actually present a case and demonstrate the advantages.

Bullying those who don't blindly follow buzzword-driven development principles and resorting to name-calling just wastes everyone's time, and actually just creates noise that muffles the contributions of those who actually have something interesting to say regarding the tecnology.

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

#216

Post by xmly » Sat, Jan 04, 2020, 9:17 PM UTC

scarface74 wrote: post #104

bloopernova wrote: post #99

Earlier quoted context omitted.

I think some folks are afraid of losing their jobs, so they lash out with snark.

Someone else said on HN, developers don’t just move to the cloud to avoid administering servers, we also want to avoid server administrators.

hahaha

good point

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

#217

Post by baddox » Sat, Jan 04, 2020, 9:18 PM UTC

MaxBarraclough wrote: post #197

baddox wrote: post #169

Earlier quoted context omitted.

It’s more than just a managed service. RDS is Amazon’s managed database cloud service, but you still provision and pay for a specific virtual server with a certain number of CPUs and amount of RAM. “Serverless” generally implies that you do not provision any server hardware (even virtual) and instead only provide application code.

I see your point, but we could view that as a quirk of the way they handle billing. If the instance fails, you're insulated from that, right?

I’m no expert, but I think you run RDS on an EC2 instance, so it’s basically just a normal virtual server running Amazon’s managed version of the RDBMS. I’m not sure what happens if an instance “fails” but I assume you can have downtime if Amazon needs to move your VM, just like EC2, but I assume Amazon handles moving the instance and restarting it.

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

#218

Post by rumanator » Sat, Jan 04, 2020, 9:19 PM UTC

baddox wrote: post #205

rumanator wrote: post #194

Earlier quoted context omitted.

> But that has nothing to do with whether the term “serverless” has a well-established meaning. It’s not just a buzzword, or at least it’s not always used as a buzzword and does in fact have a straightforward meaning. You're confounding two independent issues: "serverless" being a buzzword, and "serverless" not having a precise and well established meaning. The fact that "serverless" is indeed a buzzword is indisputa…

> The fact that "serverless" is indeed a buzzword is indisputable. It can be used as a buzzword, but it isn’t always. The same goes for “the cloud.” It’s used in marketing because it sounds cool and people think they need it, but at the same time it can be perfectly clear to use the term in technical contexts. > For example, "serverless" is used by some people to refer to a more concrete and specific and well establi…

> What’s vague about this? FaaS is a serverless product, but not all serverless products are FaaS.

That was precisely the point I made. There's no need to repeat it.

Yet, you've missed the point I've made subsequently, where I've specifically pointed out how the fact that the "serverless" buzzword is being tacked onto old and established technologies such as plain old managed services.

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

#219

Post by rumanator » Sat, Jan 04, 2020, 9:22 PM UTC

scarface74 wrote: post #161

rumanator wrote: post #155

Earlier quoted context omitted.

> Your “proof” is an anecdote that was easily disproven by a link. Real-world problems don't go away when you try to brush them aside. You either face the facts or remain in fantasy land. > If it takes your developers two weeks to host an API in a Lambda Please don't put words in other people's mouths. You have absolutely no idea about what the problems were and already made it quite clear that you don't care about f…

I’m going by the only facts that you offered. You said that it took your developers two weeks to do something that should only take an hour. I showed you an example of how to host a standard API or website within lambda with minimum effort. If your developer haven’t come up with processes to efficiently manage their development and deployment processes - it’s a process issue that others have already solved.

> I’m going by the only facts that you offered.

You did not. You fabricated accusations to fill gaps in your comprehension based on your imagination alone, and proceeded to use your made-up accusations to attack others. That's not cool, and just speaks volumes regarding your lack of arguments and your ability to contribute to a discussion.

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

#220

Post by crtlaltdel » Sat, Jan 04, 2020, 9:24 PM UTC

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…

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

^this. if you want to send email its not hard....but if you want that mail to pass spam filters its a different problem altogether. hosted services like SES and mailgun will expose problems in how you are using emails (not handling bounces, not handling unsubscribes, etc) and in our case was very helpful.