Vodafone’s Cloud Native Journey with Tom Kivlin

Some of the highlights include: 

• Why Vodafone moved to a cloud native architecture. As Tom explains, the company was struggling to manage operations across more than 20 markets. They also needed to improve the customer experience, and foster customer loyalty. 
• Why their business and engineering teams were both in favor of cloud native.
• The benefits of deploying daily operational activities around a single cloud native platform.  
• An overview of where Vodavone currently is in their overall cloud native journey. Tom also explains how cloud native conversations have changed inside of the company throughout their journey, as various business units have caught on to the benefits of the cloud.
• Vodafaone’s transition from outsourcing roughly 97 percent of their operations, to bringing 95 percent in house. Tom explains how this has improved efficiency and expedited time to market.
• The challenge that Vodafone faced in trying to apply legacy network security solutions to distributed and dynamic systems. 
• Tom’s thoughts on why Vodafone’s cloud native transition and modernization efforts have been crucial to their success over the last five years. 

Links:

• Vodafone Group: https://www.vodafone.com/
• Connect with Tom on LinkedIn: https://uk.linkedin.com/in/tom-kivlin-5b469321
• The Business of Cloud Native: http://thebusinessofcloudnative.com 
• Tom’s Twitter: https://twitter.com/tomkivlin
• CNCF GitHub: https://github.com/cncf
• CNCF Slack: https://slack.cncf.io/
• Kubernetes Slack: http://slack.kubernetes.io/

Transcript

Announcer: Welcome to The Business of Cloud Native podcast, where we explore how end users talk and think about the transition to Kubernetes and cloud-native architectures.

Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I am chatting with Tom Kivlin. Tom, thank you so much for joining us.

Tom: You're welcome. No problem.

Emily: Let's just start out with having you introduce yourself. What do you do? Where do you work, and what do you actually do during your workday?

Tom: Sure. So, I'm a principal cloud orchestration architect at Vodafone Group. I work in the UK. And my day job consists of providing guidance and strategy and architectural blueprints for cloud-native platforms within Vodafone. So, that's around providing guidance to the software domains that are looking to adopt cloud-native architectures and methodologies and also to the more traditional infrastructure domains to try and help them provide their services in a more cloud-native manner to those modern teams.

Emily: And what does that mean when you go into the office—or your home office, go into your dining room where your laptop is, I don't know—what do you actually do? What does an average day look like?

Tom: It can vary. So, depending on the activity at the time, it could be anything from preparing a global policy that needs to go through the senior technology leadership team, to preparing some extremely detailed requirements for selection process or creating some infrastructures code, or the code artifacts for the deployment of cloud-native services, whether that's in our lab, or to help our services teams within Vodafone.

Emily: Tell me a little bit more about what pain made Vodafone think about moving to cloud-native and Kubernetes.

Tom: Primarily, it was the challenge of having 25 different markets, or 23 now. We launched a digital strategy to—so back in 2015, we launched a five-year strategy, which we wanted to massively increase the rollout of 4G, of converged network offerings, of improved customer experience. And we found that the traditional way of managing software was not supportive enough in our ambition. And so, having to choose cloud-native technologies, things like Kubernetes, but also the modern operating models, that was the driver: it was to improve our customer experience, and our customer-affecting KPIs, really.

Emily: And when you say it wasn't supportive enough, what do you mean specifically?

Tom: So, things like time to market, for example. So, if we wanted to offer a new service—so one of the things that 4G started the drive towards was a more granulated service offering to consumers, and so lots of different things could be offered. And if it took you six months to think of an idea and then have to go through—or even longer than six months to get to the point where that could be offered to customers, even if it was just a very minor feature within an existing product, then that's not going to engender customer loyalty. And so, things like the cloud-native mindset, where there's a much closer link between the engineering teams and the customer, there are much shorter periods of time between ideas coming in from the customers and then being delivered back to the customers as product features, that sort of time to market was really enabled by cloud-native technologies and mindsets.

Emily: And how does having two dozen, more or less, different markets, how does that play into the decision A) to move to cloud-native in general, and managing the IT infrastructure?

Tom: So, one of the things that's really driven it is trying to simplify and reuse artifacts. So, if you've got 23 markets all doing a different thing, then there's obviously a lot of duplication happening across the group, whereas if everyone's using the same technology in the same platforms—take Kubernetes as the example—everyone can write their software for that platform. Everyone can write their operational ecosystem around that platform. So, the deployment artifacts, the pipelines, the day two operational activities, they can all be based around that single cloud-native platform. And so, that enables a huge amount of efficiency from the operational side. And that in turn allows those engineering teams to focus on things that are adding value to the business and the customer instead of having to focus on fairly low-level tasks that are just keeping the lights on, if you like.

Emily: What's different for each one of those markets?

Tom: So, it might be something like language, it might be something as simple as that. It may be that the offerings are slightly tweaked. So, rather than, I don't know, as an example, rather than Spotify being included as a kind of add on, it might be some other service that's more relevant to that market. It may be that there are particular regulatory requirements that are specific to a market that needs to be considered within the product design and the engineering of it. And so, having a cloud-native response allows sharing and reuse of artifacts where we can, but still allows for that customization where it's required.

Emily: Where would you say Vodafone is in the cloud-native journey? Do you feel like you've, mission accomplished?

<...