Features Should Not Dictate Mission Critical System Designs
I was working up a new presentation for the upcoming 24 Hours of PASS on mission critical system design (a bit more on that later) when one of those puzzles of life we all have cooking away on the back burners of the mind suddenly snapped into focus. The story of that puzzle goes a little something like this…
The development team ships a great feature called ladders for changing those light bulbs in high ceilings. They also have a fashionable feature called yellow polka dot cloth, which is just perfect for those retro 70s swimming trunks and bikinis that are all the rage. And they put in a cleverly-engineered tricycle feature loved by our active 4 year olds. Nothing at all wrong here.
Yet many times I arrive onsite to help a new customer with their mission critical system only to find that they’ve currently got a three wheeled, yellow polka dot, monster truck jacked up on stilts. I always used to wonder just how on earth they ever got to this point.
Now, thanks to last week’s epiphany, I finally understand. There is a natural tendency of humans to map what they need to what they have – regardless of any actual correlation between the two. There’s probably a law of needs way down the list about this already, and if not there should be because it really is true.
I guess this was correct in most natural situations. If a caveman needed a weapon to fight off a sabertooth tiger, picking one that was close at hand would be a critical survival skill. Clearly this is no time to start with a blank page and work through exactly what the best weapon would be to kill a huge, hungry cat that is looking at you like you are the answer to all his culinary dreams.
But therein lies the real moral of the story, and it’s just as true for DBAs.
Under pressure you’ll have to take the existing features which are, after all, designed to implement high availability and disaster recovery. The funny thing is that this is relative cheap and fast, but just always seems to fit like that sweater your aunt knitted you for Christmas – one sleeve too short, one too long, a bit tight around the neck, and never draping just right.
The features that ship in the product are great. However, chances are that if you sat down and wrote out real wants and needs for your particular applications and environment you would find that those existing features can get you only part of the way to success. Suddenly the gaps that you never saw when you just implemented HA/DR features become all too noticeable. The plan becomes a bit more complex and you wind up using a feature for this, part of a feature for that, writing some scripts over here, and adding a bit of custom hardware over there. It starts to be, well, work. But now the solution fits. It just feels right and does what it should when it should.
Of course, some knowledge always helps, and I mentioned that I was working on a new session for 24 Hours of PASS called “The Art and the Science of Designing a Mission Critical SQL Server Solution”. If you’ve ever thought about taking out that blank page and starting from scratch, I believe you’ll find it gives you some fresh new ideas and a nice starting point.
I hope some of you will join me there on Wednesday, June 24th at 8PM Pacific/11PM Eastern. Alternatively, feel free to try to fend off that big cat with a convenient tree branch – but we both know down deep that it’s probably going to end with one very happy feline.
If I’ve achieved nothing else, I hope you take away that what you really need is rarely what you have conveniently at hand and that you must actively resist human nature to see that this is the case.
That was an enlightening presentation and now that Ive had a chance to go over the links in the presentation, it’s even better. Thanks for your time.
Thanks Kevon. I really enjoyed pulling this content together and I’m glad it was helpful. The recorded sessions are now live at http://www.sqlpass.org/24hours/2015/goc/Sessions.aspx.