Ryan Kirk of @Formula1

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but we look at things through the lens of business and engineering leadership. Joining me today we have Ryan Kirk, lead cloud architect and team manager at Formula One. I was super impressed at how Formula One is taking full advantage of being cloud native to stand up and tear down what they need to support each race around the world, and along the way increasing their teams’ velocity. I always start really simple with the basics: who are you and what do you do?

So, Ryan Kirk, I’m the lead cloud architect and team manager at Formula One. So kind of my bag, I guess, is anything to do with clouds. I sort of do technical strategy as well as implementation. And so the cloud function very much lives in my court, and the DevOps function as well, which is a more recent thing. So anything DevOps as well. So it’s been a great combination of teams, I guess, within the business.

Yeah, I would say you said two phrases that send me signals that you’re a little further along in what we would consider your API journey, because embracing the cloud and DevOps culture are two important signals that we look for when it comes to understanding where our customers are. But tell me, what’s with the cloud transformation, and is it recent, is it new, have you been on this journey for a while? What’s it look like?

So we’re kind of a bit late to the party in terms of cloud adoption, and we adopted the cloud, specifically AWS, five years ago when we partnered up with them. And up until then, we had dabbled in cloud tech, but we were very much an on-prem solution, and it really accelerated our cloud adoption having that partnership. It was like opening a tool chest of all these magical toys that we had never seen or played with, so it was quite good fun, especially in the beginning.

So prior to that, we had an on-prem solution, and it was an incredibly bespoke solution, but it worked for us where we were. We’re a traveling circus, I guess, in that aspect. We had a huge data center that would travel to every single event. So you picture your corporate data center in a way, that would have, off the top of my head, probably between 30 and 40 racks of kit, and we would up and lift that, we’d go to the circuit, have all the engineers go a week before the event, and there was a really fine-tuned routine, I suppose, in a way, that everyone knew what they were doing, even from the smallest of processes, so we could get this behemoth rigged up and ready and tested within a matter of 48 hours. And we’d have the race, and it would all come back down again, get put back on a plane and off it went. And that’s how it ran for a good part of 15 years. So that’s, it was one of those if it isn’t broken, don’t touch it type things.

And then once we signed with AWS, it opened our eyes in terms of what we could do with the cloud, from both a corporate aspect as well as a race aspect, and really use what the cloud is great for, and that’s having event-driven architectures and the infrastructure that you wouldn’t necessarily or typically have access to in a standard data center. And then once that snowball was rolling, it just picked up momentum, and more and more ideas got thrown into the mix, and here we are five years later.

Wow, yeah, it’s an important journey, and it’s one I see a lot of enterprises on right now. So I’m guessing with this journey, you touched on a little bit, newfound powers require newfound skills and people to start paying attention and managing this at an operational level. So the DevOps culture kind of comes in. Can you tell me a little bit about what that looks like at Formula One?

Yeah, sure thing. So that was the hurdle, the cloud adoption in a way, in the sense of getting over that idea of you can’t go and switch it off, you can’t go and reboot it physically, it’s all, you don’t see it, it’s magic, it happens way in the distance. So that was one thing, and then the second thing was the idea of DevOps. And we dabbled in what you could class as DevOps in a way, automation within task schedulers and that sort of stuff, so the idea wasn’t completely foreign to us. However, the whole, what 99 percent of people like you and me would consider DevOps now, it was an alien idea, and it was something that took us a little while to bring into the culture. You can sort of say to developers, you know, you can deploy and it just takes care of it, it will move. And it’s kind of, well, how does it move, how does that process work if we just put it in a single location, how does that work, how does the change approval process work? And there were loads of questions, but they were all good questions, because it helped the educational part of it, it helped that selling point, it helped the adoption, because it was like, look at this, we can fully automate this and we can auto-recover this.

