Modern Infrastructure

Liquid immersion cooling surfaces in the server market

James Thew - Fotolia

Manage Learn to apply best practices and optimize your operations.

Moving on from cloud deployment heartbreak

When it comes to cloud computing, there are no guarantees. Some cloud projects are destined to fail, but what matters is what you do to fix them.

Even with careful planning, some cloud deployments are destined to fail. So what can enterprise IT do to mitigate loss when a cloud migration goes south?

Once an application is up in the cloud, the best solution can often be to fix it in place rather than migrate elsewhere. That typically involves reversing the moves taken in testing while using the same monitoring tools to do so.

"Glean as much information from this existing environment as you can," said Robert Green, principal cloud strategist at Enfinitum. "The whole goal is to understand when it breaks down. If you can understand what time the system starts to break down, you can start understanding where the bottlenecks are."

Once you know where the system breaks, the next thing to consider is if the application scales horizontally or vertically, as well as what type of support is needed to resolve the problem. Sometimes, though, it's the cloud vendor that's the problem, and it's simply time to move on. In those cases, it's important to have a blueprint to deploy in multiple clouds and an installer to automate the process, Green said. The applications themselves won't be able to migrate from one vendor to another, so copies will have to be made and data moved.

A disaster recovery plan can help with a possible migration, including backing up to physical disks or replicating to a different region. One way to speed the migration process is to use direct network access -- a service provided by Amazon Web Services, Microsoft and IBM.

If a company uses a colocation facility that happens to have a point of presence for two of these vendors, it can even serve as a faster means to move from one provider to another, according to Greg Schulz, senior advisory analyst at StorageIO.

"There's really not a nonstop service, per se, between Amazon and Azure, but you can do a one-stop flight with a layover connection," Schulz said.

And while using multiple clouds for the same purpose may sound counterintuitive, it can save a lot of headaches when problems occur, Schulz said. Yes, it can eliminate most of the savings associated with the cloud, but if the goal is just to save money, you get what you pay for, he added.

"If your only focus is going to the cloud to cut costs, you're missing out on some very valuable business benefits, which is leveraging resiliency, leveraging agility, leveraging the ability to burst for seasonal demands, to really gain the flexibility of moving to the cloud," Schulz said.

Mind the API

An organization's success extricating itself from the cloud depends to a large extent on how much it uses the provider's proprietary application programming interfaces (APIs).Most IT shops aren't taking advantage of the ancillary products and APIs that cloud vendors offer because they involve services they're not accustomed to using. But there can be value in using them, cloud experts said. Applications that are built in existing data centers and then moved to the cloud to use network computing and storage are typically rather portable.

When an application is built in the cloud, migration becomes much more complicated. So while cloud vendors tout proprietary APIs as way to save money and improve returns, the irony is that the more the providers' tools are used, the more locked in organizations become.

"If they've really built from Amazon and using message buttons and alerting and monitoring and everything Amazon sells you on, oftentimes we have to walk away because it's literally in the code of the system, and you're talking about writing all APIs based on this cloud or that cloud," said Jordan Jacobs, senior vice president of products at SingleHop LLC, a Chicago-based managed hosting and private cloud provider.. "It's just not feasible. That customer belongs on AWS."

How to avoid cloud heartbreak

  1. Do your homework first. Conduct an exhaustive performance review. Establish metrics to capture workloads' peaks and valleys, anticipate growth rate, and understand capacity and storage needs.
  2. Have a plan. Use those metrics to establish a blueprint for how to deploy in the cloud and how to get out. Determine the best route to migrating workloads for your needs, and perform tests.
  3. Do it again, in reverse. When a cloud deployment fails, the cause can likely be traced to the customer, not the vendor. Use the same tools you built before your migration to diagnose and pinpoint bottlenecks.
  4. Back it up. Disaster recovery plans aren't just for disasters. Backing up data with multiple cloud providers is more expensive, but it can also save a ton of headaches when you decide it's time to leave one behind.
  5. Remember your roots. Applications that are built on premises don't always do so well in the cloud, especially those tied to specific in-house architectures based on assumptions that predate cloud computing.
  6. Eyes wide open. Cloud providers offer a host of services that weren't available in the traditional data center. These tools can save money and time, but they often come with proprietary APIs.

SingleHop's first attempt to launch its service included a proprietary orchestration tool, Jacobs said. Customers were concerned that the tool might prevent them from decoupling, so SingleHop rewrote the application using industry-standard software to make it more compatible with customers' on-premises setups.

Indeed, vendors are now starting to realize that lock-in can make it more difficult for them to get business, Jacobs said.

"Vendor lock-in has two sides," Jacobs said. "From the vendor standpoint, it's great that when customers come, they can't leave, but other part is it makes it even harder to get in in the first place."

That has led some experts to recommend building apps that aren't coupled to the vendor's proprietary services and to use libraries that support multiple cloud infrastructures.

A layer can be written on top of workflows to isolate them from the proprietary APIs, or a platform as a service provider can be used to maintain portability, as long as it's configured the same for on premises and in the cloud.

IT should be just as mindful of API complexity as compatibility, said Enfinitum's Green. Most cloud environments have RESTful APIs, but the challenge for systems administrators is making then work. "A lot of people are talking about APIs, but do you have developers on site who can build [them]?" he said.

Should I stay or should I go?

But when it comes time to decide to move to another cloud, many experts say the benefits can be minimal at best.

John Treadway, senior vice president at Boston-based Cloud Technology Partners Inc. used to advise customers to avoid moves that would lead to vendor lock-in, but the cost and difficulty of migrating applications to another provider's cloud are such that he now encourages customers to go ahead and take advantage of proprietary cloud services.

Cloud vendors are constantly changing their products and dropping prices, and while migrating to another provider is certainly possible, it's a matter of weighing the risks of such a move, he said.

"I'm making choices all the time," Treadway said. "I choose what language to use, I'm locking myself in every time I write lines of code to something that I might not like later. But the cost of migration is a lot more than licensing or other costs. You just have to go into it with eyes wide open."

Trevor Jones is the news writer for SearchCloudComputing. You can reach him at

Article 4 of 8

Next Steps

Read part one: When your cloud deployment isn't all it's cracked up to be

Dig Deeper on Cloud architecture design and planning

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Modern Infrastructure

Access to all of our back issues View All