Octopus Deploy’s Steve Fenton on GitOps Trends and the Future of Continuous Delivery

Hey everyone, it's Alan Shimmel. Welcome back here to Tech Drunk tv. I'm really happy to have this next gentleman on with us right now.

He's been on Tech Drunk TV before, but usually in part of his role with the CD Foundation, the Continuous Delivery Foundation, he's here today in his, his full-time gig, right, which is Principal DevX researcher at Octopus Deploy. Let me introduce you to Steve Fenton. Hey, Steve, how are you?

I'm fine. Thanks very much, Alan. How are you?

Good. It's good to have you on. Appreciate it, Steve.

Um, I mentioned your Principal DevX researcher at Octopus Deploy, but let's, let's unpack that a little bit. What exactly does Principal DevX researcher mean there, and how did you wind up in that role? Yeah, so it's a, an interesting story.

Um, I've been in software for a couple of decades, um, and when I came to Octopus Deploy, I just, um, had so much curiosity for what was going on. I couldn't leave things alone. I was like, every time I found some data somewhere, I wanted to find out more about it and understand what was going on.

Um, and I've been kind of participating with the CD Foundation when they've been doing their research efforts. Um, and I, uh, participate in the Dora community around that state of DevOps research, and I just kind of can't get enough data. Um, and so I've kind of ended up building that in as part of the role that I do here is that I'm really curious about software delivery and culture.

Um, and this is a way for me to kind of scratch the itch and find out more about it, especially things, um, you know, uh, like get ops and, um, infrastructure as code and loads of things that I didn't actually get to, um, get my hands on back when I was developing so much. Um, so yeah, I'm really interested in these, these newer ways of working. Absolutely.

I absolutely. Um, you mentioned Dr. Pus Deloy a few times, Steve, I, I think most of our audience, of course, is familiar with Octopus Deploy, also familiar with codefresh, right?

The, uh, one of the, uh, companies that merged into Octopus Deploy, and of course, they're the people behind Argo GI Ops and, and all of that. So, um, but for those who maybe aren't, give, give us kind of the, the overview of the, of Octopus Deploy. Yeah.

So Octopus Deploy focuses, um, in on the, uh, continuous delivery part of software. So there's loads of tools out there that will help you, um, build your code and create artifacts. But when it comes to doing deployments, especially at really large scale, um, there's not as many tools in that space.

So that's really what we're interested in, is solving the deployment problem, day two operations. Um, we're kind of in that space, so where people are trying to do unusual things like deploy software to, you know, hospitals and retail stores and lots of cloud, um, infrastructure and places like that. Excellent, excellent.

Um, Steve, just real quick, the website for Octopus Deploy? Yep. com.

It's great, great, great, uh, url, isn't it? Yeah, I know. Something about great URLs.

Okay. So Steve, you know, let's turn to our topic of discussion. Now that we've gotten all that out of the way, uh, you guys recently released the GI ups, the state of GI UPS report.

Yeah. So was eagerly anticipated, uh, report, talk to us about it. Yeah, so we were really lucky.

Um, we went out to the community, asked them to share the survey that we had asked them to fill it in, and, um, 660 people came back and gave us answers, which was really amazing. 'cause that meant that we could cut up the data in lots of different ways and still have nice sample sizes for everything. Um, and what we wanted to do was find out, we knew, um, open GI Ops has existed for a while, which is A-C-N-C-F project that defines what GI Ops is supposed to look like.

Um, and one of the questions we had was, is that correct? Are those the things that are needed for, um, for GI Ops to be successful? Um, so we were asking people what practices they were applying and what benefits they were getting from it, and we started to build a picture of what do you need to put into that Git ops process in order to get the benefits?

So things like increased security and easier compliance and simpler audits and less production access. All of those kinds of benefits, the things that we think GI UPS are gonna get us, we wanted to say, if you do this, will you get those things? Um, so yeah, we, we couldn't have done it without all of those people giving us answers, and I couldn't have done it without all of the GitHubs experts who I could then share that with and say, why does this graph look like this?

So, yeah, there's lots and lots and lots of real GitHubs experts that have helped, you know, people, uh, like Dan Garfield, Costas Caponi, and, and um, uh, people from organizations like Cross who, uh, they're doing this every day, so they really know this stuff, so, Absolutely. Yeah. And of course, Dan has been on our show many, many times over the years.

Um, so there's always sort of at least three key findings in these types of reports. Steve, what are the key findings here? Yeah, so, um, one of them is, um, in terms of the future of gis, um, most of the people that are using it are excited and wanna do it more.

So, um, I think there were, uh, out of all of the people that we spoke to, only 7% were thinking of reducing or stopping GI ops. Everyone else is either maintaining or increasing their, their GI ops usage. So, um, if you throw away all of the data analysis and just think if GitHubs is, is working, people want to keep doing it, that's a strong signal that people are getting something from it.

Um, which is, which is kind of like a really important thing. Um, we also dug into that 7%, um, 'cause that's what I find, this is where my curiosity comes in. It's like, oh, 7% don't wanna do get Ops.

What do they have in common? Um, that's different to all of those other people that wanna keep doing it. Um, and very often they are missing the reconciliation loop, which is this crucial part of get ops where, um, you know, your state keeps on getting brought back into the correct target state when it gets, when there's drift.

And people who aren't, aren't doing that Reconciliation Loop, are much more likely to be in that group saying, actually, we might stop using GI Ops because we're not getting the benefits from it. So that's probably one of the crucial findings is, uh, don't give up until you've tried, um, using the reconciliation loop. Yeah.

