Show Notes
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:
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?
Tom: So, mission accomplished, as in the first step, yeah. So, we set out a goal in 2015, to get a certain number of our applications to the Cloud, and that's largely been reached, I think, especially with our customer channels, so that the kind of points of interaction with the customer, the huge number of those are cloud-native today. And things like automated customer interaction with chatbots, and the like, that's all added to the cloud-nativeness of the interaction. As part of our next iteration, we'll be looking for more cloud-native software and cloud-native platforms, and that will start extending into the network systems themselves, as well as the more digital and easily modernizable layers, if you like.
Emily: What sort of business value do you feel like you're looking for as you move to the next step?
Tom: So, primarily, it's going to be driven by customer satisfaction and customer affecting KPIs, like I said before. That's always what’s driven the business metrics anyway. So, things like being able to support the demand of the customer. So, whether that's the new 5G services, for increased bandwidth. So, obviously, if our network systems themselves are cloud-native, then taking advantage of the auto-scaling, and the auto-healing, and the autonomic nature, then the customer experience, and the customer satisfaction will increase.
Improving time to market, so again, part of 5G is that the whole notion of creating more differentiating services, and so if we can do that through the cloud-native mindset with product owners being much more closely engaged with customers, then that improves our product offerings. And we can optimize our network profitability by using cloud-native features like modern big data analytics, and even AI and automation to improve the operations of the network. At the end of the day, the business value is improved customer satisfaction, which improves our financial performance, obviously.
Emily: And when you started out in 2015, who was pushing for moving to cloud-native? Was this the business saying, “Hey, how do we improve customer satisfaction?” Was it engineering saying, “Hey, here's an idea for something that could help us move faster?” Who was behind that?
Tom: That’s a good question. I think it's probably an element of both. It was the opposite of the push me, pull you, I guess. So, there was engineering pushing on an open door, I suppose you could say. So, Cloud was a bit of a buzzword around that time anyway, but I think it's fair to say the concepts of improved time to market, improved stability, the potential for improved security, improved automation, and repeatability, they were all relatively easy sells to product teams who want to be able to sell products to customers. And once you're able to explain what problems those concepts solve, I think it became a bit of a, like I say, pushing on an open door.
Emily: Can you tell me a little bit about the process of explaining what problems these things solve? Was there anything that was getting lost in translation?
Tom: Yeah. I think the biggest thing that I can recall—obviously, it's a company-wide thing. I'm never going to be aware of everything that happens—certainly, it's critical to try and understand what the target operating model is before trying to say, “Here's the technology solution to it.” So, I think some of the lessons that were learnt in the early stages were, rather than trying to say, “Here's the technology answer to a modern way of working that hasn't been agreed or adopted or even understood yet,” let's do that part first, so people understand how they need to work in this modern kind of culture. And then the technology answers then make a bit more sense to people because they're able to say, “Okay, I understand the problems that’s solving now because I'm now working in that way of working.” So, that's probably the biggest learning point I would take from the previous five years.
Emily: Do you feel like the conversation, how did it evolve from the first conversations over the course of the past five years, and then what's it like now?
Tom: It's very different now. The concept of Cloud and cloud-native has become a given and very well understood across the business, even outside of technology. So, we talked to other business units, and they're quite comfortable in understanding the benefits of Cloud. And it's now about when they mature into cloud-native, and when they mature operating models, rather than if. And it's now talking and giving guidance about how to do it, rather than trying to sell the concept itself. So, it just feels like you're at that next stage of not having to sell the idea anymore, and more into the detail of how to implement that idea.
Emily: What would you say were some of the biggest surprises? And let's start with thinking about some of the biggest surprises, not necessarily technically but organizationally, in how engineering was talking with the business, how people were working together. Was there anything about this journey that was unexpected?
Tom: Not particularly. I think the biggest change that happened, which was possibly unexpected when we started, was the level of insourcing that we have undertaken to support the cloud-native operating models, the time to market, and the modern engineering teams. So, we used to be around 97 percent outsourced or something like that, in terms of building software that wasn't just vendor supplied. And for all that software now, we're more like 95 percent in-house. And so, that's quite a big change, and I think that probably surprised people that A) we needed to do it, and B) that we have done it, and relatively successfully got pretty wide-scale digital engineering functions across many markets now.
Emily: And why do you think that matters?
Tom: Because it gives us control of the roadmap, it gives us control of that time to market cadence, and it allows us to use the data that our teams understand and know about, and to share that with other markets. So, as I say, even though an engineering team might be in the UK, they can share what they've done, they can share the artifacts, they can share the data that's driven decisions and software activity with other markets within Vodafone. And that just improves that efficiency, again.
Emily: Do you think insourcing also improves customer satisfaction KPIs?
Tom: Certainly we've seen that. So, whether that's a correlation or causation is kind of for someone with more access to more data than I've got. But certainly, we've seen an increase in online sales, and our digital marketing is more data-driven. And that has happened in correlation with the in-sourcing of software engineering skillset, yeah.
Emily: Do you have any specific examples that come to mind in, maybe you are able to react in a way that wouldn't have been possible if you'd been using the old system?
Tom: I'm not aware of any specific examples, unfortunately.
Emily: Was there anything about the move to Kubernetes, to cloud-native, that you expected to be difficult, and wasn’t. So, that was easier than you expected?
Tom: That's a good question. I suspect the provision of multiple clusters. Kubernetes is difficult. It's a complex system, hence why there are so many cluster management vendor offerings available. And I think we chose a couple of partners early on in the journey to help us with that, and I think that really helped, and it made Kubernetes a little less scary for the software teams who were using it.
So certainly, I've heard feedback—this is anecdotal, rather than anything that's evidence-driven—actually, just being able to create clusters and deploy into them was easier than people had thought when they were learning about Kubernetes through the quick start tutorials and the like.
Emily: Was there anything that sticks out as being far more difficult than expected? The more unpleasant surprises?
Tom: I wouldn't necessarily call them unpleasant, but obviously there's going to be a transition period—which we're in—between the traditional data-center-centric networking and network security policies and concepts, and those that work with Cloud and cloud-native platforms like Kubernetes. And there have definitely been challenges in trying to apply the legacy approach to network security with a distributed and dynamic system like Kubernetes, where you can't give everything a static IP address or even have separate subnets within a cluster for segregation, for example. It has to be done in a different way. You can still apply the same controls, they just have to be done in a different way. So, I think that's one of a few challenges that we found that we've had to work through with different vendors, with engineering teams, and with our internal teams to try and update our guidance on how to apply those controls.
Emily: And to what extent have there been organizational challenges, and how have you gotten over those?
Tom: That's a tricky one to answer, really. I think it all comes down to the balance between understanding and buying into a strategy, but then applying that to application lifecycle and investment lifecycles. So, I think this is probably true for any company: just because a strategy says this is the thing to do, you got a roadmap for your portfolio of applications and services that you need to balance a limited budget. And so, that's been the biggest challenge, is to try and identify how much of each budget at various levels can be spent on strategic activity, and then for which services, and trying to keep that balance, and bearing in mind that there are lots of different things pulling on that same pot of money.
Emily: And what have you learned about managing that?
Tom: I think primarily that there needs to be a holistic view of strategic projects. It's quite difficult to put the onus on a local budget, to spend the money to do something strategic when the benefits are probably—and the business case is probably seen more widely than the individual budget area. But I think it differs between situations, and between markets, and what's happening. I think the primary thing is to understand the costs of the strategy upfront, and try and work those costs into whatever needs doing over the period.
Emily: A slightly different question, which is, is there anything you feel like in the cloud-native journey that you're still working on solving, that you haven't really figured out yet?
Tom: I'm not sure whether we haven't figured this out yet, but one of the things we're putting a lot of effort in at the moment, is the use of advanced data and analytics platforms to try and drive even more network automation, and network planning efficiencies. So, I think it was last year at Google Next, we announced a partnership with Google to make use of their data services. And there's a few projects ongoing within Vodafone to try and drive the amount of knowledge and useful information we can gather from the vast quantities of data we have about our services and the customers that use them because the more we can use that data, the more we can respond to customer need in a timely manner, whether that's reactively in terms of operational response or whether that's proactively in seeing trends that we can then meet a need that may be unsaid yet.
Emily: And if you were to talk to another engineering leader who was trying to push through the open door as you were saying, what advice would you give them?
Tom: The biggest bit of advice is to understand the current way of working for whichever area you're—is on the other side of the door, and understand their pain points because it's not always the same answer. So, generalizing, it may be that one area is more than happy to have a centralized global platform offering, whether that's within our data centers, or public cloud, or both. Another area, just the way it's managed, may require a more distributed model, where the services are offered on a more market specific level. And so, I think that that's the main thing, is to understand the specifics of that area that you're talking to because it will affect how you want to architect and onwardly deploy and manage that technology.
Emily: It would affect not just how you want to architect the technology, but also how you want to communicate what your plan is, right?
Tom: Absolutely. Yeah. So, in the first of the examples I gave, where an area might be happy with a centralized service, that probably means they're already using one. The way you would communicate that would be via that existing channel, if you like. Whereas on the flip side, that kind of channel may not exist, and therefore running the project or projects and communicating with stakeholders would be much more distributed.
Emily: At Vodafone was there ever any challenge selling it, not just over to the business side, but also selling internally inside engineering teams? Or was everyone pretty gung ho to do this?
Tom: No, there’s always challenges. I think again, it goes back to understanding the pain points of an area and understanding why things are the kind of as they are today, which I guess is general for things outside of technology and outside of Vodafone generally is. If you understand the position of the person you're debating with, then you're more likely to reach a common understanding than if you go into it with your own point of view and being unwilling to listen. So, I think that's the main thing is just being willing to listen, to understand pain points, and to be able to react to those within a strategy. You'd hope that it's flexible enough to be able to meet a wide range of needs without needing to necessarily change the overall vision.
Emily: How important do you think this cloud-native transition has been for Vodafone?
Tom: I think it's been crucial. I think we couldn't have done what we've done in the last five years without it. So, there's a video that our group CTO has posted on LinkedIn recently which highlighted a few things around improved mobile KPIs, we've got 4G in 21 markets, we've got the largest 5G in Europe, and all of those improvements from time to market I've already mentioned, we simply couldn't have done that without a modernization program to move to cloud-native across a number of our systems. So, yes, that's partly a technology thing, but also, it is such a cultural thing, and having that modern way of working where you have your modern engineering teams who are closer to the customer, but they're also—the different mindset of a modern engineering company where you're not afraid to try new things, and if you fail, you learn from them. And I think that's all part of what I would class as cloud-native, and that has been, like I say, it's been crucial for us to be able to get where we have been.
Emily: It's interesting to think cloud-native means if you fail, you learn from it. That's a fairly basic concept, and yet true. I can see how that is, sort of, part of being cloud-native.
Tom: Yeah, it's one of those things is quite a basic thing, but I think in traditional ways of working, the focus on the availability of systems and the performance of systems can blind everyone to the possibilities outside of that particular area of focus. And it puts pressure on people at all levels to try and minimize periods of downtime or periods of low performance. And over time, people become less and less willing to be able to try new things, through fear of failing because just the way people work it’s difficult to learn from those failings because it affects customers. And so, what cloud-native technologies enable because of the way things are orchestrated—things are dynamic, things are repeatable—it's very easy to try new things, and not affect all customers. Now, obviously, good software engineering practices help as well. But I think the cloud-native technologies and the ways of working really do support the whole “learn by failing” premise.
Emily: Do you think it would have been possible to get the customer satisfaction KPIs that you did, without moving to cloud-native, in any other way?
Tom: I think the only way you could have done is by a huge investment in people and the traditional technologies. It would have been a much more expensive and slower journey, in my opinion.
Emily: Anything else that you want to add about your experience moving to cloud-native?
Tom: No, I don't think so. I think one of the things—like I said before, the increase in automation, the increase in the modern technologies is just really helped with those customer affecting KPIs, and that has to be the drive for why you're doing it.
Emily: All right, just a couple more questions, then. What is your can't-live-without engineering tool?
Tom: Oh, that’s a good question. Probably Python. I think so many people use it either as a cross-platform scripting tool to be able to automate things and get on the first step towards cloud-native, or it's such a key part of many cloud-native tools like things like Ansible and other tools, and it's used hugely within our data analytics domain to try and drive the usefulness of the data. So, yeah, that's probably the one I’d choose.
Emily: And then this actually is the last question which is, how can listeners follow you or connect with you?
Tom: So, I'm on Twitter at
@tomkivlin. I'm also on LinkedIn. So, I'm
Tom Kivlin, working for Vodafone Group. I am a member of the telecom user group within the CNCF. So, you can find them on
GitHub and also in the… I think it's the
CNCF or the
Kubernetes Slack. And yeah, happy to share experiences and keep learning.
Emily: Well, thank you so much. Again, this is Tom Kivlin, and we'll go ahead and wrap it up there. Thank you so much, Tom.
Announcer: Thank you for listening to
The Business of Cloud Native podcast. Keep up with the latest on the podcast at
thebusinessofcloudnative.com and subscribe on iTunes, Spotify, Google Podcasts, or wherever fine podcasts are distributed. We'll see you next time.
This has been HumblePod production. Stay humble.