The philosophy of Azure Cosmos DB

Recently, I have been reflecting on the very inception of products and services, especially from the consumer standpoint. Generally, I tend to be suspicious when a product or service pretends to be (or it sold as) a Swiss knife. In fact, products and/or services are typically designed with one or a handful "killer" use cases in mind, with an audience in mind, and a win-win cost structure.

I turn now to my beloved Azure Cosmos DB to illustrate how those three points were translated into key drivers (you may say "philosophy") that led first Project Florence, and then DocumentDB to become Azure Cosmos DB. I indirectly intend to defuse a few objections which are misplaced - not that Azure Cosmos DB is not susceptible to challenges but often you see a lot of objections missing the point.

Let's start with the "Swiss knife" syndrome. I must admit, the name "cosmos" leads to think a universe-like containing everything you need. That's just a straw-man. It is actually the most boring and trite objection to Azure Cosmos DB: to achieve the mythical "one-size-fits-all", allegedly attempting to encapsulate in one hub the whole NoSQL world, fitting all the use cases you may be imagining of. But this cannot be the case, by design I'd hasten to say.

To illustrate: Azure Cosmos DB habits a lively and synergistic ecosystem. If Azure is the universe, Azure Cosmos DB is a planet belonging to Azure Data Platform galaxy (or gemstone if you like art). This includes out-of-box integration with Azure Functions, Azure Search, Azure Data Factory, Azure Stream Analytics, Azure DataBricks, etc. and with Azure Synapse enabling hybrid transactional analytical processing without requiring ETL. Definitely an open platform without the pretense of encapsulating any workloads.

Secondly, the fact that Cosmos DB is a cloud-native solution, means that it is designed for multi-tenancy from the ground up with a software-level resource governance layer. Again, another dimension where it is a good fit (and therefore excluding where it is not).

Thirdly, its enterprise readiness cuts through a very specific type of mission critical workloads. Just to mention a few enabling features:

• Autoscale, to automate the scaling up and down of your data containers
• Encryption-at-Rest with customer-managed keys, to give customers full control over the keys used to encrypt data on disks
• Geo Replication with Multi-Master, to distribute your data across multiple geographic regions and ensure business continuity and disaster recovery against data center outages
• Automated Backup/Restore, to automatically snapshot your database for backup/restore to protect you against accidental corruption or deletion
• Azure Private Link, to deliver services directly to customers’ virtual networks, as PaaS by providing private connectivity from a virtual network to Azure platform reducing the risk of data exfiltration.
• Automatic Sharding, to partition (scale out) the data across nodes to optimise queries, data distribution, and data elaboration. Automatically.
• Financially backed SLAs,  to offer comprehensive 99.99% SLAs which covers the guarantees for throughput, consistency, availability and latency configured with any of the five Consistency Levels or Database Accounts. Azure Cosmos DB allows configuring multiple Azure regions as writable endpoints for a Database Account. In this configuration, Cosmos DB offers 99.999% SLA for both read and write availability.

COMING SOON: Point in time Restore, and "Serverless" option to deal with workloads with no steady and predictable consumption.

It should be pretty obvious what game we are playing, shouldn't it? (here for an exhaustive overview of the platform and all the new upcoming features).

Let's look into the second aspect now that is the audience it is meant to serve. Here we don't need to go too far. There are mostly two strategies (not just in the NoSQL world):

• Appeal to developers. Winning over developers has been the mantra for the likes of MongoDB, which have invested in their marketing efforts to convince developers that its NoSQL offer will make their lives easier (with the aim of winning business via a grassroots shift).
• Appeal to business. Tapping into the broad "digital transformation" buzz to reach lines of business, operations, across the board given the common need to build new customer experiences. Couchbase falls into this category, for example.

I personally have long dismissed this dichotomy. Are there developers with their own agendas? Are lines of business blindly dictating what to do? Hey, I am not naive. I am aware of turf wars happening in many organizations but we must go beyond that - actually, we as technology providers, have the duty to bring downs those walls and show how technology is the glue to create value for our customer's customers. In my engagements, and when it comes to Azure Cosmos DB for instance, I tend to uncover if not established, the relation between the problem at hand and how this is impacting their customer's experience, top line and bottom line. It's not rocket science. A minute after we may be discussing how to calibrate Request Units (RUs), get down to the nitty-gritty of data partitioning, create a playground for experimentation (thanks to the "free tier" option), serve where developers are e.g. using MongoDB APIs and the native shell directly in the Azure Portal, enabling "real-time" scenarios for modern cloud apps, and back to data estate modernization, etc. It really is a flux with no bold boundaries. I would say this: everything that you do, if it has no meaning for the end customer, you are probably going down a rabbit hole (check my previous post where I illustrated how NoSQL/CosmosDB plays a key role in any digital transformation endeavor). Understandably, this has far reaching implications, including the way people work together, cross-departmental mindset, up to companies' culture but I know of no other way but start doing and stop theorizing ;-)

Let me add another bit here which I believe is at the moment the structural advantage of Azure: Microsoft developer-oriented-ness is right from the start really second to none, AND our understanding of the enterprise world speak of itself.

In a future installment, we will take a close look at the "cost-factor".