As of this writing, all of the major cloud providers have a serverless component to their offerings. Even outside of Amazon, Google and Microsoft, there are many platforms where you can run your code without having to worry about the underlying infrastructure that it runs on.
But what is the best way to write code in this new architecture? And what if you want to be able to make this code portable between multiple platforms? That’s where a tool like the Serverless framework comes in.
In this article, we’ll take a look at what the Serverless framework is and how to develop code for serverless architectures.
What is serverless computing?
When Google App Engine launched in 2008, serverless computing was born. This meant that developers using GAE had all of the infrastructure needed to run their code taken care of. They no longer had to worry about provisioning the servers their code would run on or make sure all the underlying software was up-to-date, but could just focus on writing and deploying their code.
Serverless continued to grow when Amazon Web Services launched their Lambda product offering in 2014. Google and Microsoft announced Cloud Functions and Azure functions respectively in 2016, although it took until 2018 for Google Cloud Functions to become generally available.
As the names of some of these services imply, code that runs on serverless platforms is usually packaged into functions that are triggered either by outside events or other serverless functions and have a defined output or result. These functions can be written in a variety of languages, depending on the underlying cloud provider.
How is serverless different from server-based architectures?
The serverless architecture differs from a more traditional server-based architecture in a few important ways:
- It is event-driven: The most obvious is that serverless functions are event-driven. Instead of being hosted on a server that’s always running and can both respond to incoming traffic but also run background tasks, serverless functions need to be invoked by some outside input. This could be a function that runs a compression algorithm on an image as soon as it’s uploaded by a user, a log-processing function that runs at the same time every night and is triggered on a schedule, or a function that provides the end-user some data in response to an API request.
- It is a Function as a Service (FaaS): No matter which infrastructure provider you choose, serverless can otherwise be known as Function as a Service infrastructure. That is, you provide the function that you want run, defined in a language of your choice, and the infrastructure provider figures out what servers, ancillary services and other considerations need to be configured to run that code.
Why choose serverless computing?
When choosing a serverless architecture for a particular application, there are a couple of definite benefits. Most notably, because you are not managing the underlying infrastructure, it can scale in relation to increased demand without any intervention from you. This makes it a great solution for workloads that are unpredictable or may need to scale quickly and suddenly.
In addition, because you don’t have to manage the underlying servers, you are effectively outsourcing some of your DevOps cost to your cloud provider. This can potentially reduce especially the ongoing cost associated with maintaining servers after the initial deployment, which isn’t necessary under the serverless model.
One of the main benefits of serverless is the pay-per-use model associated with most serverless implementations. For example, AWS Lambda only bills you for every millisecond (ms) that your serverless functions are running. This sharply contrasts with having to pay for an entire EC2 server to be running for the month, for example.
Downsides to the serverless architecture
For all the benefits of serverless, there are some downsides as well. For example, if your use case falls outside what might be considered a good fit for serverless, it can actually be more expensive to run a serverless architecture. The Amazon Prime Video team discovered that moving from Step Functions back to a more traditional EC2/ECS deployment reduced costs by 90%.
In addition, compared to their serverless counterparts, monolithic applications with a more traditional architecture can be easier to develop and test locally and in other staging environments.
What is the Serverless framework?
If after evaluating the benefits and drawbacks of the serverless architecture, you feel like your next application is a good fit for serverless, then it’s time to think about how you should start building. One possible way is to use the Serverless framework. This framework is a tool that helps you quickly and easily build serverless functions that can run on multiple different cloud providers.
Key benefits of the Serverless framework
With a “vanilla” serverless development process, you tend to be limited to choosing one cloud provider and, once you’ve chosen, start to develop your function to fit the needs of that provider. This makes it very difficult if you decide to migrate from AWS to Azure, for example. With the Serverless framework, you write your function at a higher level of abstraction, which makes deploying it to a different cloud provider very straightforward.
One difficulty of developing serverless functions has always been testing and developing locally before deploying your code. With the Serverless framework, you get a local environment that very closely mimics what your code will be running on in production, so you work out any potential bugs as early in the process as possible.
Build and deploy a simple serverless function
For a more in-depth look at how this process works, let’s take a look at how we would deploy a serverless function with the Serverless framework. To get started, head over to serverless.com and sign up for an account. Once you have an account, you should see your Serverless dashboard.
Back on your own machine, run
npm install -g serverless to install the Serverless CLI, which is what we’ll be using to build and deploy our serverless function.
With the CLI installed, run
serverless from your command line. This will guide you through setting up the project, configuring your AWS credentials so your deployments will run smoothly and running your first deployment.
Configure AWS access
We will be using AWS in this example. If you don’t already have an AWS account create one. If you have an AWS account, log in and navigate to the AWS console.
Once inside the AWS console, create an IAM user and configure an Access Key. This is how the Serverless framework will deploy your function. Make sure you download the CSV with your access keys that AWS provides you once they have been created.
At this point, the CLI will prompt you for both the Access Key Id and Secret Access Key. Enter these credentials from the CSV that you downloaded.
Deploying your test function
Once you have your credentials configured successfully, you’re ready to deploy your first function. By choosing
Y at this last prompt, the Serverless framework will initiate a deployment of your function.
Once this command has run successfully, you should see your newly-deployed Lambda function inside your AWS account!
And with that, you’ve deployed your very first serverless function with the Serverless framework. To learn more about developing more complicated serverless functions, check out the documentation.
Airplane as a serverless platform for running your functions
If you’re looking to enable team members to run the functions you’ve created, see the output, and build more complex internal tools than a few Lambda functions can provide, consider Airplane. Airplane is a developer-centric, code-first approach to creating internal tools and workflows.
With all of these pieces combined, running either in the cloud on Airplane or as an agent in your cloud infrastructure, there’s no limit to what you can build with Airplane.
If you’re ready to get started, sign up for a completely free account today! If you have any questions or want to chat, you can always reach us at firstname.lastname@example.org.