Frameworks for Serverless Development: Which One Should I Choose?
A summary and a few thoughts based on my experience
There are a number of frameworks and helpful libraries out there to build a serverless project on.
Choosing the right one is not an easy task though. It can be daunting to go through all of them in the quest for the perfect framework. And the pressure is high since we know that whatever framework we choose, we’re likely to be stuck with it for a long time.
The Serverless Mindset is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
In this post, I go through a handpicked selection of frameworks for serverless development. I have worked with most of them, so I have some thoughts that I’m going to (briefly) share.
Hopefully, this will help you make a more informed choice based on your project’s specific requirements.
For simplicity, I categorise frameworks as either full-stack or backend and opinionated or un-opinionated.
But these are not cut and dry categories. Most backend frameworks can also be used to set up a full-stack environment, and un-opinionated ones tend to have opinions here and there anyway.
The Serverless Framework is a favourite by the community. It’s used by many teams and organisations and has a vast plugin library. Getting help online is relatively easy.
I get the feeling that some people choose the Serverless Framework to avoid vendor lock-in since it is not directly associated with any of the big cloud vendors. This, in my view, is misguided. A quick glance at a
serverless.yml file for an average AWS setup will reveal plenty of custom Cloudformation code that would be hard to port to a different cloud provider.
Working with the Serverless Framework can be a frustrating experience if you’re trying to use resources that are not natively supported. You’ll typically end up with your functions defined using the Serverless Framework syntax, and everything else under the
Resources section defined using pure Cloudformation. I don’t find that very practical.
I recommend using the Serverless Framework if you care about community, ecosystem, and plugins.
Amplify is, in my opinion, one of the most exciting projects in the serverless space. It is owned and maintained by AWS, it is based on Cloudformation, and it comes with everything you need to build a full-stack application.
Amplify is not just a framework though, it’s a full ecosystem. It comes with a Studio (which gives you a visual interface for building your backend and for importing your Figma designs), a hosting service, and integrated CICD.
Amplify is relatively easy to start with and can be customised/extended using Cloudformation. Some Amplify users have complained about its lack of flexibility. This is, to an extent, part and parcel of what you get with an opinionated framework! But I’ve also seen it getting better since it was launched. AWS is pouring some real resources into this framework, and the progress is noticeable. Today, Amplify is not nearly as inflexible as it used to be (you can even extend it using the CDK).
I recommend using Amplify if you need a full-stack framework that just works and you’re happy to follow along with its opinionated patterns.
SAM (Serverless Application Model)
SAM is AWS’s answer to the Serverless Framework. It’s easy to use, it’s fully compatible with Cloudformation, and it’s well documented. It used to be my go-to framework for years.
It doesn't have nearly as much of a community as the Serverless Framework but there are a lot of official videos and resources from AWS. When needed, help is usually there to be found.
It comes with CDK compatibility, monitoring, and tooling for local testing.
I recommend using SAM if you need a simple framework that gets you started quickly, gives you full flexibility as you grow, and supports AWS resources natively.
I have used the CDK on and off for years on smaller projects. Recently, my team and I decided to make it our default choice moving forward.
Besides supporting all of the regular Cloudformation resources, the CDK has a bunch of extensible constructs that build on typical combinations of resources, secured and configured according to best practices.
I recommend using the CDK as a default, go-to infrastructure-as-code framework, as well as for most types of serverless development.
Full stack, opinionated
The new kid around the block is Serverless Cloud. It introduces a brand new idea, namely infrastructure from code. This basically means that you write your code, deploy it, and the framework figures out what infrastructure you’ll need to run it.
This is a great concept, and I think it has good potential. In practice, I suspect most people are still reluctant to get fully invested because the downside of not writing your infrastructure is that you can’t control it.
On the other hand, you can’t beat Serverless Cloud when it comes to simplicity. It makes getting a quick project out there a breeze.
I recommend giving Serverless Cloud a go. It may well represent the future of serverless development.
Serverless Stack (SST)
Full stack, opinionated
SST is, in my opinion, the one to watch (along with Serverless Cloud). SST is fully based on the CDK which SST extends and expands with a bunch of useful constructs.
SST comes with a number of useful packages, a web console, and even an environment for running Lambda locally.
The creators of SST have made it relatively easy to migrate from an existing CDK or Serverless Framework project, which is nice.
What I like about Serverless Stack is that all these tools and libraries can be used somewhat independently. I can treat an SST project just like a normal CDK-based project, occasionally making use of an SST library if I see fit.
I recommend using SST if you’re keen on the CDK but could use the extra tooling for full-stack development (such as the local lambda environment).
I would love to hear your thoughts! Have you used any of the frameworks above? Have you had a different experience with them? Are there other frameworks that I should have mentioned?