That, that, that is a, that's good advice right there. Um, you know, Steve, I recently in, uh, New York for, uh, the in-Person Day for Platform Con platform engineering is, you know, a lot of people gathering around that title. It's, it's something that's not necessary.

The title's new, but what, what underneath it is not. Um, I'm wondering, and, and they had some sessions there about GI ups, you know, as part of working with IDPs, working obviously with co platforms. Yep.

Wondering if anything in the report sort of lent itself to that. Yeah, so, uh, I'll, I'll try and subtly pull up the numbers in the background. Uh, whilst I, whilst I answered this, we, uh, we did find out what roles, um, people had, um, and platform engineers are in the top three roles using GI ops really.

So that's What I, that's kind what they were saying there too. So that, that, that's correlation for me. Yeah.

And I think it makes sense because, uh, when you think of how GI Ops works, we're using tools that developers already like to use. We're using version control and we're using configuration files that hopefully are human readable and they can make sense of them. So, I mean, I, I feel this, when I was doing development, I, um, I had to log into cloud portals to, to do anything when it came to infrastructure.

And trying to remember where everything is inside of a cloud portal is actually quite painful, especially because the portals then get refreshed and all of that memory. I remember when Azure Blades changed from being like this horizontal thing to being a more modern look and suddenly I couldn't find anything anymore. Um, so I think, uh, platform teams will want to give, um, GitHubs as a tool for those developers as a way of just removing the need to, um, log into three different cloud providers portals and maybe, um, find IP addresses and do remote commands, all of that headache.

So whenever a developer needs to do something, there's like one place and it's the place they're already using. So I think that's the very sensible move from platform engineers to look at this as an option. Absolutely.

Absolutely. Um, what other key findings or maybe even something that surprised you In the report? Yeah, a big surprise for me was, um, the Open GI ops principles lean very heavily on, um, the configuration should be declarative.

So instead of being like a sequence of steps that result in, um, the state that you want to get to, you actually define that as your configuration. You say, this is the end state, like the target for what we want. Um, and the idea behind that is it serves as like a document of what the, the state should be.

Um, but it also means that a new kind of tool can kind of be brought in that will automatically reconcile that for you, um, as opposed to you having to have no a baseline and then kind of operate against a baseline and get it to a state. Um, but we actually found a very large number of people aren't yet doing that. Um, they're still using, uh, kind of step by step imperative, uh, configuration.

So they'll be missing out on some of the benefits that you get from having that document. 'cause it's, it's executable. You, you use it to bring your, you know, maybe it's your Kubernetes cluster and the applications running on it.

You use it to get those in the right state. Um, but having that document means that you can tell what it's supposed to look like, um, even if you're just reading it. Whereas with imperative, you have to build the picture in your head as you read it line by line.

So we expected more people to be doing declarative config, um, than, than actually were. So, um, and that changes by role quite a lot as well. So again, um, when we were looking at roles, we found that um, DevOps folks, architects platform engineers are more likely to be doing declarative config, but then system and, um, system engineers and site reliability engineers were slightly less likely to doing declarative config.

So very interesting. There's more to explore there. I don't have, I don't have all data.

Yeah. Because understand that there's such a, the connection between those roles, you would think there wouldn't be a divide like that, but more, definitely more to discover there. Lemme ask you a question, Steve.

You mentioned twice the Linux Foundation's GI Up, GI ups. It's not GI UPS project, it's committee or action committee Something. Yeah, that's right.

They've got, they've got a, um, there's a project called Open GI ups, which Right. Um, it has like these four principles, which they kind of all got together to decide what GitHubs should look like. Um, and that's been a really useful guiding, like this is what GitHubs means and it's, it's helping to stop some of that semantic diffusion that we often get around a term.

It's like, there's four things that you can say, if it looks like this, it's probably GitHubs. Yeah. Steve, what's the connection between that and Argo?

So, um, a a lot of the Argo folks were involved in forming those principles, but I, I, so I believe Some of the Flux folks were as well. So it was like a big collaborative effort. Um, that's good.

And bringing it together. And, and that's the beauty of the Linux Foundation, right? It it does, it brings what may be competitors into coopetition and that's, uh, and you know that rising tide lifts all boats and then you go from there.

Yeah. That's super important. Yep.

com, but where can people get this state of GI ops report? So, um, we have it linked from our website. com/publications.

Okay. Uh, you'll, you'll be able to download it from there. And I'm also working, um, on some interactive diagrams that will help folks understand some of the really deep insights we got.

I created a diagram called a strength relationship diagram, and it maps each individual practice to the different outcomes, but it can be a little bit overwhelming 'cause there's lines everywhere. So I'm creating some interactive versions, which I'll be publishing soon that will make it easier for people to explore that data. So watch this space.

Absolutely. Steve, thank you so much. I appreciate it.

Um, keep up the great work, both you as well as our friends at Octopus Deploy and, and some of the folks you mentioned. I hope maybe to see you, uh, CubeCon in Atlanta. Well, it's still a few months off, but I know we're already planning on being there.

I assume the the octopus deploy folks are as well. Yeah, we'll have a, we'll have a whole contingent attending CubeCon. We had a great time in Europe at CubeCon and I'm sure the, uh, it was great.

Won be amazing tea. Yes, it was. Yes, it will be.

All right. Steve Fenton, principal Dev DevX researcher at Octopus Octopus deploy all about the state of GI Ops report here on Text Drunk tv. Check it out.

We'll, back in a moment.