And again, it was another snowball that picked up momentum, and now we run, especially cloud, every single one of our systems is fully automated. Automated deployments through change control, we’re very heavily involved in DevSecOps in the past 18 months, so all that automatic security remediation and reporting has saved us bucket loads of time. Even from rotating API keys, it’s something that takes 10 seconds if you’ve got one key to rotate, but if you’ve got hundreds and you do it every single three months, and bringing DevOps into that process, saving that operational overhead, you can’t really put a price on it. So yeah, we’ve kind of got fingers in all kinds of pies in DevOps. Within DevSecOps, we’ve got GitOps, we’ve got traditional CI/CD processes, standard automation in that sense.

Yeah, where I would say everything Ops seems to be a common theme for this show, we’re DataOps, MLOps, ModelOps, the full spectrum we’re seeing too. And so you’re preaching everything that your team needs as far as automation and flexibility and agility. How did you explain this to leadership? What sort of convincing did leadership need to understand the benefit of all of this?

So for DevOps, it was a build it and they will come type thing. We developed these proof of concepts in the background, it was just, let’s see if we can automate this, and it was more of a show and tell rather than a this is what we want to do, it was, this is what we’ve been doing, come and have a look. And we would showcase some of our solutions, and that ended up selling itself in that way. And the fact that, especially from senior leadership and management, it was very much, okay, well, these deployments are going into production, what change control processes do you have? Yeah, okay, it’s fine, once it hits this point we get an email and then it gets approved. So once that part was out of the way, it really did sell itself, it didn’t take very much convincing, and the proof was in the pudding, in the sense that the ticket numbers for manual deployments and the requirement for manual deployments severely decreased, and the results just shone through of the benefit that it has to a business.

Yeah, what I’m seeing across a lot of different organizations is they incrementally just start living in this new cloud native, elastic way, find these superpowers, demonstrate what’s happening, but it’s not like overnight everything’s fixed, and you still have to deal with legacy partners, you still have to deal with a lot of things that are happening, but this agile or more elastic core of cloud native is really beneficial to helping evolve all the conversations with leadership, conversations with partners, all of that. Are you seeing benefits outside of your core team and leadership from this approach?

Yeah, so we’ve had quite a big focus on repetitive tasks for people like our development team. So an example of this would be, at the end of each race, on a Sunday night the race happens, we would back everything up, which is fairly expected, and our data teams and our development teams, they want access to this data as quick as they can, especially all the databases that contain the newest car data, lap data, timing data, telemetry, all that sort of stuff, because they want to be able to test with it. So in the old country DevOps world, that would be a traditional ticket into IT, the engineer would take that backup and restore it into the development environment, but it’s a process that takes a little while. So through DevOps we’ve managed to build a self-service type environment that allows developers and people to, once that backup’s there, they can log in, hit go, and it will just go and deploy into that environment without a need of someone in IT. So that’s just one of the things, that self-service benefits both departments, in the sense that the devs are unblocked, they can run with whatever they want to do, within reason of course, and the IT guys then don’t get these tickets building up and being poked on a Friday to do them for the next day. So it’s a bit of a mutualistic relationship in that sense, but again, that core DevOps is the real not-so-secret sauce that provides that.

So how do you make this, you mentioned how you’re enabling developers, there’s a certain part of this that’s an amount of governance you’re putting in, guardrails for developers to kind of exist. It’s a very common approach with the cloud, but you’re giving developers, and you mentioned self-service, self-service is a really important theme that we’re seeing. So how do you make this visible to developers so they know what’s possible, what’s out there? Is it documentation, is it observability? What do you do to help them see this very abstract landscape that exists?

So we kind of sit with them. We work very closely with them anyway, and they will come to us with their bugbears and say, is there a way that we can do this, for example, and we chat it out, how would you want it to work, where would you want it to go, and we take those requirements in and facilitate that. We might say, well, here we go, we’ve taken your requirements and this is what the output is, and see what they think. And it’s an informal chit chat on how, but good stimulating conversation comes out of it. It can be anything from a database restoration, it can be creating repositories that are consistent, there’s a variety of stuff.

