> Not a single post on Hacker News can use the term "serverless" without the exact same replies being posted every time.
Indeed.
> It's as if a certain portion of the HN crowd simply cannot fathom that a new term exists and is in use, and instead resort to the same, tired responses.
If was only "a certain portion/crowd" it will have no responses at all.
I see more like:
"It's as if a certain portion of the HN crowd simply cannot fathom that servers exists and is easy to use, and instead resort to the same, tired responses."
Another “serverless” route for Docker containers is to deploy the containers with Fargate which isn’t too hard and gives you autoscaling without having to re-architect your application for serverless. (And has correspondingly less vendor lock-in)
> 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.
> 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 to have contingency plans if you beat storage/network/CPU/RAM limits
Except when it comes with a bottle-neck by default. Running mail servers requires rather little resource.
> 3. The closest thing to this is to break up a monolithic email server into microservices and deploy them as independently scalable containers, which is a considerable engineering effort.
Why in earth? Have you seen the postfix architecture?
> Assuming this works as advertised, you can go from zero to a full blown email service for organizations with thousands of people (assuming the stated AWS limits are lifted), in record time.
I'm pretty sure one can have a up and running mail server while the "cloudformation" thingy will still be running :)
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.
This use case and logic seems really weird to sell the serverless buzzword. My personal email has been somebody else's problem since the 90s and is done through the provider of my personal domain at no additional cost.
Setting up a serverless email server seems like something I'd have to bother with and maintain a few years down the line when the platform of choice inevitably changes something. Some use cases of serverless applications just shift maintenance efforts. Sure, I don't have to update OS packages. I still have to wonder if the service I'm using for my serverless stuff will be there (for startup vendors) in a few years or, more likely for vendors like AWS, change their terms, pricing or aspects of their API. I can pay a student intern to maintain a single VPS based $whatever, AWS consultants cost a multiple of that. If that's something you can and want to do yourself, sure, that's great - even for small use cases like this but then it becomes a philosophical toy problem more than a technical challenge.
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 your limit.
By default, you can't send emails to unverified addresses. If you'd like to be able to send (as opposed to just receiving), you'll need to reach out to AWS to remove this limitation from your account.
I see zero benefit in having complete vendor lock-in, non-sense limitations, seriously, with a $5 VPS can send at least 300 emails per minute.
I find these absurdly limited mail services strange. The one time I had to craft some "extra" email, was sending out surveys to an opt-in group for an EU project. There were some 10 000 recipients, and we had to send each a different email, in order to link responders with surveys (ie: a template email with description and an unique url of the form https://example.com/survey/123xyz).
Generating the emails in a naive loop and sending them via python took an insignificant amount of time - but in the end we worked out doing batches of 2000 at a time was easy enough - and with some help from the college that ran the email service (via exim) it all worked out (if you're going to send 10k mails in a day, it's nice to give your postmaster a heads up).
Hosting the mail server ourselves (using eg exim or postfix) would've worked too. Not sure about any of the spam-as-a-http-api services - even with custom domains they tend to have poor reputation, and they have these silly limits that mean they're not only not "auto scaling" - they're very low performance.
The problem is spam. The big providers providing hosted emails do a lot of work to make sure the emails people send with them actually end up at the recipients inbox and not in spam quarantine - but that doesn't work if the provider is then used by spammers. So the limits are set to discourage spammers while making most use-cases for email still possible.
If one were to ask me what to do, I'd say emails should cost 0.1 cent each, to be paid to the recipient...
The emails sent by your $5 VPS wouldn't stand a chance of actually being delivered to people's Gmail or Outlook mailboxes. Whereas SES actually works.
Also, it is incredibly easy to ask AWS support to increase the limit. A startup I worked with had only thousands of users; we told AWS about it and they gave us 5 million emails per 24 hours.
By all reports of people who have set up their own mail server lately, just having SPF and DKIM set up still won’t cut it for delivery to the major mail providers these days.
I run my own email server, with no spam filter, and inspect where every spam comes from. I get a lot of spam from random shitty providers, but none from major VPS providers (Scaleway, Hetzner, Linode, Digital Ocean, ...) with the exception of OVH.
I do however get spam from Amazon SES a couple of times a month.
All those limits are removed within hours and are one time support ticket requests. AWS doesn't want every account to be instantly usable as a spam account if someone is compromised.
I think the more significant annoyance would be the lack of IMAP/POP, I don't see how that is addressed.
It saddens me to see people growing a business and having to make tradeoffs due to hosting costs or trying to catch up with new tech.
My (opinionated) take on this if you are just starting a new business:
0. Lay your foundation on something that is battle tested and well supported.
Rent/buy a real computer (dedicated/root server), not cloud.
Use software that is already included in major/stable GNU/Linux distributions.
1. Build your stuff.
Get used to writing things.
Beware tech news.
> When the file is next edited by the next individual.
That usually means you add a separate goal and focus to your ticket to be committed inan unrelated issue, which in some projects is frowned upon as it avoids tracking, context, or auditing.
Every codebase is like this because it's cheap to open tickets and pepper the codebase with TODOs but orders of magnitude more expensive time-wise to actually do the work. The method of storing the information and prioritizing the work is irrelevant. You simply don't have enough bandwidth to do it all and some of it simply isn't materially important enough to ever get prioritized.
For some reason it become socially acceptable to bash folks who do system administration for a living.
Seems that you are really frustrated because you had a bad experience while working with a sysadmin and I don't think it is fair to despise people who do system administration just because of that.
This is toxic, and is _not_ ok.
Sysadmins are busy people, with their own reponsibilities, tasks, etc. They are always willing to help, assuming that you know how to communicate nicelly, tell about what you want to achieve, being a humble, honest human being.
Assuming that the sysadmin profession entails helping people all the time is plain wrong. Don't abuse.
Though, even if you ask for help several times about a specific subject is very likelly you will receive useful links, docs etc to get you "unblocked".
You still have to read and try to help yourself with the new piece of knowledge that you received.
---
> Not a single post on Hacker News can use the term "serverless" without the exact same replies being posted every time.
Indeed.
> It's as if a certain portion of the HN crowd simply cannot fathom that a new term exists and is in use, and instead resort to the same, tired responses.
If was only "a certain portion/crowd" it will have no responses at all.
I see more like:
"It's as if a certain portion of the HN crowd simply cannot fathom that servers exists and is easy to use, and instead resort to the same, tired responses."