> A lambda publishes a message to SNS, another one picks it up and writes something to DynamoDB, the third one takes that new record and sends an email…
Or, you know, just do related functionality in the same AWS Lambda function. While I would probably do the sending of an e-mail asynchronously as well (as AWS Lambda function triggered by a DynamoDB stream), the indirection over SNS to write something to DynamoDB seems overly complex.
Why would you do something asynchronously with a Serverless architecture you'd do synchronously with Ruby on Rails?
> […] and random hardcoded configs in AWS console.
Just don't do that. A Serverless application will always be a pita if it relies on manual configuration. Ensure all relevant configuration is part of Infrastructure as Code (e.g. CloudFormation or Terraform).
> Impossible to replicate production environment
If the project is set up properly with Infrastructure as Code replicating the production environment is as easy as it can possibly get. And because it's Serverless, if an environment isn't used, it usually doesn't even incur notable costs.
There is no silver bullet and I believe Serverless as well as other approaches have their place, but what I miss are similar posts about great experiences with Serverless applications. I for myself wouldn't want to go back and I'm really happy with the problems Serverless applications solve.
The impossible to replicate the production environment I think was referred to impossible to replicate locally, on your machine.
At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. Having each time to upload some code to debug it is time consuming. Also you have to rely only on logs to debug, you obviously cannot use a debugger, and thus the solution is to insert a ton of print statements in the code and remove them, which is not a problem to me (I usually do that even in code that I debug locally) but the service to read these logs (ColoudWatch) is not great at all, you don't even have all your logs in one place, it's a mess.
I think serverless is overrated, sure it maybe the right tool for a simple project, but when the complexity grows it's best to use other more classical solutions.
> At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline.
AWS's Serverless Application Model explicitly supports local testing.
https://docs.aws.amazon.com/serverless-application-model/lat...
Which problems did you experienced?
SAM is able to run AWS Lambda functions locally and to emulate some API Gateway behavior. It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally. As Serverless applications often rely on such additional AWS services, the ability of SAM to run AWS Lambda functions locally doesn't really help for running such applications locally.
You guys don't even take the time to do a simple search... https://docs.aws.amazon.com/amazondynamodb/latest/developerg...
You can have pretty much all the services locally if you want you can even have a step function locally
DynamoDB and AWS Step Functions are notable exceptions to the fact that AWS services are usually not available locally. The vast majority of AWS services isn't available outside of AWS.
I have a local tool for every AWS service just tell what are you looking for, for example I use https://github.com/softwaremill/elasticmq to emulate SQS locally