Yeah, so it’s a very white glove kind of feedback loop with them. I’m guessing this is perpetual, this isn’t like a one-time sit down and then we’re done. It’s an ongoing way?

Yeah, it’s ongoing. We catch up with teams across the business almost weekly, just for, we sit back and chew the fat and just have a chat, or we talk, right, okay, we’re having a bit of a problem with this, can you guys do anything, is there anything you guys can do to make this quicker, easier, less reliance on you guys, and it comes out in that format.

Nice, I like it. I think we rely on a lot of automation where it makes sense, sometimes I feel like as enterprises we go a little too far with automation, where we need probably just some humans in there figuring this out and actually understanding how it works. So I think that really reflects that. And I think the other area I’m seeing it critical, being human alignment, is not every developer on the ground understands all of what’s needed from the 100 or 500,000-foot view when it comes to security, when it comes to regulation, and a lot of those things need to be packaged up and provided to them, back to those guardrails or that enablement. So what’s the regulatory landscape? You guys are a circus or a carnival moving around, I’m guessing you roll through different jurisdictions, you got things you got to think about when it comes to data storage and stuff like that.

Yeah, this is it. Our information security team is another team that we work incredibly closely with, because, as we all know, it’s easier to implement something going in than try and reverse engineer it when the newspaper gets rolled up and you get bonked on the head with it because you haven’t met certain compliance requirements. So I’d like to think we’re quite well versed in those security requirements, and especially the cloud is one thing, we run against AWS’s security framework and CIS benchmarks and all that sort of stuff, we build a lot of automation around that, so that if any future things come up, it just will go and remediate that, rather than finding out that the production system’s got something that we wouldn’t necessarily want.

Back at our traveling circus, that was a tricky one, because it works, don’t touch it type thing, and it’s a hard thing to put security guardrails around something that’s so bespoke and so delicate, in that sense, not delicate from a resiliency perspective, but we only have one of these. So this was a data center that would go to every single event, and without it there was no race. But yeah, those infosec guys, they run a tight ship and they do very well to keep it all under control, because as you can imagine, we deal with hundreds of different consumers, and that might be video consumers, data consumers, broadcast services, it’s not just what we see on the screen, there’s a load that happens in the background, like global customers and that sort of thing. So they do a good job to keep that locked down without affecting that operation.

Yeah, and I’m guessing the cloud’s giving you a lot more agility and flexibility but also control, and with those guardrails I’m guessing there’s governance in place to keep people from making changes right before a race, or pushing something bad on a Friday night right before a race, something like that.

Yeah, we have a really interesting change freeze, and it’s quite famous. So when we try to explain it to certain parties, it’s quite tricky, because we have, the race obviously happens on Sunday, now on Thursday we have a closed full system test, so the FIA will drive a car around the track for an hour, and it is filmed like an F1, it’s treated as an F1, what we class, so when we’re live on air on TV we call it a session, so if I refer to it as a session, that’s kind of what I mean. So we are live on air, we are all systems go, everything is in live production, so we treat this as an F1 session as it were, and everyone sits in place as if there were F1 cars going on the track. Now as soon as that starts, that marks the official change freeze of anything technical that can affect the broadcast. There’s a little bit of sway, our network teams and those more critical infrastructures, their real low-level infrastructure change freezes is the day before, because you don’t really want to be putting in stuff like router changes before a change freeze, so they step back and do it in case there’s any issues, they have time. So that marks the change freeze, now nothing can change from then until the end of the race.

