Application Architectures - The Practice of Cloud System Administration - page 84

width or overload the link. However, every packet sent on the backbone has a cost associ-
ated with it, and Google pays that expense.
The second path is to go to a frontend at the nearest datacenter that hosts Google Maps.
If that datacenter is very far away, the query may traverse multiple ISPs to get there, pos-
siblygoingoveroceans.Thissolutionwillberatherslow.Thesetranscontinentallinkstend
to be overloaded and there is no incentive for the ISPs involved to provide stellar perform-
anceforsomeoneelse'straffic.Evenso,thecostofthetransmissionisaburdenontheISP,
not Google. It may be slow, but someone else is bearing the cost.
Which path does Google Maps traffic take? The fast/expensive one or the cheap/slow
one? The answer is: both!
Googlewantsitsservicetobefastandresponsivetotheuser.Thereforetrafficrelatedto
the user interface (UI) is sent over the first path. This data is HTML and is generally very
small.
The other part of Google Maps is delivering the map tiles—that is, the graphics that
make up the maps. Even though they are compressed, they are big and bulky and use a lot
of bandwidth. However, they are loaded “off screen” by very crafty JavaScript code, so re-
sponsiveness isn't required. The map tiles can load very slowly and it would not hinder the
users' experience. Therefore the map tile requests take the slow but inexpensive path.
If you look at the HTML code of Google Maps, you will see that the URLs of the
UI and map tiles refer to different hostnames. This way the global DNS load balancer
can assign different paths to the different types of traffic. The GLB is configured so that
maps.google.com, which is used for all the elements related to the UI, returns the IP ad-
dress of the nearest frontend. The map tiles are loaded using URLs that contain a different
hostname. The GLB is configured so that this hostname returns the IP address of a fron-
tend in the nearest datacenter that serves Google Maps. Thus users get fast interaction and
Google pays less for bandwidth.
4.6 Message Bus Architectures
Amessagebusisamany-to-manycommunication mechanism betweenservers.Itisacon-
venient way to distribute information among different services. Message buses are becom-
ing a popular architecture used behind the scenes in system administration systems, web-
based services, and enterprise systems. This approach is more efficient than repeatedly
polling a database to see if new information has arrived.
A message bus is a mechanism whereby servers send messages to “channels” (like a
radio channel) and other servers listen to the channels they need. A server that sends mes-
sages is a publisher and the receivers are subscribers . A server can be a publisher or
subscriber of a given channel, or it can simply ignore the channel. This permits one-to-