CosmosDB documentation should state that usage will not have support from Microsoft

[KrylixZA]

Describe the issue

This particular issue is multi-faceted. I will do my best to lay out the series of conditions that combines to form this issue concisely.

I do want to state categorically that there is nothing wrong with the Dapr component for CosmosDB, we just need to update the documentation to make users aware of the situation.

First off, we know from the components that Dapr uses the Azure CosmosDB GO SDK. This is clear from the cosmosdb.go file.

Secondly, the documentation for the CosmosDB Go SDK states the following:

The Go SDK for Azure Cosmos DB is currently in beta. This beta is provided without a service-level agreement, and we don't recommend it for production workloads. Certain features might not be supported or might have constrained capabilities.

Thirdly, the CosmosDB Go SDK is configured to connect to CosmosDB using Gateway mode.

Fourthly, in this article on monitoring CosmosDB latencies, the docs only mention an SLA about response times for CosmosDB when using Direct mode to connect to CosmosDB:

Azure Cosmos DB provides SLA of less than 10 ms for point read/write operations with direct connectivity. For point read and point write operations, the SLAs are calculated as detailed in the SLA document. For more information about connection mode, see the Connectivity modes article.

All of the above combined is essentially saying that if you are using the Go SDK for CosmosDB and run into any issues, you will not be supported and if you have any operational issues with your database, because of the way the SDK is configured, you will not have any SLAs and subsequently much support on resolving the issue you're experiencing.

My company has engaged with Microsoft to get these issues rectified starting at the root of the problem in the Go SDK. However, until such a time as these have all been resolved, we should make users aware.

URL of the docs

https://docs.dapr.io/reference/components-reference/supported-state-stores/setup-azure-cosmosdb/

Expected content

We should document the conditions mentioned above and specifically note that any usage of CosmosDB through Dapr will likely not fall under any SLAs from Microsoft and recommend users try something else instead. Potentially Azure SQL DB or a Redis offering in Azure.

We should also consider moving CosmosDB out of Stable into Beta until such a time as the Go SDK for CosmosDB is moved into stable.

Screenshots

N/A

Additional context

N/A

[msfussell]

@KrylixZA - Thanks for raising this issue. I will discuss this with the Components Contrib maintainers and get back to you.

[KrylixZA]

Thanks @msfussell. I know there are some Microsoft Dapr maintainers working on this issue as well. Might be worth looping them in 👍

[artursouza]

We had this discussion a while back when creating the certification process. The rationale was that our tests would guarantee the stability of a component and not depend on a 3rd party to claim a dependency as stable. The reason is because the meaning of stable or alpha or beta can vary for each vendor. Even the runtime code have dependencies at version 0.x and we don't claim that the runtime is alpha or beta.

It is important to document that while we claim a component is stable, it is based on our tests and not a guarantee of support by any specific vendor. I think this disclaimer is important.

[KrylixZA]

Thanks for the clarity @artursouza. Would you like me to submit a pull request? Or should we wait for Microsoft to respond to the issue before submitting the pull request?

[artursouza]

This is independent of any vendor. I believe you can send a pull request we can review the wording in it.

[msfussell]

@artursouza @KrylixZA - Docs maintainer will pick this issue up and make this clear

[joshuadmatthews]

This is a fairly concerning read. A lot of people are using CosmosDB and Dapr in their AKS and Container Apps. If we are giving up all support by essentially using a SDK that Microsoft says is not for production use, that seems a tad more severe than some less important dependency technically being in alpha/beta. I also wonder how this really goes support wise, as Microsoft is pushing Dapr within their tools and tends to offer support for integrations like that when they are "first class" the way Dapr seems to be. Has anyone communicated with Microsoft to find out how much or little support users will actually have when using the Dapr Cosmos State store component?

Also wondering @KrylixZA has Microsoft provided any timeline for fixing the Go SDK or is it essentially a "when we get around to it" for now? I've had some discussions with the team that does the SDK's and they seemed to express that updates to the Go SDK to make it feature complete with the .NET version were not a high priority for them right now.

[jcocchi]

Hi @KrylixZA and @joshuadmatthews - I'm from the Azure Cosmos DB team. Thanks for your feedback! Jumping in to clarify a few points

The Azure Cosmos DB Go SDK used in the Dapr component is still in beta and is planned to GA at the end of March. Microsoft will support the Go SDK even while in beta to the extent possible. There are no plans to add Direct mode to the Go SDK, which means it isn't covered by the Azure Cosmos DB Latency SLA. However, the Availability SLA will apply when the SDK reaches GA. In practice, many customers use and are successful in Gateway mode even for mission critical applications despite no Latency SLA.

We won't have full feature parity with .NET or other languages at GA, but we take feedback seriously and welcome feature requests. Please submit issues for missing features directly on our repo and we'll do our best to address them.