Harvard Business Publishing learns some lessons about work in the cloud
- 03 October, 2014 07:00
When Ken Griffin, the director of IT operations for Harvard Business Publishing, warned his staff, "12 months from now, those servers are being switched off," his message was crystal clear -- there's no going back, learn the cloud or step aside.
Top management at Harvard Business Publishing, a nonprofit subsidiary of Harvard University that publishes management learning materials, decided in 2012 to go all-in on the cloud. "We don't want to replace hardware anymore," Griffin said.
The company is now two years into a three-year plan to move all of its operations, consisting of more than 70 applications used by about 650 employees and contributors, to the cloud. Griffin shared some of the lessons he and his team learned on the journey at the Interop New York conference this week.
Moving to the cloud is more complicated than a simple "lift-and-shift" approach of copying software and data over to the hosted service, Griffin said. Organizations should be open to change, he said. The most efficient way to do something in the cloud may involve a radically different approach than doing it in-house.
Some of the migrations were fairly easy, such as moving mail services to Office365. Griffin was surprised how many cloud services employees were already using before the official decision to move operations. Employees were using Jive, Jira, Dropbox and a variety of commercial consumer and enterprise services.
The base infrastructure, built on Amazon Web Services (AWS), required more planning, though. Initially, Harvard Business Publishing had planned to replicate AWS' infrastructure services in the on-premises systems and not make any architectural changes. This approach quickly proved to be inefficient.
Today, there are no Web servers in Harvard Business Publishing's cloud operations. Content is served directly from Amazon's Simple Storage Service (S3), and delivery can be auto-scaled as demand waxes and wanes.
With AWS "architecture is key," Griffin said. Poor cloud-system design means that "you will be in a world of pain," Griffin warned.
AWS can provide organizations a fair bit of help to transition to the cloud. Griffin advised getting a professional support subscription and then letting AWS know how much your organization plans to spend. Once Griffin indicated that Harvard Business Publishing could spend up to US$50,000 a year running operations on AWS, Amazon made sure its questions were answered.
While the technology may need rethinking, Griffin found the biggest challenge was getting existing IT staff to move to a cloud mindset.
System administration duties in the cloud can differ significantly from system administration on-premises. Managing S3, for instance, requires an entirely different skillset, based more on software, than one needed for setting up and running storage arrays.
"We asked people to make themselves obsolete," Griffin said of his staff. They were encouraged to learn the new technologies while maintaining the old ones. The training wasn't mandatory, but Griffin warned staff when the project started that if they didn't train for the cloud "in three years, your stock will be lower than it is today. We may have to part ways."
Three IT employees left because of the shift to the cloud and were replaced by people well-versed in the "devops" style of management more suitable to cloud environments, Griffin said.
Uptime is also an issue that needs to be rethought. Griffin asked Amazon about specific SLAs (service-level agreements), or the guaranteed time AWS would be up and running for a year. Amazon techs responded that the company could provide any SLA needed, simply by architecting the system to the needed resiliency, spreading resources across different geographic zones, establishing multiple, redundant operations and so on.
Nonetheless, downtime happens. So the team is putting a notification system in place to alert employees when systems such as email are offline.
Griffin admitted the publishing company faces a number of unknowns using AWS. He doesn't know exactly how much it will cost to run everything on AWS, though he has estimated it will be about the same cost of running an in-house infrastructure. He also doesn't have a clear exit strategy for pulling operations out of AWS. Architecting a system to AWS does mean using proprietary hooks, which can't be easily translated to the hooks of other cloud services.
"We have all of our resources in one basket," he said.
Overall, Griffin is comfortable with Amazon's reliability, though. "There are scenarios where AWS can fail, but there are more scenarios where our data centers can fail," he said.