In this new series of articles, I delve into the topic of Global Load Balancing, how it works, and how you can use SteelApp to enhance application delivery for all applications, wherever they are based.
Let’s start with a simple example to show how this works - the Telephone Directory. A Telephone Directory is used to look up names in order to find the corresponding telephone number. If we assume there is one Global Phone Book accessible from anywhere, every person and organization in the world would be listed in it, Similarly, the Internet has a similar system called “DNS” that computers use to look up names (like www.brocade.com) in order to find corresponding addresses. Now, picture how complex this system becomes when multiple numbers belong to one person or company in every geographic location around the world. How can the process be simplified for the end user of the telephone directory?
Example: Suez Technology
In these articles, we’ll talk about a fictional organization - Suez Technology - and relate their experience to our directory example above. Let’s say Suez Technology develops maritime traffic management software, and are based in Egypt. Their software support team is based in Egypt and it serves customers across the world. In our Global Phone Book, there is an entry for Suez Technology technical support:
However, phone lines are sometimes unreliable and occasionally international customers have difficulty contacting the technical support team. At other times the call is noisy, and there is a noticeable delay when people speak, making conversation difficult. Suez is very conscious that this gives customers a poor impression of their business.
Suez decides to set up a second technical support call center, based in Vancouver, as they have many customers in North America and the Far East. This should improve the reliability of the telephone calls, and give customers in those parts of the globe a better service. A second phone number for the Canadian call center is added to the Global Phone Book:
However, the phone book simply contains a list of names and numbers. How do callers know which number is best for them? Or should they just choose a number at random?
Location-Aware Phone Book
How could this be improved? Imagine if we had a ”location aware” phone: when you searched for an organization’s phone number, you would also provide the phone number you are calling from. This system would route you to the best call center by choosing the right phone number, based on the call center’s availability and geographic location, perhaps using the following process:
• Identify your geographic location from your number (in this case, Cambridge, UK)
• Look up all of the possible phone numbers - one is in Egypt and one in Canada
• Ignore any of the phone numbers that are not reachable (i.e. off the hook)
• Decide which of the available numbers is geographically closest to you
• Provide you with the best phone number to call.
Overloaded call centers?
Now take our example even further by imagining that a call center could inform the Global Phone Book as to the level of workload they are seeing. For example, the Vancouver call center could say, “customers are currently queued for 5 minutes before we can handle their call”. So, if the call center in Canada happened to be particularly busy and the Egypt one were relatively idle, the Global Phone Book would take this into account. A caller from China may be geographically closer to Vancouver, but the phone system would chose to give him the Egypt number instead.
As a result, customers get a much better level of service. They are never sent to a call center that is off the hook or too busy to take their call. They are routed to the center that is closest so they get the best call quality.
In the next article, we will see how the Internet uses a system called “DNS” (Domain Name System) to manage international addressing, in a similar way to the Global Phone Book example that was described above. A Global Load Balancing service uses DNS as the international phone book, to decide how and when to route traffic to provide the optimum service for our applications, and we will look at how SteelApp can act as both a provider and a client for DNS addressing.