Serverless cloud computing services started with AWS Lambda, which lets you run code without provisioning or managing servers. AWS Lambda is an example of functions as a service, or FaaS, and other FaaS implementations quickly followed at Microsoft Azure and Google Cloud. Later, cloud providers started offering other services in serverless form. Serverless was a new way of thinking about cloud services, and in practice serverless architectures often cost a fraction of provisioning permanent server instances to run the same loads.
Serverless explained
Despite what the name implies, serverless doesn’t mean that no servers are used. Instead, it means that you don’t have to provision, manage, or pay for the underlying servers per se.
When a request for a serverless service comes in, the cloud provider allocates an instance (virtual machine) or pod (a logical set of containers, usually managed by Kubernetes) to handle the request from its pool. When the serverless code exits, the allocated resources are returned to the pool. In general, you pay for the resources you use based on their CPU capacity, RAM allocation, and time active.
Serverless functions and services can invoke each other, can invoke other services, and can write to shared file systems and databases. One of the biggest technical advantages of serverless functions is their extreme scalability: Unlike provisioned servers, which can easily be swamped by traffic spikes, new serverless function instances are launched for every event that needs them, and all instances automatically return to the pool when they are not needed.
What happens when an appropriately sized instance (or pod) isn’t available in the pool when a request comes in? The cloud provider must create a new one. That causes some latency in handling the request. If latency is a problem for your use case, then you can pay to keep some functions initialized and hyper-ready to respond. AWS calls this Provisioned Concurrency; the other cloud providers use different names, but they all rely on keeping some instances pre-warmed to reduce latency.
Serverless functions and services usually have high availability. If you are using a single server, virtual machine, or container to run a service, the probability of an eventual service outage from a machine or data center failure is high. Cloud providers generally maintain redundant compute capacity for serverless functions across multiple availability zones (data centers in different but nearby physical locations) in each geographical service region.
In addition to serverless functions and services from cloud providers, there are many cloud-agnostic frameworks and SDKs for creating serverless apps. These include Kubeless, Pulumi, OpenFaaS, OpenWhisk, and Serverless Framework.
Serverless databases explained
According to Jim Walker of Cockroach Labs, a serverless database adheres to nine core principles:
- Little to no manual server management
- Automatic, elastic app/service scale
- Built-in resilience and inherently fault tolerant service
- Always available and instant access
- Consumption-based rating or billing mechanism
- Survive any failure domain, including regions
- Geographic scale
- Transactional guarantees
- (Elegance of relational SQL)
Principles 1 though 5 could be applied to any serverless service, but principles 6 through 9 are specific to global SQL databases. Number 9 appears to be biased in favor of distributed SQL databases such as CockroachDB, which is why I have added parentheses around that item.
The traditional way of connecting to most databases is to establish a persistent TCP connection from the client to the server. That’s not a good fit for serverless databases, because setting up a TCP connection can be time-consuming. Ideally the client should connect to the serverless end point nearly instantly (under 100 ms) and get a response back within a second for simple queries. Some serverless databases (Amazon Aurora Serverless, for example) support HTTP (preferably HTTPS) connections and take care of the connection pooling needed to support scaling and make connections nearly instant.
How serverless databases can save you money
Traditional databases should be sized for the maximum expected query load and storage capacity. If a database can scale up and down without the need for data migration, you can save money by adjusting the CPU up during heavy traffic periods and down during light traffic periods.
Serverless databases typically don’t need to be sized at all. You aren’t charged for CPU unless you submit a query, and at that point you get as much capacity as your query needs. You are then charged for the capacity used multiplied by the time the database is active. Unfortunately, you are still charged for your data storage. According to Amazon, you can save up to 90% of your database cost with Aurora Serverless compared to the cost of provisioning capacity for peak load.
When serverless databases are suboptimal
The recommended use cases for serverless databases are variable workloads, unpredictable workloads, enterprise database fleet management, software-as-a-service applications, and scaled-out databases split across multiple servers.
Databases that have predictable, steady loads are better handled with traditional server deployments. Even databases that are busy weekdays and idle on weekends and holidays are usually better handled with servers rather than serverless, with the proviso that you shut down the servers every weekend and holiday. You’ll need to do the arithmetic to be sure, but you can use the pricing tables and your usage patterns to determine which approach will be more cost-effective.
Examples of serverless databases
The following nine serverless databases are available as of this writing. A tenth, MongoDB Atlas, offers serverless instances in a preview. It wouldn’t be surprising if other database vendors with cloud versions, such as Oracle, add serverless versions at some point in the future.
Amazon Aurora Serverless
Amazon Aurora Serverless v2, currently in preview, scales instantly from hundreds to hundreds of thousands of transactions in a fraction of a second. As it scales, it adjusts capacity in fine-grained increments to provide just the right amount of database resources that the application needs. There is no database capacity for you to manage, and you pay only for the capacity your application consumes. Amazon claims you can save up to 90% of your database cost compared to the cost of provisioning capacity for peak load. Amazon Aurora Serverless v2 is MySQL-compatible.
Amazon DynamoDB
Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database designed to run high-performance applications at any scale. DynamoDB offers built-in security, continuous backups, automated multi-region replication, in-memory caching, and data export tools.
Azure SQL Database Serverless
Serverless is a compute tier for single databases in Azure SQL Database that automatically scales compute based on workload demand and bills for the amount of compute used per second. The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns. Azure SQL Database Serverless is a version of Microsoft SQL Server.
Azure Synapse Serverless
Azure Synapse Serverless allows you use T-SQL to query data from your data lake in Azure rather than provision resources ahead of time. You only pay for executed queries, and the pricing is based on the amount of data processed by each query.
CockroachDB Serverless
CockroachDB Serverless is an always-free option, currently in beta, on the PostgreSQL-compatible Cockroach Labs cloud. It can use highly available clusters on AWS or Google Cloud in a multi-tenant configuration. The limits for free use are 250M request units per month and 5GB storage. Beyond that the charges are $1 for 1 GiB per month and $1 for 10M RU per month.
Fauna
Fauna is a flexible, developer-friendly, transactional database delivered as a secure and scalable serverless cloud API with native GraphQL. Fauna combines the flexibility of NoSQL systems with the relational querying and transactional capabilities of SQL databases. Fauna supports both the Fauna Query Language and GraphQL.
Google Firebase
Cloud Firestore is a serverless NoSQL, document-oriented database that is part of Google Firebase. Unlike a SQL database, Cloud Firestore has no tables or rows. Instead, you store data in documents, which are organized into collections. Each document contains a set of key-value pairs.
Cloud Firestore is optimized for storing large collections of small documents. All documents must be stored in collections. Documents can contain subcollections and nested objects, both of which can include primitive fields like strings or complex objects like lists.
PlanetScale
PlanetScale is a MySQL-compatible, serverless database platform powered by Vitess. Vitess is a database clustering system for horizontal scaling of MySQL (as well as Percona and MariaDB). Vitess also powers Slack, Square, GitHub, YouTube, and more.
Redis Enterprise Cloud
Redis Enterprise Cloud is a fully-managed, serverless, in-memory database that runs on AWS, Azure, and Google Cloud. Enterprise modules can extend Redis from a simple key-value, data-structure store to support many data models and functions, including search, graph, JSON, time series, and AI. Redis Enterprise does automatic re-sharding and rebalancing while maintaining low latency and high throughput for transactional loads. Redis on Flash, a Redis Enterprise feature, can place frequently accessed hot data in memory and colder values in Flash or persistent memory, such as Intel Optane DC.
As we’ve seen, serverless databases offer highly scalable, cloud-based data storage and retrieval without requiring you to provision CPU or storage ahead of time. All serverless databases offer a pay-for-what-you-use model, and a few are free for small databases with limited burst speed.