There are a couple of things that later made me rue my statement.  First, any IT company with revenues measured in tens of billions is relevant everywhere in IT.  Even Apple should be considered a threat to companies selling to the enterprise.  Second, Microsoft is ubiquitous.  Like them or not, they still own the most popular enterprise operating system by far as well as the Microsoft Office cash cow.

The spirit of my poorly worded comment is that we are not seeing today from Microsoft the enterprise computing leadership they showed during the 1990s.  I have seen this depicted in a graph of their share price, whose shape is attributed to a change of leadership.

Consider the applications that drive so much of EMC and VMware’s business today.  Microsoft introduced this steady stream of good-to-great OSes and applications that are now deployed in huge volumes:

• 1989: Microsoft Office released.  I believe that Office is the best product Microsoft makes today.  I love it.
• 1993: Windows NT released.  Remember how ridiculous of an idea it was to consider replacing UNIX with Windows?  Who’s laughing now?
• 1993: SQL Server released on Windows NT.  People may view Oracle as the 800 lb gorilla in the database space. But, by instance, SQL Server is more widely deployed.  We still see many, many more SQL Server VMs than Oracle.
• 1996: Terminal Services first released with Windows NT 4.0.  Terminal Services (and XenApp, Citrix’s extension to it) was the most common application in VMware virtual machines a few years ago.
• 1996: Exchange Server released.  Exchange remains the undisputed leader in enterprise mail.
• 2002: .NET launched.  With my UNIX-focused education as a software developer, in 2002 I laughed at the idea of using a Microsoft framework.  In 2005 I was writing applications on it.

I think these few softwares show some of the innovation and staying power of Microsoft in the enterprise.  Making sure each of these worked on VMware consumed years of my professional life.  Microsoft’s problem is not that they do do not have great products out.  Its problem is that they have not introduced “the next great thing” in the software space.  Xbox seems to be a mighty product.  But it does not look like their current projects will one day obtain deployment rates of Office, for example.

So, what will Microsoft 2.0 look like? It could be based in Palo Alto. Think about the components of Microsoft software stack I listed above: operating system, database, virtual desktops, messaging, development frameworks.  Now look at what VMware has done recently:

• 2001: VMware releases the first version of ESX Server.  Measured by installations on bare metal, ESX is already the second most popular operating system in the x86 market.  Will it some day replace Windows as number one?
• 2006: VMware releases VDM, the product that will become View.  VDI (both VMware’s View and Citrix’s XenDesktop) are clearly eroding the “virtual desktop” dominance of terminal services.
• 2009: VMware acquires Spring to bring to market its own development framework.
• 2010: VMware acquires Zimbra, for its enterprise messaging capabilities.
• 2011: VMware acquires Slide Rocket, a potential SaaS replacement to part of the Microsoft Office suite I love so much.
• 2011: VMware releases vFabric Data Director.  Like Microsoft SQL Server, vFDD is derived from the code of someone else’s database.

It is clear that VMware followed since 2011 the path Microsoft laid out in the 1990s.  In some ways this makes VMware look like it is copying the Redmond giant.  But VMware would argue that each of its offerings are vast improvements on those from Microsoft: ESX improves upon Windows, View upon Terminal Services, Spring upon .NET, etc.  Whether the industry commits to VMware the way it did to Microsoft in the 90s is yet to be seen.

Anyone want to place some bets on what the next Microsoft will look like?

Microsoft SQL Server runs at better than 80% of native on VI3 in most benchmarked environments. In production environments, and under loads that model those conditions, SQL Server runs at 90-95% of native on ESX 3.5. I can say this with confidence despite a large amount of the industry’s skepticism because I’ve spent so much time on SQL Server in the past half year. I’d like to share some of my research on the subject and observations with you.

Two weeks ago my colleague Chethan Kumar and I presented on SQL Server in Cannes, France for VMworld Europe 2009. This presentation was the culmination of six months of investigation that was started at VMworld 2008 in Las Vegas. At that event I heard many customer concerns about SQL Server performance that I was resolved to identify the problems’ root causes. I talked with every customer I could find that claimed that SQL ran at anything less than 70% of native.  So many of these contacts claimed that they had measured SQL at 25% of native or worse that I knew that something was going wrong.

First, let me show you a slide that Chethan presented at the show in Cannes:

Chethan spent three months investigating SQL Server to find out how much he could improve virtual performance from the “out of the box” experience. As this figure details, the sum total of performance improvements was 15%. Here’s another break-down of these results:

The only option that we found in ESX to improve virtual performance was static transmit coalescing, which is documented on page four of one of our SPECweb papers. Large pages and SQL’s priority boost, which are best practices provided by Microsoft for SQL Server configuration, provide the largest gains in performance.

The key messages that we communicated to our audience were that a properly running SQL Server should run at 80% of native or better. In most production cases it can run at a performance indistinguishable from native speed. And if performance is lagging, there don’t exist many changes that can be made to ESX that can yield and performance gains at all.

This begs the question: “If ESX can’t be tuned to double SQL performance, what is causing these reports of terrible SQL Server throughput?” The great majority of the problems are coming from mis-configured storage. But a variety of other items such as poor hardware selection or use of the wrong virtualization software contribute to the confusion, as well. I’ve been documenting these issues in Best Practices for SQL Server on this community and will continue to update that document as more problems are discovered.

If you have a SQL Server running un-virtualized in your environment, I’d like you to try virtualizing it again. Follow our best practices document and pay close attention to your storage configuration during deployment. I feel confident that once you’ve setup your environment properly, you’re going to like what you see.