Assembling Cloud-Based Geographic Information Systems: A Pragmatic Approach Using Off-the-Shelf Components - Cloud Computing with e-Science Applications - page 153

Internet

Client

Windows Azure (Cloud)

Hosted Service

Web Role 1

Web Role 2

Web Role 3

SQL Azure Database
Gateway Load Balancer

DB Copy 1 DB Copy 2 DB Copy 3

Database Synchronisation

FIGURE 7.6
Implementation of cloud-based GIS application in Azure.

in the cloud. It is important to mention that each web role is an extra-small
machine in Azure, which has a shared core, 768 MB memory, and 5 MB
bandwidth. Azure allows measurement and monitoring of various perfor-
mance parameters of the web roles such as the system load and, based on
this information, scaling rules can be created. By using monitoring infor-
mation, scaling rules, and Azure REST APIs, the number of web roles can
be increased automatically ( horizontal scaling ). In some cases, if increasing
the number of instances does not balance the load, the size of the web
role machine can be increased ( vertical scaling ). Vertical scaling requires
redeployment of the application, which is time consuming and may cause
interruption to the service. Automatic scaling has not been implemented
in our application.
Figure 7.6 shows a load balancer that evenly divides the workload among
web roles, a common practice in any web-based architecture that poses a
particular hurdle in Azure. Running multiple independent copies of the
application on independent machines leads us to a problem if the session
state variables are used in the application, as there is a possibility that
different requests by the same client go to different web roles, as shown
in Figure 7.7.
From this point, if an application is using session state variables, then
sessions stored on one web role are not in the knowledge of other web
roles. As there is even a possibility that a single client will be served by a