The marketing hype around cloud computing is at an all-time high. That only makes sense as there have never before been so many options to source IT in an operating expense (OPEX) delivery model.
Many businesses are trying to answer the question, ”What do we do with cloud and what does it mean to our business.” Organizations have to consider software as a service (SaaS), an application development, environment as a service, or even servers and storage as a service. In other words platform as a service (PaaS) and infrastructure as a service (IaaS) respectively.
Delivering information technology to your business today looks different than it did just a few short months ago, much less a year or two years ago. There’s new hardware and software hitting the market every day, so your approach to resourcing IT should incorporate the efficiencies and advantages the latest products and methodologies afford. With so many “cloud” options, IT decision makers should bring this resource delivery model into the problem solving equation.
When faced with either a hardware refresh or bringing a new application online, a major consideration is hardware sizing. How many servers and how much storage is needed to support the workload? This shouldn’t be asked once but every six months, a year, two years down the road.
What will be required to support rapid adoption of either an internal app or a customer-facing app? The cloud holds some promise in terms of accommodating for that unknown. The widely accepted term for this workload accommodation is cloud bursting. When the workload taxes on-premise resources, additional compute is leveraged from a cloud provider. Here’s how one might set up for cloud bursting.
First, identify the workload that needs the additional headroom. That may be the application, web servers, a database or the entire stack.
Next, pick your cloud service provider (CSP). Be familiar with the CSP’s terms and conditions. Know whether you’ll be billed hourly, daily or monthly and if there’s a reservation fee for resources while your machines are dormant. Also consider whether private or public compute instances make better sense. There’s a cost trade-off in public vs. private and there is a data privacy/compliance consideration as well.
Third, you’ll need to package your source machine images for upload to the cloud. Find out how the CSP prefers to accept your images: virtual machine disk (VMDK), Open Virtualization Format (OVF), XenVM, or perhaps they’ll accommodate an entire vApp if they’re a vCloud shop.
There are a handful of tools on the market that can help convert the application stack and package it for portability. VMware Studio and PlateSpin Migrate are two examples.
Once you’ve imported your images to the cloud, provision the resources for your vitual machines (VM’s). It’s best to use global application delivery controllers between your primary resources and your cloud resources. Think of this as policy driven traffic direction between data centers – in other words, global load balancing. This is the key to security and control when setting up the cloud bursting model.
The last piece to the puzzle is – bandwidth. Make sure the Internet connectivity on the cloud side is sized appropriately, lest that is a bottleneck and your cloud bursting efforts are for naught. With proper VM templates loaded, resources provisioned, load balancing in place and connectivity to support the traffic, you’re ready to burst your workload into the cloud.