Introduction

I've been on a pretty heavy Serverless kick over the last 12 months. At my day job and at home, I've started all of my projects with Serverless being the default deployment plan. It's simplified things so much that I've abanonded .NET development for back-end services in favor of Node.js because the Serverless containers start faster with it.

Making the shift to Serverless compute came with a lot of new terms and technologies that I had to learn. Moving to NoSQL Document databases, Node, CLI driven work-flows and the most difficult being developing products outside of the glorious debugging experience I've had with Visual Studio.

To that end, I've decided to blog a complete guide to going Serverless. The guide will be split over multiple posts, from creating a cloud account, to setting up a local development environment, debugging and deploying the service. If time allows I might explore deploying a web-site as a serverless solution as well. For the initial posts in this series though I will be focusing on the creation and deployment of back-end API services.

Each post in the series can be accessed here:

Part 1 - Introduction

What is Serverless?

Over the last few years a new technology has slowly gained popularity in the operations support world. The new technology provided a service for operation admins, security engineers, DevOps engineers and developers to build jobs that ran in the cloud without needing any infrastrucure. The service was called Functions as Service (FaaS) and allowed for deploying, literaly functions, into the cloud that could be executed.

Once deployed function could be triggerd by an event in the cloud. Such as uploading a file, deleting a file, a new message landing in a message bus, a configuration rule being violated etc. Even better was that FaaS allowed for the deployment of these functions without the engineer needing to provision a server for the function to run on. Depending on what your FaaS provider of choice is, the security model for the deployed function is incredibly simple as well. In some cases they can run outside of your network, allowing for them to run in isolation to your production environment. This reduces the blast-radius in the even that your function could potentially be compromised.

With FaaS working so well it was only a matter of time before functions integrated themselves with the web. Serverless compute was born when FaaS could be integrated behind API Gateways, allowing the functions to receive HTTP requests. Now FaaS can be triggered by HTTP requests, handle the request and send a response back to the original requestor. This marrying of technologies is where the term Serverless came from as there are no web servers for the developers to deploy to, no Apache/NGINX/IIS server for IT Administrators to patch and secure. Developers can write the web application with just a few small changes and deploy in seconds without any supporting infrastructure.

The cloud

For this series of post we will be focusing completely on Amazon Web Services (AWS) as our cloud back-end. Amazon's FaaS solution is called Lambda. Coupling Lambda with their API Gateway service provides you with a powerful and simple Serverless solution. Everything we will create in this example falls under Amazon's free tier, meaning for the first year you won't have to pay for anything. You are given 1,000,000 executions of your Lambdas for free, per month. You are given 25 reads and 25 writes per second on their NoSQL Document database called DynamoDB. That's way more than what we need to build out a development environment and deploy it.

We will provision our entire back-end using code as well. Creating your cloud environment manually through the AWS web site is prone to misconfiguration as you spin up new environments. Dev and QA will eventually drift from each other, and production and Dev will almost always start to look different as soon as you've deployed. Creating your resources via code allows for versioning your infrastructure. Having your infrastructure versioned makes roll backs a lot easier and enables the option for you to rapidly spin up additional resources on-demand if needed.

Wrapping up

Over the next few blog posts we will build our a simple Todo API that will not need a SQL store, won't need a web server and will provide free user provisioning and account authorization.

Let's get this party started, on to Part 2!