Why Do Developers Love Serverless?

Serverless is among the most hyped technologies in the last few years. It was created to offload operational burdens to the cloud. Now, serverless is a compute option for all companies, even those that run their data center. A large part of this evolution is that developers generally love working with serverless. There are four primary reasons that developers favor serverless approaches, serverless scales automatically, responds to events, allows developers to focus on a single feature, and reduces the operational burden on the team.

Serverless Scales

It is often difficult to predict how and when a piece of software gets used. A system might have 100 transactions per second for an hour and drop down to one transaction every ten seconds for the next three hours. In a traditional system, this would mean building your application to handle a peak load, including testing, with the ability to scale well. Serverless functions scale automatically. A serverless system spins up additional function handlers to process changes in a workload. Developers don’t have to worry about optimizing a system for 100 transactions; they optimize for one and let the system do the scaling work.

It is important to note that the fact that the system automatically scales doesn’t mean developers don’t care about performance; it means that developers can focus on scaling by optimizing the single case. In traditional systems, when a developer optimized, they had to think about where the process was running, what else might be competing, and test that the system can handle this load. Serverless narrows the developer’s focus by removing operational concerns like scaling, making their job easier.

Serverless Responds to Events

Serverless functions respond to events. These events can be anything from a file dropped into a file store, to items placed on a queue, to HTTP server calls. The serverless platform handles the wiring of these event sources to the function. The platform handling the wiring reduces the amount of code that developers need to write. More importantly, it means less plumbing code for developers to write, such as queue or file system access, that isn’t solving the problem at hand. I have personally worked on applications that have more plumbing code to connect services, than logic to drive business need. Plumbing code is especially frustrating because it is often not simple to develop, and comes with many problems that developers must solve repeatedly in each new application. Serverless has less plumbing code because the platform handles access to the events that drive the functions.

Serverless Allows Developers to Focus

We pay developers to solve problems. A common problem in the industry is that of yak shaving – the idea being that, while trying to solve a single problem, you find many other issues to solve before you can get started solving the problem you started with. Serverless reduces the number of problems that a developer needs to solve. They do not need to solve many scaling, connection, or operations problems. Instead, developers can focus on solving the problem at hand. While having developers that are not working on unimportant but required problems is great for the company, it is also important for developers. This focus provides more value to developers and allows them to accomplish more.

Serverless Reduces Operational Burden on the Team

In the past, developers built software and handed the finished software to an operations team that operated the software. That is to say, the operations team ensured uptime, connectivity, and the scaling of resources was available. In recent years, development teams operate more of the software they create in a process known as DevOps. I believe this is a good process as it provides rapid feedback to the team that creates the software and ensures that they are focused on building a robust solution that considers operation as well as feature correctness.

With operations moving into the development, the work that was done by the operations team is now owned by the development teams. This work includes keeping services up, scaling to handle traffic, and keeping the application responsive. Many teams add specialists to reduce this burden, but even with a specialist there is a cost in time of operating the software they build.

A development team that owns operations has more work to do before creating valuable features for the business. This workload leads development teams to try and offload as much responsibility as they can to the platform they are working on. Serverless handles running, scaling, repairing, and connecting the software that development teams often create, which allows them to reduce the overall operational burden.

Many Developers Love Serverless

Developers love that serverless provides a lot of features they needed to manage or develop in the past. Serverless lets developers focus on what is important, write features more quickly and is an excellent addition to the architecture toolbox. It is easy to work with and available in any environment: AWS, GCP, Azure, or Kubernetes for on-prem.

But…

Serverless is not a panacea. Serverless involves vendor lock-in, does not perform well from a cold start, and observability is more difficult. This is why serverless is a tool in the toolbox and not an entire toolbox itself. Give the developers serverless but make sure that they weigh the benefits against the issues and understand that it is only one tool in building great systems.

For further technical content by Gabe, visit his Medium blog