All said and done, I understand the pains behind trying to get serverless working locally, it's a pain to setup properly, doesn't work as well it should and it still let a lot of bugs going through the cracks. That said, it stills worth it the extra work.
Why? Shift left!
As soon as you can get rid of idiotic bugs and get your code up to shape, the better product you'll have at the end. Because it's also a pain to do that in the cloud no matter the tools you use (elk stack, new relic, data dog, splunk etc.). Turns out that in the end is also cheaper and faster. It's not a matter of being afraid to test in production, but how can you test it during all cycle, without impacting business and clients. Bugs in production are usually way more expensive than the latest MacBook pro (just high price hardware reference). I have friends that to this day still work on mainframes and shit is not pretty on production, mainly because of the arguments that you are defending. Also a big problem of cloud is conflict between using the same environment for different changes (and to spin up a clone environment in cloud is not a good alternative depending on the architecture).
So to sum it up, even though local environment is not even close to the the production environment, if it is well configured it can get a headstart for the devs to be able to start developing sooner and fixing bugs and constantly refactoring the code without worrying too much about other complex relationships you'll have in the cloud. Better to start small and then add a new layer of challenging new problems,cross that bridge only when you get there.
Why wait? By delaying pushing stuff to the cloud you may be fixing bugs to only create more bugs; I've seen it happen! Write your code locally, serverless deploy function -f functionName and 3 seconds later you can serverless invoke, curl or use Postman against that updated logic and see the logs stream live to you using serverless logs -t. There is no complexity, only feedback and the ability to get what you need working doing so right away in the ACTUAL environment it will eventually generate revenue in from day one!
Having used Serverless Framework for years, there's a problem with the deploy function approach. If you make a change to some common code that multiple functions rely on, it becomes really hard to figure out which ones need to be updated.
This is why we created SST (github.com/serverless-stack/server...), it hot reloads your Lambda functions, so you won't have to individually update them. And you can use Postman or curl while checking out your logs directly in the terminal.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
All said and done, I understand the pains behind trying to get serverless working locally, it's a pain to setup properly, doesn't work as well it should and it still let a lot of bugs going through the cracks. That said, it stills worth it the extra work.
Why? Shift left!
As soon as you can get rid of idiotic bugs and get your code up to shape, the better product you'll have at the end. Because it's also a pain to do that in the cloud no matter the tools you use (elk stack, new relic, data dog, splunk etc.). Turns out that in the end is also cheaper and faster. It's not a matter of being afraid to test in production, but how can you test it during all cycle, without impacting business and clients. Bugs in production are usually way more expensive than the latest MacBook pro (just high price hardware reference). I have friends that to this day still work on mainframes and shit is not pretty on production, mainly because of the arguments that you are defending. Also a big problem of cloud is conflict between using the same environment for different changes (and to spin up a clone environment in cloud is not a good alternative depending on the architecture).
So to sum it up, even though local environment is not even close to the the production environment, if it is well configured it can get a headstart for the devs to be able to start developing sooner and fixing bugs and constantly refactoring the code without worrying too much about other complex relationships you'll have in the cloud. Better to start small and then add a new layer of challenging new problems,cross that bridge only when you get there.
Why wait? By delaying pushing stuff to the cloud you may be fixing bugs to only create more bugs; I've seen it happen! Write your code locally,
serverless deploy function -f functionNameand 3 seconds later you canserverless invoke,curlor use Postman against that updated logic and see the logs stream live to you usingserverless logs -t. There is no complexity, only feedback and the ability to get what you need working doing so right away in the ACTUAL environment it will eventually generate revenue in from day one!Having used Serverless Framework for years, there's a problem with the deploy function approach. If you make a change to some common code that multiple functions rely on, it becomes really hard to figure out which ones need to be updated.
This is why we created SST (github.com/serverless-stack/server...), it hot reloads your Lambda functions, so you won't have to individually update them. And you can use Postman or curl while checking out your logs directly in the terminal.