SQL Server Data Services is a cloud-based data service that’s currently comparable to a combination of Amazon’s SimpleDB (for key/value storage) and S3 (for blobs). But as Soumitra Sengupta explains here, SSDS is indeed based on SQL Server and it aims to progressively open a wider channel to the capabilities of SQL Server and the broader Microsoft data platform. When SQL Server Data Services (SSDS) was introduced back in March, Information Week said this:
Though Microsoft has often been criticized for making its products work only with other Microsoft products, SQL Server Data Services doesn’t require SQL Server or .Net applications. “I can walk up to it with standard types of tools,” [project leader Dave] Campbell said. The service supports Rest and SOAP interfaces and will support the AtomPub protocol.
That’s a true statement, as I recently verified while exploring the service. From a web developer’s perspective, one of the easiest ways to tirekick a RESTful system is to use cURL, the “Swiss-army knife for HTTP,” to retrieve and also post data. Within minutes of cracking open the SSDS documentation I was doing just that: Using curl, on the command line, to create and querying SSDS containers and entities.
Of course there are other ways. The SSDS SDK beta released last week, for example, includes several handy tools. One is the browser-like SSDS Explorer, which enables you to navigate around in SSDS data space, create and delete containers and entities, run queries, and view the underlying HTTP requests and responses. The other is a command-line tool that you can use to automate those interactions.
But the cURL experience is worth mentioning because it underscores how the emerging Microsoft cloud is crossing a cultural chasm. In a blog entry about Astoria (ADO.NET Data Services) — another RESTful offering — RedMonk’s Michael Coté wrote:
You’re either a 100% Microsoft coder or a 0% Microsoft coder. Sure, that’s an exaggeration, but the more nuanced consequences are that something intriguing like Astoria will play best with Microsoft coders, unlike Amazon’s web services which will play well with any coder.
For that reason, Michael was more intrigued by Astoria as a hosted web-facing service than by Astoria as an on-premises service:
A hosted option has the potential to remove this mental barrier to usage. If you’re just coding to a URL, that’s not quit so bad as coding to a .Net library and all the Microsoft baggage and tool-chain needed to support that.
I’d put it a bit differently. With all RESTful services, there is properly a continuum of access styles. The most primitive is something like curl, which is useful for certain kinds of basic exploration. But most real work is done with the help of libraries that abstract the RESTful interface. Those libraries can be available for Java, for C#, for dynamic languages like Perl, Python, and Ruby, and perhaps even for those same dynamic languages implemented for Java or .NET. These flavors in turn determine a range of tools that can be brought to bear on development and debugging.
But I agree with Michael’s point: Microsoft platforms have not historically encompassed the continuum of access styles. Happily, the emerging cloud does. And while the novelty of “just coding to a URL” on a Microsoft platform will undoubtedly attract some tirekickers who otherwise wouldn’t show up, the real draw will be the ability to exercise choice along the whole continuum.
That choice, by the way, is not only relevant to developers accessing hosted, web-facing services. It will matter as much — and with the SOAP option, even more — to developers accessing on-premises services behind the corporate firewall and across corporate boundaries. Facing outward or inward, you’re most productive when you can choose the right access style for the job at hand. Between the realm of the 100% Microsoft coder and the 0% Microsoft coder, a wide and fruitful middle ground is opening up.
Update: Some nice examples of cURL SSDS idioms here from Jeff Currier. (Thanks, Soumitra!)
Jon,
The “continuum of access styles” also applies to ADO.NET Data Services (a.k.a. Astoria) which supports REST queries and JSON or AtomPub wire formats. SSDS’s Web-facing head-end is scheduled to be updated to Astoria standards in a future update.
–rj
> The “continuum of access styles” also
> applies to ADO.NET Data Services (a.k.a.
> Astoria)
Correct. And other emerging pieces, notably Live Mesh.
You’re right to compare SSDS to a /combination/ of SimpleDB and S3.
SSDS is also “actually consistent” instead of “eventually consistent” (like SimpleDB/S3) which makes it applicable to radically different use cases. I’d imagine this was an explicit decision, acknowledging the corresponding tradeoffs, and it will be interesting to see which approach gains more traction.
Thanks to John Spurlock for pointing out a key difference between SSDS and S3+SimpleDB combination. While I think “eventual consistency” will surprise a lot of developers as they build applications, I understand the trade-offs. Question is whether most developers understand the differences and the trade-offs between “consistent” and “eventually consistent”. I think there is place for both but until I hear from actual developers writing real applications, I remain interested to see how this issue evolves.
There is another subtle on as the services are exposed today. SQL Server Data Services (SSDS) supports a few primitive types while string seems to be the only type supported by SimpleDB. It has implications in how predicates are evaluated during filtering and semantics of sort.
BTW,does anyone know what Amazon is using as the underlying engine for SimpleDB? First rumors were that it was Dynamo but I have also heard rumors that it is Berkeley DB.
@Soumitra,
According to Charles Ying, SimpleDB runs Erlang (see http://www.satine.org/archives/2007/12/13/amazon-simpledb/).
@Jon,
For a different approach to a SSDS client that runs REST and SOAP (and compares performance), see http://oakleafblog.blogspot.com/2008/07/updated-sql-server-data-services-ssds.html.
–rj