{"id":660,"date":"2020-05-11T00:00:00","date_gmt":"2020-05-11T00:00:00","guid":{"rendered":""},"modified":"2025-06-29T23:28:47","modified_gmt":"2025-06-30T06:28:47","slug":"office-licensing-service-and-azure-cosmos-db-part-2-improved-performance-and-availability","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/office-licensing-service-and-azure-cosmos-db-part-2-improved-performance-and-availability\/","title":{"rendered":"Office Licensing Service and Azure Cosmos DB part 2: Improved performance and availability"},"content":{"rendered":"\n

This post is part 2 of a two-part series about how organizations use Azure Cosmos DB to meet real world needs, and the difference it\u2019s making to them. In part 1<\/a>, we explored the challenges that led the Microsoft Office Licensing Service team to move from Azure Table storage to Azure Cosmos DB, and how it migrated its production workload to the new service. In part 2, we examine the outcomes resulting from the team\u2019s efforts.<\/i><\/p>\n\n\n\n

Strong benefits with minimal effort<\/h2>\n\n\n\n

The Microsoft Office Licensing Service (OLS) team\u2019s migration from Azure Table storage to Azure Cosmos DB<\/a> was simple and straightforward, enabling the team to meet all its needs with minimal effort.<\/p>\n\n\n\n

An easy migration<\/h3>\n\n\n\n

In moving to Azure Cosmos DB, thanks to its Table API, the OLS team was able to reuse most of its data access code, and the migration engine they wrote to avoid any downtime was fast and easy to build.<\/p>\n\n\n\n

Danny Cheng, a software engineer at Microsoft, who leads the OLS development team explains:<\/p>\n\n\n\n

\u201cThe migration engine was the only real \u2018new code\u2019 we had to write. And the code samples for all three parts are publicly available, so it\u2019s not like we had to start from scratch. All in all, the migration tooling we developed took three developers about four weeks each.\u201d<\/em><\/p>\n\n\n\n

Virtually unlimited throughput<\/h3>\n\n\n\n

Today, database throughput is no longer an issue for the OLS team. With Table storage, the team faced a throughput limit of 20,000 operations per second per storage account, which forced them to maintain each of their 18 tables in a different storage account to achieve maximum throughput. The team now maintains one Azure Cosmos DB account, which has no upper limit on throughput and can support more than 10 million operations per second per table\u2014all dedicated and backed by SLAs<\/a>.<\/p>\n\n\n\n

Guaranteed high availability<\/h3>\n\n\n\n

Azure Cosmos DB gives the OLS team a 99.999 percent read availability SLA for all multi-region accounts<\/a>. This has led to a significant increase in storage quality-of-service (QoS), as illustrated in the following metrics captured using internally developed tooling.<\/p>\n\n\n\n

\u201cDuring peak traffic hours, Azure Cosmos DB delivers much better storage QoS than we were seeing with Table storage,\u201d says Cheng. \u201cToday we\u2019re seeing five nines, when in the past we were at about three nines.\u201d<\/em><\/p>\n\n\n\n

\"Graph<\/figure>\n\n\n\n
\"Average<\/figure>\n\n\n\n

Automatic failover<\/h3>\n\n\n\n

The OLS team can now configure automatic or manual failovers<\/a> to help protect against the unlikely event of a regional outage, with all SLAs maintained. The team can also prioritize failover order for its multi-region accounts and can manually trigger failover to test the end-to-end availability of OLS.<\/p>\n\n\n\n

\u201cWe\u2019ve configured automatic failover, but the service is so reliable that we haven\u2019t needed it yet,\u201d says Cheng.<\/em><\/p>\n\n\n\n

Lower latency<\/h3>\n\n\n\n

Table storage provided the OLS team with no upper bounds on latency. In contrast, Azure Cosmos DB provides single-digit latency for reads and writes, backed with a guarantee of <10 millisecond latency for reads and writes at the 99th percentile, at any scale, anywhere in the world. The following metrics illustrate the differences in latency that the OLS service is seeing between Table storage and Azure Cosmos DB. (DbTable is Azure Table storage and CosmosDbTable is the Azure Cosmos DB Table API.)<\/p>\n\n\n\n

\"Difference<\/figure>\n\n\n\n

Turnkey data distribution<\/h3>\n\n\n\n

With Table storage, options for global distribution were limited. What\u2019s more, the OLS team couldn\u2019t implement failover on its own. With Azure Cosmos DB, the team now enjoys distribution  to any number of regions\u2014including multi-master capabilities<\/a>, which when enabled will let any regions accept write operation.<\/p>\n\n\n\n

\u201cJust by clicking on the map, data can be automatically replicated to any Azure region in the world,\u201d says Cheng. \u201cThis feature is very convenient, and we plan to put it to use soon.\u201d<\/em><\/p>\n\n\n\n

Other technical benefits<\/h2>\n\n\n\n

In addition to the above, Azure Cosmos DB provides the OLS team with some additional advantages over Table storage:<\/p>\n\n\n\n

Automatic indexing.<\/b> With Table storage, primary indexes are limited to PartitionKey and RowKey, and there are no secondary indexes. Azure Cosmos DB provides automatic and complete indexing on all properties by default, with no index management.<\/p>\n\n\n\n

Faster query times.<\/b> With Table storage, query execution uses the index for the primary key and scans otherwise. With Azure Cosmos DB, queries can take advantage of automatic indexing on all properties for faster query times.<\/p>\n\n\n\n

Consistency.<\/b> With Table storage, the OLS team was limited to strong consistency within the primary region and eventual consistency within the secondary region. With Azure Cosmos DB, they can choose from well-defined consistency levels<\/a>, enabling them to optimize tradeoffs between read consistency and latency, availability, and throughput while they were designing the solution.<\/p>\n\n\n\n

Get started with Azure Cosmos DB today<\/h2>\n\n\n\n