Overlap between sdk crates and service crates

[rickrain]

There seems to be some overlap between some sdk crates and service crates. The table below lists some overlap that I'm seeing (may be others).

sdk	service
data_cosmos	cosmosdb
device_update	deviceupdate
messaging_eventgrid	eventgrid
security_keyvault	keyvault
storage_blobs	blobstorage
storage_datalake	storagedatalake
storage_queues	queuestorage

Is this a result of prior publishing of crates that was carried forward, or something else that I'm missing? There also are some subtle differences, such as in models/structs, between the two. I know the service crates are auto-generated. So, perhaps a different way to ask this is, what determines whether a crate is going to be an sdk crate or a services crate?

Similarly, when creating examples where there is overlap between the two, should we favor the sdk location? For example, I just noticed all the great examples in ./sdk/security_keyvault/examples. Yet, earlier this week, I PR'd one in ./services/svc/keyvault/examples. Should that sample have been placed in ./sdk/security_key_vault/examples instead?

[bmc-msft]

As you identified, the service crates are generated based on the API specifications. It's my understanding that the eventual goal is for the SDK crates to be idiomatic overlays to the generated crates.

Right now, I'm working on an update to the recently added azure_device_update SDK crate to provide a more rust-like interface over top of the azure_svc_deviceupdate generated crate.

[cataggar]

The work @bmc-msft mentioned is now captured in #733. It will be the first SDK crate to build on top of a generated one. It is fine to have similar examples for the both the generated service crate and the sdk.