However, there are always issues, so these things happen, we do have to do emergency changes. Everything is logged meticulously and discussed, and also what’s the plan, is it going to happen again in the future, you found something that’s not gone right, how are you going to fix it, how are you going to stop this from happening. And then once the race is over, the change freeze lifts. And it’s funny because we might have maintenance being done, and it can be on any part, not just internal, but maintenance by the connectivity providers, it might be in AWS, it could be here, there and everywhere, and from their perspective they’ll go, right, we’ll do it on Saturday at 1am or Sunday at 1am, because that’s out of hours, customers are Monday to Friday. Not quite luck with us, if for example we are racing in Japan, Sunday morning at 2am we might be in the middle of qualifying or live on air. So you kind of try and explain this and say, I know you’re doing maintenance, it’s out of hours, but it’s not out of hours for us. So we bring them on board with our change freeze quite often, especially if they’re partners of ours, and bring them into the overall change freeze within F1 itself. Because we always do all of our race systems, we do all our maintenance and patching on a Monday and Tuesday, those are our down times, because no matter where you are, it won’t affect the race. So it’s interesting navigating, took a while to adjust to navigate those obscure times.

Yeah, it’s much more, I hear a lot about regions and the cloud helps there, but being global, we all talk about we’re global businesses and we’re all kind of tech companies these days, but that’s an interesting mix across the board of time scheduling and critical nature. Because retail stores will have high sales during certain hours of the day, but yours is much more rolling and kind of different and unexpected, I’m guessing. So does the cloud and DevOps and APIs, this kind of state of being you feel like is making this all doable for y’all as a team and making it so you can deal with any challenge that comes your way?

Yeah, it does, and using best practice infrastructure as code, using stuff like GitOps, we know that we can recover elsewhere with quite a small recovery time objective. We’ve got it all defined, it would just be a case of, instead of pointing it to A, we just point it to B if there’s an issue in A, and give us a little bit and it will all come up and services resume. So it’s really how, and we test these and we do that war game style testing quite regularly, and it’s how it feels, it’s a confidence thing, because you’ve shown that if it all goes wrong with one side you can do it on the other side, and that’s great. And also if you start having issues with underlying infrastructure and stuff, you have that automation that can pick up those things almost as they happen, rather than, oh yeah, this happened five minutes ago or a minute ago, it can almost pick it up and it will do what it needs to do almost in the background, so by the time we get an alert, a chain of stuff has happened that we should already be in a better place by the time we’ve logged in. So through automation and DevOps, it just fills you with confidence more than anything.

Yeah, having a handle over your topology like that, or you mentioned infrastructure as code. I just don’t remember 20 years ago being able to have this level of control or the granularity of control over how things work. I mean, I could roll back a database, but I couldn’t roll back my whole infrastructure to the last known state or set it up anew. It’s a really new kind of reality that we live in, that seems almost like we’re living in the future.

Yeah, it really is, and again, coming to that management aspect, when you describe, are we doing infrastructure as code, and kind of see a bit of a blank look, they can piece together what it is but they don’t know the benefits of it, and you kind of say, well, this entire multi-tier system that runs this service that’s important, yeah, we can, within a couple of commands it will just spin up over there and it will just work. And it’s bizarre, like you said, it’s that futuristic way of working that 10, 20 years ago you wouldn’t have thought that you would be looking at 60 lines of code and you can move an entire system in the background. So it’s, again, can’t really put a price on that in a way.

Yeah, and I’ve heard quite a few signals from you that y’all are further along in your journey than some of the other enterprises I’ve talked to in healthcare, finance, and you mentioned, like, if it isn’t broken don’t fix it, there’s attitudes like that in finance that go 40, 50 years back, and so they’ve got a lot of technical debt to deal with. But just the way that you’ve talked about the benefits of DevOps, the benefits of cloud elasticity, the benefits of being able to move and have control of your topology shows that you guys have kind of gotten over the hump with it. There’s always challenges that we have to face, fires, issues, but it shows you just have a lot more control over the landscape than I think some of the conversations I’ve had. What interests you in all this, personally? What’s the thing that excites you about coming to work each day in this landscape? Because that’s the other aspect of this I see, is people seem to be happier in these states. So what keeps you excited?

