Azure provides high availability through various means and at various levels. High availability can be at the datacenter level, the region level, or even across Azure. In this section, we will go through some of the architectures for high availability.
High availability within Azure regions
The architecture shown in Figure 2.6 shows a high‑availability deployment within a single Azure region. High availability is designed at the individual resource level. In this architecture, there are multiple VMs at each tier connected through either an
application gateway or a load balancer, and they are each part of an availability set. Each tier is associated with an availability set. These VMs are placed on separate fault and update domains. While the web servers are connected to application gateways, the rest of the tiers, such as the application and database tiers, have internal load balancers:
Figure 2.6: Designing high availability within a regionNow that you know how to design highly available solutions in the same region, let’s discuss how an architecture that is similar, but spread across Azure regions, can be designed.
High availability across Azure regions
This architecture shows similar deployments in two different Azure regions. As shown in Figure 2.7, both regions have the same resources deployed. High availability is designed at the individual resource level within these regions. There are multiple VMs at each tier, connected through load balancers, and they are part of an availability set. These VMs are placed on separate fault and update domains. While the web servers are connected to external load balancers, the rest of the tiers, such as the application and database tiers, have internal load balancers. It should be noted that application load balancers can be used for web servers and the application tier (instead of Azure load balancers) if there is a need for advanced services, such as session affinity, SSL termination, advanced security using a web application firewall (WAF), and path‑ based routing. The databases in both regions are connected to each other using virtual network peering and gateways. This is helpful in configuring log shipping, SQL Server Always On, and other data synchronization techniques.
The endpoints of the load balancers from both regions are used to configure Traffic Manager endpoints, and traffic is routed based on the priority load-balancing method. Traffic Manager helps in routing all requests to the East US region and, after failover, to West Europe in the case of the non-availability of the first region:
Figure 2.7: Designing high availability across Azure regions
In the next section, we will be exploring scalability, which is another advantage of the cloud.
Scalability
Running applications and systems that are available to users for consumption is important for architects of any business‑critical application. However, there is another equally important application feature that is one of the top priorities for architects, and this is the scalability of the application.
Imagine a situation in which an application is deployed and obtains great performance and availability with a few users, but both availability and performance decrease as the number of users begin to increase. There are times when an application performs well under a normal load, but suffers a drop in performance with an increase in the number of users. This can happen if there is a sudden increase in the number of users and the environment is not built for such a large number of users.
To accommodate such spikes in the number of users, you might provision the hardware and bandwidth for handling spikes. The challenge with this is that the additional capacity is not used for the majority of the year, and so does not provide any return on investment. It is provisioned for use only during the holiday season or sales. I hope that by now you are becoming familiar with the problems that architects are trying to solve. All these problems are related to capacity sizing and the scalability of an application.
The focus of this chapter is to understand scalability as an architectural concern and to check out the services that are provided by Azure for implementing scalability.
Capacity planning and sizing are a couple of the top priorities for architects and
their applications and services. Architects must find a balance between buying and provisioning too many resources and buying and provisioning too few resources. Having too few resources can lead to you not being able to serve all users, resulting in them turning to a competitor. On the other hand, having too many resources can hurt your budget and return on investment because most of the resources will remain unused most of the time. Moreover, the problem is amplified by the varying level of demand at different times. It is almost impossible to predict the number of users of an application over a day, let alone a year. However, it is possible to find an approximate number using past information and continuous monitoring.
Scalability refers to the ability to handle a growing number of users and provide them with the same level of performance as when there are fewer users utilizing resources for application deployment, processes, and technology. Scalability might mean serving more requests without a decrease in performance, or it might mean handling larger and more time‑consuming work without any loss of performance in both cases.
Capacity planning and sizing exercises should be undertaken by architects at the very beginning of a project and during the planning phase to provide scalability to applications.
Some applications have stable demand patterns, while it is difficult to predict others. Scalability requirements are known for stable‑demand applications, while discerning them can be a more involved process for variable‑demand applications. Autoscaling, a concept that we will review in the next section, should be used for applications whose demands cannot be predicted.
People often tend to confuse scalability with performance. In the next section, you will see a quick comparison of these two terms.
Scalability versus performance
It is quite easy to get confused between scalability and performance when it comes to architectural concerns, because scalability is all about ensuring that irrespective of the number of users consuming the application, all users receive the same predetermined level of performance.
Performance relates to ensuring that an application caters to predefined response times and throughput. Scalability refers to having provisions for more resources when needed in order to accommodate more users without sacrificing performance.
It is better to understand this using an analogy: the speed of a train directly relates to the performance of a railway network. However, getting more trains to run in parallel at the same or at higher speeds represents the scalability of the railway network.
Now that you know what the difference between scalability and performance is, let’s discuss how Azure provides scalability.