Multi-tenant architecture is a software architecture in which multiple “tenants” (software instances, users, etc.) are served by the same physical machine, rather than by separate wholly dedicated machines. It is often a feature of cloud serverless platforms, as hosting and running multiple tenants on the same machine often allows the cloud vendors to reduce the per-user cost.
For example, imagine you are a developer and you’d like for your application to have a cloud database.
With traditional single-tenant architecture, you would have to choose and pay for one or more dedicated machines. To put it in simplified terms, if you needed 1.5 machines worth of server storage and compute capacity, you’d still have to pay for two complete machines.
Multi-tenant architecture allows you to pay for only the resources you actually consume by enabling more than one software instance or user to share the same machine.
So in the case of your cloud database, you could choose to use CockroachDB Serverless, and rather than having to choose a set number of machines and worry about hardware details, you can simply create your database cluster and it will be allocated the resources it needs in real-time on shared machines. Rather than paying for whole machines 24/7, you pay only for the portion of the machine’s resources that you actually use – and in the case of CockroachDB Serverless specifically, you actually pay nothing if your database’s storage and usage is below the limit for free accounts.
A serverless database is any database that embodies the core principles of the serverless computing paradigm. Those core serverless principles are:
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
For developers, what’s important to note is that a serverless database abstracts away most of the complexity into a simple API in the cloud. In a serverless database developers should expect scale, resilience, and transactional consistency to be accomplished without much operational overhead.Perhaps most importantly, with a serverless database you pay only for what you use. And most serverless databases are free up to a certain amount of storage (Example: 5GB).
This video explains serverless databases in less than 3 minutes:
While the term serveless has a specific definition, it is not well understood, and the term is used generously by marketing teams in the industry. Because of this trend it’s difficult to narrow down which databases are truly serverless. This is the current list:
For starters, any serverless application will run better on a serverless database. This does not mean that serverless applications need to run on a serverless database. It’s just that running a serverless application on a serverless database allows you to take full advantage of being distributed.
There are relational serverless databases and eventually consistent Serverless databases so the use cases will vary depending on whether you want the transactional consistency that you get from a relational database. Also, each of the serverless databases listed above has different strengths and weaknesses. Some have instantaneous starts while most others have cold starts. Some have single write node limitations, or unfamiliar SQL language variations, or high latencies…So you’ll have to research each before deciding which is best for your use case. In general, a serverless database is adopted for these two reasons:
Serverless databases abstract operational tasks
Serverless databases simplify the costs of the cloud (aka, pay for what you use)
Here are some situations in which a serverless database is a good fit today:
Side project - Don’t spend money upfront and if the app is successful, monitor & control your spending throughout.
Proof/Starter Project - build out a simple proof of concept for an application idea without paying for a platform in order to confirm that the database is the right fit before spending any money.
Development environments - prototype a new use case on a serverless database. This type of dev environment is great for quick tests or to try out features.
Continuous integration (CI) pipelines - create a testing environment for your development teams so they don’t have to think about choosing, sizing, etc. the machines. They can just write code and run queries, and automate all of this.
Evaluation - users that would like to understand how a database works before committing to paying for a cluster. Users who want to test out certain features or begin prototyping their application before paying.
Also, serverless databases can provide additional benefits if your project/application has:
Spiky transactions - applications that have unpredictable high and low traffic depending on the time of day, year, month, etc. (i.e. a social media app that sees spikes on weekends. A financial news site that sees spikes twice a day when markets open and close. A retail site that sees spikes during Black Friday or the holidays.) Or applications that might have unpredictable spikes in traffic. (i.e. A breaking news website. A gaming workload when a game suddenly goes viral.)
Budget caps - a project has a limited budget, but potential for scale. Test out the application first and manage your budget through its development.
Limited manpower dedicated to the project - only a small group of engineers are assigned to work on this project, but still would like to see it be successful
Immediate delivery - an application that needs to be delivered, fast. Quickly build on a serverless database and make updates while in production.
A SQL API is simply an API, or Application Programming Interface, that facilitates the use of a SQL database. Rather than connecting directly to the database to send SQL queries, developers using a database with a SQL API could send data requests to that API, similar to how their application would interact with any API.
Step Function is a serverless service provided by AWS that’s aimed at making it easier and quicker to link AWS-based serverless functions and other AWS services into “steps”, where the output of one function becomes the input of the next function.
While it’s certainly possible to accomplish this without the use of step functions, AWS Step Functions offers a visual workflow editor, and it automates elements such as retry handling and tracking that would otherwise need to be coded manually. In other words, serverless step functions take some of the development work out of the hands of developers, and handle it automatically in the cloud.
“Step Functions” is a product offering that is specific to AWS, but the other major cloud vendors do have similar offerings such as Azure Logic Apps and GCP Workflows.
Serverless SQL is an alternative way of referring to a serverless SQL database such as CockroachDB Serverless. If a company is looking for a serverless SQL solution, it means they are looking for a database that gives them all of the advantages inherent in using serverless architecture for the database without sacrificing the familiarity and consistency associated with SQL databases.
A REST API is an API that meets the requirements for RESTful architecture, which include (among other things):
Independent client and server applications
Statelessness (requests must include all information necessary for processing)
Cacheability
Layered architecture
REST APIs are meant to be more scalable and more lightweight than some other API designs, and RESTful architecture is thus a popular choice for modern API architectures.
A serverless REST API is just a REST API that has been deployed using a serverless architecture. For example, you could build a serverless REST API using AWS Lambda for serverless functions and CockroachDB Serverless as your serverless database.
Serverless functions are any functions of an application that are hosted and run on a cloud serverless platform, such as AWS Lambda, GCP Cloud Functions, or Azure Functions. A serverless function is typically designed with one single purpose in mind, and it will run (and consume compute resources) only when triggered.
Serverless functions allow developers to ignore the intricacies of provisioning and managing specific machines to run their applications on the cloud. Instead, the cloud provider who operates the serverless function service (such as AWS Lambda) takes care of provisioning and managing machines, and scaling up and down automatically based on the frequency with which the function is being called.
Aside from the convenience of not having to worry about the details of servers, serverless functions can also save developers money, because each function in an application is run and scaled independently, and developers are billed only for the compute they actually use.
If, for example, a developer has an application with four main features but users typically only use one of them, serverless functions would allow for the functions associated with the popular feature to scale seamlessly while functions associated with the unused functions would remain available in case they were called, but would not be racking up any server charges while they remained dormant.
There are a variety of reasons you might not want to use serverless features for your application. Among them:
Latency – when a once-dormant function gets called for the first time in a while, it can take a while to start up, depending on the specifics of your application and the cloud services you’re using. This is known as a “cold start”, and it can cause high latency in your application if you’re not able to avoid or mitigate it.
Observability – due to their nature, it can sometimes be challenging to debug issues with serverless functions in production.
Vendor control – while handing the complexities of server provisioning and management over to cloud vendors has its advantages, it also means that developers can’t control those things. It can also sometimes limit the ease with which you can implement technology from outside that vendor’s ecosystem into your application architecture.
There can also be a bit of a learning curve for some developers, as event-driven architectures and serverless functions are relatively new. This can be both an advantage and a disadvantage – it may take developers longer to wrap their heads around for the first time, but it could also help with hiring as many developers prefer working with cutting-edge technologies, and see work in event-driven development with serverless functions as valuable experience.
The term serverless framework can refer to two different things: the general concept of a development framework for deploying code to serverless platforms such as AWS Lambda, or one specific such framework that is branded as Serverless Framework, developed by Serverless, Inc.
Broadly, a serverless framework is a software development tool that’s aimed at making it easier for developers to deploy code to serverless cloud platforms.
Typically, a serverless framework will exist for one or more programming languages, and be aimed at helping with deployment to one or more cloud serverless platforms. Zappa, for example, is an open source serverless framework designed to facilitate deploying Python applications to AWS Lambda.
Serverless, Inc.’s Serverless Framework is one example of a serverless framework as defined above: it’s a development tool that facilitates deploying apps written in a variety of different coding languages to AWS Lambda (among other platforms).
Request Units (RUs) measure the compute and I/O resources consumed when a user or application queries a database. Different queries will “cost” different amounts of Request Units; a small read request might cost just a few RUs, whereas a full table scan could cost many.
Similarly, a database serving an application with millions of users (and thus millions of read/write requests) will consume RUs at a much faster pace than a database that’s rarely used.
RUs provide a convenient way to track resource consumption and billing for serverless databases, although different databases may define and price RUs in different ways. In the case of CockroachDB Serverless specifically, all users are allocated 250 million RUs of usage per month for free, with a cost of $1 per additional 10 million RUs after that.
The term edge computing refers to bringing computing processes such as computation and data storage closer to the “edge” of a network.
Traditionally, users or devices connected to a network would send data to a centralized location for storage and processing, but this approach introduces some latency, particularly now that any product or application can have users all over the globe.
Edge computing, then, describes an alternative approach – a distributed computing paradigm where data is processed in a location that’s physically close to its origin to minimize latency.
For example, consider an application with users all over the world. If that application relies on a centralized SQL database located in Chicago, a request from a user in Germany has to travel halfway across the world and back – almost 10,000 miles in total!
If, however, the application relies on a distributed database such as CockroachDB, a German user’s request might only have to travel a small number of miles to an EU-based node where it can be processed, greatly reducing latency for the user.
This reduction in latency is the driving force behind the move towards edge computing.
“Compute” is a term that is used in a variety of contexts, but in discussions of serverless services such as serverless functions or databases, “compute” is typically used as shorthand for the computing resources (such as CPU, RAM, GPU, etc.) required to perform some kind of action.
In the context of a serverless database such as CockroachDB Serverless, for example, the amount of “compute” – i.e. computing resources – your database uses each month processing queries is one of the factors on which billing is based.
In the context of CockroachDB Serverless, burst capacity is the monthly reserve of Request Units available to free users to handle bursts of database activity. Paid users will have a larger burst capacity, based on their monthly resource limit. CockroachDB Serverless defines “bursts” as any usage above the 100 RU/second threshold.
Each free user begins the month with a reserve of 10 million Request Units in reserve for bursts, and earns an additional 100 RUs per second (minus whatever amount of RUs are consumed in that second). This burst capacity ensures that even free users can handle sudden usage spikes without decreased database performance. When all available burst capacity has been consumed, the database will return to processing queries at a consumption rate of 100 RUs/second.
In the context of discussions of serverless databases, you may hear people talking about “the cluster.” Or you may hear references to an Aurora cluster, or a CockroachDB Serverless cluster. What does that actually mean?
A serverless database cluster is the collection of nodes that, all together, make up the database.
Serverless databases such as CockroachDB are also distributed databases. This means that, rather than living in a single place, the data in the database is split up and replicated across multiple “nodes” to ensure that it always remains available. “Cluster” refers to the collection of these nodes – all of the nodes that, together, make up your database.
(Of course, it’s all a bit more complicated than this makes it sound.This article is a great primer on the architecture of a serverless database.)
At first glance, it sounds impossible – how can any cloud-based architecture be serverless? But of course, the serverless in serverless architecture doesn’t really mean without servers. So what does it mean? Let’s dive in!
Serverless architecture is an approach to software development that allows developers to ignore considerations associated with the physical machines their code will be run on. Physical machines are still used, of course, but they are provisioned by a cloud provider in accordance with the in-the-moment requirements of the developer’s application.
Serverless architecture thus allows developers to focus on building the services that power their application, without having to worry about which physical hardware to choose, how and when to scale, how and when to maintain and upgrade their machines, etc. Instead, the cloud provider takes care of all of that.
Serverless architectures also typically offer a pay-for-what-you-use model, which is often cheaper than paying for a preset number of dedicated machines. For example, a developer who uploads a function to AWS Lambda will be billed based on how many times the function was run during the billing period.
Many elements of an application can now take advantage of serverless architectures.
One of the most common examples of serverless architecture is serverless functions (functions as a service, or FaaS). Cloud providers including AWS (AWS Lambda), Google (Google Cloud Functions), and Microsoft (Azure Functions) allow developers to upload specific application functions to the cloud, where the function will then be run when it is triggered (for example, by an API call).
Another common example is a serverless database such as CockroachDB Serverless. Developers can host a distributed SQL database with the cloud provider of their choice and it will scale automatically (within the developer’s set monthly spending limit) to meet demand.
Serverless architecture is often used in tandem with microservices architecture, as the two complement each other well. When an application is broken down into individual microservices, each of these can be hosted using a serverless architecture, allowing them to auto-scale individually, rather than having to scale all of the application’s resources up and down monolithically.
The advantages of using a serverless architecture can vary based on the application, the use case, and the cloud provider, but some of the most commonly-enjoyed benefits are:
Scale: Serverless architectures allow applications to scale automatically (from a developer perspective) because all the work and automation associated with scaling is handled by the cloud provider.
Cost savings: Because they typically use pay-per-use models (rather than making developers pay for entire machines), they can often offer great performance at a lower price.
Time savings: Because they offload all of the server maintenance and ops work onto the cloud providers, serverless architectures free up developers, giving them time to focus on the more important work of building their applications.
Serverless architectures aren’t the best choice for every use case, however.
If you require detailed control over the machines your application is running on, either for performance or security reasons, serverless architecture may not be the best choice, since that work is offloaded to the cloud providers.
Serverless architectures aren’t always cheaper, either – there are certainly cases, particularly for larger enterprises, where dedicated machines can end up being the more affordable choice. Vendor lock-in with many serverless services can also be a problem that leads to increased costs.
Additionally, not all serverless platforms and cloud providers are created equal. Issues like slow cold starts can actually make your application’s performance worse, so it’s important to look at the details when it comes to choosing any sort of serverless provider.
An API, or Application Programming Interface, is a kind of software interface between two different applications. Typically, an API can accept incoming requests and output a relevant response. This allows one application to access some of the data and/or functionality of another application.
A cloud API is just an API that works with cloud services. For example, a company with a cloud database might build a cloud API to make querying that database more efficient.
AWS Lambda is Amazon Web Services’s Functions-as-a-Service (FaaS) offering. It allows developers to run their code in the cloud, without having to worry about provisioning or managing specific servers. Instead, devs can upload a function to Lambda and have it run only when it’s triggered.
As with most serverless products, one of the big advantages of AWS Lambda is that it scales automatically, so developers don’t have to worry about provisioning more machines if their application goes viral – Lambda handles that automatically.
It also charges developers only for the compute their functions actually use, so they don’t have to worry about racking up big server bills for keeping their functions in the cloud even when their application isn’t seeing much use.
The other major cloud providers offer similar FaaS services; for example, GCP offers Cloud Functions and Microsoft has Azure Functions.