Microsoft SDS Change Eerily Reminiscent of WinFS Fate

Last week Microsoft announced that they would be abandoning the ACE and dynamic entity (“property bag”) model for the SQL Server Data Services cloud data storage system. They would also switch from their REST data API (used in ADO.Net Data Services) to the old-school “Tabular Data Stream” wire protocol.

While Microsoft’s promise of more relational support was always a distinguishing feature of their cloud DB service, and while they tried to spin the news in that direction, it feels a lot more like when they abandoned WinFS and announced that, really, everything you could do with WinFS would work fine using NTFS and a whole heck of a lot of indexing. Maybe sorta true … but feels like a big step back.

Of course, big customers – large enterprises with SQL Server databases and lots of SQL code – would not want to see a change in their data layer and would prefer this move. But accommodating them is assuming that they are ready to become first-version customers of the data cloud at all. And I doubt this for two reasons.

First, any move to the cloud involves a trade-off of control which some companies are loath to make even if they are confident the system will work. Which is problematic because:

Second, anyone who has dealt with big databases knows that there is no magic. Despite the quest for automagic autoscaling self-tuning databases, no one, so far as I know, has made one that does all of this for really large enterprise applications. There are just too many application specific variables, not to mention poorly written app code that can cause trouble in proportion to the amount of resources you give it access to.

I do believe Microsoft has the engineering brainpower to try the problem, and are as likely as anyone to succeed. It’s just that I haven’t seen any evidence of a specific strategy or technology. Maybe if I were a bigger customer … but seriously, if Redmond had this problem solved (and it’s one of the biggest out there), they would either patent it or publish lots of white papers. Either way, it would be publicized and reviewed. A trade secret? maybe, but which Fortune 500 CIO is going to jump on that bandwagon and the cloud and the outsourced data stuff all at the same time?

To the extent that these large database apps could be made to behave without human intervention, there is likely to be a tradeoff in resources, and when you’re paying per GB or per compute-cycle, that equals a side order of more cost to go along with the entree of new greater risk.

The point is that the ACE/dynamic entity/REST model is well understood, performs, utilizes resources in a known manner. Not appropriate for every app. Not relational in the formal sense if at all. Not easy to migrate to. But it goes like the devil. So you’re getting something concrete in exchange for your risk and your dollars. Unlike a magical SQL Server instance in the sky.

Maybe there is magic in there, and I’ll be proven wrong. Or maybe 99% of the customers’ database needs are so small that it’s a non-issue, and Microsoft is really just competing with the thousands of hosting providers that will host actual individual SQL Server instances for you on a large server. But this change still seems to raise more questions than it answers.

Is that Service Really a Scalable Cloud or Just Full-Service Web Hosting?

A lot of cloud stacks, or cloud app platforms promise scalability for your app, "With a little EC2 in every box!" (TM). There is a big catch and a little catch, though, and if your app gets big, then either or both of these may be a deal-breaker.

First, and most important: Running a vanilla RDBMS (e.g. MySQL) in a VM somewhere does not make it magically scalable. Read that sentence one more time.

Some cloud offerings integrate tightly to the traditional sort of DB instance you might attach to your web app on a single server. Examples include Heroku, which applies your Rails migrations to a PostgreSQL instance, and Stax, which offers MySQL.

The great thing about these environments is that they don't require significant changes to your standard app built on their supported platforms (mostly Rails and Java variants). Upload, minimal admin, and IJW (it just works).

That's turn-key, full-service web hosting, right there. It's beautiful -- in fact, in an OO and Rails course I wrote, I chose Heroku for deployment as a way to let students get something up and running on the web without getting into the operations/deployment/tuning aspects of Rails which deserve their own course.

But if your app gets large -- or just uses large datasets -- the database is rapidly going to be a bottleneck. Scaling out an app logic tier to a dozen EC2 instances automatically may sound good, but it won't do a thing for a DB-bound app (it may make it worse). And these databases don't scale out without a little architecture, planning, configuration -- all of the things which these cloud platforms are designed to avoid. And which, on some platforms, you cannot do at all.

