Everyone loves a bandwagon, and sure enough all kinds of projects and technologies are now declaring themselves Serverless. While in some ways this doesn’t matter—it’s what each individual tool or pattern does for you that’s truly important—it is worth putting some more precise definition around the term Serverless so that we can at least clarify our understanding of what we’re getting, and so that we can more effectively judge various technologies to see which is best for any given context.
In this chapter we don our flame-proof suits and differentiate what what we think is and isn’t Serverless. Given these distinctions we then look at a selection of technologies, asking whether they should be considered Serverless, to help you in your architectural assessments.
In Chapter 1 we said that the most significant common theme across Serverless was the fact that you no longer need to manage your own server hosts or server processes. Or, in other words, that Serverless doesn’t mean the servers have gone away, it means that you don’t need to worry about them anymore.
That’s by far the biggest change with regard to many other ways of delivering software, but there are others. Below we list what we think are the key defining criteria of a Serverless technology, whether it be in the realm of Backend as a Service or Functions as a Service. There’s no “standardization committee” to back up these opinions, but in our experience ...