What's the difference between AWS SAM (Serverless Application Model) and serverless framework?

You can check this article comparing SAM and Serverless

The key differences listed on that page are as follows

The Serverless Framework is a framework that makes it easy to write event-driven functions for a myriad of providers, including AWS, Google Cloud, Kubeless and more. For each provider, a series of events can be configured to invoke the function. The framework is open source and receives updates regularly.

The AWS Serverless Application Model (SAM) is an abstraction layer in front of CloudFormation that makes it easy to write serverless applications in AWS. There is support for three different resource types: Lambda, DynamoDB and API Gateway. Using SAM Local, Lambda and API Gateway can be run locally through the use of Docker containers.

Both frameworks have in common that they generate CloudFormation. In other words: they both abstract CloudFormation so that you need to write less code to build serverless applications (in the case of SAM) and to deploy Lambda functions (for both SAM and Serverless). The biggest difference is that Serverless is written to deploy FaaS (Function as a Service) functions to different providers. SAM on the other hand is an abstraction layer specifically for AWS using not only FaaS but also DynamoDB for storage and API Gateway for creating a serverless HTTP endpoint.

Another difference is that SAM Local allows you to run Lambda functions locally and to spin up an API Gateway locally. This makes it easier to develop and test Lambda functions without deploying them to AWS. With the Serverless framework you can also invoke Lambda functions from the command line, but only if they are deployed to AWS and available through API Gateway.


Biggest differences between SAM and SF:

1) SAM is AWS only; SF supports multiple backends so it supports deployment for multi/hybrid cloud application. SF also support kubernetes backend.

2) For AWS, both SAM and SF templates compile to Cloudformation (CF). SAM has the ability to use Transform which is essentially macros for CF.

3) SAM is written in Python; SF is written in Javascript.

4) SF has plugins which allow you to run any codes (including non-Javascript); which effectively means it's possible to go beyond limitation of Cloudformation (CF) since there are always something (new-ish) that isn't supported in CF yet. Plugin system is also extremely flexible and can be very useful.

5) SF variables system is more flexible which allow you to do dynamic include based on existence of other parameters (such as stage); SAM variables are much closer to CF.