I’d probably say the rate that it changes. It’s kind of almost a false state to have something perfect, and that’s quite nice in a way, because there’s a million and one ways to do things, and there’s always ways you can improve what you’ve got. You might have something that’s very good, very resilient, there’ll always be something that you can change, and especially with these cloud providers, they work so hard in the background rolling out new features, new services, new architectures and stuff. Where it’s so dynamic, you never sit stagnant, and that’s what I really enjoy about it, because a system that we put in a year ago, we might look at it and go, all right, let’s just strip it out, change the technology, try and innovate further, let’s focus on bringing the efficiencies in, we can bring the costs down, we can bring the resilience up. And it’s that dynamic side of things, I think, that excites me, that no days are the same. And me and my team, the stuff that comes through the front door, requests and bits and pieces, we obviously will deal with, and the race side of it we will deal with, but outside of those two we kind of work on what we want to work on. So if we decide, all right, let’s do a little POC on this, and just sit there and work on it, it just makes it fun. If you’re a tech head, then it’s good fun just having a good old tinker around, pretty much, and seeing what you can do with the tool set that you have.

And one thing I notice when I have all these conversations with different enterprises in different industries is people can’t see the benefits of being in an environment where there’s not always a fire or something crazy or all this legacy infrastructure operating that you have no idea how it works. You’re given more breathing room, you’re given more space to do these kind of prototypes and innovation, because you’re not always chasing the latest fire. But what you just described, in these other more chaotic environments where things have grown up wildly, organically, people want things to be done, they’re like, well, just tell me when we’re done with Kubernetes, tell me when we’re done with API first, they view things as a checkbox. And what you described would scare the hell out of them, like perpetual change. Is this just you and your personality, you like change, or do you think it’s just a state of doing business moving forward that all businesses are going to have to deal with, change at this space?

I think it’s a bit of both. I do like change, I do, but I also think that it is, as you said, in these historic, monolithic legacy systems that we’ll just leave it alone, eventually it’s got to change, it has to. And even not monolithic legacy systems, eventually they will change. So if you’re changing them regularly, then you’re keeping up with various trends, it’s not such a big step. We might, a good example, say you containerize an application, and you run it, and you decide you want to go a step further and run it on Kubernetes, it’s not such a jump. You’re not then taking a legacy application going, right, we’re going to run it on Kubernetes and we’re going to containerize it, it’s more of an incremental step rather than this huge hop. And I think that’s good, because although perpetual change is scary, saying we’re going to move this all the way into the latest and greatest is kind of a little bit more scary. So it’s the lesser evil, which one’s the lesser evil type thing.

Yeah, and that’s a lot less scary than some of the waterfall releases I’ve been on in my career, that were just scary because there were hundreds of features and changes and things incoming, and when something went wrong it went horribly wrong, versus today I’ll make little changes that are just, I’m not moving boulders, I’m just moving a handful of pebbles, here you go, and if something goes wrong it just doesn’t freak us out as much. So it sounds like, I’m going to add a third element to your world, the industry you’re in, Formula One, so things are going to move fast, and then there’s your personality, but then also I think it’s the culture that you’ve created through cloud, DevOps, APIs, this way of flexing your muscles in your knowledge and what you need to know to get the job done, and you guys are just confident in your abilities, it sounds like.

Yeah, and I think as well, quite an important starting from our experience within the cloud and DevOps team, is that don’t be afraid of what you don’t know. So when we ventured into the Kubernetes realm, we didn’t really have too much of an idea, it was just, let’s play around with it, let’s learn about it and see what the hype’s about, because we’d heard loads about it at the time, and we learned from people who had had experience in it and ended up paving our own route, and now we’re running production systems in it. So I think it’s certainly that, even if it’s something that’s complete alien, it’s still worth taking a look at, because it might provide you benefit somewhere.

