TL;DR
⚡ Opt for SST for new, simpler projects, rapid delivery, owning NextJS infra, or when having limited AWS expertise.
☁️ Go with CDK when integrating with or migrating existing infrastructures, for large enterprise projects, or when dealing with intricate infrastructures.
Why ❓
If you're wondering which serverless framework to adopt for your next AWS project in 2023, you're in the right place.
Whether you're starting from scratch or working on an intricate enterprise infrastructure, this comparison dives deep into the pros, cons, and best use cases for the top contenders.
Stick around and let's ensure your next choice is an informed one 🧠.
The contenders 🥊
Here are our three contenders
1 - Serverless + AWS CDK + Lift: An integration that amps up the traditional Serverless Framework with Lift's static frontend construct and CDK's robust infra definition.
💡 Have a look here to understand how the three are bridged together
2 - AWS CDK: AWS's native toolkit, offering a high-level, typesafe approach to AWS resources.
3 - SST: A TypeScript first framework streamlining serverless apps on AWS, from debugging to deployment.
Now let's dive right into our data-driven face-off between the frameworks. See how they stack up against each other across pivotal criteria. 🥊
Comparison Table 📈
| Criteria | Description | 1️⃣ Serverless Framework + CDK | 2️⃣ AWS CDK | 3️⃣ SST |
|---|---|---|---|---|
| Stars / Downloads | 45k ⭐ - 1.2M downloads/week | ✅ 10k ⭐ - 1.6M downloads/week | 17k ⭐ - 35k downloads/week | |
| Release frequency | 1 / month | 7 / month | ✅ 36 / month | |
| Ease of contribution | Codebase complexity and accessibility, communication with maintainers | "JS codebase Complex codebase" | ❌ Slow processes hard to dev locally | 🟠 Easy to chat with the team (Discord) Codebase Typescript + accessible PRs are very slow to merge |
| IaC Type-safety | Typescript definitions for all resources | "Base is YAML, but typescript support with @serverless/typescript. Serverless Framework resources are not natively typed." | ✅ Fully typed | ✅ Fully Typed |
| Lambda Definition | Ease to define a lambda resource and its triggers | ✅ Config file per lambda Triggers for many services + cron | 🟡 Lambda configuration is verbose. No abstraction for lambda triggers, need to define them manually. | ✅ Both inline and verbose lambda configuration are available. Trigger definitions for API Gateway, Eventbus, SQS |
| Other Resources Definition | Ease of defining resources such as S3, DynamoDB, EventBridge, SQ | 🔴 referencing serverless provisioned resources is hard CDK / serverless stacks are dissociated | ✅ | ✅ |
| Framework flexibility | Extending the capabilities of the framework to fit your need | ✅ possible with plugins | ✅ low level framework, you can do what you like | 🟠 still a work in progress fallback to full cdk (losing other features) |
| Static Frontend Deployment | Existing solution to deploy a static website | ✅ Lift | 🟠 requires rebuild or use of less popular construct | ✅ StaticSite in SST |
| Next.js App Deployment | Existing solution to deploy NextJs server | 🟠 amplify plugin serverless-nextjs not maintained | 🟠 amplify 🔴 cdk-nextjs (not well maintained) | ✅ NexjsSite in SST |
| DevX / Debugging lambdas | Ease of debugging lambda executions | 🟠 | ❌ | ✅ live debugging |
| Debugging deployment | Ease of debugging fails during deployment | ✅ | ✅ | 🟠 SST adds a layer of liability |
| AWS Features completeness | amount of supported features | 🟠 few releases, few contributors to implement new features | ✅ | 🟡 small delay (~1week) |
| Multiple Runtime Deployment | Support for deploying multiple AWS Lambda runtimes | ✅ | ✅ | ✅ |
| Multi-stack Definition | Ability to define multiple stacks in a single file | ❌ 1 serverless.ts per stack | ✅ | ✅ |
| Nested Stacks Support | Support for AWS CloudFormation nested stacks | ❌ | ✅ | ✅ |
| Documentation | quality of the frameworks documentation | 🟠 yaml, no ready-to-use snippets but still quite complete | 🟡 | 🟡 |
Our recommendation 🥇
Opt for SST if one of:
- Starting a fresh project of low to moderate complexity
- Prioritizing rapid delivery of value
- Implementing NextJS without Vercel
- Limited AWS expertise and need a more guided approach
Go with CDK if one of:
- Integrating with or migrating an existing infrastructure
- Engaging in large corporate projects deeply integrated with the company's Information System
- Handling intricate and detailed infrastructures.
Wrapping Up 🌟
Deciding between SST and AWS CDK comes down to the unique needs of your project. As the serverless landscape evolves, so does our understanding.
Join the discussion, bring your experiences to the table, and please challenge our criterions! Let's journey together towards a more informed decision-making process in the serverless world. 💬🚀
Top comments (5)
SST doesn't support multi-account and multi-region deployments currently which AWS CDK natively does. Please be thorough with your research before publicly advocating solutions that might lock people in and limit their usability. For reference, refer this issue - github.com/sst/sst/issues/1299.
We based our analysis on a comprehensive, yet selective, list of criteria. If someone has a specific need that isn’t covered by these, they should conduct their own research. 🤓
We didn’t include multi-account deployment, but your input will certainly help others make more informed choices. Thank you 🙏!
How do you compare 3 frameworks by excluding a core feature which the other two support? Doesn't makes sense!
Your ‘core’ feature might not be essential for everyone. We’ve been deploying serverless apps for years without needing it.
We didn’t mention the SST console, which is a ‘core’ feature for SST, but hey, who’s keeping track? 😉
In the end everyone should pick the best for their use case, we just help people decide 📚
Well, you put in a point called "AWS Features completeness" and put in "small delay (~1 week)". Considering AWS's official tooling allows these features and SST doesn't even after 2 major versions, it's definitely nowhere close to feature complete.
Coming to SST Console, yes, it's a good feature, you should've added it and also added that it will be moved into a separate paid product.
If you do not clarify the limitations of a platform against another you're not helping anyone. Hopefully that makes sense.