Federal Healthcare Higher Education Hybrid Cloud K-12 State & Local

The Argument for the Multicloud

Mark Maynard
Written by Mark Maynard

This article is part of a series penned by Mark Maynard on GovDataDownload covering cloud technologies, best practices, and trends in the space. You can find his article archive here.

Many organizations, public sector and enterprise alike, are exploring different cloud models, including a multicloud approach.  In many cases, organization are trying to alleviate traditional IT infrastructure costs and deliver effective cloud services to their constituents. In this piece, we’ll look at the traditional models, and the benefits of a multicloud approach.

Historically, when selecting applications to migrate to the cloud, it was necessary to choose applications that could be migrated in whole.  That said, applications with databases or other individual components that could not be migrated to the cloud were passed over in favor of applications that had no such restrictions.

To add some clarity to this, imagine an application that fits into the typical three tier (Web/App/DB) model for a cloud application (see figure 1 below), but has a database or other data repository with performance or other requirements that cannot be met by the current Hyperscale providers.  Alternatively, imagine an application that fits into that typical three tier model, but has functionality requirements that cannot be met by a single Hyperscale provider.  In both cases you would, historically, have an application that could not be migrated to the cloud without leveraging a hosting service willing to implement a custom solution to meet your application’s specific requirements.

Multicloud

Figure 1: Cloud application fitting into the typical (Web/App/DB) three tier model

While there are hosting services able to implement any custom solution your applications require, they are comparatively expensive and will contractually commit you to using their services for a predetermined amount of time (three to five years typically) and you could face extremely large monetary penalties should you stop using their services before the end of the contract.

If it is not possible to move an application to a Hyperscale provider and a custom hosting service is not economically feasible or has terms too restrictive to be acceptable, what option remains?

In one of my earlier posts, “What is the Cloud? No Hype or Sales Pitch,” I reviewed the location types and the networks that make up the cloud (see figure 2 below).  One of those location types, Cloud Connected CoLo Providers, are providers that specialize in datacenter colocation space that have high-speed/low-latency network connectivity to multiple Hyperscale providers.

multicloud

Figure 2: The locations and networks that make up the Cloud

Given that the components of a typical cloud application do not need to be located in the same place to function, provided the locations are connected by a network with sufficient throughput and low enough latency to meet the application’s performance needs, it is possible to host these applications in multicloud solutions such as NetApp and Equinix’s NetApp Private Storage (NPS).  In a multicloud solution, the components of the application are distributed over multiple locations in the cloud to include a Cloud Connected CoLo provider, like Equinix, that provides sufficient high-throughout/low-latency network connectivity between the locations (see figure 3 below).

Multicloud

Figure 3: A typical cloud application leveraging NetApp and Equinix’s Multicloud solution NPS

In this example, the URL, load balancer, primary infrastructure services stack (DNS, authorization, authentication, ETC.), databases and other data repositories are located in the Cloud Connected CoLo location while the web, app, and replicate infrastructure services stacks are distributed across a group of Hyperscale providers.  Locating the databases and data repositories in a colocation facility will enable you to deploy any custom solution needed to meet their performance or other requirements.

By distributing the remaining components of the application across multiple Hyperscale providers, your applications will be able to leverage all the various capabilities offered by the different Hyperscale providers and distribute redundant services across multiple Hyperscale providers to achieve higher levels of availability.

Additionally, this multicloud architecture also delivers the following benefits:

  • By having the URL, load balancer, and primary infrastructure services stack in the Cloud Connected CoLo provider you will gain:
    • The ability to use load balancer configuration changes to add, remove, or replace Hyperscale providers as needed to meet your applications’ changing functionality and performance requirements
    • The ability to maintain a single central infrastructure services configuration that uses data replication to span all the locations in your multicloud architecture
  • By placing the web, app and replicate infrastructure services stacks in the Hyperscale providers and leveraging their ability to rapidly deploy and decommission application capacity you will have:
    • The ability to increase or decrease application capacity as needed to meet your applications changing capacity requirements
    • The ability to minimize variable compute costs by leveraging Hyperscale providers’ “pay as you use” model and only operating and paying for the application capacity needed at any given time
    • The ability to minimize Disaster Recovery (DR) investment by not deploying the DR web and app stacks in each of the Hyperscale providers’ alternate region unless a disaster occurs
  • Locating your databases and other data repositories in the Cloud Connected CoLo provider will enable:
    • The ability to maintain control of the data (data governance) to include full control over the hardware and software used to contain the data as well as the people who have logical and physical access to the data
    • The ability to maximize database performance and minimize database transaction latency by leveraging ultra-high performance (100 thousand to 1 million IOPS – Input/Output Operations Per Second – and higher) storage solutions
    • The ability to share databases and other data repositories between multiple Hyperscale providers

Selecting a cloud architecture should always be an exercise in meeting the requirements of the application using the least complex solution possible.  In many cases, this means selecting a Hyperscale provider capable of meeting all your application’s performance and functionality requirements and moving the application into the provider’s environment.  However, there are going to be times when the performance or other requirements of one or more components of an application (usually a database or other data repository) cannot be met by a Hyperscale provider.  Additionally, there will also be times when an application will have functionality requirements that cannot be met by a single Hyperscale provider.

In these cases, a multicloud architecture will allow you to deploy the custom solution needed to host the components of your applications with requirements that preclude the use of Hyperscale providers, while still leveraging those providers to host the remaining application components.  In short, by centrally locating the primary copies of all application and configuration data as well as the primary access point to the application in a location with direct network connectivity to multiple Hyperscale providers, your colocation facility will become the data backbone that ties together the unique data processing capabilities of all the Hyperscale providers.

Interested in reading more cloud insights from Mark Maynard on GovDataDownload? You can find his article archive here.

About the author

Mark Maynard

Mark Maynard

Mark Maynard is a Senior Engagement Manager for NetApp U.S. Public Sector