Azure Cosmos DB is getting really high hype similar to how Service Fabric was getting some years ago. It is advertised as the defacto standard for data storage. The main reason people think it will solve all their problems is because of its SLA. I don't think Microsoft is advertising it as the one storage solution for all. They still recommend other storage solutions based on requirements. But somehow the industry thinks Cosmos DB as the ultimate one. Especially managers who stopped hands-on years ago but follows tech news and blogs :)
What is the problem with SLA? Since Microsoft has to reimburse on failure, it is bound to lot of conditions. It's not only Microsoft, even if we are providing a service with SLA, we will also have some sort of conditions associated with it. Below are the conditions for Cosmos DB latency SLA.
As is says the application should be in the same local Azure region. It cannot be a mobile application connecting to Cosmos DB directly through the internet or the application running on-premise.
Next, is the accelerated networking enabled. Accelerated networking is free but available in some VM tiers. Not sure what is the case with containers and App services.
Then comes the protocol. It cannot be the HTTP(s) which has its own overheads.
The below links explain the same.
https://azure.microsoft.com/en-au/support/legal/sla/cosmos-db/v1_3/ - Updated May 2019
https://azure.microsoft.com/en-us/blog/azure-documentdb-service-level-agreements/
Happy Architecting.
No comments:
Post a Comment