Yeah, and it’s definitely building up that muscle, it’s like training for a marathon or a race, you’ve got to be doing this regularly, there’s a lot of training that goes behind this, but you have to be willing to learn new things, you have to be curious, have a certain amount of curiosity, but also be able to find information. This is one of my questions that I ask, I think I ask probably 75 percent of my guests, and I feel like I should replace it, but I keep hearing some really interesting answers so I’m going to keep asking: where do you get your new information, how do you personally learn new things, or your team, what’s the best source to access info?

Oh, that’s a good question. I always find it’s a bit left field, but I find YouTube’s great. If you’re curious about something and you don’t know that much about it, YouTube’s fantastic, because you can find very high level overviews to really deep diving into very specialist topics about that certain thing. So I find if I’m curious about something, I usually go to YouTube and find an overview of some sorts and a technical overview, so there’s a bit of tech thrown in there, so it’ll give me a bit of an understanding, and that’s how, that’s my first step into it really. And then if I want to really deep dive, it depends on the topic, but Google’s your friend, finding, there’s massive amounts of great content out there for learning, and it doesn’t necessarily require training courses or even payment, there’s a lot of things that you can get halfway there at the very least on the free content that’s available through Google and YouTube and stuff. And then once we kind of get to that point and go, yeah, actually this is something that we really want to get our teeth in and really go quite hard with this, then we might look at exploring other avenues for the entire team from more specialist training, but generally before that it’s just self-research.

Yeah, no, that’s important, and there’s a certain amount of curiosity, I think, that’s required, you’re going to want to learn these things, you got to be wanting to scratch, YouTube’s a big place, you got to be good at searching, finding what you need. And I think it’s a good way. I work real hard to produce a lot of, have my team produce a lot of video content that’s not just Postman-specific, we focus across the API lifecycle and in areas that aren’t directly API to try to educate people. And we have three formats, we have our 90-second, our 10-minute, and our 60-minute formats that we publish, to try to, because we know we’re all busy and we need, sometimes a two-minute video is all we’ve got time for on our lunch break.

Yeah. What’s innovation look like? You got Kubernetes in production, what’s the innovation landscape look like, is it AI/ML, is it serverless, is it service mesh, what’s the spectrum of things that interest your team?

Oh, a bit of everything. So at the moment Kubernetes is quite hot, we’re playing around with all kinds of various applications and technologies on that and integrating it with our GitOps framework, we’re also looking to implement that same framework on premise as well, so that we really do have that source of truth that sprawled into cloud environments, on-prem environments. So that’s exciting us. Serverless, we’ve always been a massive fan of serverless, so we use a lot of it for our automation on the platform, we just find it works, it’s reliable, and it’s one of those, once you do it, fire it and forget about it and it just does its thing. So we’re big advocates of serverless. In terms of innovation, I guess it’s certainly bringing more of the DevOps framework onto our broadcast sites, and that’s exciting us, because there’s so much scope for having everything on all layers, application layers, and also network infrastructure and that sort of thing. It’s all this scope, and we’re working with the various teams at the moment to really bring out that same framework that works so well for us in the cloud and bringing that down into the broadcast environments as well. So that’s got us quite excited at the moment.

I like to hear that, because what really excites me about APIs is, when I started this in 2010, it was, well, we have websites, now we have mobile apps, we need to standardize our APIs, and then we got devices, internet of things, but the network lately, I’m doing a lot of work with Cisco and Cloudflare and Akamai and others, like the programmability of our networks, like, as an old DNS, I always hated DNS back in the old days, I love DNS now because there’s all this enablement. So the network layer, there’s just so much opportunity for automation and just living applications. I would say the concept of what an application is is just blown out of the water now, you’re just applying all your digital resources and capabilities is what you’re doing.

Yeah, you really are, you almost create an abstract idea of an application in that sense, aren’t you, because the application isn’t the application as we used to know and love, it will act in the same way as, like you said, that network infrastructure and having that layer above it, what kind of sits beneath doesn’t really matter, it’s just an abstract idea, and controlled in the same way, you deploy in the same way, and it’s interesting, it’s come very far from what it used to be. You had those vertical silos, that was an app and a network was a network switch, and that was that.

