{"id":269425,"date":"2022-03-14T06:57:25","date_gmt":"2022-03-14T11:57:25","guid":{"rendered":"https:\/\/www.webscale.com\/?p=269283"},"modified":"2023-12-29T07:58:45","modified_gmt":"2023-12-29T12:58:45","slug":"how-to-de-risk-cloud-region-selection","status":"publish","type":"post","link":"https:\/\/www.webscale.com\/blog\/how-to-de-risk-cloud-region-selection\/","title":{"rendered":"How to De-Risk Cloud Region Selection"},"content":{"rendered":"

When building a cloud application, one of the first decisions to consider is where to deploy it. In fact, Google\u2019s helpful document on\u00a0Best Practices for Compute Engine Regions Selection<\/a>\u00a0states \u201cWhen to choose your compute engine regions\u2026 Early in the architecture phase of an app, decide how many and which Compute Engine regions to use.\u201d Considerations for selecting the regions, according to Google, include latency, pricing, machine type availability, resource quotas and more.<\/p>\n

It goes without saying that this is not just relevant for new apps; existing apps that need to scale with a growing user base should take these factors into consideration, particularly if the user base is distributed or even global.<\/p>\n

Google specifically notes latency is a \u201ckey consideration for region selection\u201d as high latency can lead to an inferior experience. The document walks through the impact on latency of various cloud deployment patterns \u2013 including single region deployment, distributed frontend in multiple regions and backend in a single region, distributed frontend and backend in multiple regions, and multiple parallel apps \u2013 and discusses various strategies and best practices that can be used to mitigate latency issues, including premium tier networking, cloud load balancing and cloud CDN, local caching and app client optimization.<\/p>\n

To be frank, this all has us scratching our collective heads. To begin with, the document is 19 pages long. That\u2019s 19 pages on how to choose where to deploy your app. Moreover, we find it a bit contradictory.<\/p>\n

For instance:<\/p>\n

When selecting Compute Engine regions, latency is one of the biggest factors to consider. Evaluate and measure latency requirements to deliver a quality user experience, and repeat the process if the geographic distribution of your user base changes.<\/em><\/p>\n

\u2026while elsewhere\u2026<\/p>\n

Even if your app serves a global user base, in many cases, a single region is still the best choice. The lower latency benefits might not outweigh the added complexity of multi-region deployment.<\/em><\/p>\n

In other words, latency is critically important, so important that you should repeat this process as the geographic makeup of your user base evolves, but not so important that it\u2019s worth the added complexity of a multi-region deployment.<\/p>\n

Actually, in one sense this is a point we agree on wholeheartedly; we\u2019ve\u00a0written<\/a>\u00a0extensively<\/a>\u00a0on the\u00a0barrier<\/a>\u00a0that\u00a0complexity<\/a>\u00a0can create when scaling your application.\u00a0However, we don\u2019t think the right answer is to limit your application to a single region. The right answer is to get rid of the complexity.<\/strong><\/p>\n

We\u2019ve written an entire paper on\u00a0why organizations are modernizing applications with distributed, multi-cluster Kubernetes deployments<\/a>. We think it\u2019s critically important, and we discuss the benefits at length, including availability and resiliency, eliminating lock-in, improving performance and latency, increasing scalability, lowering cost, enhancing workload compliance and isolation, and more.<\/p>\n

And yes, trying to self-manage a multi-region cloud deployment can be complex. That\u2019s why we don\u2019t make customers do it. At Section, we like to think of this as the de-risk deployment strategy. Or, more succinctly, the \u201cdon\u2019t make me pick a region\u201d approach to cluster deployment.<\/p>\n

We don\u2019t mean to pick on Google, they are a valued part of our\u00a0Composable Edge Cloud<\/a>. And in truth, this is a conundrum for any public cloud platform \u2013 deploying to more than one region is hard, yet staying with a single instance is a de facto admission that a portion of your user base will have a sub-par experience.<\/p>\n

This is the best-practice methodology for region selection, according to Google\u2019s document:<\/p>\n

\n

Now that you have considered latency requirements, potential deployment models, and the geographic distribution of your user base, you understand how these factors affect latency to certain regions. It is time to decide which regions to launch your app in.<\/p>\n

Although there isn’t a right way to weigh the different factors, the following step-by-step methodology might help you decide:<\/p>\n

    \n
  1. \n
      \n
    1. \n
        \n
      1. See if there are non-latency related factors that block you from deploying in specific regions, such as price or colocation. Remove them from your list of regions.<\/li>\n
      2. Choose a deployment model based on the latency requirements and the general architecture of the app. For most mobile and other non-latency critical apps, a single region deployment with Cloud CDN delivery of cacheable content and SSL termination at the edge might be the optimal choice.<\/li>\n
      3. Based on your deployment model, choose regions based on the geographic distribution of your user base and your latency measurements:
        \nFor a single region deployment:- If you need low-latency access to your corporate premises, deploy in the region closest to this location.<\/p>\n

        – If your users are primarily from one country or region, deploy in a region closest to your representative users.<\/p>\n

        – For a global user base, deploy in a region in the US.<\/p>\n

        For a multi-region deployment:<\/p>\n

        – Choose regions close to your users based on their geographic distribution and the app’s latency requirement. Depending on your app, optimize for a specific median latency or make sure that 95-99% of users are served with a specific target latency. Users in certain geographical locations often have a higher tolerance for latency because of their infrastructure limitations.<\/li>\n

      4. If user latency is similar in multiple regions, pricing might be the deciding factor.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/div>\n

        We prefer a simpler alternative. Just deploy to Section, and we\u2019ll take care of the rest.<\/p>\n