Skip to content
Serverless Handbook
GitHub

Getting Started with Serverless

Hello friend ❀️

I'm happy you're giving serverless a try. It's one of the most exciting inflection points in web development since React introduced us to components.

I know creating your first serverless application can be quite intimidating. Type "serverless" into Google and you're hit with millions of results all assuming you know what you're doing.

There's Serverless, the open source framework, then there's AWS Serverless, and a "serverless computing" Wikipedia article, your friends mentioned something about lambda functions, then there's Netlify and Zeit and maybe Heroku and apparently Microsoft does serverless now too?

It's all one big mess.

That's why I'm creating Serverless Handbook. It's the resource I wish I had :)

Let's start with a little background so you get a better understanding of what serverless is and what it isn't. Then you're gonna build your first serverless backend – an app that says Hello πŸ‘‹

Don't want the intro? Jump straight to your first app

What is serverless anyway

Serverless is other people's servers running your code.

The logical next step to platform as a service, which came from The Cloud, which came from virtual private servers, which came from colocation, which came from a computer on your desk running a web server. 🀯

A little history:

First we all had servers.

The world's first web server, a NeXT Computer
The world's first web server, a NeXT Computer

You installed Linux on a computer, hooked it up to the internet, begged your internet provider for a static IP address, and let it run in your basement. Or in my case, the bedroom.

Yes my high school bedroom was very warm in the summer but it had a server and a static IP address. I was the coolest kid in class. 😎

An IP address is how computers find each other on the internet, by the way.

With a static IP address, you can tell DNS servers how to find your server with a domain. Once you have a domain, people can type it into the URL bar and find your server.

But a domain doesn't give you a website or a webapp.

For that, you still need to configure Apache or Nginx, set up a reverse proxy to talk to your application, run your application at all times, ensure that it's running and ... yeah it gets out of hand fast. Just to put up a simple website.

Then came colocation

A colocation server rack
A colocation server rack

Colocation was a solution for the bedroom or basement problem. What happens if your house catches fire? What about when power goes out? Or your mom trips on the power cable and unplugs your computer?

Residential hosting isn't very reliable.

Your internet is lower tier than a business would get – less reliable, more volatile, and if the company needs to do maintenance they think nothing of shutting it off during non-peak hours. Guess what, your server needs solid internet 24/7.

When you go on vacation, nobody's there to take care of your server. Your site might go down for a week before you even notice.

With colocation you take that same server and put it in a data center. They supply the rack space, stable power, good internet, and some physical security. You often buy a more reliable computer as well.

You're still left to deal with configuration, maintenance, and replacing hard drives when they fail.

PS: Computers break all the time. A large data center might have to replace a hard drive every few minutes just because a typical drive lasts about 4 years and when you have thousands, the stats are not in your favor.

It's on you to keep everything running.

Then came virtualization

Colocation solved physical problems, but not the fact that your servers are bored to tears.

A typical server runs at maybe 30% utilization. Meaning 70% of the time you are wasting your money.

Reasons for low utilization vary. Some of it is keeping the hardware happy and thermally content, some of it is over-provisioning so you have spare capacity in case of spikes. Sometimes your site just isn't as popular as you'd like.

What if we could run multiple servers on the same machine?

The first type of virtualization was pretty basic: virtual hosts let us host multiple websites on the same machine. A domain maps to a specific application on your computer, web server figures out the mapping, and voila: sites can share resources.

Worked pretty great but caused problems.

Websites on the same computer are very close together, you could hack one site to gain access to another. Sometimes they'd starve each other for resources. You could config yourself into a corner with overlapping configuration.

Real virtualization and later containerization were the solution to that problem. Rather than multiple websites on the same machine, you can host multiple whole computers on the same machine. It's like having many brains.

The VPS – virtual private server – was born. Providers of "ssh access" were crazy popular in the 2000's. Pay a few bucks a month and you too can get a real live server on the internet. No hardware setup required.

You're still on the hook for software setup and you do share the same machine with many others.

So what if your site scales?

The cloud is born

A data center
A data center

Early VPS was a lot like The Cloud already. Computers running on the internet without touching hardware.

Where VPS fell short was scale.

Once your traffic started to grow, you'd soon need more servers to handle the load. There's only so much work a single server can do per second.

But how do you ensure your servers are all the same? How do you spin them up fast enough when traffic spikes on Black Friday?

You deal with it by hand.

Set up a server, make sure it works. Create a new server. Copy your configuration. Create scripts for common tasks and spend hours making sure everything's just right.

Repeat for each new server.

Cloud solves this problem with automation and containers. Usually docker containers, nowadays kubernetes's ease of use is winning.

You start every new server from a core image in your cloud provider's library. Comes with some setup and common defaults. You add tweaks and create a new image.

The cloud then gives you easy controls to create as many instances of that server as you'd like. Press a button, get a server. ✨

Sometimes you can even make it scale automatically. Scripts notice traffic rising and spin up some servers. When the traffic subsides, those same scripts can tear the servers back down.

Platform as a Service

A variation on The Cloud was and still is the PaaS movement – platform as a service.

With PaaS you pay somebody else to deal with cloud stuff and you focus on code stuff. They configure your servers and dockers and kubernetes and make everything play nice together. You build the app.

