Hybrid cloud. You're all aiming for it--that's what vendors, analysts and respondents to a soon-to-be-released private cloud survey are saying. The upcoming InformationWeek survey found that 61% of those building a private cloud and currently using public cloud plan to adopt a hybrid-cloud approach. Let's see what needs to be done before you get there.
First, let's assume that hybrid cloud means running a set of applications across a private cloud (a cloud infrastructure you own and manage) and a public cloud (compute, storage and networking resources that someone else owns and manages but you use/lease/rent). Sometimes the application is here, sometimes it's there, and sometimes it's in both places. There are a few hurdles to get over.
You have to get the application and its associated data to the right place at the right time, which isn't as easy as it may seem. Many enterprise applications are built with the assumption that the stuff they depend on will be close by, and if more processing power is needed, then you can add another server and direct load to it. If you're going to use a hybrid cloud to move processing between clouds, then you need to make sure the applications are already residing in both places. Given the size of many virtual machines (VMs)--measured in the tens of gigabytes--you will need to preposition the bits and keep them up to date or wait for several hours, days or weeks to get the bits where they need to be.
There are several ways to position the applications. The most likely is building an OS image in the cloud service and installing your applications there, rather than trying to move an existing VM from your private-cloud environment to a public cloud. Frankly, the transport time to move a VM from here to there will likely be so long that it would be faster to reprovision. With management tools like Puppet and Chef, ensuring that servers and applications are properly configured is pretty easy.
Moving the data is a different issue. It's simplistic, and likely wrong, to think that you need to move your entire data store to either location. You may find you can get away with keeping your data in one location and accessing it from anywhere. Obviously, you need to be aware of the additional delay and bandwidth costs, but a few milliseconds won't matter much, depending on your application. Oh, I know delay is cumulative and reducing delay is always a good thing, but here you have balance--acceptable delay versus the benefit of a hybrid cloud. You may even be able to mitigate delay, with some creative prefetching, caching and other application-level tuning.
If you must move data, perhaps you can move just the portion that will likely be required, rather than the entire data store. If the data store has to be in both places in its entirety, you're looking at setting up some sort of replication and synchronization. That can be pricey, considering that you'll need to purchase and manage the replication software. You'll be paying for not only the cloud storage, but also the cost to transport the data. It starts to add up.
Then there's the networking. Networking in the public cloud is generally pretty pathetic compared with what you have in-house. In many cases, you can't even define VLAN IDs or IP subnets in cloud networks. I know a number of enterprise applications require fixed IP addresses and are hard to change once set. I also know there are IT admins who insist that static IP addresses are still the only way to go. Forget it. Wherever you can, replace fixed, static IP addresses with host names and let applications resolve host names to IP addresses the way Internet pioneers Jon Postel and Paul Mockapetris intended.
Alternatively, you could look at overlay network products that encapsulate inter-VM traffic and just ignore what's underneath. And let's not forget that if you're going to move an application to another location and possibly IP address, or run the app in both places, you'll need to direct traffic to each location.
Getting to a hybrid cloud isn't impossible. In fact, with proper design and engineering, it's quite achievable--provided you determine what your application demands really are and how you can meet them while splitting processing among different locations.
With many enterprises new to NaaS, service providers can differentiate themselves from competitors by prioritizing superior customer service and experiences.
Unlocking the full potential of telecom in the SaaS era relies on comprehensive strategies and a constant commitment to evolving security practices.
Eliminating complexity by standardizing with a platform approach is the way to put the brakes on the complexity cycle.
