Serverless - it’s a pretty cool tool that makes it easier to deploy apps to the public cloud.
But I was a bit confused. It turns out that Serverless (or
sls) essentially has two different products, both under the “Serverless” name.
Both of them help you create objects in the public cloud to deploy your app.
But there is a fundamental difference in how they run.
In this article I’ll look at both.
This is the original, fully client-side Serverless project. It’s been around for a few years now.
It’s essentially a deployment management tool for AWS (and other clouds too, like Azure, Google Cloud and more.)
It looks at your application’s configuration, and provisions the cloud resources that you need.
How it works
sls CLI reads a
In this file, you declare a provider (e.g. AWS), and the things that you’re deploying (functions, database instances, etc.).
sls creates the appropriate objects in AWS for you (usually using an AWS CloudFormation template), creates roles and deploys your code, if you have any.
In the words of Serverless themselves:
Under the hood, the Serverless Framework CLI deploys your code to a cloud provider like AWS, Microsoft Azure, Google Cloud Platform
You can tell if you’re using plain Serverless Framework, because your
serverless.yml looks like this:
service: my-burger-api provider: name: aws ... resources: ...
When you’re using Serverless Framework, the deployment model is:
your computer → AWS (or other cloud).
It’s a bit like…
A version of AWS SAM (AWS’s serverless development tool) which can deploy to any cloud.
So, instead of learning a cloud tool for each provider (see supported providers), you can just use one tool to deploy to them all.
This is a new offering from Serverless which went GA in 2020.
Serverless Components live in the cloud.
With Components, all of the decision-making about what to deploy, and the deployment itself, is done server-side, through serverless.com, in their “Components Engine”.
Serverless Components is now powered by our innovative Components Engine, which performs all deployments
The catch is, you can’t deploy just anything, you can only choose from the Components that are available.
How it works
You write a
serverless.yml file, and declare which
component you want to use.
Each Component satisfies a specific, opinionated use case – like “Express.js app”, “Lambda Cron job” or “GraphQL app”.
To use a Component, you pass it some parameters called inputs. It uses these inputs to provision resources in AWS for you. Then, it shows you the result in a web UI.
You can tell if you’re using Components, because your
serverless.yml will look something like this. Here I’m using the Express component:
component: express name: my-api inputs: ....
So when you’re using Serverless Components, the deployment model is:
your computer → serverless.com → AWS
This means that your AWS credentials pass through serverless.com. And also that you’re tied to their platform.
As it says in the Components README:
Serverless Framework Components are used via the Serverless Framework CLI, but they are different from Serverless Framework’s Traditional experience in that deployment happens via an innovative hosted deployment engine (similar to a CI/CD product). You will be prompted when using Components, to login and ensure you’re aware of this difference.
It’s a bit like…
A hosted (SaaS) offering that deploys and manages your apps in AWS for you. And gives you CI/CD.
I hope that’s cleared things up. It was certainly confusing to me when I first started!