Public or Private, Multi-Cloud is the Future. How Will You Manage It?

By | November 5, 2015

A version of this article originally appeared in TechTarget SearchCloudApplications as Managing application deployments in a multiple-cloud enterprise

original_personalised-multi-cloud-baby-mobileAny conversation about cloud services usually begins with AWS, but for most organizations, it won’t end there. Whether to fight vendor lock-in, increase the diversity of available services, arbitrage price disparities or maintain control over particularly sensitive information an increasing number are adopting multi-cloud strategies that include both public and private components. While it’s a sound strategy, they quickly run into another problem: managing applications and infrastructure configurations across cloud stacks that don’t share a common API and have very different service definitions and billing models. It’s a seemingly complex task, but hardly a showstopper, with a number of mature software and SaaS options available to automate deployments across a variety of cloud stacks.  Yet all the automation tools rely on a common conceptual framework: treating cloud resources as abstract objects that can be configured, run and managed as software code. Hence, the overlap with DevOps methodologies and organizational models.

The multi-cloud imperative

Think multi-cloud is only for hyper growth cloud-native startups or multinational enterprises? Think again. According to the RightScale 2015 State of Cloud Report, 58% of respondents use both public and private clouds. Furthermore 14% have a multiple public cloud strategy with another 55% working towards a hybrid mix of public and private. Lest you dismiss RightScale, which is a leading provider of cloud management software, of stacking the deck in favor of its product thesis, Forrester Consulting comes up with similar data. It found that 52% of large firms already use more than one public cloud vendor with a third running on three of more.

Source: RightScale State of Cloud 2015

Source: RightScale State of Cloud 2015

Source: RightScale State of Cloud 2015

Source: RightScale State of Cloud 2015

The multi-cloud imperative is fairly simple. No organization wants to have critical infrastructure solely dependent on a single vendor, even one as large and reliable as AWS. Indeed, without a proper AWS architecture that includes multiple availability zones, outages are a very real possibility as Amazon itself, along with Airbnb, Tinder, Reddit, and others recently found out when the Northern Virginia zone went down for several hours.


Yet as Forrester points out, cloud heterogeneity is causing angst among IT pros. It notes, “The trend towards multivendor hybrid cloud models is challenging them to figure out how they should manage disparate cloud services while delivering a consistent experience to developers and other business consumers of cloud.” Inconsistent management and monitoring interfaces are particularly frustrating. Indeed, RightScale’s survey finds that a quarter of respondents find managing multiple cloud services a “significant challenge.” Digging deeper, Forrester’s data shows the biggest issues in managing multiple clouds are:

  • service consistency between providers
  • workload migration between clouds
  • consolidated management across multiple clouds
  • supporting different cloud end-user portals

Cloud-agnostic deployment software can help with all four.


Cloud-agnostic management options

There are dozens of software and SaaS products designed to automate infrastructure and application management across multiple clouds. Some focus on specific needs or usage scenarios. For example, Cloudyn is designed for asset and cost management and includes a workload optimizer to identify the most efficient cost-performance deployment option for a particular workload, while CSC, using the former ServiceMesh product focus on cloud governance, security and lifecycle management. Others, like CliqrCloudify and ElasticBox take an application-centric approach to cloud automation.

Yet the most popular multi-cloud products are generally those used by organizations embracing a DevOps approach to cloud management, a tact that extends application programming into the realm of infrastructure configuration and management. Indeed, an important differentiator of each tool is its choice of programming language.

RightScale is on most people’s short list for cloud automation, however it’s own survey finds the most commonly used infrastructure DevOps tools are Chef, Puppet, Ansible and Salt.

  • Chef: Befitting its name, Chef turns infrastructure configuration, deployment and management into a set of recipes that can be interpreted by any system running the Chef client. Of course, there is some server complexity behind the scenes, but as we detailed in a previous article on using Chef with AWS, Chef can manage all parts of a cloud application deployment and also can be fully run within the cloud itself, i.e. the Chef server, developer workstations, system nodes and analytics engine can all run as IaaS instances. Chef supports the major cloud services including AWS, Azure, Google, VMWare (vCloud Air), IBM Softlayer plus Smartcloud Orchestrator and Rackspace/OpenStack. Chef’s domain specific language (DSL) is based on Ruby, which may be a problem for some since it’s not as commonly used as Python and may not be installed by default on standard system images.
  • Puppet:Puppet is the granddaddy of orchestration software making it both mature and widely supported. Puppet has a unique class-based DSL inspired by the Nagios configuration file format that resembles JSON. Although it has a Web UI, advanced configurations will require programming and using the CLI. Configurations define the desired state of infrastructure which the Puppet server and runtime implement on target nodes. A newly released tool, Puppet Razor, can auto-discover and inventory infrastructure and dynamically select a preferred system image for bare metal provisioning.
  • Ansible: An open source platform whose commercial version was recently acquired by Red Hat, Ansible is unique in that it doesn’t require a software agent: it operates completely via SSH connections. Ansible uses YAML for its configuration “playbooks”, which are used for system configuration, deployment and orchestration. According to the Ansible documentation, “Playbooks can be used to manage configurations of and deployments to remote machines. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way.”
  • SaltStack: A relatively new platform that focuses on speed and scalability, Salt is available both as open source code and a supported enterprise edition. Salt uses YAML to describe system states, however the entire platform includes a complex set of components that means a steep learning curve particularly for those not already familiar with another automation platform.

Source: RightScale State of Cloud 2015

Recommendations, Use Cases

Any of the major automation platforms described here will work on both private infrastructure and across all the major public clouds, however the integration details will vary widely. The choice of product should be dictated by the sophistication and scale of one’s infrastructure and expertise of the IT/DevOps team. Packaged SaaS products like Dell Cloud Manager (former Enstratius), RightScale or Scalr are the easiest to deploy and operate since they all have comprehensive Web UIs with prebuilt templates and integrations to the major cloud services although connecting them to internal infrastructure may be trickier. Of the more general purpose tools, Puppet is the most mature, making it quite popular with large enterprises, while due to its agentless design and simple YAML syntax, Ansible is probably the easiest to implement and learn.