| > Just as there is a non-zero cost associated with maintaining Lambda, API Gateway, and the associated CloudFormation scripts, and finding people who can (and are willing to) maintain them. This is mostly true, although "maintenance" for those things is minimal. There are fewer moving parts you are responsible for maintaining, and the ones requiring ongoing changes (OS and software management) don't exist. To maintain an existing web application, you are on the hook to potentially ship updated libraries (but not runtimes) in your functions, and to pay your AWS bill. This is like a half-step above no maintenance at all. If I build a web application for a client that I deploy using a modern serverless architecture, it will require virtually no hands-on maintenance from me for... years? If I build a web application with a more traditional stack, I will definitively need to charge some amount for maintenance because it's not feasible to ignore patching or assume patching won't break all the automation I'd have around scripting, health monitoring, deployment, and everything else. That's a significant difference. > 99% of that complexity is already shouldered by AWS and their ilk. They implement log forwarding, metric dashboards, instance health checks, and simple (complete) examples of how to scale based on CPU and memory - the two metrics used for scaling in most cases. At what number do I scale up? At what number do I scale down? How do I detect when there's a problem with the instances coming up? And I'm familiar with AWS--they certainly help with those things, but it's still on you to have the log forwarding agent running on your box, to set up the dashboard, to ensure you have the separate agent running on your box to forward memory usage metrics, and to ensure you're not doing anything that won't break your automatic minor version upgrades for your AMI (or manage your own, if you're not using EB or don't use that feature). It's a whole lot better than doing it without those AWS services, but it's a significant step away from what you get with a serverless architecture. > You mean RDS? Databaes need to be maintained no matter how the application is run. For a quick personal anecdote, there's a world of hurt waiting unless someone is hired who knows how to manage and tune databases, no matter who runs the infrastructure. If you use RDS, sure. If you're using DynamoDB or (soon) Serverless Aurora, it doesn't require nearly as much tuning or babysitting. > How is this different? Linux troubleshooting skills won't help to identify if it's third party software or your software - and those pains don't go away magically with Lambda. Sure they can. Linux troubleshooting skills would tell you if an updated third party tool is now leaking memory, for example. And they often do go away with Lambda because your functions run on a level of seconds or minutes instead of hours, days, or more. Every function is effectively terminated every few hours at most. You could have problems with your libraries, but that's a much more limited troubleshooting scope than an entire VM. |