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 :)
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.
All the hard parts of doing that are in dealing with reputation, not in setting up a mail server or or scaling it. I've run an e-mail service with ~2 million users on hardware with comparable CPU, memory and IO capacity to my current laptop in the past. Setting up the mail server was not the time consuming part.
And the reputation bit in this instance is handled by SES. If you put a regular mail server behind something like SES for outbound messages, that's simple too.
While I do see benefits to serverless, this seems to me to be a good demonstration of how it is still in a totally embryonic state when it comes to things like ease of use.
As someone who has been in this industry for over 30 years from being a grunt to wearing CTO hats if there's one thing that my experience unquestionably taught me is that there's absolutely nothing ever works like it is advertised. Ever.
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 to have contingency plans if you beat storage/network/CPU/RAM limits
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.
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