[gregmac]

So on the surface, this is essentially just a library that implements an abstract interface to a bunch of "cloud services", and then provides implementations of those abstractions for some of the actual cloud services.

It adds API tracking, so presumably there is some connection back to CloudRail. What happens if CloudRail goes down or is responding slowly or the connection is blocked? Does the library still work?

Seeing as it's also only a library, if someone stops paying, does it continue to function? Obviously if the upstream provider(s) change their APIs in a backwards-incompatible way, it would break, which is no different than if you use the provider directly. It seems like what you're really paying for here is the work done to build the library, the updates (and monitoring for need to update), API tracking service, and support. You're not actually using CloudRail's systems for the connection, so is there a license check that disables the library if the CloudRail account goes dead?

The nature of this abstraction also means lowest common denominator. The use of "interfaces" over top is a good way to handle this, but could also get messy. When you have a certain function that is only available on one provider, or is not available on only one of several providers, how do you decide when to create a new interface vs not support that function vs implement it as a "throw not implemented error" (or do you have any never do that)?

[cloudrail]

The library sends statistical data back to CloudRail to provide statistics and notifications for required library updates. We handle this in a way that the library still works even if the CloudRail server is down or slow. The data itself flows directly between library and cloud provider. Currently we don't disable libraries because they die anyway without updates eventually.

Yes, our unified interfaces are the lowest common denominator. We provide functionality which is not available among all providers in a separate interface. The only exception are functions where the developer needs to be prepared to get an empty result. E.g. some users just don't set a profile picture on social, so you have to handle it anyways.