OSBA can't create a cosmosDB collection?

[williamayerst]

I'm able to provision a cosmosDB instance and database using OSBA, but I can't create a collection - it seems a bit of an oversight unless I misunderstand? Am I missing something obvious?

[zhongyi-zhang]

OSBA targets at managing service instances, said Azure resources and their configurations, what your apps don't care. So that your apps can just use the service. Take cosmosDB as an example, with the connection string in binding, your app can use a client to easily create collections, and it is already in the service itself level. Does it make sense?

[guibirow]

IMHO it doesn't make sense, mainly for the simple fact CosmosDB RU is managed either at database level or collection level. The main resource is the collection not the DB.

I can't let applications create collections whenever they want because it generate a cost that can't be predictable, it also open room for misconfiguration, abandoned resources and many other things.

If collections were managed like tables in a relational database where you pay for the database only, the problem would be much smaller but we would still need to create the collection by other means.

makes no sense use OSBA if we have to manage half of the work using other tools.

I appreciate your help.

[zhongyi-zhang]

Oh I just realized that the "dedicated provisioned throughput mode" was introduced in CosmosDB and they raied the collection as a resource. My knowledge to CosmosDB collection stayed at same-as-MongoDB-collection stage. I got your point... As collection is already the third layer (collection -- database -- database account) in this service, I think a grandchild service module needs to be added to OSBA. The implementation and usage are both more complicated in vertical. Would it be clearer to put a "createIfNotExists" in app initialization?

[guibirow]

We don't plan to allow clients to create collection if it does not exist because our plan is:

• Least privileged consumers, were applications are only allowed to consume azure resources, not create it.
• Keep track of resource consumption and costs per application(micro-service)
• Create a RU auto-scale logic per database and collection, when our services scales it also scales the data storage throughput.

In summary, we would like to define the collections needed by the application as a Custom Resource Definition and nothing more. Something similar to the ingress resources, where we define an ingress class and each application define their routing rules.

If the collection will be put in a shared database or their own database, it should be responsibility of the cluster\infrastructure administrator to decide, the developers should only provide the resource definition for provisioning.

[zhongyi-zhang]

Yeah CRD, I heard that azure service operator, which should fit your scenario better than broker, is now in developing. But I don't know when it will go public. @frodopwns @Azadehkhojandi would you consider about the scenario @guibirow shared? I believe this is a good case to show the advantage of operator :).

[guibirow]

@frodopwns @Azadehkhojandi is there any updates about the azure service operator mentioned by @zhongyi-zhang Could you point us to a preview or docs if it is available?

[sakthi-vetrivel]

@guibirow This project is now available at https://github.com/Azure/azure-service-operator