Serverless and Functions-as-a-Service

Don't believe the hype—understand it

by David Bryant Copeland AKA @davetron5000

Updated Mar 01, 2018

Serverless? Functions? Huh?

As I write this, I have a basic understanding of functions as a service and serverless architectures, but as of about a month ago, I could not comprehend what purpose these things serve or why I'd ever care about them. It's such a different way of thinking about building applications that it just didn't compute.

But, I think there's something to it, and I think having an understanding of what problem it solves will make it clear that an architecture built on functions managed by “someone else” could lead to powerful system design. Let's learn it together.

Functions as a services or FaaS is the generic name for products like AWS Lambda, which bills itself as “Serverless Compute”, which is a fancy way of saying “you can run your code without having to manage even virtual servers”, followed by a big huge asterisk of restrictions and constraints around how you write your code and what it can do.

Some of those are outlined on Lambda's limits page, such as:

The idea is that your code is a small function that does one thing, does it quickly, and doesn't require a lot of resources. If you can arrange for that to happen, you can run your code without managing a server of any kind. This is why FaaS is used interchangeably with the word serverless (not to be confused with the confusingly-named-but-seriously-points-for-calling-dibs-on-the-name Serverless Framework, which we will only refer to by its full and capitalized name).

You might wonder how your function even gets called. This, too, has lots of limitations and, at first, feels really strange. When you look at AWS' use cases, it talks about events, and FaaS or serverless architecture are also talked-about with phrases like “event sourcing”.

And this is the key insight into what all this is about. If you choose to think of your system as one that receives events—like a user clicking on a web page, or a timer going off, or a database being updated, and your code is nothing but a bunch of functions that are invoked based on these events, it starts to almost make sense. Almost.

What we're going to try to do is look at some common use cases where you'd set up some application to run on some server such that it does some things, and re-imagine those use-cases as event sourced and implemented as functions. We'll see where that takes us.