How to prevent a bad case of cloud buyer’s remorse

buyers remorse cloud computing

The trend is clear: The percentage of IT infrastructure and application workloads residing in enterprise data centers is expected to shrink from 59% today to 47% in two years, primarily the result of companies shifting resources to the public cloud, according to a survey recently released by data center provider Datalink.

But IDG Research Services, which conducted the study, also uncovered a countervailing trend: Nearly 40% of organizations with public cloud experience have moved at least some of those workloads back to on premises, mostly due to security and cost concerns.

According to Jason Anderson, chief architect with Datalink (which was recently purchased by Insight Enterprises), the reasons for this apparent cloud buyer’s remorse vary, depending on who you talk to. C-level executives tend to cite cost as the driver for moving apps back to the data center. "They moved something out to the cloud, but they didn’t have a full handle on what the spend would be to host the app in the cloud. As they started getting bills for their monthly run rate, they realized they'd made a significant error in how much it would be," he says.

One step down from the C-levels, IT managers say the primary reason is security. "The concern was that it was apps that ended up in the cloud not because IT had made a strategic choice but because they got there through shadow IT or IT organizations didn’t have the full picture of regional concerns," says Anderson.

Even where the cost was manageable, there was a problem with regions. Cloud providers like Amazon and Microsoft have multiple data centers around the country and break down the locations of their customers' containers by physical regions, like US East and US West. Within the region there are multiple locations. When you put together your virtual private cloud, if you don’t pay attention you will end up with all resources in a single availability zone and if it goes down, you've got a problem.

So you could have done everything right, creating your three-tier app with multiple databases on multiple VMs, but if the whole thing is built inside one data center and there is an issue with uptime, your whole app goes down.

"If there is a problem in a zone, you are powerless. They fix it when they fix it. They provide a level of service but if you haven’t re-architected your app to deal with those instances you are dead in the water. The public cloud provides all the tools and resources to survive those incidents, but you have to do the work. They won't do the work for you," says Anderson.

Here are some tips for avoiding unexpected problems with your cloud deployment:

1. Do your homework

One common problem is companies not doing their homework. They assume the cloud is just like on-premises when it's a completely different animal, and they don’t change how their apps operate.

"When there is no governance, we see cloud sprawl. They spin up resources, there's no control or understanding of what they are used for. So we see customers go to public cloud and realize they are spending way more than on prem," says Jarret Raim, head of strategy and operations for Rackspace Managed Security.

"A lot of cloud providers have a pricing model attached to usage or consumption, which is very different from an on-premises model and that can really screw people up, where they think they are coming into a $50k contract and it blows up into a $500k contract based on consumption," says Andy Wilson, CEO of Logikcull, a cloud-based legal intelligence provider.

"I often see companies take an existing app and move it to public cloud and make it work in public cloud, but find costs are extreme and end up moving it back," adds Tim Crawford, president of AVOA, an IT consultancy. "When you look at an app in the enterprise, it has a few architectural assumptions. One is it relies on resilient hardware. In public cloud that's not the case."

Tim Crawford, president of AVOA, an IT consultancy

Shadow IT, or developers going into business for themselves, seems to be a recurring theme. "Many companies have found out they are using public cloud, but didn’t have much of a plan when they started," he says. "An individual development team decided to put something on public cloud. So when companies find out some assets have moved out there without security or compliance, then we have seen some of them pull those apps back."

2. Determine the best apps for the cloud

The best way to avoid having to do a withdrawal from the cloud is to do a careful determination before moving it to the cloud. Certain apps are meant to be in-house and certain apps work in the cloud, and far too many IT departments didn't ask the question of where it would work best, says Anderson.

"A lot of people didn’t do their homework, financial, regulatory or architectural homework before they got into the cloud. It does not come with an easy button in that you get to stop thinking about important financial criteria or the work of infrastructure architecture," he says.

An app within the corporate network is designed to run on infrastructure that is always there 24/7. Whether they use it for five minutes or all day, the cost is the same, said Crawford. "With public cloud you don’t want it to run at peak 24/7, you want to cycle up resources and cycle down as needed."

Mission-critical workloads and apps that are sensitive from a performance perspective, such as latency sensitivity and requiring large infrastructure, are going to run best and most efficiently on premises. This includes analytics, databases, ERP solutions, and processing-intensive apps like business intelligence.

More elastic and less latency sensitive apps can run on cloud. This is especially true for apps that only have a short burst of use rather than something that needs to run full out 24/7. The bargain the cloud offers is the ability to spin up services as you need them and shut them off when you don't.

Dan Phillips, CEO of CloudHealth, a SaaS company that helps IT shops optimize their cloud usage, outlined a process for deciding which apps are more conducive to the cloud. One thing to take in mind is how much of a commitment to an on-premises data center a firm plans to have, he notes.

"Most companies will start by going to the cloud for new app development, where they feel it doesn't make sense to develop apps in legacy infrastructure they will not stay with long-term. Start with the cloud from scratch. They also do it when it’s time to upgrade an app. The third stage is taking existing apps and moving to the cloud. They do that last," he says.

"If you are only moving to the cloud because you think you might save some money, that's not the best reason to go," adds Phillips. "We see companies feeling they need that flexibility and agility and speed and ease for a competitive standpoint in their business."

3. Be aware of security issues

Another issue raised was security, something that changes when you move to the cloud. Raim says that the security team that protected an on premises system has to take a very different approach to the public cloud due to the technology changes.

"You may need different tools, you have to use a different approach, you don’t have access to switches or the underlying network infrastructure. The constructs you have are sometimes very different from on prem. So it forces a security operation to do things differently, buy different tools and integrate it all," he says.

You need to do an honest self-assessment of your current security, not just data encryption but data in transit, what kind of logging is done, and so on, adds Wilson. "As you move to cloud services, the number one thing a cloud company has to offer is trust. It makes common sense that if you know they are selling trust. Ok, let's verify that trust. If it's good they will be forthcoming with that before you ask for it. They will have pages on how robust their security is. Where does their data go, who has access to it? All those questions should be answered freely," he says.

4. Culture change

Finally, moving to the cloud means a change in how business is done, said Raim. "The No.1 thing is everyone thinks of moving to the cloud as a tech change, but it also requires a large cultural change. That’s the hard thing to get right. Like DevOps, there are changes to how to build software. Cultural changes are hard and there is a certain rate you can force it into an organization," he says.

So, in summation, to avoid moving to the cloud and then moving back on premises you need to ask why you are moving, will the app benefit from the move, and does it lend itself to operating in the cloud. If you just move an app to the cloud and operate like it was on premises, expect a very large bill, followed by moving the app back into your data center.

Andy Patrizio is a freelance technology writer based in Orange County, California.

This story, "How to prevent a bad case of cloud buyer’s remorse" was originally published by Network World.

Copyright © 2017 IDG Communications, Inc.

It’s time to break the ChatGPT habit
Shop Tech Products at Amazon