Recently, on the venerable Vegan Load-Balancing List of which I’ve been a member of over a decade now, the question about the viability of Global Server Load Balancing and DNS-based GSLB Solutions like F5’s own Global Traffic Manager (GTM) was questioned.  As has want to happen, for over the past half-decade, Pete Tenereillo’s infamous GSLB Page of SHAME was summoned as a reason why no one would want to spend money on a GSLB solution as it, supposedly, offers no value over simple networking tricks—or just using plain old DNS.  In my usual fashion, I responded.  Maybe I was a bit hasty, maybe I was a little less than clear.  In any event, it appears that I need to clarify my position about this particular article from a much less emotional place.  So, here it goes:

First off, a more detailed explanation of my comments.  My first suggestion was that Pete’s paper is over 5 years old.  Think about that.  How many other things in technology are that old and are still the same?  In fact, someone responded with “everything in Pete’s article is 100% true”.  Well, when it was written, sure.  But, even Pete acknowledged shortly thereafter that some things were already changing in regards to Windows XP and how it treated DNS caches and lookups.  A lot of things have happened in the last 5 years including the fact that most modern browsers and OSs accept low and even zero TTL values.  Many of the mega-proxy servers are no longer and the ones that remain are much more sensitive to DNS cache values than ever before.  5 years is a lifetime in technology—let’s be a little more realistic.

The second suggestion I made was that the paper’s premise had been ripped to shreds thousands of times since its last update in 2004 on numerous sites, including the Vegan LB List.  You can check the archives—very few people argued that Pete had his technical details wrong—but questioned his premise—that they held no value, certainly not what people were charging for them.  His entire argument was based on providing real-time HA between multiple datacenters flipping users back at forth at will; and his only criteria for success was 100% at all times.  I know of very few people who have the back-end synchronization capabilities to make this viable even if you could guarantee every single client would be instantaneously moved.  This was one use case of the technology and not the most prevalent one at that.  Probably the MOST prevalent use case was in Business Continuity and Disaster Recovery.  By using a GSLB solution, a complete loss of the primary datacenter could be acted upon—automatically—in seconds if necessary. In this scenario—maintaining state and/or dynamically routing people mid-session to the backup site was not the requirement as that state didn’t exist.  The main requirement—that people could access the application again—even if they had to close their browser or reboot their system.   Not only that, but GSLB solutions allowed us to do that on an application by application basis—something BGP route injection has no clue about, nor does generic DNS.  I’ve personally seen hundreds of customers that use the intelligence of GSLB to provide immense value to their solution from maintenance to contextual routing to simple traffic overflow scenarios using cloud bursting.  If these solutions really had NO value outside the lab and were simply the marketing sham Pete intimates, they wouldn’t still be selling a decade after their introduction—I think the world would have learned by now.

The last comment I made was that I have difficulty listening/reading someone detail how a solution WON’T work without suggesting a solution that does, or at least provides more value than the one being discussed.  I have no problem with someone pointing out the shortcomings of solutions or the inability of a solution to address certain aspects of the problem.  I do have a problem if you do that without offering any viable alternatives.  The conclusion of the paper was basically, GSLB can’t solve this use case perfectly and therefore is no better than using normal DNS thus—you can’t do what GSLB intended to do. I’m sorry, but that’s not a solution; that’s not very helpful.  It also dismisses all the things it CAN do much easier and more automatically than standard DNS.  I just don’t think that was appropriate.

Don’t get me wrong

I don’t want anyone to think that I’m personally attacking Pete.  His paper, at the time, really generated a lot of attention and many, many conversations.  I would even go so far as to suggest that his paper helped raise the visibility of the issues which led to many of the changes that make the solution many times better than it was for that use case.  For that, I applaud Pete; I really do.  His well written document provided a road map to manufacturers, vendors, service providers and enterprise about the things they did that limited the success of these solutions and what they could do to make them work better.  He was certainly a shining and outspoken leader in our field and I’m thrilled I had the pleasure of chatting with him numerous times over the years.

What this is REALLY about, is the need to be a little more discerning when taking information and resources off the Internet.  Sure, Pete’s document contains a wealth of information, but maybe it shouldn’t be the end-all, be-all of the research effort based on the date which is plainly posted.  As I said, even a quick search of the vegan-lb list showed that within a year, some of the issues were being mitigated.

So, Shame on GSLB?  I don’t think so.  It has been providing value for years and because of people like Pete Tenereillo and their courage to make a stand—the solution has only gotten better and better over time.

Shame on ME?  Yeah—probably.  I should have devoted the effort right up front and I didn’t.  So, Pete—no hard feelings—right?  I sure hope someone references something I wrote in 5 years.  It wasn’t you, or even your document that riled me—it was the way it appeared to be being used.


Follow me on Twitter Subscribe Bookmark and Share Add to Technorati Favorites