The Guardian migrated 70 applications to AWS’s public cloud in just nine months, according to the publisher’s head of engineering Mariot Chauvin – after an initial attempt to build a private cloud that was both “expensive” and a “disaster”, he admitted at AWS’s Transformation Day in London.
In a frank talk on the 200-year-old publishing group’s decision to go “all-in” on AWS, Chauvin said the company began to toy with the cloud in 2012, and initially attempted to build a private cloud. “We thought we could do it internally with OpenStack and avoid lock-in. We built an expensive team. It was a disaster. Our team was not able to provide the same facility and elasticity as AWS services”.
Noting that the Guardian has reduced operational expenditure for IT by 25 percent as a result of the AWS migration, he said its speed was made possible in part by offering considerable autonomy to his 120-strong developers..
(The strength of that team was also a major factor: “We built most of the apps in-house so there was a lot of experience there” he notes; a position companies with thousands of legacy applications running on long-forgotten codebases may envy.)
The Guardian’s AWS Migration: Developers Told “Here’s Your Deadline, Here’s Your Budget, Do What Works”
In terms of approach, he took a laissez-faire one: “We gave a deadline to every team, saying ‘you have to migrate to the cloud in nine months: do what you like, use any AWS services you see available, within this budget’.
“Coordination and consistency came through sharing best practice.”
“Our developers were very happy to experiment, without being dictated to over their specific choice of architecture,” he highlighted.
Content from our partners
See also: The Telegraph Goes All-In on GCP
Speaking to Computer Business Review after the session, he said he reviews the choice of cloud provider approximately every three years: “It’s a foundational choice, your cloud provider. Right now I don’t see a huge difference between the major providers except for a few offerings which probably impact companies larger than us.
“Compute cost for AWS is falling thanks to economies of scale. Of course we have a financial controller, review costs daily. But there’s incredible elasticity in the service; it cuts your insurance costs, your infrastructure costs. We run editorial tools, the website, ID system, data infrastructure, analytics etc. in AWS.
“We probably use over 100 AWS services.”
A slide from Mary McDaniel’s presentation. Credit: AWS
Mary McDaniel, a senior practice manager in AWS’s Application Modernisation and Migration team had introduced Chauvin’s talk. Asking who in the room was considering a large-scale migration to the cloud, a majority of hands went up.
Her main tips for a large scale cloud migration boiled down to just get started: peel off an application and learn from migrating it.
“Start somewhere”, she emphasised. “Start where you get the most business value. You learn so much as you go; you iterate as you go, then you get faster and your landing zone improves. Don’t let the perfect be the enemy of the good.”
(There are application discovery and workload migration tools galore on AWS’s marketplace she noted, pointing to AWS’s own CloudEndure).
It was a point emphasised early at the event by AWS’s head of enterprise strategy Phil Potloff. As he noted: “Two-thirds of most IT budgets just go on keeping the lights on. It doesn’t save a lot of time or money for innovation. And we are finding is that boards are not comfortable with traditional models of Big IT Projects any more.
“I spent months with a company that spent four years just doing requirements gathering. If you do that, then everyone knows where to put their pet project: you get scope bloat, and increasingly blast radius. Then, to control that, you put in manual gates: review points, etc. that slow down projects even more…”
While not every migration will be as smooth as the Guardian’s (Potloff noted: “I met one bank that said they had 66,000 applications”) the thrust of Transformation Day’s sessions was clear: “bite the bullet, get some workloads in the cloud and see how that goes; dev teams and boards will thank you for it.”
See also: Enter the Snowball – a Snapshot of Photobox’s Cloud Migration
