Blog Post

There’s no need to be a one-cloud company

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

We’ve all heard the phrase, “don’t put all your eggs in one basket.” It’s a simple, but profound message that many of us forget on a daily basis, largely because we think “it can’t happen to me” or finding workable alternatives is too difficult. When it comes to the cloud the same idea prevails. But that road leads to failure. And if you’re willing to put a little up front work into your cloud adoption strategy, you will definitely come out the winner in the long run.

Cloud providers are happy to tell you they have a magic bean that you can install, and “Boom!” you’re cloudified and you need look no further for additional options in terms of providers. So you gently place all your eggs in one cloud basket, then go home and pet your Unicorn while sprinkling pixie dust all around.

Sure, there are myriad solutions available today that individually can solve some of your application requirements such as Joyent, Amazon, Rackspace, VMware, HP, CloudSigma, CloudProviders, etc. However, I haven’t heard any of these providers working on distributing your cloud risk across other solutions. They have choices for hybrid clouds, or public & private blends, but when they talk risk avoidance, it’s the same cloud, with an additional location. To be fair, I don’t blame the providers, it’s up to us as customers to ensure we’ve effectively managed the risk for our business. You can’t lay that responsibility on a vendor.

One cloud – Not even a distributed one?

There are inherent risks with putting all your eggs in one basket, regardless of the elegance or marketing of that basket. Any single technology platform brings with it the risk that a single platform specific issue could adversely affect the whole. I’ve seen too many problems occur in production, even after successful testing, and the reality is that in most cases you just can’t test against every potential environment or use scenario. So, yes the risk remains, regardless of zoning or regional distribution. As the saying goes, the strength of a chain is dependent on the weakest link.

As you develop your technology ecosystem and what I like to call your Fluid IT operating model, you should be creating a strategy for adopting and using multiple cloud platforms, in part to help you reduce your single supplier risk. However, reducing risk of an outage isn’t the only reason you should look for a multi-cloud solution. There’s also the assumption that if you’ve developed an environment that allows you to utilize multiple clouds, you are enriching your ecosystem, and are likely better allocating your workloads and using geographic diversity to better serve your customer.

Sounds great, but how can I manage multiple clouds?

As mentioned in the Fluid IT blog the ability to absorb new technologies and platforms seamlessly is critical. It’s important to note that the faster you can provision critical infrastructure, the faster you can get yourself and your business in trouble, which is why a strong management platform is so critical.

How many of us in IT have built “test” environments for an applications team only to find they’ve been pushed into production without any oversight, governance, change management or even IP address updates? Now, consider how wrong things could go in a cloud environment where there’s no governance, oversight, etc. in place to assist in the process of moving apps from a test environment to production. All clouds need a strong management platform that helps automate and manage specific aspects of a code deployments.

And when it comes to trying to spread an application or several applications across multiple clouds, the need for a strong management platform becomes even more crucial. If the lack of widespread management tools gives you the shivers, realize that the other alternative is to keep everything manual and turn your rapid deployment infrastructure into a Ferrari stuck in traffic. Yes, the car is fast, but it doesn’t matter when stuck on the 101 during rush hour.

So, no, you shouldn’t be on just one cloud, but you also shouldn’t be on any cloud(s) using weak management tools, or worse attempting to do your policy, governance, change management and capacity planning by hand.

Is it really worth it?

There are myriad benefits to being able to use clouds from several different providers, such as reduced risk, having access to the right infrastructure for the right workloads, getting the best price for jobs, and optimizing distribution to address latency concerns. However, there isn’t a simple answer to adopting multiple clouds for any individual workload. That effort will take time and hard work. So, even if your first goal is just to distribute your risk by application, not across applications, you’ll still be better off by hiring a bunny (cloud management) that can manage several baskets using the same controls, governance and policy. Then work through the bunny to distribute your eggs (workloads) across baskets (clouds).

Mark Thiele is executive VP of Data Center Tech at Switch, the operator of the SuperNAP data center in Las Vegas. Thiele blogs at SwitchScribe and at Data Center Pulse, where is also president and founder. He can be found on Twitter at @mthiele10.

Image courtesy of Flickr user ralieghwoman.

