AlwaysOn Is the New Active/Passive and Active/Active
Congratulations, folks! It’s official – as I predicted with in my Availability Groups FAQ just over a year ago, the term AlwaysOn has now become the new active/passive and active/active and annoys me just as much if not more. Every time I see it misused I want to proverbially stab myself in the eyes. I really tried to avoid writing this post. I truly did. But people have forced my hand because it’s become like using ur for your, witch for which, etc. – in other words, it’s just wrong and people need to start using the right words.
I swear people should be given a test: if you can’t use the right terminology, you can’t use the feature or speak on it. It’s ignorant otherwise and you’re perpetuating problems. This even goes for people I truly admire and respect – like Bob Ward (one of the best and most knowledgable people about SQL Server around PERIOD) who recently wrote what is an otherwise great blog on availablity groups, but is marred by literally using the wrong term (and see next paragraph for spelling of it; there is no space) the ENTIRE post. MS doing it (be it CSS or a PM) is especially egregious since it helps perpetuate the bad. ARG!
So what is AlwaysOn (one word, no space between Always and On – another common mistake)? It is a marketing term that covers two features in SQL Server: availablity groups (AGs) and failover clustering instances (FCIs). So their official names are technically AlwaysOn availability groups and AlwaysOn failover cluster instances (or failover clustering instances). Don’t believe me? Click here. A few of us had a spirited debate on Twitter awhile back, which I think prompted Jonathan Kehayias’ (blog | Twitter) blog post which predates this one. Part of the reason we had a friendly debate is that depending on who you ask over in SQL Server, AlwaysOn is either just AGs and FCIs, or to some, it covers all features that remotely have to do with availablity. Either way, it still does not equate to AlwaysOn = the availability groups feature.
As with the A/P and A/A, let me give you a bit of history. The availability groups feature in SQL Server 2012 went through a few name changes over the development of the product. It had a total of four (not necessarily in this order):
- HADR
- HADRON
- AlwaysOn (yes, your eyes do not fail you)
- Availability groups
Let’s start with the first two. If memory serves me correctly, HADR was the first name for the feature which then morphed into HADRON. HADR was around for a long time. HADR was around so long that there are still remnants of it in SQL Server (such as the AG DMVs) that are not being renamed. Truth be told, I liked HADRON. It is easy to remember (a key hallmark for anything marketing) and it rolls of the tongue easily. However, switch two letters and you have a disaster waiting to happen. For those with delicate sensibilities, I apologize but let’s face facts. I can see why they probably didn’t go down that road. To add to the comment about Bob Ward, take a look at the titles of some of the CSS blog posts. (As an aside, you should bookmark that CSS blog site. They always post interesting stuff.) Many still use HADRON. They’re not helping any here.
That brings me to the dreaded term: AlwaysOn. Yes, it was the feature name for AGs for what seemed like five minutes, but it’s the one for some reason that most of the SQL dev PMs stuck on and started using in things like presentations, so I think that’s why it stuck. I don’t remember when marketing co-opted the term and made it cover the features of availability groups and FCIs, but it happened. I think that was much later in the dev cycle, which is also I think why the damage was done and somewhat irreversible.
The the term AlwaysOn (with or without space) has a long history with SQL Server going back nearly 10 years which adds to the confusion. The term Always On (with space) was introduced in SQL Server 2005 to brand a program to certify storage vendors with SQL Server (example: Dell’s whitepaper; EMC and Hitachi also have similar ones). In SQL Server 2008, Always On (with space) was used to cover availability in general – much like how it’s SUPPOSED to be used in SQL Server 2012. Don’t believe me? Here’s proof.
I leave you with this: STOP USING ALWAYSON IF YOU ARE REFERRING TO AVAILABILITY GROUPS. Please use the right terminology. Just as active/passive and active/active are incorrect for FCIs, AlwaysOn is wrong for AGs.
In the immortal words of Bartles and James, thank you for your support.
Pingback: Something for the Weekend - SQL Server Links 10/05/13 • John Sansom
Pingback: System Center VMM 2012 SP1 High Availability with SQL Server 2012 AlwaysOn Availability Groups
Pingback: StarWind Software Webinar Follow-up Q and A | Edwin M Sarmiento
Pingback: 101 Things I Wish You Knew About SQL Server - Thomas LaRock
Here we are in July 2015, two years after the rant, I was in a meeting with a chap from Microsoft, he was referring to Availability Groups as AlwaysOn…
I fear that the damage may well be permanent.
It may be, but as long as the feature name remains AGs, and is not changed permanently to AlwaysOn, they are wrong.
Pingback: Failover Cluster Manager Can Be Deceiving | SQLHA | Ready When You Are
Now that we’ve upgraded to 2012, developers ask me why we aren’t using “active/active AlwaysOn clusters” about once a month, and my head explodes each and every time. Thanks for writing this, so I can share it!
You’re welcome. Things just got more complicated – see my new blog post http://sqlha.com/2015/12/16/dear-microsoft-i-love-you-but-youre-driving-me-batty/
Pingback: Dear Microsoft: I Love You But You're Driving Me Batty - SQLHA - SQLHA
Speaking of using the right terms. It is a small point but the article is about being correct. The word “terminology” refers to the *study* of terms, not the collection of terms. So, the phrase “the right terminology” is just wrong. It would be “right terms” or “the correct terms” or “the right names” or “the right words.” To say “the right terminology” would be to say the correct study of terms.
My biggggggg complaint to you all you MS gear heads is the lack of a single page that describes the “AlwaysOn” options with diagrams.
As a designer of systems who hasn’t look at SQL Failover Clustering in a while all I really care about is this new Always/Active-Active whatever increase throughput on the SQL server. If node has 4 cores, does this sorta mean your running SQL with 8 cores. Who knows.
There is no such feature as AlwaysOn. AlwaysOn is a marketing umbrella for two features (AGs and FCIs), and depending on many factors, it is not a simple “if this, then this” thing. It’s why my book will be so large. AGs and FCIs are not about throughput. They are about increasing availability. SQL Server 2016 has redo improvements for the AG transport, but it is not about scaling SQL Server out. If you want to scale SQL Server out, you need to design your app properly or scale up as you normally do. There is no “easy” button.
I can’t say with 100% certainty, but I believe HADRON came first. In 2008 while working at Microsoft, I came across a “Project HADRON” document outlining the feature we now know as Availability Groups.
Another note: When SQL Server 2012 first came out, the BOL page for AlwaysOn described it as a group of features for maximizing availability of the databases and listed AGs, FCIs, online index rebuilds, and other online features. All the extra stuff was removed at some later date. Not sure when. It now lists only AGs a FCIs.