git push to deploy and voila. πŸ‘Œ

Most PaaS providers let you drop down a few levels and break everything. You get to mess with low level configs, operating system libraries, web servers, databases, etc. Empowering and dangerous. I often get it wrong.

While PaaS takes care of your servers, you often still have to take care of the "frontend". Set up your domains and DNS config, make your application run just right so the platform is happy, configure your own CDN, deal with static files, stuff like that.

The platform only does servers.

Serverless is born

Serverless comes as the logical step after PaaS.

Once you have a system that uses containers to automatically scale and tear down based on demand, use idiomatic configuration for replicability, and painless deploys ... that's pretty much serverless right there.

Serverless's main innovation are extremely tiny containers and the ecosystem of services and tools around that.

Server containers so tiny you can spin them up and down in milliseconds. They achieve this because the code they run is:

  1. Very small
  2. Extremely standardized
  3. Does very little

A serverless "server" is often just a function responding to a single API endpoint. Request comes in, server wakes up, runs for a few milliseconds, and goes back to bed.

The platform takes care of optimization, configuration, and everything else. You get an input and return an output. Just like a function.

Your servers never idle because they only live as long as the request they're serving.

Most providers offer some reuse to optimize for load times. If it takes 100ms to spin up a server and you're getting requests every 10ms you might as well use the same server :)

Biggest benefit of this approach?

Metered pricing. No more money wasted on idling servers waiting for requests. Pay for just the time you get useful work done.

Your first serverless backend

Man writing code
Man writing code

In the next few minutes you're going to build your first serverless backend. A small service that says Hello πŸ‘‹

We're using open source technologies and deploying on AWS Lambda. You can learn about other providers in the Serverless Flavors chapter.

You'll need a computer set up for JavaScript development: Have nodejs installed, a code editor, and a terminal.

Setup for serverless work

When working with serverless I like to use the open source Serverless framework for configuration. We'll talk more about why in the Good serverless dev experience chapter.

With the serverless framework we're going to configure our servers using YAML files. Write some config and the framework figures out the rest.

Install it globally:

npm install -g serverless

You'll need AWS credentials as well.

I recommend following Serverless's guide on AWS setup. It walks you through the necessary steps on your Amazon account and some terminal commands you'll have to run.

Create a tiny project

There are no special initializers for serverless projects yet. So to start a serverless project, you create a directory and add a configuration file.

mkdir hello-world
cd hello-world
touch serverless.yml
touch handler.js

You now have a project with 2 files:

  • serverless.yml for configuration
  • handler.js for server code

In future chapters we'll write backends using TypeScript, but one thing at a time :)

Configure your first server

Configuration for your server goes in serverless.yml. We're telling the Serverless framework that we want to use AWS, run nodejs, and that this is a dev project.

Then we'll tell it where to find our code.

# serverless.yml
service: hello-world
provider:
name: aws
runtime: nodejs10.x
stage: dev

Our service is called hello-world and there's some details about our provider. The stage helps us tell the difference between development, QA, and production deployments. More on that in the Dev, QA, and prod chapter.

Now let's tell our server how to run some code.

# serverless.yml
service: hello-world
provider:
name: aws
runtime: nodejs10.x
stage: dev
functions:
hello:
handler: ./handler.hello
events:
- http:
path: hello
method: GET
cors: true

We started a functions section.

Each entry becomes its own tiny server – a serverless lambda. Together, they're the hello-world service.

The hello lambda calls an exported hello function inside our handler.js file whenever a GET request hits /hello.

All that from just these few lines of code πŸ‘Œ

PS: enabling CORS lets you call this function from other websites. Like your frontend app.

Write your first backend function

Backend functions in a serverless environment look a lot like the JavaScript functions you're used to. Accept some arguments, return a response.

Add a hello function to handler.js

// handler.js
exports.hello = async (event) => {
return {
statusCode: 200,
body: "Hello πŸ‘‹"
}
}

It's an async function that accepts a triggering event and returns a response. A success status with a Hello πŸ‘‹ body.

That's it. You just wrote some backend code.

Deploy your first serverless backend

To deploy, we run serverless deploy.

And your server is up.

You get a URL for your lambda and some debugging output so you know what's going on. My URL is https://z7pc0lqnw9.execute-api.us-east-1.amazonaws.com/dev/hello, if you open it in your browser, it's gonna say Hello πŸ‘‹

I'll keep it up because I'm not paying for it unless somebody clicks. And even when they do, current AWS pricing gives me 1,000,000 clicks per month for free πŸ˜›

What you got

Behind the scenes, the Serverless framework talked to AWS and configured many things.

hello world lambda

  • API Gateway to proxy requests from the internet to your function
  • Lambda to run your code. This is a tiny container that wakes up when called.
  • CloudWatch logs to collect logs from your code. Helps with debugging.

All those get configured for you. No UI to click through, no config to forget about next time, nothing your friends have to set up to deploy the same code.

hello world

Exciting stuff.

Next chapter, we're going to talk about some pros & cons of using serverless in your next project.

Thanks for supporting Serverless Handbook consider sharing it with friends

New chapters in your inbox every week or so ❀️

Cheers,
~Swizec

Edit this page on GitHub
Next:
Serverless Pros & Cons