Several months ago, I started working in a small startup. Given their growing volume of clients and needs and due to the small team, they decided to build most of their core infrastructure through AWS lambda functions, using the serverless framework for it. So, we’re running our whole business through lambda and it works! It’s amazing to see that a whole working business is built over such a simple architecture. Before working here, I just saw lambdas as a way to build crons or small tasks, but it could be bigger than that.
After working with it for some time, I’m starting to see a lot of advantages but some cons too. Summarized, it’s a really good way to make things scalable and provide a unified framework to build things without worrying too much about infrastructure issues. But, it has some trade-offs to be known too.
Pros:
- Serverless: Its name says it, don’t worry about servers. Just code, deploy, and it will work. In these days of overwhelming complexity through containers and Kubernetes, it’s fine to avoid these kinds of worries.
- Replicable environments: Prod and Dev environments can be easily replicable at 100%! No need to worry about environments too!
- Easy deploys, easy rollbacks: Through the Serverless framework, being platform agnostic is quite easy (not 100% transparent, though).
- All of this allows building and shipping things really fast!
Cons and Trade-offs:
- Framework limitations: The Serverless framework does not provide any information about how to build your stuff. It just provides an easy way to build and deploy a Serverless infrastructure on a lot of cloud platforms. The way that it avoids the server problems and configs does not mean that it helps you properly develop things. You can develop HORRORS (coupled lambdas, twisted code, etc.) and deploy them easily. Its advantage is in avoiding dedicated staff for infrastructure, not for development.
- Provider lock-in: You’re a slave to a cloud provider. Someone will manage your servers, response times will depend on them, scalability too… if you work with Serverless, make sure you’re able to migrate to other alternatives easily.
- Complex YAMLs: You will be defining too much stuff through YAMLs. Be sure that you’re writing them properly.
- Local development issues: Local development can be problematic if you start to couple lambdas. One lambda development works fine, two at the same time don’t. They don’t react to external events or invocations locally quite well, so you will need to take care of how you structure your Serverless architecture.
Having some cons, I think that it can boost the productivity of a team and fits perfectly for MVP constructions. But, think about it more as a synergy than as a Swiss knife. A poor codebase built through a Serverless architecture won’t be better than a poor codebase on-premise. But, if things are built properly, the boost of productivity is gigantic.