Give Customers Superhero Status With Cloud Bursting: A 5-Step Plan

By Bernard Sanders

Enterprise customers are embracing hybrid cloud computing for its promise of capacity-on-demand service and pay-as-you-go consumption. While the cloud has thus far delivered on this promise, if a hybrid setup is not implemented and managed correctly, these benefits can be eroded. Channel partners play a key role in helping customers both navigate the shift to the cloud and effectively managing cloud environments once they get there.

One of the best ways to help customers contain cloud expenses is through cloud bursting.

There’s been a lot of hype around cloud bursting, and the term has taken on different definitions. I use it here to mean automatically detecting when an internally hosted application is under load and temporarily scaling it into a public cloud provider to supplement its resources and maintain its performance. When demand drops, the application scales back down.

Cloud bursting is the shining promise of hybrid cloud. Done right, it’s capable of cutting IT costs by optimizing resource utilization. However, its benefits have been within the reach of only the smallest fraction of organizations. Why have most customer shops failed to achieve cloud bursting?

There are three main reasons:

The good news is that channel partners can help. While the intermediate steps can be complex and take quite a bit of effort, they will deliver great value.  

The Cloud Bursting Hierarchy

Here is a plan to help your customers achieving cloud bursting:

1. Automate the Server Build Process

First, base server builds must be automated so that they require no manual work from any teams. These automated builds will be company-specific, but should encompass all steps, such as:

Parts of this process can be configured using a configuration manager such as Puppet, Chef or Ansible. The entire process should be kicked off using a cloud-management platform (CMP), so that builds can be performed in one step, from one interface — and ideally from both a GUI and an API. The CMP should also provide on-demand, self-service capacity with pay-as-you-go consumption.

Once this is achieved, you have true infrastructure as a service (IaaS) and can expose end users to the GUI and API of the CMP to give them self-service IT. This can be a game changer, especially for shops where users of IT resources must still submit tickets to request new server builds. They (and the IT team) become much more effective and less frustrated when they are empowered to build their own servers.

Of course, you should advise customers on appropriate guard rails for the sizes, networks, templates and settings users can choose.

Even if your customer’s ascent up the hierarchy of needs takes them only this far, they will realize massive business impacts. I’ve had the privilege to see several organizations make this advancement, and it is impressive how much relationships between teams improve and how much employee satisfaction increases. IT teams can feel like heroes again, and their users have the right tools to do their jobs.

2. Automate the Whole App Stack

Once IaaS is achieved and base OS builds are automated and orderable by users, you can start focusing on automating your customers’ application stacks so that builds for common apps are standardized across the enterprise and best practices are encoded in the automation layer. An IT team may choose to automate deployment of databases first, or web or app tiers.

After these sorts of products are automated, the focus can turn to automating multi-tier, multi-server applications. Most self-service IT automation tools have a blueprint system for doing this, and this stage is where their flexibility, power and simplicity will be tested. The CMP will also need to provide network management to reconfigure load balancers and firewalls. Make a robust test of the blueprint catalog as well as network control part of your criteria when you evaluate CMP options for customers.

3. Internal Auto-Scaling

After internal, full-stack builds are automated, select an application/service that you would like to scale up and down automatically. Web apps are a good place to start because they can be easily load-balanced, the servers are relatively stateless and adding and removing nodes is a fairly straightforward process.

Next, help customers use the CMP to automate scaling that application, so that the process can be performed in one step when a user requests it. Most CMPs have facilities for user-initiated scaling, including reconfiguring network devices and running user-defined configuration tasks upon scale up or scale down.

After one-step scale up and scale down are possible, the next step is to trigger these actions based on detected conditions, such as high or low CPU load. To do this, administrators will need to define scaling policies within their CMP, including identifying the right performance metrics, defining the minimum and maximum for both thresholds and number of servers in each tier for each environment, and scaling up behavior — for example, how many servers to scale by and which environments to expand into.

4. Hybrid Cloud Management

This step can come before or after internal auto-scaling. It involves selecting one or more public clouds and enabling the entire stack deployment process within the providers’ infrastructures. If you used a configuration-management system to automate deployment of these apps, that will make this step easier because those recipes/classes/components can be reused on servers in the public cloud.

If you have deployed a CMP as a self-service portal, it will provide a single user interface from which you can discover, manage and provision VMs in all of your private and public cloud environments. Just ensure when evaluating CMPs that the one you select has broad and deep support for any public cloud you may consider, as well as for all your customers’ virtualization and configuration management technologies.

It should also support blueprints/application definitions that are versatile, so the same blueprint can be deployed to different technologies and environments. For example, it should enable you to build one blueprint that can be deployed to VMware or to Azure. Avoid the need to create multiple separate blueprints.

5. Cloud Bursting

Once you’ve helped customers achieve internal auto-scaling and hybrid cloud management, cloud bursting is no longer a distant aspiration. As long as the triggering systems you use support cross-technology, cross-environment scaling, they should not differentiate between deploying or scaling the application internally versus externally.

From here, the application is the last element that will need to support this configuration.

For your first foray into cloud bursting, a purely stateless application would be the best choice; think a web app with static content and no database connection required. This may be a bit simplistic, but it’s important to pursue MVP and prove the concept first to gain the customer’s confidence.

When you get to web apps that need database connections, you have a number of approaches to consider, including deploying the database to the cloud at the beginning of the bursting event and replicating the data just in time, continuously replicating the data through a multi-master configuration, or having read-only remote databases that proxy write operations back to a central master. Each of these has pros and cons, and the right choice will depend on the application and customer needs.

The prospect of endowing customers with cloud-bursting power may seem daunting, but if you break the pursuit down into more manageable milestones, you can help them realize great improvements along the way and transform operations for the better.

Bernard Sanders is CTO of CloudBolt Software. He has more than a decade of enterprise software experience, including engineering and product management, technical sales, software development and professional services engineering at leading technology companies.