Redmond Review

What's Old Is New Again

Aligning SQL in the cloud to SQL on the ground is about more than just common sense. It's about getting things done.

When I wrote my first column for this magazine 15 years ago, I covered a new advance in database programmability for Visual Basic programmers. I've been gone from these pages for a while, but I'm back. And, as an appropriate topic for a return engagement, I focus on another database programming advance, this time for .NET developers.

Back then, I explored something called the VB Compatibility Layer (VBCL), which let VB 3 programmers use version 1.1 of the Access/Jet Database Engine. VB 3 was the first version of the product to include its own database engine, and the VBCL ensured the newest version of that engine would be available to its programmers. Compatibility was key then, and it remains so today -- as Microsoft seems to have belatedly realized with its cloud computing strategy.

Last month Microsoft announced a major change of course for SQL Data Services (SDS), its cloud database offering. Although SDS is not yet released, Microsoft is nonetheless giving the technology a completely different programming interface than the one it announced more than a year ago. Back then, Microsoft brought us a product that, while based on a modified version of the SQL Server we all know, had to be programmed through an interface and conceptual paradigm that bore very little resemblance to it. Rather than giving us a database with tables, columns and T-SQL, Microsoft instead provided us with the "ACE" model: Authorities (which were akin to servers), Containers (akin to databases) and Entities (a cross between data records and dictionary objects). The ACE model didn't have tables, didn't require any consistent schema from Entity to Entity and could be accessed only through SOAP and REST Web service interfaces. Microsoft promised us relational capabilities for SDS, but appeared set on providing them by enhancing the ACE model, rather than just giving us direct access to the SQL Server behind the curtain.

The ACE model is good for basic storage and retrieval of data. Support for BLOBs means ACE works well for content management too. But for .NET application developers needing to do mainstream database work (in other words, almost all .NET developers), this first cut at SDS didn't make much sense. Microsoft had turned SQL Server into a structured storage repository instead of a relational database, and had implicitly told developers that if they wanted to move to the cloud, they'd need to re-design their databases and re-write their code. Ouch.

To call Microsoft tone deaf on this issue would be an understatement. But eventually the SDS team heard the music, and got the rhythm. On Feb. 23, at the co-located VSLive!/Microsoft Developer Conference in San Francisco, Microsoft hinted that they would re-jigger the SDS model to be relational, and on March 10 it announced through the SDS team blog that SDS would, in fact, be a cloud-based SQL Server, accessible via T-SQL over Tabular Data Stream (TDS), SQL Server's native protocol. Apparently, existing on-premises .NET/SQL Server code will work fine with the new SDS; only a change in connection string will be necessary to turn SQL Server code into SDS code.

So Redmond listened to its customers, and the bizarre obsession with copying Amazon's SimpleDB Web service is over. Microsoft has given us a truly simple offering: the SQL Server technology that most Microsoft developers have been using for a decade and some have been using since even before my first column was published.

What's old is new, I suppose. For database technologies as well as columnists. Aligning SQL in the cloud to SQL on the ground is about more than just common sense. It's about getting things done. Yes, the cloud, done right, will differ from on-premises technology. It will offer dynamic scaling and utility-based pricing. In short, it will lower the barrier to entry for getting applications up and running, and keeping them running smoothly. But the cloud, done right, will reflect and preserve familiar on-premises technology, too.

Because the cloud isn't just about how cool it is to run your application "up there." It's about easily provisioning the servers and services you need to run your business down here. SDS 1.0 had its head in the clouds; SDS 1.1 is appropriately down to earth. A compatibility layer indeed.

About the Author

Andrew Brust is Research Director for Big Data and Analytics at Gigaom Research. Andrew is co-author of "Programming Microsoft SQL Server 2012" (Microsoft Press); an advisor to NYTECH, the New York Technology Council; co-moderator of Big On Data - New York's Data Intelligence Meetup; serves as Microsoft Regional Director and MVP; and is conference co-chair of Visual Studio Live!

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube