If Microsoft and I had I relationship status, it would be “it’s complicated”. As a Microsoft MVP and someone who specializes in all things Windows  and SQL Server (within reason … there’s way too much for one person to literally know everything), I make my bread and butter on their platforms. Sure, I’ve used Unix and other RDBMSes over the years, too – but not like SQL Server. I speak VMware very well (not just Hyper-V). While I don’t want to bite the hand that feeds me, anyone who knows me is aware that I’m outspoken. Some people love it, other people have an issue with it.

I try to be honest but not mean (despite what people may think – and you’d know when I’m being mean, trust me), but the reality is some people just can’t handle the truth so you pussyfoot around it. I come from a place where facts rule the day and I try not to let emotion cloud my judgement, but some of Microsoft’s recent decisions have me a bit puzzled, and quite frankly annoyed.  What MS decides directly affects not only how I do my day job as a consultant and educator, but any one using Windows and/or SQL Server. In this post, I’m going to focus on two issues because I think Redmond needs some tough love and a dose of reality from someone who cares and is passionate about both Windows and SQL Server.

Issue One: Always On

Yes, you read that right – Always <space> On. It’s almost a joke now with me and AlwaysOn, but it ceased to be funny a long time ago. It’s funny in the “haha” sense, and you can see by my Twitter feed people troll me all the time. I’m used to it.

You may have seen my previous blog post “AlwaysOn Is the New Active/Passive and Active/Active“. If not, take a few minutes and read it because it sets this up. If you want the TL;DR approach here it is: AlwaysOn is not the AG feature. If that was the issue, I wouldn’t be writing a new blog post.

As noted in that blog post, the words “always” and “on” have a long history with SQL Server. Always On (with space) was the initial designation for the highly available storage for use with SQL Server. So availability has always been linked; that is not in question. To quote this Hitachi whitepaper:

The Microsoft SQL Server Storage Solution Review Program is a specific SQL Server program that enables storage solution providers to highlight those storage solutions and configurations, via the SQL Server “Always On” labeling, that they have successfully reviewed against core functional Microsoft SQL Server storage requirements. The core requirements defined herein must be met for reliable, highly available SQL Server storage systems. 

Here are some other links from that era (there are more, but I think you’ll get the idea):

• EMC Celerra Solutions for Microsoft SQL Server 2005 Always On Technical Note
• IBM System Storage Solutions for Microsoft SQL Server IT Environments
• Always On White Paper for Fujitsu ETERNUS Storage System

As I wrote about in my book Pro SQL Server 2005 High Availability (Apress, 2007) in Chapter 4 on page 122:

At TechEd 2006, Microsoft unveiled the SQL Server 2005 Always On program (http://www.microsoft.com/sql/alwayson/default.mspx) [note: this link does not work now; it did back then, so don’t try it], which is an umbrella that brings all the SQL Server availability technologies under one banner. Part of the Always On program is a partner program for storage solution partners. This specific portion of Always On is known  SQL Server Storage Solution Review Program.

I write a bit more in that, but this was the first morphing of the Always On name, which now included clustered instances as well as database mirroring, log shipping, backup and restore, etc. By SQL Server 2008, the storage certification portion of Always On was killed and it was just the HA-related features (FCIs, DBM, and log shipping clearly mentioned) as evidenced in this SQL Server 2008 OLTP marketing PDF.

Enter the feature introduced in SQL Server 2012: availability groups (AGs). Yes, AlwaysOn was a name for the feature for about five minutes in its development cycle as noted in my other blog post, but ultimately marketing decided to name the feature to be AGs and now had a new umbrella moniker for only FCIs and AGs: AlwaysOn. So the official names for those features are/were (we’ll get to were in a minute) AlwaysOn Failover Cluster Instances and AlwaysOn Availability Groups. So AlwaysOn has no space in 2012. This can be seen here and a screen grab is below in Figure 1. So out are DBM, log shipping, etc from the AlwaysOn moniker. And for heaven’s sake, it’s not AOAG. It’s just AG. We don’t say AOFCI – it’s just FCI (which is clearly seen at the link and in the screen grab; click to make it bigger). Precedence, people. Follow it.

Figure 1. AlwaysOn defined in SQL Server 2012 Books Online

My frustration with people using AlwaysOn improperly as the AG feature is well documented in the other blog post, and that issue has been occurring now for the better part of five years at this point. I’m not going to lie – it’s hard getting people to refer to the feature properly. Microsoft and its employees are some of the worst offenders truth be told.

Fast forward to this year’s MVP Summit which was right after PASS Summit. I was tipped off by a few birdies there was a change coming to AlwaysOn I would not be happy about – Always On (with a space). At first I thought they were trolling me and having a laugh – but no, this was real. SQL Server marketing in their “infinite wisdom” has decided to go back to the original spelling from here on out, which means for SQL Server 2016 (and possibly everything in 2012 and 2014), forget the no space. Ugh.

The new and improved Always On (with space) made its first official appearance in the December 15th blog post “Enhanced Always On Availability Groups in SQL Server 2016“. Now that it’s out there, I can talk about it. I’ve been sitting on this one for over a month. As one Microsoft PM once said to me, “You can report the news, but you can’t make it.”

I’ll cut right to the chase: as if we didn’t already have an AlwaysOn problem, marketing just made it worse. I mean this in the nicest possible way: I really think their heads are up their posterior. That won’t win me any favors, but it has to be said. What the hell are/were they thinking here? This change neither clarifies things or makes them better. It makes them WORSE. We’re taking a time hop back nearly 10 years.

When a bunch of us who fight this constantly found this fact out last month, we were all pretty livid. Marketing apparently lives in a bubble where they don’t give a hoot that people like me have to live with these asinine and uninformed decisions. No, I don’t expect them to consult me personally when they do something related to the SQL Server availability feature set, but it’s like they asked no one who even uses this stuff or thought about the downstream effect. I have a great working relationship with SQL dev, but I’m calling this ugly spade what it is: ridiculous.

What they should have probably done for SQL Server 2016 is something I would actually advocate (no, really): call the feature currently known as AGs  – what most do already  – AlwaysOn (no space). Drop the umbrella banner and just have HA features. FCIs will just be FCIs. I have been adhering to the rules marketing set up for 2012 and 2014, and I get penalized for it because they do a piss poor job enforcing it. PMs on TAP calls and in presentations regularly call AGs AlwaysOn with nary a word said. MS should train their own employees properly to be honest; it would solve many of my issues. Now marketing pulls this rabbit out of the hat? Unbelievable. Well, it is believable; I just have a hard time believing they consciously thought this was a winner of an idea. This almost is the equivalent of Bizarro and Bizarro World in the Superman universe.

A good friend and fellow MVP, Mike Steineke (Twitter | Blog), said two things today with regards to this which made me laugh but are true:

• AlwaysOn naming is as random and complicated as SQL licensing
• “Lucas thought Jar Jar Binks was a good idea too…  Meesa like AlwaysOn” – something one of his employees said and appropriate given the opening of Star Wars Episode VII The Force Awakens this week

I think those two quotes sum up my feelings pretty well.

EDIT: As has been pointed out by two comments, the real goal here is consistency. Failure to be consistent leads to confusion and problems (read the comments for more).

Issue Two: Services/Applications/Roles/Resource Groups and Windows Server Failover Clusters

SQL Server is not alone in its penchant to do things that are detrimental to customers and understanding the platform. Back in the day pre-Windows Server 2008, at the Windows level, we had the concept of resource groups. Simply put, they were basically containers for clustered resources. For example, if you installed a clustered instance of SQL Server 2005, its resources would be in its own resource group. In Cluster Administrator (the GUI-based management tool), they were referred to as groups. The command line cluster.exe also used the group nomenclature. So far, so good. Figure 2 shows what that looks like with a clustered default instance of SQL Server 2005 named BATMOBILE.

Figure 2. Cluster Administrator in Windows Server 2003

In Windows Server 2008, we got a new GUI administration tool – Failover Cluster Manager (FCM). Lo and behold, they changed the name for things in the GUI to be Services and Applications, not groups. But cluster.exe and in Windows Server 2008 R2, the PowerShell cmdlets (such as Get-ClusterGroup), refer to groups. For people who don’t know Windows Server Failover Clusters (WSFCs), this can be confusing (more on that in a minute), and if you come from 2003, it’s a problem as well. The reality is that underneath the covers it’s still a resource group. The concept never changed. There are other issues I won’t get into in this blog post. The groups –> Services and applications thing can be seen in Figure 3 which shows another default FCI named AJA.

Figure 3. Failover Cluster Manager in Windows Server 2008 R2

In Windows Server 2012, this was then changed in FCM to be Role(s), but again, any command line still refers to groups. Figure 4 shows a named clustered instance of SQL Server named MINI\DISC.

Figure 4. Failover Cluster Manager in Windows Server 2012

Why is the UI and the command line out of sync? There honestly isn’t a good reason other than it is what it is. As someone who trains and speaks all the time, I need to make that connection for people between what you do in PowerShell and why it is different than the UI management tool. That also usually means I have to show Windows Server 2003 to people – something I’m sure they do NOT want me doing. I’m sure we’ve all seen the 1,000,001 WINDOWS SERVER 2003 IS GOING OUT OF SUPPORT – UPGRADE NOW e-mails, ads, Tweets, etc. from various folks including Microsoft.

I’ve been talking to the Cluster PMs about this since Windows Server 2012, and with Windows Server 2016 since it wasn’t done, formally filed a bug which was recently closed as will not fix in this version – maybe in the future. Look, I get it. It’s basically a visual thing which does not affect functionality and it’s not broken, and I’m sure there are things that need time allocated to fix which are more important. However, it leads to confusion when showing PowerShell (“What’s a group?”). It’s bad enough dealing with the 2008 R2 to 2012 questions of the Service/Application change to Role. Three versions into this new Role cycle, I’m calling enough is enough. Usability is a concern.

So if they want me to continue to show Windows Server 2003, don’t fix this. Until they do, Windows Server 2003 will be shown in some of my presentations and classes because many people learn visually and need to see that progression. Either that or change the UI back to Group or Resource Group. I’d be OK with that, too.

The Bottom Line

As you can tell, I’m not a very happy camper. Windows and SQL Server have given themselves enough rope to hang themselves on these two issues. SQL Server’s issue is completely self inflicted and causing a lot of confusion out in the world, and has for the better part of five years. I can only hope they come to their senses before SQL Server 2016 RTMs. As for Windows, like I said, I get things that are truly broken need to be fixed. But at this point when you want to put 2003 to rest, you can’t do it half assed. There’s still time before Windows Server 2016 RTMs. I’m not asking for this change to roll back to 2012 or 2012 R2.

I can’t reiterate enough that I am writing this from a standpoint of passion and caring, but the truth hurts sometimes. No one likes hearing their baby (in this case, their work) is ugly. Unlike animals and humans, these problems I discussed here are not life and death, and can be fixed. The ball is in your court, Microsoft. Do the right thing. I would love to see comments below because I think Microsoft needs to hear it from more than just me. Many voices affect change.