• United States

The multiple cloud mindset

Nov 01, 20176 mins
Cloud ComputingEnterprise ArchitectureHybrid Cloud

Utilizing multiple clouds has become commonplace, but as a strategy it’s not without pitfalls.

hybrid clouds
Credit: Thinkstock

Public cloud or private cloud? Amazon or Azure? There once was a time when you could go to any bar in Las Vegas after a day of trade shows and hear people debating such topics, sometimes with great passion. But what has emerged more recently is the stance that you don’t have to choose one or the other, painting yourself into a figurative box of vendor lock-in. Instead, what more and more organizations are choosing is to not choose at all.

Our friends at IDC call this Hybrid Cloud, but that terminology implies a single application using multiple clouds. It’s more accurate to say that organizations increasingly have a multiple cloud mindset. What does that mean? Choose the right cloud for the right job on an application-by-application basis.

But how does that change your organizational thinking? Does this model spread the administrator skillset too thinly by asking for expertise across multiple platforms? Who gets to nominate the different clouds and decide which applications go where?

Choosing clouds

Just about any analysis of the IaaS market will tell you it’s difficult to make a mistake in the public cloud with AWS, Azure or Google. Each has its specialty of cutting-edge functionality and global reach that might lead your organization to certain decisions for certain applications. Others might get chosen based on specific features, like IBM’s Watson services, or prior contract relationships or even physical datacenter locations.

In the private cloud space, VMware’s long dominance has it already present in most companies, with Azure Stack making a strong play while a myriad of OpenStack options remain viable as well. Ultimately, most companies are choosing two public and one to two private clouds, if for no other reason than they need placement variety based on the application portfolio they’re responsible for. Really, it’s difficult to make a bad choice here, and the misconception is that once you’ve made that selection, the hard part is over. It’s not.

Insulating cloud skills with tooling

The hard part comes when you must manage all those applications on all the different clouds, and tooling helps a lot in the form of Cloud Management Platforms (CMP), a newer class of tools that provide a single pane of glass to manage deployments, provide benchmarking capability, application migration tools, brownfield VM management, and a variety of other features. Without a CMP insulating an organization from the specifics of individual clouds, it can create a skill gap that is difficult to maintain over time.

Instead, what a CMP provides is an abstraction of application deployments in a way that obfuscates the details of the individual clouds and removes the need to have administrators go back and forth between different cloud consoles to keep track of what’s going on across their entire application portfolio. With everything in one place, the multicloud mindset becomes manageable and frees an organization to make more important decisions like, what applications should go where?

Who decides what goes where?

Any CMP worth paying for won’t just help you manage application deployments across multiple clouds from a single control point. It will also help you figure out what should go where through benchmarking. There are plenty of reasons that might drive an application deployment to a specific cloud—many of them dealing with data sensitivity and data center proximity to its user base. But in most cases, the tie-breaker is a price vs. performance analysis.

Each cloud uses a different underlying hypervisor with different physical hardware. How can you make an apples-to-apples price-performance test not only between clouds, but on different instance types within a cloud? Trial-and-error benchmarking, that’s how.

Some tools will attempt to take a small data set and extrapolate your application performance on a specific cloud, but those are educated guesses. The only way to get a direct comparison and see how different applications perform differently on different clouds is to try out each combination of cloud, cloud data center and instance type. Automating this process is where a CMP can remove pain from what would otherwise be a very laborious process.


As mentioned previously, CMPs generally create an application profile or blueprint that describes the components of the application to the CMP in a way that the CMP can then translate into specific resources in specific clouds at deployment time. For example, a typical three-tier web application might have a local load balancer, a web server and a database server. Specifying those components and the specific files that populate each component to uniquely deploy a particular application is typically part of a CMP application modeling process.

But once that process is complete, some CMPs give you the ability to deploy that application and an additional VM with which load can be imparted on the application. Imagine doing that across several clouds, a few data centers within that cloud, and a number of instance types, and the reuse benefits of this modeling step become obvious. This benchmarking functionality spins up the application and its load generator, runs a test like jMeter to impart the load and records the transactional throughput.

Is it worth deploying your web server on a four CPU instance type or will you be fine with a two CPU instance? Automating tests like this can give you the answer. The best part is when something changes, like a new public cloud instance type or new hardware in your private data center, you can simply run the automated test again to see if the new situation is worth migrating the application from Cloud A to Cloud B (which the CMP can also help you do).

Summing up

Utilizing multiple clouds has become commonplace, but as a strategy it’s not without pitfalls. Attempting this approach on your own could mean thinning out your administrative staff and their skill-building, but tooling such as CMPs can help. CMPs have cloud-specific knowledge built into them so your administrators can spend less time learning APIs and more time focusing on managing applications and all the placement, metering, billing and other optimizations that requires. That approach ensures your administrative staff uses their time wisely while allowing you to take advantage of the best each cloud has to offer.


Pete Johnson is a Technical Solutions Architect at Cisco, covering cloud and serverless technologies. Prior to joining Cisco as part of the CliQr acquisition, Pete worked at Hewlett-Packard for 20 years where he served as the Chief Architect and as an inaugural member of the HP Cloud team.

The opinions expressed in this blog are those of Pete Johnson and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.