For example, so far as I can tell on Heroku or Stax, there is no way to even configure multiple servers and replication, which is just a minimum starting point for scaling a DB to multiple machines. Stax may allow for a logical sharding setup, but it's not clear how one would control which VMs and disks the databases run on. Rightscale seems like the kind of firm which would specialize in the management scripts / meta-API that one would need to automate sharding, but the sharding option doesn't appear in any of the models on their website. With replication, which Rightscale does offer (though they're not exactly an app platform, more an infrastructure play), you get to this, still limited, picture:

Other cloud platforms offer datastores specifically designed to scale out, including Google App Engine, 10gen, and others. These platforms offer a non-relational or pseudo-relational datastore, with different data access APIs and a variety of restrictions relative to what you may be used to. These datastores are architected to scale easily, but there are real tradeoffs that must be considered. In fact, if you don't know these tradeoffs cold, you are not the right person to be making this platform decision. Get on craigslist and hire (or borrow) someone who knows the stuff.

The other catch is that whichever approach you choose, these vendors are offering you convenience, some outsourced operations management, and (in some tiers) elasticity and scalability ... but they are not offering cheap compute cycles. That is, if you know you'll need a large, predictable amount of raw compute time, then know also that you're paying a premium to do that computation in one of these environments.

A friend who has designed, built and operated feature film renderfarms for a number of studios confirmed that he has, on a semi-regular basis, analyzed the costs of remote VM-based datacenters (e,g. EC2) compared to their physical ones. Because the studios use these machines intensely, and are consistently consuming raw compute power, the local physical servers have always made more sense.

What does this have to do with your web app and datastore? Well, suppose you have designed your app to leverage a scalable datastore. These may not be tunable, may not perform fast, and may require you to do certain operations in code which traditionally are done in the DB. You may never see these slow queries or operations ... until they show up in your bill. That is, if the system is truly elastic and scalable, it will apply resources as needed to handle your work. If your query or sort or filter takes a lot of CPU cycles, the cycles will be made (almost) instantly available, so the user always sees your app perform well. And then you'll pay for all those cycles or instances at the end of the month.

Either way, there is no free lunch on the data persistence side. Which is not in itself a reason to avoid cloud environments. But it should be a bigger part of the conversation than it is today. And it absolutely must be part of the conversation, if larger businesses are going to move their services into the cloud.

Great Article on the True Nature of LINQ in C#

In the early days of C# 3.0, Microsoft distributed a whitepaper which walked through the rationale behind the additions to language, how the language changes related to the syntax options, and what it could be used for.

Among the key applications ... perhaps a co-evolved objective ... for the new constructs was LINQ ... of the to-SQL, to-XML, and over-Objects varieties.

As Visual Studio 2008 and C# 3.0 has moved out into wide use, though, that background has faded away and instead one sees a ton of quick examples and how-tos about LINQ and database operations that give the impression it's all some kind of fancy SQL trick.

Which is why I really liked this article on 7 Tricks to Simplify Your Programs with LINQ.

The only thing I didn't love was the name, because it's not really LINQ that Igor is talking about, it's the awesome functional programming features under the hood ... which happen to enable LINQ.

Igor shows how the underlying extension method and lamba constructs let you do the cool Lisp (ok, Ruby) tricks with C#, and he does it without getting into explaining what all the machinery is or even what it's called. Those explanations are important to be sure, but having these quick (2-3 lines!), powerful examples communicates a lot at first glance to readers who may not want to read about all the CS issues right away.

Furthermore, Igor avoids examples featuring the slightly misleading SQLesque syntactic sugar that can cloud what's really happening... until his last example.

Which is very useful, because the busy developer-on-the-run seeing a LINQ example doesn't realize that the select/from/where stuff are not magic language keywords. They're just an alternate way of saying Foo.Where or Foo.Select. They're just extension methods that happen to be fairly fundamental to working with lists and sets.

Maybe Igor even gets some folks who thought C# had somehow sucked in SQL to realize that, instead, all the time they've been writing complex SQL queries, they've actually been doing that functional programming stuff they've been hearing so much about. And now they can "think the same way" in C#.