Most applications need a data persistence layer. The most performant and scalable database with no management on Azure is Cosmos DB. It's the best database available for a serverless architecture, especially as serverless functions can quickly expose scaling issues in conventional databases with their instant and infinite scaling. The following are some of its features:
It's the best database available for a serverless architecture, especially as serverless functions can quickly expose scaling issues in conventional databases with their instant and infinite scaling.
Cosmos DB is considered serverless because it is entirely managed, with no server-level specifics, and is charged per resource used rather than upfront. There can be a blurred line with managed services—if they are managed enough, they can be considered serverless. However, Cosmos DB is definitely serverless because of its resources-used payment model. To expand on this point further, other managed services such as a piece of SaaS software would only count toward a true serverless architecture if they were charged per-resource-usage. This is still fairly uncommon, with software such as Apigee, Sitecore, or Salesforce generally demanding large licenses, irrespective of usage.
It is a NoSQL database with customizable levels of consistency (with a tradeoff against performance) and multiple supported data models.
It is charged per request (and the complexity of that request) and the data stored.
It is generally fairly expensive but will scale infinitely across the globe.
This exercise will walk you through creating a Cosmos DB instance in the Azure portal. Follow these steps:
Open the Azure Portal and search for "cosmos." Click on the result that says Azure Cosmos DB:
Figure 1.24: Searching for Cosmos DB
You should see a screen like the following one, which has an Add button in the top left. Click Add:
Figure 1.25: Screen before creating an Azure Cosmos DB instance
On clicking Add, you will see a window like the one shown in the following screenshot. Fill in the Resource Group, the name you want your Cosmos DB instance to have (advancedserverlessproductdb is used as the Account Name in this exercise), and the region you want it to be in (Location). Select the SQL API. Given that this is a development book for learning, switch off Georedundancy:
Note
In a real deployment, you would certainly want to enable Georedundancy. Under the hood, it deploys Cosmos DB to each of the "paired" Azure datacenters, such as North Europe and West Europe, for example. Multi-region Writes are certainly something you should consider if you are running a truly global application, with users wanting to edit data across the world. One thing to bear in mind with this is that if you have a consistency model that forces cross-regional locks on writing, this setting could contribute to a deterioration in performance.
Figure 1.26: Azure Cosmos DB setup – Basics
Click Review + create on the bottom of the screen and then click on the Create button. This will kick off the deployment of your Cosmos DB:
Figure 1.27: Summary of Azure Cosmos DB account
It's likely to take a little while. If you click on the notifications button (the bell icon) in the portal, you can check on how it is progressing:
Figure 1.28: Notification of progress when creating a Cosmos DB
Note
If you click the Download a template for automation link in the bottom right (see Figure 1.27), you will get the ARM template and scripts in Bash, PowerShell, and Ruby for deploying that template. Behind the scenes, the portal simply submits the same template, and this template and code is very useful for your CI/CD pipelines.
You now have an Azure Cosmos DB running, ready to be your serverless persistence layer. This database will happily handle any plausible scale that can be thrown at it, without you having to lift a finger. It also has the ability to trigger Azure Functions on data that are being entered or modified in it, which is a core capability that we will be building on. If you need a RDBMS, and a NoSQL database is simply unacceptable, then other contenders to Cosmos DB would be the SQL Azure, Azure for PostgresSQL, and Azure for MySQL. However, these have the disadvantage of lack of true elastic scaling from a serverless point of view, and all the usual tradeoffs of SQL versus NoSQL apply. Generally, though, they will fit most requirements; they just need more management than a true serverless solution such as Cosmos DB. As always for any application architecture, pragmatism applies.