Chapter 1. Why Serverless?

Serverless computing (or just “serverless”) has become a hot topic in the last few years. When Amazon released its Lambda serverless platform in 2014, not many people had caught on to the power and leverage a serverless platform represented. Now, a little more than five years later, many organizations from startups to global enterprises are working to include serverless as part of their corporate IT solutions.

In this report, we’ll explore just what serverless is (Chapter 2) and the seven key elements all serverless platforms deal with (Chapter 3). Along the way we’ll take a peek into the history of online computing to see why serverless has become so important. Finally, we’ll look ahead to see what’s next in the world of online computing (Chapter 5).

A Definition

Serverless is a vague term that has taken on various meanings in recent years. For this report, “serverless” is defined as:

An architectural approach to software solutions that relies on small independent functions running on transient servers in an elastic runtime environment.

That’s a pretty simple definition made up of a few important elements. First, serverless is based on small independent functions. This is sometimes referred to as Functions as a Service, or FaaS. Writing small bits of working code is essential to a successful serverless solution.

Second, these functions run on transient servers. That means the actual machines hosting the code are temporary instances. Unlike on-premises implementations where you buy and nurture your own physical hardware in your headend, serverless solutions rely on virtual machines that run in the cloud.

And that leads to the third element—an elastic runtime environment. These transient virtual machines are spun up when traffic grows and spun down when traffic diminishes. You only have the number of instances running that are needed to handle the current work. This elasticity means better targeting of resources, better tracking of operating costs, and an improved focus on the health of your overall solution.

Finally, all these elements (functions, virtual machines, and elastic runtimes) require an architectural approach. You need to do some planning up front about how you’ll break your problem into a set of small functions and how you’ll orchestrate these functions into a scalable solution that runs in your elastic cloud-based environment.

While my definition of serverless might be a bit terse, it gets to the heart of these solutions’ value. By focusing on small working elements in the cloud, you can reduce the effort it takes to mount an application and speed your time to market. And that is what attracts many companies to this new and sometimes challenging world of serverless computing.

Some Background

While it may seem that serverless computing is a new concept, it has been around in some form for quite a while. For example, Google App Engine—a Python-based online framework—was released in 2008. And App Engine was predated by Zimki, a short-lived serverless-style platform that was developed in 2005 by a division of Canon, Inc. There were other players in the history of what was once called Framework as a Service and is now commonly known as Platform as a Service, but the details are not as interesting as the trend itself—simplifying the work of coding, building, and deploying services that run on the internet.

Both DevOps and microservices grew in popularity in part because companies were working to speed up the rate of change for their software while maintaining (or improving) the stability and reliability of their overall systems. This was a response to the increasing size and scope of IT projects as software became more central to the success of all types of organizations, large and small.

A key technical challenge in this long-term trend is the introduction of more components into a company’s ecosystem. With that increase come more interaction, interconnection, and interdependency—all of which typically make for a less deterministic and predictable software platform. DevOps and microservices practices have grown out of this need to keep the rate of change high while still keeping the overall system reliable and resilient. Along the way, scores of operations and software development teams have had to (re)learn the basic rules of network reliability, software stability, and the role people play in the success of IT projects.

The emergence of what we now call serverless solutions, built to help solve these stability and reliability challenges, is just the most recent in a line of solutions developed to help companies meet both their IT and business goals. As we’ll see in this chapter, serverless and related platform approaches, like containers and virtual machines, were all created to increase the consistency and observability of network infrastructure, and create a more reliable and stable platform for software developers. And that makes implementing small changes less prone to mistakes and more reliable in production.

However, before digging into why serverless solutions make coding, building, and releasing software changes easier and more reliable, it is worth stepping back to look at some basic network realities to see what teams are up against when it comes to building solutions that rely on lots of small components. From that point of view, we’ll review a short history of changes in platform infrastructure technologies that lead up to today’s serverless tooling that is helping to (once again) reshape the way operations and software development people work together to build successful IT solutions.

A good place to start on this journey is to review some of the challenges of dealing with networks of small interdependent components.

Fallacies of Distributed Computing

One of the big challenges faced when moving to a microservice-style architecture is the increased dependence on the network as an element of your design. The more components you have running in distant locations, the more likely it is that one or more of these components are either not operating (due to their own local problems) or unreachable (due to network-related problems). Since many organizations have been building large, single-source releases (sometimes called monoliths), they have usually been able to avoid dealing with the problems inherent in large-scale network software. However, these issues have been a part of software architecture from almost the very beginning of computing history.

