 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
With the goal of bringing more productive discussions on this topic into focus and understanding which types of multicloud capabilities are worth pursuing, this series concludes with a look at multicloud through the lens of traffic portability.
Multicloud traffic portability means you can shift traffic between environments dynamically. If you have geographically dispersed users, traffic portability would allow you to route traffic to the nearest cloud provider that could service them. So, if your app can run on Azure and AWS, maybe there’s a closer AWS data center to your customer than Azure. Or maybe one cloud vendor works better for data sovereignty in Europe, so you route to a particular vendor only for those requests.
In most cases, the goal of traffic portability is to have the ability to dynamically shift traffic very quickly between multiple cloud platforms and on-premises data centers. This could also mean you’re balancing 50/50 traffic between AWS and Azure. Or maybe you’re doing maintenance in your Google Cloud environments, so you move 100% of traffic to another cloud temporarily. Canary deployments are another example where you’re testing something new with 5% of traffic on a public cloud provider and keeping the other 95% of traffic in your data center.
There are three types of traffic portability:
Each type comes with a different set of trade-offs in speed, reliability and cost. Some of these types only become realistic at large-scale companies.
Ingress-only traffic portability is implemented with a hub-and-spoke architecture, where one “hub” data center or cloud contains most of your data and does most of the coordination. At the end of the “spokes” in this architecture are all of your front ends, and they’re mainly taking ingress traffic. You also could call it “frontend-only”.
The main attributes of ingress-only traffic portability are:
The caching and latency benefits of this architecture come from the fact that you’re baking in a hierarchical design. This requires that the applications are aware of this architecture, and it usually requires workflow portability so you don’t have to manage ingress to different front ends in different environments with different workflows.
This type of traffic portability is an enhancement of the data and services you’re moving compared to ingress-only. It adds the requirement for partial replication of your backend systems of data in each cloud region and data center. It’s not a carbon copy of your backend data center, but most of your backend services and data are there. This might include data sharded by region and some data in a central location for all regions.
The main attributes of partial failover traffic portability are:
Unlike the hub-and-spoke model, where there’s a single point of failure, this model has more HA and DR capabilities if your central data goes down. However, this has greater data portability requirements than the ingress-only model, and both require some form of workflow portability.
The advantage of partial failover compared with ingress-only is that the overall portability of the app and its traffic is increased with a partial failover option, and when you start to do traffic shaping to different clouds and data centers, the important data is already there.
Full failover traffic portability is the most complex type of traffic portability. With it, you gain the ability to completely take down one site (on-prem or cloud) and failover traffic to any other site. Your sites all have the necessary data in this scenario, so this allows ingress traffic to reach any front end. Full failover also provides maximum HA and DR. With full failover, if you have copies running in multiple clouds, all your traffic shaping will be portable.
The main attributes of full failover traffic portability are:
This type of traffic portability is extremely rare since it requires all four types of multicloud workflow portability. There’s no need for a hub-and-spoke architecture anymore because each request can be processed entirely in any location.
Most of the trade-offs for each type of traffic portability are related to cost, speed and reliability.
Because of large cost increases for any form of traffic portability, a deep assessment of costs and benefits is required. Partial and full failover traffic portability should only be a consideration for large, web-scale companies. These forms of traffic portability are rare even among companies that can afford it.
Usually, the customers we see using partial or full failover do it because of regulatory or contractual requirements. As an example, Walmart requires most of its vendors to run their workloads on non-AWS platforms.
At a smaller scale, ingress-only traffic portability is a more realistic option to avoid situations where traffic must be forwarded on a per-application basis, meaning some services must always go to a particular cloud, region or on-prem data center.
To wrap up this article series, here’s a summary of the four main definitions of “being multicloud”:
The one multicloud capability I encourage every company to plan on building, even if you’re not yet in a multicloud or hybrid cloud scenario, is workflow portability. Even if you’re firmly in the single-cloud camp, there’s minimal extra investment required to start using tools and workflows that are cloud-agnostic.
Data, workload and traffic portability are rarer forms of multicloud portability. Although they can bring significant gains in speed and reliability, there are other ways to get those things without the added complexity and sometimes massive investment of those three options. Often, it’s better to accept data, workload and some traffic lock-in rather than trying to build complex architectures to support any contingency.
Workflow portability, in contrast, removes a great deal of complexity when multicloud finally comes for you. Having a separate workflow, toolset and required expertise for two different clouds (or cloud and on-prem) is a waste of your engineers’ time and resources when a unified workflow is a viable option. It’s this view of the options that led us to build HashiCorp’s products the way we did — on the premise that workflow portability provides the most cost-effective and useful benefit for operating applications and infrastructure in the real-world, multicloud environments enterprises are working with today.
If you haven’t read about the other three definitions of multicloud — data portability, workflow portability and workload portability — check out the first three articles in this series to understand the trade-offs and enablement patterns for each.
