Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Why cloud native transformation is about people as much as technology for Ticketmaster

Matthew Finnegan | April 4, 2017
Ticketmaster has reduced infrastructure provisioning from months to minutes with Kubernetes containers, says executive programme director Bindi Belanger.

Software automation tools also helped streamline processes.

"The goal of all this was to create delivery teams that were self sufficient. Their jobs would be build software, run it, own it operate it, optimise and monetise it."

 

Moving to the cloud

The decision to move Ticketmaster's data centre infrastructure into Amazon Web Services was a key part of the transition too.

"We don't need to spend a lot of time and money building out infrastructure to be always on," Belanger said. "We wanted infrastructure that was on demand and scalable. But most importantly the decision to move to the public cloud was to force modernisation of our products and services to cloud native standards."

She added that there were numerous operational advantages from moving to the cloud. "The benefits of moving to the cloud are clear," she said. "Not just infrastructure resources like compute and storage, but how we are using our human resources.

"If your teams are spending all their time building and maintaining and upgrading infrastructure they are not spending time adding value and helping development tams move faster."

The goal was to increase speed. "We wanted to shift our leaders to focusing on not changing things, towards taking calculated risks so that we could enabled speed and continuous delivery, which is another way of saying constant change."

 

Cloud native teams

"Our decision to move to the public cloud was a decision to become a cloud native company," said Belanger.

A variety of measures were put in place to create more efficient technology operations:

'Tech maturity' and 'team maturity' models were put in place as way to measure effectiveness and target improvements. "We wanted to be able to define and measure team performance and technical performance objectively."

Data was used to inform decisions around operational changes. The business started "publishing telemetry on everything from uptime to failed maintenance". "We were working towards creating culture where change was normal and not something to fear," she said.

Smaller, more agile teams were created. "In order to create the ideal cloud native teams we realised that smaller was better. Two to five people teams have proven to be really successful. Two people to a team might seem a little strange, but we found that having fewer people focus on the same problem allowed us to move faster."

New staff were recruited to support the cloud native approach. "We wanted people that had developer background, which is something that is not easy to find if you are looking that are also really familiar with infrastructure.

"We wanted problem solvers. We didn't want people who were like 'we have done this for the past five years lets keep doing it, the status quo is fine'. We wanted people that were constantly looking to drive and embrace change."

 

Previous Page  1  2  3  4  Next Page 

Sign up for Computerworld eNewsletters.