Serverless: a concept and a poorly named framework

Yellow blocks

In the past 5 months, I’ve been contracting for Bitgenics, Erwin van der Koogh’s startup company based in Melbourne. We’ve built a Front-end Delivery Network called LINC, a hosting platform for single page applications, or SPAs. Basically, the whole thing runs on Amazon Web Services (AWS), and there is not a single server in sight. It is “serverless”.

By now, we’ve all heard about Serverless. First of all, it’s a concept. It means not only that you don’t have to manage your own servers any more, but that you don’t have to manage any servers at all. Serverless happened in two steps: firstly we moved servers from on-site to “the cloud”, and secondly we stripped the need to having to manage servers.

As said, LINC is “serverless”. To achieve this, we use Serverless (the framework) to configure and set up a big part of our back end. The Serverless Framework (SF) is named both properly, and poorly. It describes what it’s for, but Googling anything about it quickly becomes a pain because you need to include the “framework” in every search query to prevent from finding “conceptual” serverless results only. Ugh. Being an absolute newcomer to the SF I’ve ran into this snafu more than once.

Anyway, I’d like to share with you some of the things I’ve learned about Serverless and the Serverless Framework during the last couple of months. The Serverless Framework is basically an abstraction layer between the developer (me) and CloudFormation, that part of AWS that allows you to manage certain parts of your back-end. After installing the serverless (or sls) code on your machine, you can create a new project by running sls create -t aws-nodejs. There are other templates available, but aws-nodejs is the one for me.

(Before I forget, sls -h will show you the commands and subcommands available to you.)

This command will create three files in your current working directory:

serverless.yml
handler.js
.gitignore

The serverless.yml file contains the configuration for your project, which is actually called a service. Make sure to change the service name to whatever you want it to be.

After opening this file, you’ll notice a lot of comments, which may seem a bit daunting in the beginning. It does make sense to take the time to go through it, though. If anything, it will familiarise you with the file syntax. As you can guess from the file extension, it’s a YAML file.

Only three parts are not commented out in the configuration file (I’ve left out the comments for convenience):

service: aws-nodejs # NOTE: update this with your service name
provider:
name: aws
runtime: nodejs4.3
functions:
hello:
handler: handler.hello

This is the simplest set up for creating a single lambda function in AWS. The file handler.js, which is mentioned as the handler, exports a function hello. (This is determined by handler: <filename>.<function-name>.) The name hello is only used by sls, but you should give it a useful name.

Now, I don’t want this post to turn into a tutorial on how to set up a serverless service (let me know if you want it anyway). I want to show that it’s relatively easy to do so and not limited to deploying lambdas. You can set up API Gateway to trigger your lambda by adding an HTTP event specifying the endpoint and method (e.g., post/get). Creating DynamoDB tables is equally simple.

Our serverless set up at this moment consists of a bunch of lambdas, a couple of DynamoDB tables, API Gateway endpoints with custom domain names, and S3 for storage and logging purposes. We use the Certificate Manager to (programmatically) create SSL certificates when we have to, Route53 for our domains, Simple Networking Service (SNS), Simple Queueing Service (SQS) and CloudWatch for message passing and triggering of lambdas, and finally ECS that does the heavy lifting. We use a fair part of the AWS eco-system, and it has much more to offer.

We use different stages (on different AWS accounts even) for development and deployment purposes, and switched to using MFA (multi-factor authentication) for security purposes. This is natively supported by AWS’s IAM (Identity and Access Management).

Over the past couple of months I have not only learned about the Serverless Framework, but also learned many new things about AWS. I probably only scratched the surface, but that’s fine. I mean, Amazon releases new features on a daily basis, which I know because of their weekly email updates. Quite impressive.

On top of all that, I had a lot of fun building LINC together with Erwin!


For more information about LINC, or to sign up for the closed beta, please visit the website: https://bitgenics.io.