What is a Serverless Database?
Serverless computing services are offered by cloud vendors. In this cloud computing model, the vendor runs servers and manages resource allocation dynamically. Cost for serverless is calculated according to resources used by the application, not pre-purchased capacity units.
Serverless databases are a prerequisite for serverless computing. They are designed specifically for unpredictable and rapidly changing workloads. Serverless computing still requires servers, and serverless databases are essential for operating those servers.
- Features of Serverless Databases
- Multi-Tenant Architecture
- Dynamic Quality of Service
- Geo Distribution
- Single Transactional Query Language
- Choosing a Serverless Database
- Data Model Needs
- Infrastructure-as-Code
- Fully Managed
- Pricing Model
- Serverless Database Pros and Cons
- Advantages of Using a Serverless Database
- Disadvantages of Using Serverless Databases
Features of Serverless Databases
Multi-Tenant Architecture
One of the advantages of a serverless database is that it can act as a single resource pool for multiple projects in your organization.
For the development team, this is a huge advantage as there is no need to build isolated application-specific data sources.
This is made possible by multi-tenant architecture, which enables developers to configure multiple applications and set up all deployments in the same database cluster.
Dynamic Quality of Service
When using multi-tenancy, you can assign each tenant unique priorities. In this case, you can assign priorities to specific tenants to use those system resources.
This allows operations teams to maximize resource usage across the organization’s projects. You can run your resources at 60-80% utilization; if more than 90% of the peak is observed, the lower priority workloads are suppressed.
Geo Distribution
Since most companies do business on a global scale, you need to provide data to users around the world. Working with an infrastructure that has many data centers in different geographical locations, you can serve data physically near to your users, which can significantly improve user experience.
Also, by using geo-distributed high availability, there is less risk of service disruption. Serverless databases allow you to replicate multiple datasets globally without additional tools or custom development. Protocols built into the serverless database network layer allow you to respond correctly to errors and performance degradation.
Single Transactional Query Language
A key advantage of a serverless database is that it lets you serve multiple applications using one store of resources. However, applying a single data structure or to all applications that use that data can cause serious challenges in development. For example, storing data in its original format is not possible when using this structure.
Some applications require strong data schemas, while others require a schema-less data model. The ideal serverless database supports both structured and unstructured data, so it can accommodate several different data models
Serverless databases can make a schema optional. This can help support both structured and unstructured data use cases. It also lets you benefit from the advantages of a schema, without any of its disadvantages (because it’s possible to process data without it).
Choosing a Serverless Database
Serverless databases are available as managed services from public cloud providers like AWS and Microsoft Azure. Serverless applications can also be supported by open source NoSQL databases like MongoDB and Cassandra. Let’s consider the different factors at stake when evaluating databases for a serverless application.
Data Model Needs
The first factor to consider is the requirements of the application data model and the degree to which the database meets these requirements.
Amazon has promoted the concept of a built-to-purpose database. The idea here is that in the past, most applications were forced to use relational databases. There are many different database types to choose from, and all of them can be used to power serverless databases. Choose the one that best suits your application:
- Relational / SQL / normalized-improves query flexibility at the expense of performance. For example, MySQL, PostgreSQL and Raima Database Manager
- NoSQL / denormalized-optimizes read-time queries at the expense of denormalized data sets and more difficult querying. These include MongoDB, Cassandra, and DynamoDB.
- Specific use cases-a database for a specific purpose, such as Elasticsearch for full-text search, Neo4J for graph modeling, or Redis for in-memory operations and ultra-high performance.
Most applications have data that suits one of the first two categories. The choice is flexibility vs. performance. If your data access patterns might change and you need flexibility, use a relational database. Use a NoSQL database to achieve high performance at scale.
Infrastructure-as-Code
Infrastructure as Code (IaC) is becoming the best practice for developers and IT specialists. IAC allows you to fully define the infrastructure using a configuration file, deploy it on demand, and make updates in a consistent and repeatable manner.
This approach is especially useful for serverless applications and applications, where the infrastructure is tightly integrated. Serverless applications include queues, streams, blob storage, with event triggers connecting them together. If your serverless application doesn’t use IaC, it can be very difficult to manage, and therefore your serverless database must also support IaC.
Fully Managed
The idea behind serverless was to move heavy infrastructure tasks over to cloud vendors, freeing up development time. It is natural to extend this to the database as well, and rely on a managed database, to avoid maintenance related to database patching, upgrades, and scaling. However, for some use cases, managed databases may not provide an optimal solution and may be less customizable for specific use cases. The alternative is to run a standalone database like MongoDB, and use it to serve your serverless applications.
Pricing Model
Many serverless applications use a pay-as-you-go pricing model. On AWS Lambda, you pay for the actual calculations performed by your Lambda function, regardless of the amount of traffic or time the function is running. Similarly, services such as Amazon SQS, SNS, and API Gateway use a pay-as-you-go pricing model.
Pay-as-you-go in the database world is slightly different. This is because you have to pay for storage in addition to the computing power required to access the data. However, storage is typically priced per GB, and can still be much more cost effective than paying for an entire AWS EBS volume attached to a compute instance.
Serverless Database Pros and Cons
Advantages of Using a Serverless Database
Buying a fixed number of servers and using them to deliver a serverless database is complex, and usually provides low utilization, making it much more expensive than using a managed serverless database. Managed database options also eliminate operating costs such as licensing, installation, maintenance, support, and patches.
In a serverless architecture, developers and operators can save time by not having to set up and tune auto-scaling strategies. Cloud providers are responsible for expanding capacity to seamlessly meet demand. Now a small group of developers can develop applications independently, with no need for infrastructure or engineering support teams.
Disadvantages of Using Serverless Databases
Infrequent use of a database can result in higher database response latency, compared to databases running actively on dedicated servers, virtual machines, or containers. This happens because the cloud provider spins down the server when the serverless database is not used. The longer the startup time, the longer the wait time. This problem can be mitigated using features like AWS Lambda’s provisioned concurrency.
Serverless computing is also not suitable for certain computing workloads, such as high performance computing. The reason is that the cloud provider imposes certain resource limits, which do not allow extreme performance or throughput. Another reason is that it can be more cost effective to configure the required number of servers and run them for a specific time period to achieve the required throughputs or compute capacity.
Serverless monitoring is much more difficult than in traditional server infrastructure. Diagnosing performance or excessive resource usage problems can be difficult. You can reserve all the features, but you can’t attach a profiler, debugger, or APM tool to study the details.
Environments running serverless architectures are generally not open source, making it difficult to accurately replicate performance characteristics in a local environment. Fortunately, there are already good serverless monitoring tools emerging that can solve this problem.
Serverless databases can be mistaken to be more secure than traditional databases. It is true that cloud providers take the necessary steps to address operating system vulnerabilities. However, vulnerability to attacks might actually be much higher, because the application has more components than a traditional architecture, and all of them are entry points for serverless applications. Security approaches that operate at the endpoint or server level are not relevant in a serverless environment. New serverless security tools place their focus on protecting individual serverless functions.
