You’re ready to deploy your application to the cloud, and now you need to make a big decision: where will you host it? By where, we don’t mean “which provider” – we literally mean where will it be deployed geographically? Have you thought through the hosting region and its ramifications?
Because this is a BIG decision that will strongly impact your application and user experience. The cloud is not – despite many misnomers – everywhere, all at once. If you’re using one of the hyperscalers (AWS, Azure, GCP, etc.), you’ll need to choose one or more hosting regions. We’ve written before about the challenges and impact of selecting that region, and the enormous complexity if you try to choose more than one region (in fact, this complexity is the reason Google recommends choosing single locations). To make the decision you’ll need to think through things like latency, pricing, machine type availability, resource quotas and other critical considerations.
Now let’s discuss why you’re about to get that decision wrong.
Incomplete Data
First, you’re not clairvoyant and this is a decision that’s inevitably made with incomplete data. Let’s take latency as an example. Do you know where your users are located? We assume you have market projections, but do you actually know the location and volume distribution? Almost certainly, the answer is “no,” so organizations do the next best thing: they make an educated guess and pick a particular cloud instance for deployment. This decision means that users within that region (such as AWS EC2 US-East) enjoy a premium experience, while the experience for everyone outside that region degrades – and the farther they are geographically from the selected region, the worse the experience.
Do you know how bad that experience is, or are you waiting for complaints? Has it cost you any customers? How many?
Shifting User Patterns
Moreover, consider that access patterns shift over time, even on a daily basis. If your primary audience is business users, for example, it’s likely they’ll begin to log off as the workday ends. Going back to our earlier East Coast example, come 5 p.m. Eastern time you’re now hosting an application in a region where you statistically have the fewest users.
These shifts also happen over longer periods as a user base evolves as grows. For an application that’s gaining increasing popularity in Asia, the U.S. East Coast no longer looks like the smart deployment decision. How do you know when to change your hosting location? Even worse, how do you know that your current decision isn’t hampering growth in other regions? You’re back at square one: making decisions with incomplete data.
Environmental Changes
Another consideration: the world will also be changing around you, both moment-to-moment and in jarring leaps. For instance, it’s inevitable that there will be another major cloud outage… will it take down the region you’ve selected? Or consider compliance – how quickly can you shift your hosting strategy to accommodate changes driven by GDPR or CCPA?
In other words, there are numerous reasons that any hosting decision you make will be the wrong one. Changing that location is going to cost a lot of effort and money to fix, and that next location will also be wrong – for the exact same reasons. The harsh reality is that in a global and dynamic computing environment, it’s literally impossible for a single geographical instance to be optimal always and everywhere. Your best hope is that it’s good enough.
Of course, that begs the question: why settle for anything less than optimal? At Section, our belief is that modern application hosting should allow workloads to traverse the world’s available compute to run securely at the right place and time. We’ve designed our cloud-native hosting system to eliminate the need for developers to choose and manage hosting locations manually and arbitrarily, and rather specify hosting requirements based on application intent (reliability, performance, compliance, cost, etc.). This intent is communicated through policy-based rules used by Section’s automated orchestration system – the Adaptive Edge Engine – to dynamically and optimally determine workload distribution. Best of all, this global distribution can actually be more cost effective than using a hyperscaler.
It’s time to make the right hosting decision. Arrange a demo of Section today.
