Just say no -- even temporarily
Northern Kentucky University is in the midst of a transition to using virtual desktops rather than physical computer labs and has been turning down vendor offers that just don't make sense economically, with hopes that still-to-come products and pricing models will eventually meet its needs.
The university decided to approach the project in "baby steps," by running the virtual desktop software on premises with the idea of transitioning it to a public cloud later, says Tim Ferguson, CIO for Northern Kentucky University.
Around 18 months ago, the university did trials of the virtual desktop software from a few vendors, all hosted in-house. The software's performance didn't meet expectations and neither did the price, so the university declined to implement any of the vendors' offers. "They were surprised. We said, 'Here it is in black and white. You'll cost us more money. The ROI is not good enough. Come back to me when you can solve it,'" Ferguson says.
When Northern Kentucky University first attempted to move desktop virtualisation to the cloud, the ROI wasn't there, says Tim Ferguson, CIO at the university. "We said, 'The ROI isn't good enough. Come back to me when you can solve it," he says.
Since then, the university has deployed VMware's View virtual desktop software in-house and is about to start trials running the software on Dell's public cloud, and possibly others. Ferguson expects to have deployed all of the university's labs as virtual desktops hosted in a public cloud by 2014 or 2015, and to be saving around 30% over current costs.
The university closely tracks costs in order to be able to present current expenditures to vendors. For the virtual desktop project, Ferguson knows how many staff members support the current implementation, what the hardware costs and how much work it takes dealing with software patches. He also knows usage peaks and valleys, an important issue for a university and one that could help it save money by moving to a public cloud.
This data is extremely important when working with potential vendors, he says. "If I clearly articulate what it costs today, if they can't save me money, why do it?" he says. "If you can't articulate that, it's kind of hard to ask a vendor to do something for you."
One way that Northern Kentucky is making sure cloud services save costs is by pushing its vendors to offer true usage-based costing. Many vendors of SaaS services that Ferguson has looked at are trying to charge on a per-seat basis. But for a university, with its slow times during the summer and holidays, that pricing model doesn't make sense. At peak usage, the pricing would save money for Ferguson but on average, because of the valleys, the per-seat model ends up costing him more than keeping many apps in house.
That's a particularly important issue for Northern Kentucky's ERP system, which supports class registration. The system peaks when students are registering for class and then "flatlines," he says. While his group spends a lot of time managing the on-premises SAP implementation, "if I have to pay for the peak for an entire year, that's not very interesting," he says.
Also, the SAP system is one that the university can't take risks with because the software has to be totally available when students want to register for class. That means Ferguson is going to move that system to the cloud only when he's totally confident it won't fail. "We're going to accept less risk when it comes to those bread and butter systems," he says.
To try to figure out the ROI of any of its proposed cloud projects, Northern Kentucky starts with an ROI calculator and research from Gartner, adapting it for the university's own special needs.
For instance, Ferguson has strict privacy requirements since many cloud services used by the university handle students' information including Social Security numbers and other personally identifying data. NKU includes privacy in its ROI calculation by subtracting value when considering a vendor that doesn't seem to grasp the university's privacy requirements, he says.
The value of various factors will vary based on the organisation. Security may be more important at one business than another; the speed at which you can add more capacity might be most important for another; and liability could be critical to others. "That question of value is complicated," Domicity's Brien says.
Valuing redundancy is one factor that many businesses struggle with when transitioning to the cloud.
There are two camps that don't build in redundancy when using cloud services like IaaS, says Mark Eisenberg, who formerly worked on the Azure team at Microsoft and now is a director at IT consulting company Fino Consulting. The first are businesses that simply don't know that, for instance, when moving a workload to AWS they must balance it across regions if they want to avert the repercussions of a regional outage. AWS has been good about releasing white papers and other advice on how to properly do this, Eisenberg says.
In fact, after an outage about a year and a half ago, AWS wasn't particularly sympathetic toward customers that suffered, Eisenberg says. AWS essentially reminded customers that it recommends they build in redundancy.
The second group of customers makes a conscious business decision not to shoulder the cost involved with building in redundancy. "It depends on what they stand to lose," Eisenberg says.
The costs of building in redundancy can be daunting. Take data storage. It costs twice as much to fully replicate data. But there are also architectural decisions to consider. Having two data stores separated by a long distance introduces latency when synching the stores. For many applications, that latency might not matter. But for some types of applications it could create problems.
Cost is a factor for compute redundancy too. Businesses that can tolerate the delay involved with spinning up new cloud-based servers -- usually around five minutes -- can wait until a problem occurs before they fire up backup instances, Fino Consulting's Eisenberg says. Others may run half as many additional servers instead, because they can tolerate some latency with their apps better than they can handle a complete outage for a few minutes.
The scale issues
Architecting scale also is a challenge that comes with cost repercussions. "Just as in the on-premises world where capacity is kind of an art more than a science, it's the same in the cloud," Eisenberg says. "It's easy to say 'I'll just have more capacity than I need,' until you find out the high costs associated with doing that."
SaaS deployments come with their own set of potential cost overruns. SaaS providers often offer their best deals to customers that sign on to multi-year contracts. "So now you have this three-year contract. Maybe you outgrow it or maybe you find another app that does a similar thing but better," explains Connor Sullivan, an analyst at IDC who follows cloud computing. Businesses then feel trapped with an app that's not the best fit or they end up "double dipping" -- signing up for a new service for additional cost, he says.
Businesses also should thoughtfully consider costs over time. It turns out that the price for SaaS apps in general aren't coming down the way that many people once predicted. Historically, the thinking was that with more users of cloud services, economies of scale would reduce costs for users, Sullivan says.
Some providers like Salesforce have true multitenant cloud services and are benefitting from scale. While Salesforce is passing those savings on to customers, it is also continually adding new features, which cost extra for users. "People want those new functionalities and so the cost to the end user hasn't gone down," Sullivan says.
"The message we've been drumming is it's all about scale," Fino Consulting's Eisenberg says. "If your business problem is not about scale, cloud is in all likelihood not your ideal solution."
But even the scale issue depends on the company. "You get all these Netflix, Web 2.0 apps that are going onto the cloud not just because it makes sense but because their investors aren't willing to fund the capital expenditure for computer equipment," says Domicity's Brien.
Just as in the on-premises world where capacity is kind of an art more than a science, it's the same in the cloud. Mark Eisenberg, Director, Fino Consulting
Large companies, on the other hand, likely already have their own data centres -- and all the fixed costs that implies. "If you aren't going to turn off your servers and lay off people, you may not save any money by going to the cloud," Eisenberg says.
That is, unless a new workload is so variable or short-lived that expanding a data centre doesn't make sense. He remembers a case study Microsoft did about a customer that needed 4,000 servers for just six hours a day for a few days each week. That workload was a perfect candidate for the cloud, where the customer paid only for the time its app ran.
If the shoe fits
The type of workload an organisation hopes to move to the cloud will also determine whether the transition makes sense economically. "We have paid close attention to what sort of circumstances make for a successful cloud deployment," the GSA's Coleman says.
For instance, legacy apps that run on unique hardware platforms, apps that are highly transactional so can't tolerate latency and apps with very complex business processes that are specific to an organisation may not be appropriate for the cloud, she says. This doesn't necessary exclude all these apps from the cloud, "but it's something to consider very carefully," she explains. In some cases, careful engineering might make shifting these types of workloads to the cloud make sense, she says. But ultimately the performance might not match an in-house installation or the cost could be prohibitive.
Underlying the decision factors is the pressure on IT managers from their bosses, "who are looking at the success of Amazon and saying, 'why can't you take 10% off your budget?'" Domicity's Brien says. At the same time, those IT people don't want to rush into using a cloud service for the wrong reason only to see it cost more or impact their service levels.
All those pressures mean that enterprises are taking it slowly. Larger businesses are still at the stage of "primarily playing around" with the cloud, Brien says, in the process of trying to decide which of their apps make sense there. "They're just moving slowly, doing it bit by bit," he says.
"It's really early days, even though all you ever read about is the cloud," he says. "The overall economics of the cloud are that it will ultimately absorb most machine cycles, but it will not happen as fast as people tend to think it will."