This is going to be a short post, with the idea of being an intro for a future serie of more extended ones if seems interesting and if I get some time.
I wrote a post weeks ago sharing some thoughts about serverless architectures and their tradeoffs.
I had a previous bias on the use of Serverless solutions (specifically on serverless functions). I was thinking of them just as a way to trigger simple tasks without caring too much of managing resources, but I've never thought of build an entire system based on them. Things and thoughts change and now I see a big advantage on them.
But serverless architectures and the frameworks that allow to work with them don't tell anything about how to build stuff, they just provide a way to build and deploy easily the systems.
Currently, we're having some funny time refactoring properly part of our core codebase. With several years of tech debt accumulated, some of the services developed have an (ironic) interesting coupling to the serverless way of thinking (like invoke lambdas inside other lambdas, as if it was an http request). Yep, this is giving us some hard time while refactoring things.
But, the solution to our problem was quick to find and is quite simple to understand (not as simple to implement, but we're doing it little by little).
With inspiration good old classic hexagonal architecture. , we're starting to rebuild things without caring on how the entrypoints are. Some conclusions that we arrived were:
- Treat serverless solutions as another framework and just avoid coupling to them.
- Thinking on each lambda as a controller or as an event handler that will call to internal layers, just as another part of the infrastructure layer. Not caring about which type of trigger will call our services, just defining contracts to use them.
- Build the app from the domain to the external layers even if it's a simple solution . Once done that, you won't care if the entrypoints are done via Lambda, Azure function or via expressJS routes and they will scale easily.
About the internal calls to other lambdas... we're refactor them to be more event-driven. Or, for tricky cases, wrapping adapters over them (we're having in parallel a lot of conversations about domain modeling lately)
And, for the major architecture... Abstract also to the idea that services are run serverless (keeping an eye to performance/cold starts and similars, though). Build services as if they're another microservice more.
Top comments (0)