Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: There is a growing number of tools for building and deploying serverless applications in the cloud. We are going to focus on two of the main alternatives, AWS SAM and the Serverless Framework. We are going to compare the features, the usability, and also make some speculation about the future of these two different products. If we do a good job by the end of today's episode, you should know which one you are going to choose for your next project. My name is Luciano and I'm here with Eoin and this is AWS Bites podcast. AWS Bites is sponsored by fourTheorem. fourTheorem is an AWS consulting partner offering training, cloud migration, and modern application architecture. Find out more at fourtheorem.com. You will find this link in the show notes. So, we are ready to get started and let's talk about Serverless Framework and SAM, what are these tools for?
Eoin: Serverless Framework and SAM, they are both infrastructure as code tools. I suppose that's the first thing we can say then. They are geared towards serverless applications, but the applications you build and deploy with them, they don't have to be serverless. They are useful for deploying AWS infrastructure in general and just providing kind of a layer of convenience over CloudFormation. So, CloudFormation, we have covered this in previous episodes, especially in our very popular CloudFormation versus Terraform episode.
CloudFormation is very explicit and it can be very verbose. So, with Serverless Framework and SAM, you're providing a more concise user-friendly interface that's just a little bit more implicit and provides a lot of shortcuts and defaults for you. They are designed, I would say, to make the process of writing FaaS functions, so Lambda functions easier, but they also provide some convenient wrappers for APIs and step functions and things like that. And they also not just allow you to write the infrastructure as code template in an easier way, but they provide certain tools for building, packaging, deployment and local invocation as well. Doing all that stuff manually is a lot of work. So, maybe at this point, we can just give a quick run through what are the highlights of Serverless Framework, what are the highlights of SAM, and then we can dive into some of the, I suppose, the more detailed differences between the two. So, let's talk about Serverless Framework and for many, this is still the original and best. It was very popular when it first came out and it was probably, I would say, very instrumental in helping many people get excited and start adopting serverless in the first place. I would say the community, all of us serverless developers owe quite a lot to it and to the maintainers. It supports multiple cloud providers, which sometimes we forget about, especially if you're working in AWS all the time, but it has backends for Azure and Alibaba cloud and Cloudflare as well. So, you can deploy to multiple cloud providers with it.
What that means really is that the tooling remains the same, but of course, your code and your configuration syntax will be significantly different depending on the provider you choose. And a big thing about Serverless Framework is its plugin ecosystem. And we'll talk a little bit more about that. So, that's the Serverless Framework. And then a couple of years ago, SAM came along. So, SAM has only been generally available since 2020. And it's an open source project as well, but it's developed and managed by AWS and it targets AWS as a cloud provider alone.
So, the way they implement it is as an extension to CloudFormation using something called cloud formation macros. What that means is that more of the deployment with SAM is happening cloud side. So, it's managed by the CloudFormation service for you. Whereas with Serverless Framework, the template is compiled wherever you're doing your build and deployment on your laptop or on your CI CD server. So, you could say that the SAM approach is purer in that it's one that pushes more of the deployment responsibility to AWS to manage. An interesting point to know, we've talked a lot about CloudFormation here. Recently, they announced SAM Terraform support. Now, that might excite a lot of people. It's in preview at the moment, but it isn't trying to allow you to do everything you can do with SAM with Terraform. It just allows you to run a limited subset of features. So, if you've got Lambda functions in a Terraform project, you can use the SAM CLI tooling to build and invoke them locally. That's all it's doing for you. That's the headline features for SAM and Serverless Framework. Luciano, do you want to dive into some of the ways we can compare and contrast SAM and Serverless Framework?
Luciano: Of course. I will say that the first main difference is a little bit conceptual. I think it's kind of that difference between opinionated versus less opinionated and more flexible. I would probably put SAM into the more opinionated bucket while serverless tries to be a lot more generic and flexible. And just to give you an example, SAM doesn't allow you to modify a resource if it's not effectively declared in your stack. So, you need to be a lot more explicit.
And this is not something you can work around. It's just the way that the framework is designed. While SLS will give you ways to do that if you need to. And there are other differences that go in this direction. For instance, a lot of things in serverless are done through plugins. So, there is a natural approach to just build a plugin and you can extend with additional functionality if you want to. It's not as easy to write plugins in SAM. And we will talk a little bit more about that as well. Another big difference is the template syntax. Even though they both use mainly YAML, or at least by default YAML is the main thing you would use to write the SAM templates or the Serverless Framework templates, I would say the Serverless Framework is, again, way more flexible than SAM. In Serverless Framework templates, you have a very expressive sublanguage. Like, you can nest expressions into the YAML. And these expressions can basically allow you to interpret data from different sources. And one of the most impressive ones, and you can just say, get data from this JavaScript file. And what happens behind the scenes is that it's going to literally invoke the JavaScript file so you can build your own custom logic. And then whatever the JavaScript file is exporting is the data that gets interpolated in your own template. So, that's one of the easiest ways that I've seen in any system to basically, in any configuration-based system to allow you to write your own dynamic code whenever you need something a little bit more bespoke. And what's even more interesting is that in recent versions of Serverless Framework, you can even avoid YAML entirely. And you can write the configuration template in JavaScript itself or even in TypeScript if you want to. And that opens up for even more dynamic scenarios, because of course that's JavaScript code that gets interpreted when the template is executed.
So, you can effectively run JavaScript code at that point in time if you need to do something even more custom. And I've seen some interesting examples where people will use that, for instance, to use to generate OpenAPI documentation using maybe schema definition that they have defined already in JavaScript or TypeScript. So, this is just to give you a feeling of how powerful that approach is. You might argue that it's not like it loses a lot of the declarative that's typical of this kind of systems, but it's an interesting trade-off and in some cases it might be worth exploring this particular approach. Now, going back to SAM, SAM, as we say, is a lot more strict. It gives you a syntax that is much closer to the CloudFormation syntax. And it's basically kind of a trimmed-down version of that CloudFormation syntax because it's just giving you some macros that will be later on expanded in the cloud into proper CloudFormation syntax.
So, it's just a way to basically allow you to write more concise syntax for functions, event triggers, step functions, APIs, policies. But at the end of the day, when the code is getting prepared to be deployed in the cloud, it will be expanded again to a fully-fledged CloudFormation. The way that you can interpolate variables is much more limited than Serverless Framework because you can only use parameters and variables that are the standard ones available already in CloudFormation. You could be hacking that a little bit if you create your own pre-processing step. For instance, you could use any templating language that will eventually emit that SAM yaml, but of course it's a bit of a hacky way and this is something that you will need to build yourself.
It's not built-in in the tool. Another interesting thing regarding syntax is the recently SAM introduced cfn lint, which is a tool that has been available for a while but now is kind of built-in into the SAM experience and it's a very nice tool that allows you to validate templates just to make sure that the syntax that you are writing in that yaml is conformed to whatever syntax CloudFormation is going to be able to accept. So, it's an extra validation layer that is closer to effectively the target that you have there. Now, let's talk a little bit about languages that are supported and the languages that are actually used to write these tools because I think that gives you some ideas also why one is more flexible than the other, at least in my opinion. Serverless Framework, you will probably notice using it that it's very well built for the Node.js experience.
Like, kind of everything works out of the box if you're writing Lambdas in Node.js and I don't think this is a coincidence. I think it's probably a natural consequence of the fact that Serverless Framework itself is written in JavaScript so the authors of the framework probably had a lot of expertise with that particular language and they probably spend a lot more time fine-tuning the experience of using Serverless Framework for writing JavaScript code.
But, of course, other languages are supported but generally they require plugins. Again, that idea of extensibility through plugins. So, your mileage might vary depending on whoever is writing these plugins, the community that is maintaining them and how much effort was already put into these particular plugins. SAM is well known to work well with JavaScript and Python but supports other languages natively and just if you're curious to know, if you can check out the SAM repository, you will notice that SAM is written in Python. So, not surprising that it doesn't allow you, for instance, to embed JavaScript files into the configuration file because it would be a lot trickier to kind of execute them with something written in Python.
How do you get started? Let's compare the experience between SAM and Serverless Framework. Serverless Framework is a JavaScript project and as such is provided as a Node.js module which basically means that if you are well used to the Node.js ecosystem and all its tooling, you can just do npm install serverless and basically you have Serverless Framework available. And that means that you can even easily embed Serverless as a development dependency for one of your projects. So that way you can have, for instance, two different projects, two different serverless projects and one project could use Serverless v3 for instance, another project could use Serverless v2 and all of that is managed seamlessly by npm. So you can have two different deployment scripts and the two executables, Serverless v2 and Serverless v3, are totally managed independently and they are logged in into their own projects.
With SAM, it's a little bit different because SAM provides you native binaries for the major operating systems, Windows, Mac and Linux, so you'll need to download them and install them in your own system. SLS is well known to have kind of templates for serverless projects so you have this command, this sub-command in the SLS CLI called sls create which can be used to say, for instance, I want to start an API in TypeScript and there will be a specific command that you can run that is just going to scaffold all of that boilerplate code for you. There is something similar in SAM called SAM init so you might get slightly different templates of course but the idea is that you don't have to start from scratch, just pick a set of technologies and probably there is a template ready for you that gives you most of that boilerplate. Now, SAM might be a little bit more user-flendy because when you run SAM init it's interactive so it will let you pick different options in a more interactive way, while SLS is just probably cloning a git repository where all the code gets provided to you.
Build and deployment might be another interesting topic and in this case I think SAM is probably a little bit ahead than Serverless Framework because the first thing is that SAM uses CloudFormation change sets and this is something that serverless didn't do for a long time, only recently they added support for that but there are important differences there. If you don't know, CloudFormation change set is basically a feature of CloudFormation that allows you to, rather than just deploying the differences in a template, it will basically do a preview for you, it's basically going to assess what is going to change and then it's something that you can effectively decide I want to go ahead and deploy this or maybe you realize it's not really doing what you expected so you can just stop that particular deployment. So with SAM, basically in your deployment process through SAM it will very obviously show exactly the effect of this change set so it's very easy for you to visualize that something has changed which is actually going to be deployed and decide whether you want to proceed or not. With SLS that kind of happens as well but a little bit more behind the scenes so you'll need to go into the AWS console to actually see what's going to be the effect of the change set so it's a little bit more involved while I think the experience with SAM is much smoother and user-friendly. Another interesting thing in terms of building is that SAM uses Docker out of the box which can be very convenient when in your project you have native dependencies for instance in Python or Node.js. If you are working on a Mac machine or a Windows machine probably the local files that you have for these native dependencies are not going to work out of the box in a Lambda environment which is a Linux-based environment and maybe with a very specific architecture that might be different from the one in your particular development machine. So when you use Docker the build process is actually done in an environment that is going to be much closer to the environment of Lambda so the risk of packaging something that is not going to work in the target architecture is much more reduced. So this is very convenient. You could do the same thing with serverless but it's not really a well-known feature because you'll need to explicitly pass a flag to enable that. Another final point about deployment which is really interesting I think is one of the most innovative features of SAM and one of the strong points of SAM is a feature called SAM Accelerate which is relatively new. We mentioned it in one of our previous episodes, episode 19 where we talk about the serverless development experience. So basically SAM Accelerate is something that is meant to reduce the feedback loop that you have when you are developing a new feature. You do some changes and in order to see if these changes in your code actually do what you are expecting them to do you probably need to do a deployment and test it in the cloud and this is generally something that takes minutes so it's kind of interrupting your development loop. It's distracting and it might be frustrating if you have to do it over and over. What SAM Accelerate does is basically automatically syncing your code as you do changes. You lose some of the guarantees like you are not for instance able to do rollbacks as easily as you would do with a full deployment but it gives you a very quick feedback loop to see these changes almost in real time so it might be really a big accelerator in that development life cycle. So definitely a really interesting feature that if you haven't tried yet I really recommend you to try because you can have that feeling that you are developing locally while almost immediately being able to see the changes reflected in a real cloud environment. What do you think? Is there anything else worth mentioning in the difference between SLS and SAM?
Eoin: Yeah that was really a comprehensive set of differences. Maybe a few small things I could add on. One that really bugs me is that with service framework it still doesn't work with SSO credentials which is like I think a lot more people are using SSO for sign-on now or IAM identity center as it's now called. There's been a GitHub issue open on the serverless framework for a couple of years and recently they've commented on that issue that they just don't have time to add the support. It's been unfortunate SAM supports SSO credentials already.
Maybe as well for people who are thinking about how they structure their project and dividing their project in a repo into multiple services or stacks. SAM supports nested stacks. That's a reasonably recent addition I believe. It's a nice way of organizing your project and you can deploy the top level stack and it will deploy whatever changes are necessary within all the stacks underneath. Serverless Framework did have a plugin to support that but it's not really not maintained like a lot of the less used plugins. But it does have a really good new feature called serverless compose that allows you to manage and deploy multiple stacks together. So that was a really nice one. Might also be worthwhile talking about how good these two tools are at supporting new AWS features as AWS changes and I think for both it's pretty good actually. SAM support is generally pretty good now. CloudFormation support is usually a lot faster than it used to be when it comes to supporting new features in AWS services. But the serverless maintainers when it comes to new features like when container image support came out or ARM graviton processor support came out for Lambda, those are significant chunks of work for those teams but they really seem to pull those out really quickly and get them released out to the community which is pretty fantastic.
When it comes to permissions, getting permissions right is always a tricky thing about building AWS applications and serverless applications. Now SAM has a few things that are attempts at making this easier. One is they have some pre-baked policy templates. So these are just ways of kind of reducing the amount of boilerplate you have to write for IAM. And the other one is a new feature called SAM connectors and this is when you've got this kind of pseudo resource called our connector that you create and it allows you to say for this DynamoDB table give access to this function and make it give it write access or read access. So the idea is to make it a little bit more understandable I suppose for people who don't understand IAM. I'm kind of in two minds about it really I'm not sure I like any of these things. I think when it comes to IAM it's much better to be explicit even if it means more verbose syntax and just understand what you're doing and be very fine-grained. With the Serverless Framework you've got a nice way to specify IAM statements for functions especially if you add in the very common IAM roles per function plugin. So I would much favor that approach to it and not to try and dumb it down and provide this kind of half solution to simplifying IAM. Let's talk you mentioned JavaScript so I might just talk about transpilation. If we've got esbuild that's supported in SAM already for TypeScript and JavaScript new versions of the language so the Serverless Framework you can add the serverless esbuild plugin and it works too. So you're generally set for both of them and then both of them provide local development experience so you can do local invoke on both of them and you can use a local API gateway simulation. The only difference with Serverless Framework is that the API simulation is provided with a plugin serverless offline where SAM runs it locally for you automatically and then I suppose there's a big standout one with CI-CD for SAM and I really like this one now because it allows you to basically bootstrap a complete continuous integration pipeline and deployment pipeline using any of a large set of providers so CodeBuild and CodePipeline within AWS but it can also support Jenkins or GitLab CI-CD, Bitbucket and GitHub Actions. So this will create a pipeline which will deploy to multiple environments and also supports feature branch deployments. We had an episode a while back about OIDC providers and why you should use that method for getting your GitHub Actions to authenticate with AWS. SAM will create that for you so all of the complexity of creating that and creating the associated role is managed when you bootstrap your SAM pipeline so that's really nice one. And maybe just lastly before we start wrapping up and giving our more opinionated view on which you should choose when it comes to just extensibility you mentioned the plugin ecosystem in Serverless piano and we can give an example because you and I and a few other the fourTheorem team are working on a really significant plugin for Serverless Framework which now supports SAM as well it's called SLIC Watch and it's for adding alarms and dashboards into these projects automatically. It has to basically look at your whole template find out what functions API step functions DynamoDB tables you have and creates alarms and dashboards for you. When it comes to Serverless Framework it's pretty easy to write a plugin. The documentation is a bit hairy but there's enough examples out there where you can figure out how to use it. When it comes to SAM your only option really is to create another CloudFormation macro and then I suppose that's in it's nice in some ways because it's similar syntax to SAM itself you just add another macro and CloudFormation service is going to do that transformation for you but the thing is deploying macros into people's accounts it takes a bit of work a little bit more work than just adding a serverless plugin because you have to deploy them we can't just publish a macro to the public registry in CloudFormation you can't do that only AWS can do that so it's a pity we can't do that and it just makes it a little bit more of a step but once you do that it works the same you know we can use 90 of the same code to deliver to deliver a slick watch whether you're using Serverless Framework or SAM because the macros are just implemented as Lambda functions and we can run them as JavaScript, same JavaScript code, so I think we've covered fairly exhaustively all the differences between these two tools so maybe this is the part that people really want to know which should they use which direct which which one is the one that people should choose for the project today and what's the future look like, where are they going?
Luciano: Yeah that's that's definitely I know opinionated piece but we're going to try to bring some evidence into the answer like we're not going to say pick one or the other but we are just going to give you some indications like if you favor a specific thing maybe one tool is better than the other so definitely I like the sum generation of pipelines that you mentioned this is a really amazing feature it is always quite painful to generate pipeline codes and then testing it you probably end up doing millions of deployments just trying to figure out is my syntax correct does it really do what it wants it to do so the opportunity to just bootstrap something that it's reasonably doing most of that work and for different kind of cicds it's an amazing feature so if that's something that you really care about and something that you have been spending a lot of time in the past probably going with some and leveraging this feature can be a big enabler for you and your team if you are targeting other cloud providers not just AWS that's an argument for for Serverless Framework because of course some doesn't even try to support other cloud providers so your only option really is to use Serverless Framework there between the two so again worth remarking that your code and your configuration are going to be significantly different there is no magic cloud abstraction cloud provider abstraction but the tooling remains most of the same so you could be using the same tool for both let's say AWS and Azure if you go with Serverless Framework then if you really want flexibility of configuration again this is another point in favor of Serverless Framework like if you really have requirements that force you to have very dynamic data that gets interpolated into your templates you're going to have an easier time just going with Serverless Framework because with some you'll need to figure out your own pre-processing logic if you want to do something like that and this is also similar if you need to write custom extensions maybe you want to do something special at build time you have I don't know very specific build requirements or maybe you need to generate pieces of CloudFormation dynamically depending on different parameters it would be much easier to write your own custom plugin for Serverless Framework rather than having to create your own CloudFormation macro get it that deployed and then integrate it with some so another point in favor of Serverless Framework if you care about that kind of degree of extensibility so I would say that all in all Serverless Framework used to be a lot more mature than some so there might be a little bit of an opinion if you search around that some still new and not mature enough but i think this is kind of slowly changing because these days some really has caught up with all the features of well at least most of the features or the main features of Serverless Framework and it has even some new features like the pipelines that we mentioned or the ability to synchronize your code with the cloud in real time that makes it really a well-worthy choice I personally used to choose a lot Serverless Framework as a default in the past these days i'm kind of always thinking a little bit more about it like if I don't really need that level of extensibility i'm probably going to default to some because it feels like a safer choice going forward and this is probably a good pivot point where we try to speculate a little bit more about what is going to be the future of these two projects because this might inform your decision on whether you want to pick one or the other for a given project so again this is probably the most opinionated piece of this episode so take it with a pinch of salt but our opinion is that it feels that AWS is investing a lot on some so we expected that it's only going to get better and better and they are both open source projects but it's important to see that ownership piece like while some is clearly owned by AWS and it's in the best interest of AWS to keep it up to date and add more feature and make that development experience as nicer as possible because it brings more business to AWS itself the Serverless Framework is a lot more open and as a community but at the same time the project itself is backed by a company so it's a little bit difficult to understand how is this company going to get a return there are investors of course they need to pay back on that investment and even if they care about the community and the user experience there might be decisions there that we cannot predict that will affect negatively or positively the experience of the user in the end so I think there is a bigger question mark there on what's going to be the future of Serverless Framework when we compare it with some and I have a slightly related note to that point which again is just my own bugbear with Serverless Framework I used to think that the serverless documentation was quite good like the documentation itself on the website but also a lot of related blog posts and it was very easy when I was doing serverless in the very early days and using Serverless Framework to just search for anything and you will easily find either a documentation or a blog post and find the answers you were looking for these days for some reason and quite unexpectedly it is not as easy anymore I find myself myself ending up more and more on the commercial side of the offering that Serverless Framework has to give to users rather than actually finding the documentation for the open source tool that I'm looking for I don't know if that's intentional just to drive more business to the the commercial offering or it's just a side effect of trying to combine a commercial offer together with an open source project so that the website itself becomes a little bit more convoluted and even organizing the content gets of course more difficult so I don't want to blame necessarily the serverless company for trying to make revenue out of this project but the net effect on the users is that it gets more confusing to figure out how to use the open source part of the project so just to conclude I will say that it is also fair to say that SAM doesn't really have a great documentation either it's probably okay but sometimes when you want to do something that is slightly off the standard it's not very easy to understand how to do that so maybe this is just a suggestion for AWS to try to invest a little bit more time in trying to document different kinds of setups different more advanced features that you might have with SAM and maybe provide a lot more examples because those will will definitely help people to get started with all the different features that you might have issues and all the different kinds of permutations of projects. Okay I think that that's probably more than enough that we want to cover for this episode and we gave you a lot of opinions but of course we will be curious to know what is your opinion do you prefer some do you prefer serverless what are you using for your current projects and are you going to be using something different in your next project and of course this is only a portion of this conversation because of course there are other tools there is CDK there is Pulumi there is Terraform so if you don't use either SAM or Serverless and you end up using other tools, we would love to know why what are your requirements why did you make this choice. And maybe we can do another episode in the future where we try to explore some other of these tools and compare the differences. So thank you very much for being with us today and we look forward to seeing you in the next episode.