Azure Cosmos DB goes serverless

Recently, Microsoft added new options to its cloud-scale database. What does this have to do with Azure Cosmos DB? Well, Azure Cosmos DB forms one of the foundation platforms that power many of its key services. It got designed from the ground up as a distributed database, which implements a different set of consistency models. The Azure Cosmos DB allows a trade-off between performance as well as the latency of applications. Its several models work with examples ranging from NoSQL & SQL Application Programming Interfaces (APIs) for supporting Mongo DB's API to the Gremlin graph database query engine.

Azure Cosmos DB supports the most common cloud development scenarios. It gives a consistent platform that shares data on a global scale. This consistent data platform gets referred to as a planetary scale database.

Serverless Alternative

Although Azure Cosmos DB is rather useful, it does have some downsides. Running it at scale gets expensive. This fact needs to be taken into consideration while building applications around it. Manual or automatic scaling is a big factor that makes budgeting for the Azure Cosmos DB complex & hard to get it right initially.

For finding the right solution, Microsoft ran a preview of the serverless option based on its core SQL API; an interesting alternative for a traditionally provisioned option! The serverless option only charges when it runs a request. It otherwise suspends the very instance on which nothing happens. Additional latency gets included in the database operations. There is a charge for storage much like the scenario with any Azure database. The serverless trial got expanded to all Azure Cosmos DB APIs with general availability in the near future.

A basic observation based on proper research suggests that adding a serverless option to Azure Cosmos DB makes a lot of sense. This helps with many types of workloads wherein you receive requests in small numbers & batches. Research shows that for a small workload that has an irregular operational pattern, a consumption-based pricing model does make a lot of sense. It saves a good amount over the long-term as there is no commitment to provisioned throughput whatsoever.

Benefits of a serverless Azure Cosmos DB

The costs as quite low per serverless request unit for as many as a million RUs in the billing cycle. A more reliable server gets set on an availability zone, which is still a reasonable deal. The major upswing is that, what you lose in predictability, you gain back in lower costs! The storage costs remain the same for both manuals as well as automated provisioned throughput.

The way of getting started with serverless Azure Cosmos DB

With the serverless Azure Cosmos DB, jumping in is quite easy. However, like a standard Azure Cosmos DB account, it needs to be provisioned through a subscription. The serverless instance gets added to a resource group. The subsequent step involves choosing an apt API (Application Programming Interface) that you plan using for queries. With the capacity mood, pick a serverless option rather than a provisioned throughput. The final step is to link onto a region. It is imperative to remember that you only use serverless in a single Azure region with no option for geo-redundancy. There are no options to make use of the free tier either.

Once the serverless instance gets up & running, use its Application Programming Interfaces (APIs) for loading data & making queries. Research shows that just like a standard instance of Azure Cosmos DB, one can build or design JavaScript functions. Triggers run inside the database with different APIs getting used for managing all queries.

The time has come wherein serverless Azure Cosmos DB moves out of preview pretty soon. It is slated to add supports for all APIs including the recently developed Cassandra API. With a possibility of public review, one can set up as well as explore all its operations straight from the Azure Portal. However, while in public preview, there is absolutely no support for ARM (Azure Resource Manager) or any other infrastructure such as code deployment tools. Support becomes available as soon as the service becomes generally available.

One cannot automate the configuration & deployment. Hence, the developers can't use it as part of a CI/CD (Continuous Integration/Continuous Delivery) Pipeline for now; the reason being, all deployments need to be manual.

Building Code with a Serverless Azure Cosmos DB

We are constantly on the lookout for places where the serverless Azure Cosmos DB gets a lot of value, and one such place is in parallel with all the Azure Functions. It is a keen observation that the two serverless environments work together and these are ideal for low volume & event-driven applications. The serverless Azure Cosmos DB quickly ramps up from zero to around 4900 to 5000 request units per second. If one writes a code using Azure Functions to track error conditions or other alerts, it's an option or matter-of-fact that aids in quickly gathering & storing the much-needed data.

Microsoft keeps recommending using serverless Azure Cosmos DB as part of a developmental environment wherein one captures the data about full-scale application needs. It is a known fact that provisioning requests units are something of a black art. Hence, a serverless implementation running with all in-database code becomes a useful developmental tool. The developers can set up an operational environment, run various tests, capture a number of used requests, and use the obtained data to provisioned throughput for production development.

Understanding of the several serverless limitations

Of course, there are limitations to using a serverless Azure Cosmos DB account. The most important among these limitations is that one does not get access to multi-region deployments. It is a known fact that the serverless account runs only across a single region; a limitation that makes complete sense. Multi-region Azure Cosmos DB implementations need several or multiple instances that run at the same time for inter-region replication as well as consistency. For instance, if serverless requests only run when processing necessary requests, there is no guarantee that another region will be online for handling the replication. As a direct result, there occurs significant changes to the Azure Cosmos DB service-level objective for all serverless instances. The code writing is expected to last somewhere from half-an-hour to less & reading another 10 minutes or less!

Next Key Limitation

The next key limitation is handling around 4900 to 5000 requests units per second. Under normal circumstances, this should be sufficient for most simple as well as developmental implementations. However, it does require you to observe thoroughly the applications by being ready to get switched on to a provisioned Azure Cosmos DB instance in-case one regularly goes over the absolute limits. At the same time, each serverless container stores only around 49 to 50 GB of data as well as indexes. Microsoft does provide tools in the Azure Portal for helping to monitor operations along with the Azure Monitor.

Logical Solution

It seems wise to add a serverless option to Azure Cosmos DB as this process answers a lot many questions about financials or costs. For low usage coverage, it becomes unnecessary to go for global coverage & this should the software developer's first choice. Research showcases a shifting to use the provisioned throughput instance only when you are able to properly understand your application's request pattern, which gets budgeted accordingly.

A Brief Summary

From the discussion above, it's clear that Azure Cosmos DB serverless lets the Azure Cosmos account to be used in a rather consumption-based fashion. Here one is only charged for the Request Units consumed by all database operations. The storage consumed by data is also taken into consideration. It is a guarantee that no minimum charge gets involved when using the Azure Cosmos DB in a serverless mode.

The two modes of Azure Cosmos DB

It is a known fact that when using Azure Cosmos DB, every database operation cost gets expressed in Request Units. The cost gets charged based on the two modes of Azure Cosmos DB. These modes include:

Provision Throughput Mode: One commits to a certain amount of throughput, expressed in Request Units per second, that gets provisioned on databases as well as containers. The cost of database operations gets calculated by deducting the running Requests Units per second from the available ones in a second.

Serverless Mode: The cost gets calculated based on the number of Request Units per second that got consumed by your database operations.

The Use Cases

Azure Cosmos DB serverless gets used in the following scenarios:

• Low, unpredictable, and intermittent traffic

• Moderate performance

Workloads under which Azure Cosmos DB serverless work well

• Development

• Testing

• Prototyping

• Concept-proof

• Non-Critical Applications in light traffic

Conclusion

When Azure Cosmos DB goes serverless, it becomes more convenient & cost-effective to work with the Requests Units per second than the provisional throughput mode. Microsoft experimented with the serverless mode on Azure Cosmos 3D and it will get launched soon into the market. Look out for these serverless beauties!