It’s nice to see the serverless movement and its applications. However the fact every (public) cloud provider does it differently is killing it (incompatible logic/interfaces). Right now, serverless is merely shifting complexity of apps to cloud services. Cloud services with a lot more logic (lines of code) that does a million other things than what your application needs. That oftens means much more (uncovered) bugs. In order to have better control and predictability there has to be standards and minimizing depth of code.
I’m convinced serverless is the next after containers; but only if it becomes a standard that can encapsulate services in building blocks that you can easily connect with each other and very predictably behavior. We are not there yet, hopefully soon.
The only think that you need to make your code work with Lambda is a function that takes in an event body and a Lambda context. If you are following standard architectural best practices, your lambda entry point should just be validating your event, mapping it to your business domain and remapping the result. You should treat your lambda event just like you would an action in your controller in most MVC frameworks aka “skinny controllers”.
This is a standard “onion architecture” with “ports and adapters”.
Sound development principles don’t get thrown out of the window just because you “move to the cloud”.
I’m convinced serverless is the next after containers; but only if it becomes a standard that can encapsulate services in building blocks that you can easily connect with each other and very predictably behavior. We are not there yet, hopefully soon.