Three Critical Decisions Before Global Deployment of Mission Critical Apps on a Public Cloud

Many companies are moving workloads to the public cloud. That includes mission-critical applications such as SAP, Oracle, and more. Migrating workloads to the public cloud enables companies to gain operational agility and flexibility, as well as better utilize some advanced technologies. Moreover, when the environment on the public cloud is designed correctly — something that requires significant expertise and experience — the customer may also gain cost savings.

But what happens when a company migrates a global system to the public cloud? And said system must provide services to many branches around the world?

oXya’s experience, after completing multiple such projects, shows there are three critical decisions to be made when performing a global deployment of your mission-critical applications to the public cloud.

1. Latency

The first critical aspect is knowing how a global deployment affects latency to various branches around the world. To analyze that, we must know where most of your users are located. We will then choose a public cloud region (where your primary data center is located), so most of your users get the best possible service. There is always a tradeoff in global deployment whereby most users get lower latency (and hence better experience), and some get higher latency. You cannot satisfy everyone in a truly global, diverse enterprise. There are tools to help minimize the latency, but you still won’t reach the perfect user experience for everyone around the world.

Public clouds publish the latency between different locations around the world, to help make that decision. We can help you get that data.

When choosing a region, consider the following:

Limited options. Each public cloud has data centers in certain locations around the world. Sometimes there is no data center in the specific region where most of your users are located. Here are lists of regions for Amazon Web Services, Google Cloud, and Microsoft Azure, you can see where their data centers are located. If most of your users are in a region where the public cloud does not provide a data center, then you will need to choose a different region, that still provides good service to your users.

The Last mile. Consider your own network’s latency when testing latency between different locations. Each of your branches probably has a different network speed, and that affects users’ experience. This impact on performance by the customer’s network is called “the Last Mile”. Sometimes, the customer’s network provides the worst results and is the most challenging, performance wise. Moreover, it cannot always be improved. If your branch is in an area that doesn’t have good network infrastructure, it is quite possible that the best speed this branch can get is 200 megs. BTW, everything written about branches is also true for employees who work from home.

Remember the overall goal here — you want to find the lowest possible latency for most users, so they get the best user experience when interacting with your mission-critical app’s global system.
Once you understand where users are located and have studied the different latencies — you need to consider cost decision.

2. Cost

One may think that a specific public cloud offers the same cost in all their data centers around the world. However, that is not the case. The public cloud factors local costs for each data center — land, electricity, manpower, taxes, etc. — what it costs to run the actual data center in that specific location. Hence, the public cloud’s prices vary significantly between regions. For example, a data center in South U.S. does not have the same cost structure as a data center in West U.S, and thus offers different prices to customers.

Each public cloud provides average costs for each of their regions. For example, the cost of a VM. If we look at regional costs of Microsoft Azure, for example, we see Azure offers the best prices for your infrastructure in East U.S. Moreover, prices in West U.S. are 10–20 percent higher, depending on specific data center location. Costs in Europe are like West U.S. or higher, depending on the exact region.

Infrastructure for a company easily costs a million dollars per year. More, sometimes much more, for large enterprises. Hence, 10–20 percent difference in cost between different regions translates to a delta of $100k to $200k (or more) per year between regions. These are meaningful amounts you can either save or spend.

Note we used Microsoft Azure as example, but cost differences between regions exist in all public clouds.

And cost is not the final decision to make — we also need to verify that the chosen region(s) meet your Disaster Recovery & functionality needs, beyond Latency & Cost.

3. Disaster Recovery

Enterprise mission-critical solutions are never based on a single data center. There is always a disaster recovery (DR) site. Best practice is for the DR data center be at least 125 miles (200 kilometers) away from the primary data center, so should a major disaster occur, they will not go down together, leaving your business with no ability to operate.

There are few criteria for choosing a DR location on a public cloud. The first criterion is “Paired Region”. To explain that term, we first need to refute another assumption some people may have regarding a public cloud, and that assumption is “public cloud offers the same services in all regions”. Well, they don’t.

For a given public cloud, different regions offer different functionality. This is because when the public cloud provider rolls out new functionality (features), they first offer it in specific regions, test, offer to customers to assess demand, and only then roll out (or not) to other regions. It can take 12–18 months for a public cloud to roll out a new feature into all data centers, across all regions.

When choosing your DR region, we verify that your DR region has most of the functionality that you need as in your primary region. Once we design and build your “Paired Region”, we can leverage tools to replicate your entire SAP landscape (or any other apps) to the DR region; such replication may not work if the regions are not paired.

Conclusion

We presented 3 critical decisions that must be made when designing and building a global deployment for your mission critical applications on a public cloud. There is much expertise and experience that goes into such design, build and migration, and additional aspects to consider. For example, connected systems/applications, beyond the one you want to deploy on the public cloud. We’ll cover some of these aspects in future blogs.

For now, if you’re considering migrating your mission-critical applications to the public cloud, I’d love to hear from you — reach out to me and my team!