Deployment Archetypes for High Availability and Low Latency

https://cloud.google.com/architecture/deployment-archetypes

In the past, as application developers, we were not only responsible for developing our applications but also had to manage the entire deployment process. When we wanted to deploy our application, we had to rent servers, virtual machines, or other resources from hosting providers, and all installations and configurations had to be handled by the developers themselves.

For example, the installation of the database for the application to be deployed on the server had to be carried out by the developer. Tasks such as regularly taking database backups and, in more advanced applications, setting up synchronization and data replication between databases in a cluster had to be manually configured by the developers.

Hosting and cloud refer to different concepts!

However, over time, the requirement for increasingly complex applications to be available 24/7 (highly available) and to respond within milliseconds (low-latency) made the deployment processes more challenging and time-consuming for developers.

At this point, cloud and cloud providers came to the rescue of developers. They enable developers to deploy the desired database, server, or application in any region with high availability, all with a single click, without the hassle of complex setups. This allows developers to focus solely on coding and problem-solving, without having to deal with any infrastructure-related tasks.

So, how do cloud providers manage to offer such highly available and low-latency systems worldwide?

In this article, we will explore the deployment strategies used by cloud providers such as AWS, Azure, and GCP to deliver cloud services with high availability and low latency to their customers.

First, we need to examine the concepts of zone and region.

A zone is a group of servers where applications are deployed in small clusters. This structure can be thought of as different shelves in a library, separate rooms within the same building, or distinct buildings within the same campus. The key aspect of zones is their proximity to each other, allowing them to communicate with very low latency (within milliseconds).

A region, on the other hand, is a structure formed by the combination of at least three zones. Regions are designed to ensure service continuity even in the event of natural disasters such as earthquakes or tsunamis. If one region becomes unavailable, other regions can continue to provide service without interruption.

The naming convention for zones and regions generally follows the format below:

For example, AWS has a region called us-east-1 located in Northern Virginia. This region includes several availability zones: us-east-1a ,us-east-1b ,us-east-1c ,us-east-1d and us-east-1e. Additionally, there is another region, us-east-2, located in Ohio, which contains the availability zones us-east-2a ,us-east-2b and us-east-2c

After discussing the concepts of zones and regions, we will now examine the types of deployments used for deploying cloud applications.

Figure 1: Classification of deployment archetypes (Berenberg & Calder, 2023)

1. Zonal Deployment

This type of deployment involves deploying all components of an application within a single zone. It can be further divided into two categories:

• Single Zone: In this deployment type, all components of the application (such as storage, network, etc.) are hosted in a single zone. This setup is generally not suitable for production environments. It is more appropriate for test applications where data loss is not critical and outages do not pose significant problems.
• Primary Zone with Failover Zone: This deployment strategy involves deploying the application in two different zones simultaneously. In the event of a failure in one zone due to power outages, fires, or other reasons, traffic is automatically or manually redirected to the same application running in the second zone. This principle helps ensure higher availability and resilience for the application.

https://cloud.google.com/architecture/deployment-archetypes/zonal

2. Regional Deployment

This deployment type involves serving the application through multiple zones within a single region. It can be divided into two categories:

• Single Region: In this deployment type, the application is deployed across multiple zones within a single region. Incoming traffic is directed to the active zone, typically attempting to funnel requests through the same zone to achieve better performance.
• Primary Region with Failover Region: In this strategy, the application is deployed across multiple zones in several regions. This setup ensures that if one region goes down, the zones in another region can continue to provide service. For example, if a region in Europe becomes unavailable, the application can still be served by zones in the Middle East region.

https://cloud.google.com/architecture/deployment-archetypes/regional

3. Multi-regional

This deployment scenario involves deploying the application across multiple regions. In cases where users from different continents access the application, users are directed to the instance in the region closest to them to achieve low latency.

Additionally, if the application’s requirements necessitate storing confidential information about users and regulations dictate that the laws in a particular region do not allow this data to be stored in another region (data sovereignty), this deployment type can also be utilized.

In this setup, users’ data is stored in a single region, ensuring compliance with regional data protection laws.

4. Global

In scenarios where the application is used globally, deployment is desired across multiple regions. Users retrieve data from the region closest to their location. Instead of storing a user’s data in a single region, the data is distributed across all regions. Consequently, the application deployed in all regions operates as if it were a single, unified application, providing a seamless experience to users regardless of their geographic location.

5. Hybrid

This scenario involves the application running both on-premises and in the cloud, working together in an integrated manner. By implementing failover mechanisms between the on-premises and cloud environments, the system’s availability is enhanced. This hybrid deployment allows for improved resilience, ensuring that if one environment experiences issues, the other can take over, thereby maintaining service continuity.

6. Multi-cloud

This scenario involves deploying the application across multiple public cloud providers to enhance its availability. By doing so, if an issue arises with one cloud provider, the application instances running on the other cloud provider can continue to provide service. This multi-cloud deployment strategy ensures greater resilience and minimizes the risk of downtime, allowing for seamless service delivery even in the event of provider-specific failures.

The image below will make all of this information more memorable for you.

https://cloud.google.com/architecture/deployment-archetypes

References:

• Berenberg, A., & Calder, B. (2023). Deployment archetypes for cloud applications. Google Inc.
• https://cloud.google.com/architecture/deployment-archetypes