SQL Server Data Services Needs an Open Development Process Similar to that for ADO.NET Data Services and Entity Framework

Soumitra Sengupta’s Philosophy behind the design of SSDS and some personal thoughts post of June 27, 2008 explains SSDS’s total lack of relational features (or some might say “baggage”) in its present incarnation. Soumitra says:

Since we made an early decision to limit the number of hard problems we needed to solve, we decided that we would focus less on the features of the service but more on the quality of the service and the cost of standing up and running the service.  The less the service does we argued, the easier it would be for us to achieve our objectives. [Emphasis added.]

The last sentence applies to any software product or service. Taken to the extreme, this approach favors a service that does nothing. The SSDS Team’s objectives might not coincide with potential user’s objectives at this point in SSDS’s development.

Presently SSDS doesn’t have a role-based security model, support joins, order the sequence of returned entities, deliver aggregate values, or offer the other accouterments that DBAs and developers have come to expect from commercial and open-source RDBMSs. Obviously, SSDS’s target audience isn’t expecting drag-and-drop table and form generation offered by QuickBase and DabbleDB. But even after sprint #2 SSDS remains too “bare-bones” for me and most developers I’ve talked to.

At the end of his post, Soumitra throws the following bone to potential early adopters:

Over time, … as we learn what it takes to run a 24x7x365 service (nobody we know of is running a data service using a commercial database system at this scale and cost point) like SSDS, I can assure you we will start to expose capabilities of the underlying engine.  How quickly and how much will depend on our ability to provide you, our customers with the quality of service you need to trust your business to SSDS.

Sounds like a chicken and egg problem to me. Most organizations won’t devote resources to testing an offline database with the few features that SSDS offers today, let alone trust its business to SSDS without an inkling of if and when needed features will be implemented. I’m surprised by the few vague and guarded descriptions of SSDS features in the works, such as schemas, and the rationale behind their implementation.

The SSDS team should emulate Tim Mallelieu’s approach of describing new Entity Framework v2 features in advance and adoption of an open development process, which was initiated by Pablo Castro for Astoria. Tim made it clear what the priorities for EF v2 are in his Transparency in the design process post of June 23, 2008.

Note: Since we don’t know what SSDS’s current scale and cost point are, we can’t make a comparison with QuickBase, which is undoubtedly today’s most successful online RDBMS with 250,000 users and a newly established Developer Program.

Technorati tags: SQL Server Data Services, SSDS, QuickBase, Cloud Computing, SimpleDB, Google Base, Google App Engine