Azure/AWS ORM Design Guidelines [closed]

Question

I'm designing and implementing .Net ORM that must support both Azure Storage (tables, queues, blobs) and AWS Storage (EBS, SimpleDB, S3) and hide all implementation details behind a common interface. The major design goal is simplicity.

Some of the work has been done in http://www.cs.virginia.edu/~humphrey/papers/CSAL.pdf, but their proposed interface is, in my opinion, too tightly coupled with Azure/AWS Storage interface and is likely to break should new features are added or old ones changed. For example, I don't care that I can create/delete tables, I only need to store an object of some type in a most efficient way.

So, I would like to ask you to share your experience on the subject in a form of guidelines (DO, CONSIDER, AVOID, DO NOT). I would really appreciate any insight starting with general principles of designing ORM and finishing with the precise level of abstraction that is more likely to last considering the most probable evolution paths of Azure and AWS.

Answer 1

If you really want to avoid tight coupling I suggest you to simply implement and abstraction layer on top of the minimum set of features that are available on both types of storage.

But anyway, what you're trying to do doesn't really make sense to me. Cloud (non-relational) storage is so peculiar that trying to build a generic ORM is going to be a giant fail. Modern SQL ORMs are "good" because RDBMS all have a shared minimum set of features that is actually quite vast and in most cases you don't need the exotic stuff. With cloud storage, each implementation is almost unique, precisely because the very first aspect to keep in mind is scalability. For example, if you throw away Blob leases in Azure because in Amazon they don't exist (I have no idea, I'm just making an example), then probably you'd have a hard time managing blob concurrent access in Amazon and in Azure too, and that doesn't make sense.

I would rather try to implement a data access layer that is designed sensibly in order to avoid problems but leverage ALL the available features in both the platforms (with very different implementations if that's necessary).