Redmond Review

A Well-Grounded Cloud

In a Redmond Review column last year ("What's Old Is New Again," April 2009), I discussed a move by Microsoft to reform its then-named SQL Data Services (SDS). At the time, Microsoft decided to make SDS (now SQL Azure) a true cloud-based SQL Server offering, rather than a structured data entity store that merely used SQL Server behind the scenes. I thought that was the right decision. It marked the point where Microsoft decided to base its cloud on a core strength -- its server products -- rather than offer a pale imitation of Amazon Web Services.

Now, 18 months later, Microsoft has replicated that approach across its cloud offering. SharePoint 2010 was written with the cloud in mind. The forthcoming Dynamics CRM 5 will be released as a cloud product before the on-premises version becomes available. This isn't Microsoft trying to be trendy. Quite the contrary: As I talk to people at Microsoft, the cloud commitment appears to have become a fully integrated part of doing business. I see this as quite significant; perhaps some more examples will help me convey why.

Windows Azure, Pervasive
Recently, I was part of a group e-mail discussion with a Microsoft product team member. Someone else on the thread had a question about a particular feature. In response, the Redmond official said Microsoft would be implementing the feature "in the next version of SQL Server and SQL Azure." This was very matter-of-fact, and the feature in question wasn't even especially cloud-oriented. The point is that the two products were one, and their product development anticipated the on-premises and cloud versions on equal terms.

Another example is Visual Studio LightSwitch, the product I wrote about in my last column. The line-of-business apps that LightSwitch produces can be deployed to the desktop, the corporate server or to a combination of Windows Azure and SQL Azure. The LightSwitch team, while proud of this capability, hasn't even presented it with a lot of fanfare. To do so would betray the philosophy that the cloud should be just another deployment option, and that it's the job of LightSwitch to abstract away its differences.

There's more to this: The Windows Azure appliance; the OData features of SQL Azure and Microsoft Codename "Dallas" that equalize the two with WCF Data Services on a corporate server; Windows Azure services in MSDN subscriptions and corporate Enterprise Agreements. Over and over, Microsoft is integrating the cloud with its other products and services

Microsoft has clearly decided to move to the cloud on its own terms. Many in the industry see this as a flawed strategy; they reason that Microsoft is approaching something that's completely new and attacking it with a playbook that's completely old. In effect, they cast Microsoft as naive, arrogant or both, and claim the company is following a path that will meander toward failure. A lot of people accept this argument on authority.

Obsolete or Classic?
That authority is weak, though, and the position is unsupported and dogmatic. No one really knows how the cloud will turn out, or who will dominate it. The prediction of failure may still turn out to be correct, but the argument itself is prejudiced. Microsoft fitting the cloud to its own stack means it's attempting to fit the cloud to its customers' businesses as well. Maybe that won't work, but it sure seems worth a try. The startup customers of Amazon may acquiesce to a fundamentally new computing model in the cloud -- but the corporate customers of Microsoft may not find that so suitable.

What Microsoft has always done well is take something hard, make it relatively easy and let customers invest their own hard work on top of the resulting platform. Graphical apps in DOS were hard, so Microsoft built a GUI into the OS with Windows. The Windows API model was hard, so Microsoft gave us Visual Basic to abstract those difficulties away. The Web was hard, so Microsoft gave us ASP and Web Forms. Datacenters are hard -- and expensive, too -- so Microsoft is offering its Platform as a Service cloud to abstract away those challenges as well.

The stack-integration approach is working for product teams and gaining momentum continuously. It's starting to resonate with partners and customers, too. It's hard to see that as a bad sign. Fidelity and consistency should not be mistaken for stubbornness and inertia. Microsoft is not just going through the motions; it's being true to its roots. That's usually the right way to go.

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