At Harvard Business Publishing, It Was a Do-or Die Move to Cloud

The first thing that moving into the cloud changes is where your servers are running. But before a migration is finished, you'll find it's no longer about the location of the hardware. In fact it's changed the entire organization.

That might be one of the conclusions that Ken Griffin, director of IT operations and services at Harvard Business Publishing, will present in his Interop ITX session at 3:20-4:20 p.m. May 17: Cloud Migration: After the Honeymoon.

Griffin will be speaking from experience. His IT organization is in its fourth year of having moved into Amazon Web Services. HBP completed its migration out of a primary and secondary data center at the end  of 2016. He had announced that HBP was moving to the cloud three years earlier, then he set a three-year time limit for the move. But engineering teams associated with particular business units didn't necessarily see how some of their legacy systems could complete the journey.

With only eight months to go, Griffin issued a signal that the most reluctant cloud adopter couldn't miss. "I cancelled the contract" with his firm's Tier 3 data center space provider, with the last day occurring at the end of December 2015. He posted the cancellation notice on the department's bulletin board, along with the warning: "If your application is running in this data center at the end of December, it will have no power."

Don't move into the cloud half-heartedly, he warns. There are always reasons not to complete the move. "I heard the claim, 'This application won't work in the cloud because it won't scale there.' It's just not true," he said.

[Want to learn more about migrating to the cloud? See At AWS, 'Enterprise Strategy' Consists of Helping Migrations.]

Under Harvard Business Publishing's style of IT organization, not everyone in the line-of-business groups worked for Griffin. He couldn't just order people to do what he wanted. Some of them would still be delaying the move "if I hadn't threatened" the shutdown of their applications, he noted in a recent interview with InformationWeek.

He set a lights out date for the enterprise data center and stuck to it. Once he did, application owners "started to push things over the finish line," he noted.

Harvard Business Publishing consists, of course, of the Harvard Business Review along with the Harvard Business Review Press book division as the HBR and HBR Press unit. Another unit, Corporate Learning, makes courseware available online from the case studies, articles, blogs and events of the other units. Higher Education publishes on behalf of the Harvard Business School and educators in general.

In the process of moving the three units into the cloud and becoming a more digital company, Griffin converted his core operations group of six system administrators and network/storage managers into the DevOps team. To get the distributed team members on board, he convinced business units to send a a total of 22 IT staff members to AWS Re:Invent in Las Vegas, giving them a direct sense of who Amazon was and the cloud services that would be available through it.

"That started everyone thinking, 'If we did this, we could also do that.' It wasn't cheap to send that big a group away for a week," particularly in terms of the collective lost time on the job. But staff members came back from the jaunt more excited about the cloud.

The first part of the migration consisted of the "lift and shift" approach, where legacy systems were duplicated in the cloud in three-tiered systems with application servers, Web servers and database servers. As the IT staff became more accustomed to doing things there, they began to adopt Amazon CloudFront in place of setting up their own web servers and use Autoscaling and AWS Beanstalk for automated deployments and scaling.

Harvard Business Publishing was a user of Oracle, MongoDB and MySQL, and it established new database servers in the cloud as part of its move. After attendance at Re:Invent, however, the DevOps team and business unit developers began thinking about the possibility of using AWS database services, such as the general purpose Aurora relational system and DynamoDB object store in their place. HBP still uses Oracle, Mongo and MySQL on its own servers, but Griffin suspects there's savings in adopting cloud services in their place. Right now he has favorable licensing terms under the university's umbrella licensing agreement. Even so, he says, check back in a year.

Not just about the money

The decision to start moving into the cloud came 3.5 years ago when HBP faced a data center server upgrade cycle. The upgrade would cost it $900,000 a year over a three-year period and that figure gave Griffin "a price point, a way of thinking about what it cost us to run our own shop."

Amazon was still a young cloud provider and there wasn't the momentum of companies moving to the cloud that there is today. But Griffin resolved that the hardware upgrade would be his last. He estimates the move to the cloud is saving HBP 15% of its previous annual IT budget, but doesn't dwell on proving the point because he didn't move into the cloud primarily to achieve cost savings.

Up until then, HBP was a more or less traditional IT shop, with NetApp storage, Cisco servers and VMware virtualization throughout the data center. Griffin felt it would be wise if HBP could re-invent itself, as so many of the articles that it published recommended for companies that want to stay abreast of their times.

He launched the migration to turn HBP into more of a digital organization, "to engage the engineers and promote the practice of re-inventing ourselves," Griffin said. Even if the migration didn't lead to savings, "it would provide benefits downstream as the engineering groups experienced the excitement of working with new tools."

The cloud provides HBP with more flexibility and scalability, "but the real goal was energizing that group," he said. They needed to be in a position where they could feel like they could compete with Facebook, Amazon and other web companies, if push came to shove.

Each business unit has a member of the DevOps team sitting in on its new application design and development. "They're much more connected to what engineering is doing. The respect for each other has gone up on both sides," he noted.

Now instead of doing things the way they always have, the software engineers in the business units are starting to implement serverless applications and putting themselves on a footing where they can compete with startups that are only in the cloud, he said.

"It's hard to make all the pieces of the puzzle fit. It's easy to fall back into the realm of what you already know… The pieces came together in the end," he said.