Multi-Cloud Deployments Build Resilience

GoGrid CEO and cloud pioneer John Keagy points out the benefits of deploying workloads to more than one cloud service.

John Keagy, CEO of GoGrid

November 10, 2014

4 Min Read
(Source: <a href="http://commons.wikimedia.org/wiki/File:Altocumulus.jpg#mediaviewer/File:Altocumulus.jpg" target="_blank">Altocumulus</a> by Bidgee.)

As the world becomes more connected, people and customers expect 24x7 access to their data. It's no longer possible for a single data center to meet the demands of today's sophisticated workloads.

With the advent of the cloud, we now have access to the most advanced information architecture available for handling distributed workloads. The next evolution in cloud application architecture -- multi-cloud application-stack deployments -- helps ensure business continuity by freeing enterprises from the constraints of a single provider.

We're moving quickly toward a world of distributed cloud architectures. It's becoming rare for companies to run applications out of a single data center. Companies typically move workloads to the cloud when it makes sense to do so. But why would these companies want to adopt a multi-cloud strategy? The short answer is that once you've made the leap to cloud-based applications, you need to think beyond a lone provider to ensure business continuity.

Planning for a multi-cloud future
Let's start with backup. At a minimum, any company running applications in the cloud should begin by planning for multi-cloud backup. Employing a multi-cloud backup strategy simply means not putting all your eggs in one basket. Take the time to create relationships with multiple providers, and store backups on multiple clouds. Even if you don't distribute your workloads across multiple clouds, distributing your backups and archives can ensure you recover from a catastrophe involving one cloud provider, if necessary.

[Want to learn more about GoGrid's foray into big data? See GoGrid Emerges As Cloud's Big Data Specialist.]

Standard architectures make it much easier to employ a multi-cloud strategy. This approach is often overlooked, but imagine you're working with backup tools and a set of server images that aren't consistent across providers. Recovering from an incident instantly becomes much harder. For example, proprietary services like Amazon Web Services' Kinesis with Hadoop and Elastic Map Reduce aren't things you can spin up with another provider (in the event you need to do so). An alternative would be to set up Cassandra with Hadoop on AWS and also set up Cassandra with Hadoop on GoGrid using the same, out-of-the-box application technology. This way, when you distribute your backups, you don't have to reinvent the wheel for each cloud provider you're using.

Value in deploying to multiple locations
Finally, let's look at geographic load balancing and designing for failover scenarios. There are a few reasons you may want to direct traffic to alternate locations. Perhaps you need to optimize performance, deliver custom content to a specific region, or ensure failover. In any case, at some point you'll need a geographic load balancing service as well as failover services. Geographic load balancing lets you direct the traffic for your websites to the servers or data centers closest to visitors based on their geographic location. This approach provides shorter load times because visitors' requests are routed to the closest server or data center. A website visitor from Spain would be sent to an Ashburn, Va., data center (where several cloud service providers have located) rather than to a data center in San Francisco, for example.

You can also provide custom content to site visitors. In the same example, a person in San Francisco could receive website content in English, and a person in Spain could receive content in Spanish.

Also, adding failover capabilities to geographic load balancing provides a mechanism for continuous availability in the case of a cluster or data center failure. You can request a cluster as a "failover" cluster, for example, where the primary cluster responding to web traffic could be in a San Francisco data center and the failover cluster would be in the Ashburn data center. Should the cluster in San Francisco become unresponsive, the failover service will detect this event and automatically route traffic to the failover cluster.

Application stacks no longer exist in a single data center and should extend far beyond a single cloud provider. Adopting a multi-cloud approach to application architecture is critical for business continuity. And in an emergency, depending on the level of resilience you need and the speed at which you want to recover, taking even minimal steps toward multi-cloud will ensure your business can recover.

What will you use for your big-data platform? A high-scale relational database? NoSQL database? Hadoop? Event-processing technology? One size doesn't fit all. Here's how to decide. Get the new Pick Your Platform For Big Data issue of InformationWeek Tech Digest today. (Free registration required.)

About the Author(s)

John Keagy

CEO of GoGrid

John Keagy is co-founder and  CEO of GoGrid, which emerged from dedicated server hosting ServePath in 2008. GoGrid was one of the earliest infrastructure-as-a-service providers. Keagy has founded seven companies that were either acquired or became profitable.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights