Inigo Montoya in The Princess Bride

Serverless. You Keep Using That Word. I Do Not Think It Means What You Think It Means.

We’ve all heard it but nobody can agree on a definition

Allen Helton

I love buzzwords. Blockchain. AI. Cloud. Internet of Things. They get used time and time again until it becomes like a game of telephone— the word now has a completely different meaning than when we first heard it. Take the word serverless. Once it had a clear and concise definition, it now means any number of things ranging from “cloud” all the way to the mysterious “fix for all our problems.”

So what exactly is serverless? Is it, in fact, the fix for all our problems? Probably not. Is it the fix to some of our problems? Probably. Let’s explore some of the myths around serverless and discuss exactly what it is vs what it isn’t.

What It Isn’t

Actually serverless

Contrary to what the word made lead you to believe, your code is still running on a server. The servers get abstracted away from you. This means you can write code all day, push it to master, and it will get where it needs to go. Your code will be running in some type of container. The point of serverless is that you don’t care where the server is. As a developer, you care about the business capabilities of your software.

A fast-track to ditching your monolith

You’ve put years of work into that monolith. You’ve tightly coupled your domains, you built a high-functioning state management system — your application needs to run on-premises. Serverless applications don’t work like your monolith— they are loosely coupled, stateless, segmented pieces of code. It won’t be simple to shove what you have now, one for one, into a collection of serverless functions — you need to perform a major rework. In some cases, it might be faster to take the lessons learned from your monolith and start from scratch.

Infinitely scalable

Often touted as infinitely scalable, serverless applications tend to have unrealistic expectations placed on them. At the end of the day, the code is running on physical hardware, so there are unavoidable limitations on throughput, CPU power, and memory. However, these factors have incredibly high ceilings, and you are unlikely to max them out. Compared to an on-prem installation, a serverless application may seem infinitely scalable because it can increase the number of running servers based on demand.

The only cloud option out there

You can incorporate cloud in a multitude of ways. Possibilities include running your application in a hosted VM, deploying a set of containers, or even taking advantage of only one or two services while hosting the rest of your app on-prem. A full, serverless application is taking cloud to the extreme, and is by no means your only option on your cloud adventure.

What It Is

Worry-free infrastructure

The primary benefit of going serverless is taking away the responsibility of the hardware. Your cloud provider will abstract away that layer from you so you can focus on what’s important: the software. Typically, providers will offer autoscaling features down to a function level, helping you achieve optimal performance.

Fluctuating, yet predictable pricing model

Serverless is all about paying for what you use. Specifically, it is paying for compute time and throughput. Since your usage will never be exactly the same every month, your bill will change. Some compute heavy functions might be run more one month, or maybe you brought on a new tenant that exercises some new services more than others. Luckily, most of the major cloud providers provide calculators like Azure and AWS to help get a gauge of what your bill will be.

A mindset change

If you’re used to building monolithic applications, or are new to microservices, getting in a serverless mindset can be difficult. Breaking up code to small digestible functions is a big change from a class file that has 3,000 lines and does everything under the sun. Also, with the autoscaling, speed, and flexibility of serverless, developers tend to gravitate toward NoSQL databases instead of relational. This type of database change can be a gamechanger for your application, but a brain buster for your developers. Migrating from relational to a document store brings a set of challenges that requires a total mindset shift.

Fast, segmented development

Using services like serverless functions forces you to split your code into discrete operational chunks. These chunks live by the single responsibility principle: they are simple, they mesh well together, they are loosely coupled. The benefit serverless gives here is that you can bust out REST endpoints as fast as you can say “API layer.” Having small operational chunks of code helps you not only produce work faster but also simplifies a potentially complex business process. Breaking the code into segments lets the developer have deep vision into one area. No more spaghetti code, where one change over here breaks three more things over there.

Language agnostic

Serverless functions have a wide range of languages they can be written in. Since they run independently of each other, each function can be written in a different programming language. Language is an important thing to consider when building a serverless application, for a variety of reasons ranging from the cold start time of a function to which language is best suited for a task. So be conscious of the languages you choose for time sensitive functions.

Final Thoughts

There is a lot of buzz around serverless right now. Everyone makes the joke that there are still servers involved in serverless development, but that’s about the extent of the majority of casual serverless conversations.

Serverless applications are still in their infancy but are poised to become widely adopted. From an architecture standpoint, it makes sense to break your code up into single responsibility chunks. From an infrastructure point of view, who wouldn’t love to move the responsibility of the hardware to a service provider? From a business cost angle, it doesn’t get any better than paying for what you use. There aren’t up front or provisioning costs, just a predictable model that scales with you.

If your company is looking into exploring the serverless world — do it. Build a proof of concept or a rapid prototype. You don’t have to spend a significant amount of time seeing if it’s the right path for you. The beauty of serverless development is that it is fast, so get your ideas down and test them out. Almost all the serverless vendors offer free tiers for their services, the only cost to you is going to be your time. So get started and jump into the serverless world!

Better Programming

Advice for programmers.

Allen Helton

Written by

I am a lead software engineer at Tyler Technologies with a focus on cloud-native design and architecture.

Better Programming

Advice for programmers.