A Peek Into Serverless

Serverless has come a long way since the early days of Google App Engine in 2008. It is still relatively young, as far as technologies go. I think most would agree that serverless really started to take off when Amazon introduced AWS Lambda in 2015.  It could be argued that serverless is around 5 – 10 years old. Compare that to something like javascript, which is 25 now, and it seems like an infant. I mean javascript has been able to drink for 4 years now, and some would probably argue it’s been constantly drunk since long before that, but that’s getting off topic.

Now the point of this writeup isn’t to try to convince you to change your infrastructure or even adopt serverless. The purpose here is to just help you get a basic understanding and look at why it could be a useful tool to have in your toolbelt. However I feel it only right to stop here and talk about the “Why?”.

I can hear you, “Things have been going just fine with my server-laden approach, why do I need less?” and you know what, you’re not wrong. Somehow we managed to keep the world spinning without serverless for a long time. Now I am not here to sell you serverless, trust me,  but the advantages are pretty compelling. 

Performance 

Let’s start with no server management. No this doesn’t mean fire all your ops people; it just means they can focus on performance instead of setup and maintenance. 

Scalability

The next advantage is scalability. Now I know we are all rich and can build as many servers as we want, but why would we want to do that when Amazon, Google and Microsoft want to handle that for us. The ability to scale your applications automatically depending on its consumption is very powerful and can lean to the next advantage which is Cost. 

Cost

The cost of serverless is a pretty heavily debated one. It’s certainly possible to get yourself into a situation where you have spent some heavy money on your serverless backend. The reality is if you are consuming that many resources you are also likely making a lot more money. It’s also a very difficult comparison because managing your own servers requires a lot of people hours that are tough to qualify. So this point I will agree can be case by case. However, look at something simple like Amazon’s Lambda service. You get 1 million requests per month and 400,000 GB-seconds of compute time for free and then after that you pay $0.20 per 1 million requests and fractions of a penny for GB-seconds. I’ll close this by saying: ”A well planned serverless backend can be very affordable and well worth the transition”. It’s not a magic bullet for everything, but again that’s not the point. The point is to understand when it can be the best tool.

Alright pull up a chair, let’s dive in

There are many options in the Serverless game. Google Cloud Platform, Microsoft Azure, Cloudflare, Kubeless, and many more. For this serverless intro I decided to focus on Amazon Web Services (AWS).

AWS can be quite intimidating. I mean just look at this list, where does one even begin?

Here we can see a live recording of an actual first encounter with the AWS services list and at this point I wouldn’t blame you for just turning off the computer and tossing it out the window! 

I promise it’s not as bad as it looks. So run with me on this. 

AWS Services

Instead of thinking about AWS as a single tool, think about each service on the AWS services list as a tool of its own. I know that doesn’t sound very comforting yet, but just remember that you do not need to use everything on this list or even a majority. You can focus on just a couple or even just one. So let’s pick a couple common ones to break down. 

API Gateway

Amazon’s API gateway is a service you almost always need to interact with. API Gateway is simply a service to route HTTP or Websocket requests to some other service. So if you want to GET, POST, PUT or any other HTTP request method, this is where you will begin. API gateway can handle cors, which I am sure is something we all know and love, and give you full control over the request and response.

Lambda

The second most common service from the AWS mega list is AWS Lambda. In Javascript, the terms Lambda and Function tend to be used interchangeably. Now this is not always technically the case but the differences here are what I would consider splitting hairs. If anyone has an amazing breakdown of the differences feel free to leave a snarky comment! For the sake of simplicity, let’s just think of a Lambda as an anonymous function that is passed around as a variable to other functions. Amazon Lambda is exactly that. From a javascript developers perspective think about this as a function you can deploy to the cloud. How that function will be run is up to you and the other connected services you attach to it. For example, you could hook this function to a GET request coming from API Gateway, or maybe use Amazon’s CloudWatch Events service to trigger your lambda every 10 minutes. You could even use Amazon’s S3 service to trigger a lambda when a file is created or deleted. 

CloudWatch

Amazon’s CloudWatch service allows you to monitor your application when deployed to the cloud. Though it is an expansive set of monitoring tools a JS dev can simply use CloudWatch to see all the console.log messages. For example if you create a Lambda function that has logging within it you could find all those messages in CloudWatch and use this for cloud based debugging.

So I think this is where we are going to stop for now. This is a very superficial overview of Serverless and specifically Amazon’s basic services. Again the point here isn’t to convince you this is the right step for all your projects but to motivate you to keep learning and keep on top of new technologies as they some out. Experiment with them and see if you can find ways to improve the experience of your users.

CloudFormation

The last concept I would like to talk about is Cloudformation. Cloudformation is not a service but a way of modeling your infrastructure. What does this really mean? It means you can describe your whole backend system in a single file. Think about it as a model of all the things you would like to have in your backend. You need a database, a couple lambda functions, some user permissions, an s3 bucket for files. So you list them and their connections with each other within one file and send that off to Amazon to spin up everything you need. This file can be written in YAML or JSON depending on your preference and once created, allows for a single location to describe your backend application. 

This is a very powerful concept and not only allows you to quickly deploy applications on amazon but also deploy to multiple stages. Seeing that everything is declared in one file you can simply tell amazon to spin up a backend prefixed with `staging` or `dev` that will be identical to the final production application. 

CloudFormation, however, is very verbose. This makes it extremely powerful and customizable but also tends to lead to a lot of typing. If there is one thing I know about developers, we hate typing. So services have pop’d up providing abstractions to this verbose syntax. A few that I have used and found very useful are Serverless and Architect. Architect is extremely powerful but currently only supports AWS as a provider. Serverless however does not simply things as much but offers a very wide range of providers to deploy to if you decide you want to jump ship to Azure or GCP.

Wrapping it up

For me this post is simply to gauge some interest in this topic. I understand this was extremely superficial and it’s fair to say we didn’t see any code or implementations here. So I want to hear from you. Are you interested in serverless technologies? Has this blog post interested you enough to hear more about how to code this and set it up? If so, I will continue forward and in the next post we can look at something more like a tutorial focusing on getting a basic API up and running on Amazon. We then can connect this with our frontend and be off and running changing the world. Please leave your comments here. 

I hope this was an enjoyable read and if not at least gave you something an escape at work that your boss would not be too upset about. Thanks for stopping by, until next time, be kind , keep learning and make great things