One thing that has always been hard in computing is finding the right balance between easy-to-use APIs for developers on one hand, and powerful abstractions on the other. The reason for this is simple: If an abstraction layer was too powerful, it would be too complicated for most people to use. If abstraction was too simple, nobody would want to use it because the resulting application wouldn’t have enough features.
The idea behind serverless architectures is to take this trade-off as a given and determine how we can find a sweet spot where everyone wins: A system that is easy to understand and easy to use for developers on one hand, but still allows us to build great things on the other.
Serverless architectures work by splitting up your application into several small pieces that are run on demand when somebody uses them. The idea behind this is simple: Why should I spin up a container to do something if nobody even cares?
What parts of traditional architecture are replaced by Lambda?
To understand what serverless architecture means, we first need to define what “traditional” architectures look like. In this context, we are talking about the way most applications are set up today: At the core of it there is a web server that clients talk to in order to get content onto their screen. This web server can then use different technologies such as NodeJS or PHP behind the scenes in order to render the requested content and send it back to the client.
In a traditional architecture, The user will have no idea how AWS sends your website’s content over HTTP/2 from all over the world. They just know they wanted a picture of a cat and now one magically appears on their screen.
This is great because managers can focus on features rather than infrastructure, developers don’t have to worry about scaling their servers, and operations engineers finally get some sleep at night.
On the other hand, you will likely face new problems that did not exist before: The traditional servers your app is running on are provided by someone else. If they go down, your app goes up in smoke. This means you need to architect your application in a way that makes it fault-tolerant out of the box so you also do not run into unexpected downtime during peak hours or when switching regions (something I see happening all too often).
Serverless architectures offer many benefits over traditional architectures such as improved availability and scalability while requiring less infrastructural support from your development team. As a result, it is easier to build scalable and reliable systems that are easy to operate. For this reason, I expect serverless architectures to become more popular in the future!
Let’s walk through how you can spin up your first serverless NodeJS application using Amazon Web Services (AWS) as well as API Gateway. We will use NPM as our package manager of choice because I feel it makes it easier for developers already familiar with the toolchain.
To set up your first serverless application, you will need to do three things:
First of all, you need to install the Serverless Framework. The CLI for this framework does a couple of nice things for you: It helps manage and deploy your code, compiles it for production, and much more. To get started with the Serverless Framework in NodeJS, simply run npm install -g serverless.
Next, we need to configure AWS in order to allow deployments from our machine. You can read about how to do that here. Note that when using the Serverless Framework your credentials never leave your system which is great!
Finally, we can actually start coding! All we have left to do is create a service definition file that tells the Serverless Framework what functions our application contains. Such a service definition looks like the following:
When we run the serverless deployment, all code will be compiled and deployed to your AWS account. As a result, you can now use your app as if it were running on EC2 or Lambda directly, without thinking about any infrastructure stuff!
As you have seen, it is not hard at all to get started with serverless architectures. Why not give it a shot yourself? As always, feel free to contact our team if something does not work as expected!