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.
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.
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.
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.