Yeah, what’s changed for you all during the COVID times here, has it evolved how you approach what you do, what hasn’t changed?

I think during the COVID period, the traveling circus was essentially split in two. So when COVID kicked off, we had a very small bit of breathing space, and there was a lot of conversations, can we go and race, between us and the local authorities at the place we were going to next, and essentially the senior leadership said that at the moment, the less people we can send the better, the less equipment we can send the better. So it was always a multi-year strategy for Formula One to do remote production, it was always discussed, because we have a goal by 2030 to be net zero carbon in terms of our sustainability goals, so it was always going to form part of it. Now this was a multi-year thing, a multi-year plan, and we ended up executing it in seven weeks. It was an all hands on deck idea, it was something that we’d never done before, and we had the whole engineering division in all their different silos and the production teams, and we split in half and stretched it across one link.

So we ended up having what was called the broadcast center, which was this singular unit, singular data center that traveled, ended up getting split into two entities, and that was known as the RTC, which is the remote technical center, which is what we run back in the UK, and the ETC, which is the event technical center, which hosts a subset of our real latency and critical systems that are trackside in case we have connectivity issues, we can still provide those services, we can still have a race. So it took the culture side of things and tipped it upside down, and also the technology as well, tipped that upside down, because systems that were traditionally trackside were now based in the UK, and there was a lot of adoption that had to take place. Everything from our timing services, which are quite latency critical, to the team of people that do the live color correction on the cameras that are trackside, that gets done from here as well. So you go somewhere like Japan or Australia, and you’re color correcting a camera and you’re having, say, 130 milliseconds on your action before it’s actioned, before you see the result, and they were very used to it being sub-milliseconds because it was actually at the event, it was all fired.

So everything changed, it really did, and what was nice is that we got a race out, that first race it was a bit nerve-wracking for everyone involved, we tested and tested it, but we got through it, and then it was kind of, right, what’s the next iteration of it, what services can we do, do we need the services at the RTC, can we use the cloud for remote production, and it stimulated so many ideas. So for 2020, it was a real year of innovation, we had more years and years worth of innovation condensed into six months, and it was a busy time, but it was good, and we managed to reduce the amount of traveling kit that went to the race, we reduced by 34 percent. So that’s a lot of kit that we’ve saved, and it’s now back in Kent in the UK, and that’s where we do a lot of our remote broadcast from. So yeah, it was an interesting time.

Wow, yeah, what a journey, I mean, just your overall journey as a company, but during this time, it sounds like, and I hate saying coming out of COVID because it’s been such a hard time on a human level for so many folks, but you’re going to come out of it better on the other side, aside from the human, but for the human side and human causes, organizationally you’re much more agile, nimble, flexible, able to respond to whatever is going to happen.

Yeah, this is exactly it, it was a real testament of just, this is what it’s for, 15 years, but everyone’s heads together and we’ve managed to achieve this, and it’s been put into a proper facility, and the technologies that were used, they’re just iterating, and we’ve taken it that step further, and we’re now doing some dabbling in cloud-based production, because that seems to be the next step of the journey. There’s a few organizations that are pushing cloud-based production, and it looks fantastic, so that’s kind of the next cycle of our reduction, is to see what we can do in that space, and that’s all very exciting.

Well, I look forward to your journey, hearing more about it in the future, because I think y’all definitely built up some muscles and some processes and approach that’s pretty compelling to learn about. I appreciate you coming by today and sharing this with me.

No, it’s cool, thank you for inviting me.

Wow, thank you, and enjoy future races, I wish you all the best and luck in your API and cloud and DevOps journey, I think the Ops transformation is going to be continuing to be a very interesting landscape, and I look forward to tuning in, thanks for sharing.

Wonderful, thanks for having me again.

All right, enjoy your day. Thanks again to Ryan for stopping by. For more on Ryan you can find him on LinkedIn, and you can learn more about Formula One at formula1.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers, thank you.