{"id":7084,"date":"2024-07-03T16:07:26","date_gmt":"2024-07-03T14:07:26","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7084"},"modified":"2024-07-03T16:07:29","modified_gmt":"2024-07-03T14:07:29","slug":"going-global-achieving-resiliency-and-high-availability-with-multi-region-deployment","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/going-global-achieving-resiliency-and-high-availability-with-multi-region-deployment\/","title":{"rendered":"Going Global: achieving resiliency and high availability with Multi-Region Deployment"},"content":{"rendered":"\n

Introduction<\/h2>\n\n\n\n

In the digital age, data has become a highly valuable asset. When developing an application, the data layer forms the foundation of the entire infrastructure, serving as the bedrock upon which all functionalities are built. Ensuring that this data is not only available but also secure is paramount, as it directly impacts the reliability and trustworthiness of the application.<\/p>\n\n\n\n

Multi-region deployments in cloud computing are a strategic approach to achieving high availability and robust disaster recovery. By distributing data across different geographical locations, applications can withstand regional outages and ensure continuous operation, which is essential for maintaining user confidence and service integrity. However, the benefits of multi-region deployments extend beyond disaster recovery. They also support global scalability, allowing applications to serve a worldwide user base with lower latency and higher performance. <\/p>\n\n\n\n

Implementing a multi-region strategy requires careful planning and consideration of various factors; in this article, we will provide a full overview of our experience on multi-region deployments, highlighting the pros and cons with particular considerations about databases and, in general, on the data plane.<\/p>\n\n\n\n

Without any further ado, let\u2019s deep dive into our experience.<\/p>\n\n\n\n

High availability: Isn\u2019t using managed services enough?<\/h2>\n\n\n\n

Typically, when we start a new project, we try to use only serverless or managed services (like AWS Lambda, Amazon APIGateway, Amazon DynamoDB, Amazon Cognito, Amazon SQS, and all the infinite AWS Managed Services), thinking that we are automatically achieving fault tolerance and high availability.<\/p>\n\n\n\n

And that’s true; using Serverless services allows us to take advantage of all the availability zones in a region, making our application resistant to data-center outages.<\/p>\n\n\n\n

But what happens if an entire region, or more realistically, one service in the entire region, stops working?<\/strong><\/p>\n\n\n\n

As this site<\/a> registers all the AWS outages<\/strong> in the past years, region outages<\/strong>, even if very rare, could happen.<\/p>\n\n\n\n

As Solutions Architects, our job is to design highly available solutions in terms of Availability Zones and to create infrastructures that resist<\/strong> the region’s failures. <\/p>\n\n\n\n

This paradigm is not only for creating highly available solutions but also for reaching users worldwide by bringing content closer to their location. In this discussion, we will focus on shifting the paradigm to enhance the resilience and high availability of our applications.<\/p>\n\n\n\n

However, even if we are using only serverless services, it\u2019s not always as simple as it sounds.<\/p>\n\n\n\n

Changing the paradigm from mono-region to multi-region comes with some challenges. You have to think differently and choose the appropriate service that best fits your needs and the multi-region paradigm. Even if you pay attention to all of these problems, sometimes you will find that there is not an easy-to-use and ready solution for them. <\/p>\n\n\n\n

The data layer<\/strong> is one of the first aspects you must address: you must design for cross-region data replication and synchronization. To make things worse, each service stores and manages data with its own complexity and limitations.<\/p>\n\n\n\n

Also, let’s consider the authentication layer<\/strong>, for example. In AWS, the only service that allows you to authenticate your APIs is Amazon Cognito.<\/p>\n\n\n\n

Unfortunately, this service cannot currently be deployed in a multi-region solution<\/strong>, and it\u2019s uncertain if it ever will be. So, how can we achieve that?<\/p>\n\n\n\n

And what about logging and monitoring<\/strong>? In a mono-region solution, logs and metrics are in the same region of the application, and you know for sure that if a user has problems, you can simply watch the logs in AWS Cloudwatch (for example) and understand why your users are experiencing errors. Instead, you have logs and metrics scattered across all regions in a multi-region solution. Searching for a specific user error is more difficult as you don’t know (in an easy way) where the user is and which region is contacting.<\/p>\n\n\n\n

In this article, we will focus on Database, object storage, Route53, and Cache System solutions to transform our simple mono-region setup into a multi-region active-active solution.<\/p>\n\n\n\n

But first, let’s see some advantages and disadvantages of choosing a multi-region<\/strong> deployment.<\/p>\n\n\n\n

Multi-Region Deployment: PROs and CONs<\/h2>\n\n\n\n

As with every solution, some pros and cons must be considered before choosing what is appropriate for our application. So let’s not waste time and start analyzing all the advantages and disadvantages of the Multi-Region – Active \/ Active solution.<\/p>\n\n\n\n

PROs<\/strong>:<\/p>\n\n\n\n