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.