Reduced Risk

When we think about risk and software applications we often consider how susceptible we are to failures and downtime. The larger the number of different types of systems, or components, our teams are responsible for managing, the larger the exposure to problems occurring. Instead of managing systems ourselves we can outsource them, as we’ve described previously in this report, and also outsource having to solve problems in those systems.

While overall we’re still exposed to failure across all of the elements of the application, we’ve chosen to manage the risk differently—we are now relying on the expertise of others to solve some of those failures rather than fixing them ourselves. This is often a good idea since certain elements of a technical “stack” are ones that we might change rarely, and when failure does occur in them, the length of the downtime can be significant and indeterminant.

With Serverless we are significantly reducing the number of different technologies we are responsible for directly operating. Those that we do still manage ourselves are typically ones that our teams are working with frequently, and so we are much more able to handle failures with confidence when they occur.

A specific example here is managing a distributed NoSQL database. Once such a component is set up, it might be relatively rare that a failure in a node occurs, but when it does, what happens? Does your team have the expertise to quickly and efficiently diagnose, fix, and recover from the problem? Maybe, but oftentimes not. Instead, a team can opt to use a Serverless NoSQL database service, such as Amazon DynamoDB. While outages in DynamoDB do occasionally happen, they are both relatively rare and managed effectively since Amazon has entire teams dedicated to this specific service.

As such, we say that risk is reduced when Serverless technologies are used since the expected downtime of components is reduced, and the time for them to be fixed is less volatile.

Reduced Resource Cost

Typically, when we are operating applications we have to figure out what kind of, and how many, underlying hosts they’re going to run on. For example, how much RAM and CPU do our database servers need? How many different instances do we need to support scaling? Or to support high availability (HA)?

Once we’ve figured out planning what hosts or resources we need we can then work on allocation—mapping out which parts of our application are going to run on which resources. And finally, once we’re ready to deploy our application, we need to actually obtain the hosts we wanted—this is provisioning.

This whole process is complicated, and it’s far from an exact science. We very rarely know ahead of time precisely what our resource requirements are, and so we overestimate our plan. This is known as over-provisioning. This is actually the right thing to do—it’s much better to have spare capacity and keep our application operating than for it to fall over under load. And for certain types of components, like databases, it may be hard to scale up later, so we might want to over-provision in anticipation of future load.

Over-provisioning means we’re always paying for the capacity necessary to handle our peak expected load, even when our application isn’t experiencing that load. The extreme case is when our application is sitting idle—at that point in time we’re paying for our servers to be running when in fact they aren’t doing anything useful. But even when our applications are active we don’t want our hosts to be fully utilized. Instead, we want to leave some headroom in order to cope with unexpected spikes in load.

The huge benefit that Serverless brings to this area is that we don’t plan, allocate, or provision resources. We let the service provide precisely the amount of capacity we need at any point in time. If we don’t have any load, then we don’t need any compute resource, and we won’t pay for any. If we only have 1 GB of data, we don’t need the capacity to store 100 GB. We trust that the service will scale up precisely when we need it, on demand, and this applies equally to FaaS and BaaS services.

Beyond the removal of the accounting headache that comes with resource allocation, Serverless also makes our costs far more efficient. For any application that has inconsistent load, we will see resource cost savings by using Serverless. For instance, if our application is only running for 5 minutes of every hour, we only pay for 5 minutes of every hour, not the whole 60 minutes. Further, a good Serverless product will have very precise increments of use; for example, AWS Lambda is charged by the 100 milliseconds of use, 36,000 times more precise than the hourly billing of EC2.

In modern non-Serverless apps, we do see some of these benefits through techniques like auto scaling; however, these approaches are often not nearly as precise as a Serverless product (see above our point of EC2 charging by the hour), and it’s still typically not possible to auto-scale a non-Serverless database.

Increased Flexibility of Scaling

All of these resource cost benefits come from the fact that a Serverless service precisely scales to our need. So how do we actually make that scaling happen? Do we need to setup auto-scale groups? Monitoring processes? No! In fact, scaling happens automatically, with no effort.

Let’s take AWS Lambda as an example. When the platform receives the first event to trigger a function, it will spin up a container to run your code. If this event is still being processed when another event is received, the platform will spin up a second instance of your code to process the second event. This automatic, zero management, horizontal scaling will continue until Lambda has enough instances of your code to handle the load.

A particularly nice aspect to this is that Amazon will still only charge you for how long your code is executing, no matter how many containers it has to launch. For instance, it costs precisely the same to invoke a Lambda 100 separate times in one container sequentially as it does to invoke a Lambda 100 times concurrently in 100 different containers, assuming the total execution time across all the events is the same.