Drawbacks I experience:
- Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present.
- Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up.
- Security/monitoring: having fewer functions make this less of a worry, but it's still difficult and it's clear that there's not much of an ecosystem and best practices.
- Debugging: this can be really annoying. I can usually avoid this by having a proper local testing setup (see below), but when that doesn't cut it, this gets annoying.
Drawbacks I haven't really experienced:
- Statelessness: this is probably due to not splitting up my code in too many functions, and thus not having that much complex interactions, but this hasn't really been a problem for me.
- Execution limits: haven't run into them yet.
Drawbacks I've managed to contain:
- Local testing: I'm writing Node Lambda's. Since they're just stateless functions, it was relatively easy for me to write a really simple Express server, transform the Express requests into the API Gateway format, and convert the API Gateway response format back into Express format. This works fine for local testing, and reduces the effects of vendor lock-in. That said, I do do a lot of the request parsing in the Lambda function itself, rather than letting API Gateway do this.
- Deployment: this is actually pretty sweet. I'm using TerraForm which, although it's a bit immature and thus cumbersome to set up, has been getting the job done and allows me to easily deploy new copies of the infrastructure for every branch of my code.
- Remote testing: as mentioned above, deploying it for every branch I have allows me to see what it's going to look like in production.
Hmm, perhaps I should turn this into an article sometime...