I tried AWS serverless, figured out that it is impossible to test anything locally while you are forced to use AWS IAM role for serverless run which has access to everything.
That's just a problem waiting to happen while you are always running tests on production...
I worked on a serverless project for several years and the lack of ability to run much of anything locally was a huge cost. Debugging cycle times were absolutely terrible. There are some tools that claim to address this but as of a few years ago they were all useless for a real project.
I use my AWS security key to run local tests. It works perfectly fine. You just need a ~/.aws/credentials file appropriately configured.
I have a makefile system which controls lambda deployments. One step of the deployment is to gather the security requirements and to build a custom IAM role for each individual lambda. Then I can just write my security requirements in a JSON file and they're automatically set and managed for me.
The real joy of AWS is that everything works through the same API system. So it's easy to programmatically create things like IAM roles like this.
1. Put your stuff in a stack. Deploy it to your isolated developer account. Basically free staging environment.
2. Use the officially supported docker runtime for local testing.
3. Treat it like any other code and make unit tests
4. Use one of the tools like localstack to emulate your staging env on your machine.
There are so many options that I don’t know how you could walk away with your opinion.
Or you could just write conventional software. But I get it, you don't get resume points nor invites to cloud-provider conferences for that.
> Basically free staging environment. [emphasis mine]
Not really. Sure, the cost would usually be peanuts... until you have an infinite loop that recursively calls more lambdas. Then you have a huge bill (but hey that pays for your invites to their conferences, so maybe it's a blessing in disguise?). And yes, you will pretty much always get it refunded, but it's still a hassle and something that is absolutely not necessary.
Snark aside, having an opaque dev environment always constrained by bandwidth and latency that can’t be trivially backed up/duplicated is a terrible idea and why I always recommend against “serverless”, even besides the cost concerns.
Serverless is OK for small, fully self contained pieces or code that are fire and forget. But for anything complex that’s likely to require maintenance, no thanks.
Eh, I worked on a large serverless project that worked hard to follow best practices but it was still very clunky to run and test code locally. The local serverless tools simply didn't work for our project and they had so many limitations I'm skeptical they work for most non-prottypes.
Deploying a stack to your own developer environment works fine and is well worth doing, but the turnaround time is still painful compared to running a normal web framework project locally. Deploying a stack takes much much longer than restarting a local server.
Serverless isn't all bad, it has some nice advantages for scaling a project, but running and debugging a project locally is a definite weak spot.
This is nowhere near being true.