15 Responses to “There’s no need to be a one-cloud company”

  1. Joshua Merritt

    Really interesting thoughts. I think the key point I got from the article is the focus on a single management platform. Most of the major cloud vendors provide limited tools for monitoring and management to begin with, but definitely aren’t equipped to consolidate your view of a multi-vendor approach.

    Full disclaimer: I work for BMC Software, and this is the exact space we play into in the cloud – adding the layer of tools you truly need to manage your entire cloud, regardless of which of the big (or small) vendors you are using, or how many. Consider looking into the cloud management space to see what tools are available from vendors that may be able to help you with these challenges – they are very real, but very solvable.

    Key takeaway: Every vendor will sell you on their cloud platform, and claim full “management” tool integration. Very few actually have it at the scale you will want as technology continues to drive your business.

  2. Brian Reeves

    A small Cloud provider called FracRack LLC has already seen the writing on the wall and has begun testing of a second Cloud. Still only one company but two completely different Clouds for this exact need.

  3. Jeff Schneider

    Hey Mark –
    I prefer separating the concepts into ‘hosting provider options’ and ‘as-a-Service options’. The days of force-bundling the two together are (thankfully) going away. The modern cloud provider offers a set of as-a-service offerings that were written by various parties while adhering to the hosting providers capabilities (SLA’s, tech support, etc.)

    If the Dell Cloud were to offer Azure services, OpenStack services and CloudFoundry services, would it be a multi-cloud? Or does it require multiple hosting providers to be multi-cloud?

    I concur that the common cross-cutting aspects like security, compliance, audit, SLA management, cost controls, etc. are a fine fit for these tools. I also agree with Adrian that certain items (like managing PaaS functions) will have an impedance mismatch leading to an undesirable lowest common denominator. Do you remember when people tried to put a single ‘abstraction layer’ across both J2EE and .Net? Some things weren’t meant to have the ‘multi-‘ layered over them. I’m a strong supporter of multi-provider options that focus on the true cross-cutting concerns. I’m also a big fan of single-platform-multi-provider solutions (greatest common factor).

    • Jeff, excellent comments and points. I do believe that you could potentially buy all your cloud options from one partner as this would mitigate technical failure risk. Also, with an “agnostic” partner, you’re less likely to have a proprietary solution that would limit your future negotiation options.

  4. I’ve spent a lot of time helping end user organizations try to figure this out. It’s hard enough to move from a server centric view to a virtualized view let alone to a cloud view. @CloudSigma’s point I don’t think technology focused organizations will have a problem if the data is portable. Writing the scripts should be straight forward enough to utilize multiple clouds.

    One of GigaOM’s earlier posts pointed out that Softlayer is a player in the cloud space for some of our top apps but they aren’t necessarily the exclusive provider to all of these services.

    There seems to be a great opportunity for Cloud Brokers in this space. When you read the NIST defined roles within the Cloud market Cloud Brokers may seem to be the academic solution for this issue – Middleware for your cloud strategy.

  5. CloudSigma

    So the question is, what do you need from your cloud vendor to be able to easily use them in conjunction with other clouds. Here are a few key ones IMHO:
    – data portability (can I move my data out easily, cost effectively and in a useful format without delay?)
    – low data transfer costs (using multiple clouds means moving data between them in volume)
    – how proprietary are implementations of everything from servers and drives to networking? (the more ‘arcane’ the harder multi-cloud management will become)

    Notice I don’t list API which most people concentrate on because, assuming the provider does have a decent API, re-writing management scripts for different APIs is a relatively easy task compared to the problems created with lack of data portability, highly proprietary storage and networking implementations or high data transfer costs.

    To adrianco’s points in the comments, if you build redundancy across multiple clouds you have less urgent support needs in general compared with relying on one vendor where an ‘outage’ could be a total outage of your services. That shouldn’t happen with a multi-vendor strategy and as such outages at any one provider become less disruptive and not critical to service availability. Finally with regards to least common denominator, this assumes equal status of all clouds but that isn’t a good use of multi-cloud implementation. For example, you could have your primary site served from our cloud using our SSD storage to maximise your database performance but failover to a cloud that doesn’t have such great features for running a database but is sufficient to cover any potential outage at the primary cloud. For other services the flow might be reversed, that is the beauty!

    Best wishes,


    • Robert, great comments, thank you. There’s no doubt that “data gravity” is an issue. However, with the appropriate management tools in place to provide policy and governance (I.e., ServiceMesh) you can solve these problems. The ability to solve these problems doesn’t necessarily mean your provider will make it easy, that would need to be part of your cloud due diligence.

    • I can chip in on the ‘low data transfer costs’ point. We have a free tool which you can design your multi-cloud deployment and using the latest cloud provider prices (inc data-in and data-out), we create a detailed cost report. You can then assess how major the data transfer costs actually are compared to lets say instance hours, or storage etc.. Its at Would love to get your thoughts on it.

      Hassan co-founder

  6. adrianco

    On the other hand, with a multi vendir strategy you get to use the lowest common denominator feature set, have multiple vendor meetings and support escalation paths and also debug everything multiple times….

    Meanwhile I’m using a single leading vendor which has way more features less management and support overhead and I’m delivering more of my product features faster, so go ahead, play it safe and stay in the slow lane…

    • Adrian you guys are definitely leaders, but you are unique as compared to the vast majority of enterprises. On the other hand, I don’t think Netflix would lose much in the way of operations efficiency if your cloud ops were distributed ala Zynga. The volume is there to justify solving the problem of multi-cloud once, but then benefiting long term from price, failure, dramatic tech changes, etc.