From the book
From the book
Four Technical Criteria for Serverless
Rob Sutter, a developer advocate at Amazon Web Services, has a useful four-criteria definition of Serverless:
- No infrastructure provisioning or management
- Automatic scaling
- Pay for value
- Highly available and secure
This is more specific than "not our uptime," which helps clarify the value of Serverless and also excludes some criteria that might be marketed as Serverless but are not. It is useful to walk through several examples.
Infrastructure Provisioning
A Serverless managed service does not allow provisioning a specific infrastructure, nor does it require any management of infrastructure (see Figure 3.1). For example, most major cloud providers provide managed database services (such as AWS Relational Database Service), wherein the provider manages some functions of the database; however, these are almost always not Serverless. It's possible to tell that they are not Serverless because specific infrastructure choices must be made to deploy them: (How many different virtual machines? How many CPUs/cores on each virtual machine?) Additionally, when it comes time to apply a security patch or restore from a backup, the customer, not the provider, must decide when to do it. Perhaps worst, in the case of a customer's database going down, the customer must be monitoring the database and bring it back up. In contrast, in a handful of Serverless database services available, such as DynamoDB (AWS), CosmosDB (Azure), and Google Cloud Datastore, customers have no idea how many virtual machines or servers are running and do no management of the underlying database service.
Figure 3.1 Infrastructure Provisioning: Traditional vs. Serverless
Click to view full-sized image
Automatic Scaling
A Serverless application automatically scales through the managed services that it uses without needing any autoscaling rules set by its developers or operations staff to respond to increases or decreases in use. Scaling a typical managed SQL Server or MySQL database service at a cloud provider requires launching new servers, whereas scaling a Serverless database service can be handled automatically by the provider (see Figure 3.2). Google's Cloud Datastore has always autoscaled to whatever request load is sent to it. CosmosDB and DynamoDB have ways of limiting how quickly they respond to requests, to control costs, but both have added features in the past few years to automatically scale up and down in response to the real-time request load.
Figure 3.2 Automatic Scaling: Traditional vs. Serverless
Click to view full-sized image
Pay for Value
In the early 2000s, companies had to purchase their own physical hardware to run web applications. One of the most exciting and disruptive aspects of the public cloud was that it allowed anyone to rent physical hardware by the hour (or even smaller time units). Although this was an enormous improvement for people building scalable, highly available software, it still required capacity planning (What kind of hardware do I need?) and resulted in organizations paying a lot of money for idle and underused infrastructure.
Serverless managed services have fine-grained billing that closely matches the value their services deliver because they can optimize capacity much more easily in their multitenant services. This means that, instead of paying for a certain number of CPU cores, memory, and hard drive space (typical SQL Server/MySQL managed database service pricing), a Serverless database service can charge based upon request volume—how often the database is being read and written by clients (see Figure 3.3).
Figure 3.3 Cost: Traditional vs. Serverless
Click to view full-sized image
Highly Available and Secure
Finally, if an organization is going to hand off the responsibility of uptime, scaling, and failover to a managed service provider, that provider must provide a highly available service with adequate security. Without either of those two criteria, integrating the service into an application is not an acceptable decision. The database examples used throughout this section all have had excellent availability in practice and include best practices security as a central feature (see Figure 3.4).
Figure 3.4 Availability and Security: Traditional vs. Serverless
Click to view full-sized image