One of the well-known lists of common challenges to building systems that scale well is called “the fallacies of distributed computing”. This list was originally attributed to Sun Microsystems’ L Peter Deutsch and his coworkers. The point of the list is to remind developers that working in a network environment brings its own special challenges.

Below is a commonly shared version of the list:

  • The network is reliable

  • Latency is zero

  • Bandwidth is infinite

  • The network is secure

  • Topology doesn’t change

  • There is one administrator

  • Transport cost is zero

  • The network is homogeneous

As you read through the bullet points, a common theme emerges. Keywords such as reliable, latency, and transport cost all speak to the challenge of components communicating at a distance. When the user interface is delivered from a component running on a server somewhere in Asia and the backend data is stored somewhere in South America, these issues become critical to the success of the solution.

Other keywords such as secure, topology, administrator, and homogeneous remind us that, when the components live in many different locations, they are usually running on hardware that we know little to nothing about and are controlled by parties that do not know each other. And these circumstances (who is controlling the hardware and software installation details) can change over time without warning.

All these factors increase the likelihood that something might go wrong and ramp up the work of implementing and maintaining a secure, reliable, and responsive system. So, with all these added challenges, why are microservices still so popular? And what does the serverless movement offer to address these challenges?

Agility and Flexibility Costs

One of the biggest advantages of using smaller, independently deployed services is an increase in the overall agility and flexibility of your network-based solutions. When parts of the system are independent, they can more easily be updated or replaced with less adverse effects on the rest of the solution.

This independence and lack of coupling between elements comes at a pretty high price: reduced reliability and inconsistent scalability. As the network itself becomes an important architectural element, the overall complexity of the solution increases. When you have just one big blob of code to release, you only need to manage the network connections into and out of that blob of code. That’s not easy, but it’s doable. However, when you break that single blob of code into lots of smaller parts, you need to manage the network connections between all the parts as well as the network connections into and out of the aggregate set of parts that make up your application.

The cost of increasing agility and flexibility is usually paid in the form of increased need for managing network connections, security controls, request routing, and general stability between all the independent parts of your solution.

Over the last couple decades there have been advancements aimed at tackling this increasing complexity and cost. In hindsight, each of these advancements has been part of a steady path from software that has limited dependence on network services to software that has a great deal of network dependence.

And the way these changes have presented themselves have been at the level of the operating system or host level—in other words, the platform upon which our applications are built and supported.

Operating Platforms

As services grow smaller, the cost of network communications moves to the forefront. Over the last 20 years, the trend to break down the “monolith” of single-release deployments has increased the amount of work needed to keep all those smaller parts in touch with each other and working reliably.

The background upon which this trend has played out has been the base-level operating platform that developers use to host the services. Along with the trend of smaller deployed services, a corresponding trend of smaller hosting platforms has occurred. Technically, the platform is not actually smaller. Instead, the platform exposes less. This means developers need to deal with fewer platform details and can focus on more service-related issues.

In the 1990s Linux offered a way to host the same operating system (OS) on varying hardware. Now, no matter what kind of hardware you owned, you could run the same OS. This simplified developers’ lives a great deal. You could write your code once and be assured it would run on lots of hardware platforms.

The next stage on the road to serverless came in the 2000s with the rise of virtual machines. Initially created to make it safer for multiple accounts to run their own code on the same physical machine, virtual machine operating systems (eventually just called VMs) grew in popularity quickly. Their popularity was due to how they took the Linux idea of abstracting hardware to the next level. With VMs, you could run multiple instances of the OS on a single physical machine.

The challenge of VMs was that each OS took up lots of space both on the hard disk and in runtime memory. To solve that problem, the next level of abstraction arrived—containers. Docker released its version of containers in 2013. Containers essentially isolate the running code over a shared instance of the OS; it just looks like there are multiple machines.

And finally, right around the same time containers were getting popular, the first serverless platforms started to emerge. Amazon’s Lambda platform was released in 2014, just one year after Docker.

By the end of the 2010s, the progress from a single-instance, large-scale service release on a native OS platform had morphed into a collection of small code scripts and running parameters deployed into an existing ecosystem. What used to take days, even weeks to release could now be done in minutes. And all without developers needing to worry about the details of operating systems or network interfaces. The work of publishing services on the network had become serverless.

In Chapter 2, we’ll break down the various elements of a serverless platform and see how they work together to make writing and releasing code onto the network easier, safer, and faster.

References

Below are some handy references you can use to follow up on concepts discussed in this chapter.

Get What Is Serverless? now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial