Modernizing DevOps Pipelines, Open Source and Supply Chain Security – DevOps Chats Podcast EP 3

Welcome to DevOps Chats, the industry leading podcast for DevOps, digital transformation, cloud native, and cybersecurity. If it's happening, it's happening on DevOps chats. Hey everyone.

I'm Alan Shimel. And I'm Mitchell Ashley. And you're listening to DevOps Chats?

DevOps Chats. Yeah. Yeah.

Hey, Mitchell, we, we gotta work on that synchronization. I don't think we'd make the Olympics, uh, synchronized swimming team with that, but there's a little bit too much pause, but we'll get it down. We'll get it down.

We just saying, you know, still secure after all these years and other names and, but we'll get, we'll get it. DevOps. I'm never quite sure what name to say to tell you the truth.

That's right. She's getting old. They didn't tell you about this stuff when I was younger.

That's right. Anyway, so, Mitchell, we're back. We're back in the swing of things here, hosting both DevOps chats and Security Boulevards chats, and they are available as audio and video podcast on your podcast platform of choice.

Mm-Hmm. As well as on, uh, text Drunk TV or tv. I believe it's on there as well.

Um, and I'm, I'm having a lot of fun doing it, Mitch. It's easy to fall back, you know, what's it back in the saddle again? It, it is, and, well, first I love doing this with you.

When we started, you know, back Mm-Hmm. 15, 20 years ago. And I was listening to, we did it 20 years ago, Mitch.

Yeah. I was trying to give us a little room there. Alright.

Um, but I was listening to the first, first one that we just recorded a couple weeks ago and just the audio. And I just had this sort of like, reminiscence of like listening to us on podcasts before, like Yeah. And just hearing our voices and, and, and instead of seeing each other and hearing voices, there's something about the richness of the voice of the person, you know?

Yeah. Just hearing you and not seeing you, but just hearing you, it was kind of, I don't know if I would say it's more intimate or more, you know, connected. Yeah.

Maybe I'm just being nostalgic, but I really like, lemme ask you, do you think our voices have cha I mean, certainly our looks have changed from 20 years ago, but I feel like my voice is similar still. I know. Yeah.

I, I think it is. I'm, I think mine is. Yeah.

But we, you know, we've been talking all this time, so who the heck knows. Yeah. Anyway, it's, it's great to be on.

Mitch, let's jump into, 'cause we got a bunch of stuff to cover for DevOps chat this week. com Mm-Hmm. Right.

Some of the hot topics, hot stories there. com was the practicalities of open sourcing Mm-Hmm. And it was a contributed article.

Um, I'm just trying to remember. It's Ashwin Rag Mo Ashwin Ragga Mohan Ganesh. Right.

Mm-Hmm. Yep. And, and the gist of the article was kind of a how to and, and gotchas and things to be aware of if you wanna open source some software you wrote Mm-Hmm.

You know, and you know, Mitch, every developer, well every developer wants to develop some, have visions of developing something that they sell, you know Right. Once and sell millions of times and become wealthy beyond their dreams. Mm-Hmm.

Others think of writing something and then they're gonna open source it in some way, change the world, Uhhuh, um, you know, the next Linux, the next open telemetry. Exactly. The next what have you.

But what was interesting in this article is these guys took a no holds barred approach. You know, the grass isn't always greener. No.

And, uh, it was pretty down to earth practical. Right? Yeah.

I mean, it wasn't, uh, visions of sugar plums dancing in your head, being the next Linus, you know Mm-Hmm. Kind of person. They had a lot of good, a lot of good recommendations.

And they talked about the, i I, you know, maybe it's the, you know, the fear of making or faking it about, okay, do I really want to contribute to open source? People are gonna find out how good a developer I am. Maybe I'm not as good as I think.

And mm-Hmm. Just issues like that as well as, you know, contributing to open source projects. And it may be, well, the, the nuts and bolts of, of, you know, starting an open source project Mm-Hmm.

Maintaining an open source project, you know, and, and I hope in reading that article, people would have a newfound appreciation of, for maintainers of open source projects because it's a labor of love. It is a labor of love. Yeah.

It's not a, in most cases it's not a paying position. Uh, it's a thankless job in some ways, and it's a lot of work. All those, a lot of work.

People you're responding to about bugs in your software at work. Well, guess what? Everybody across the world might be emailing you or messaging you about or cursing you open source.

Right. Yeah. Um, you know what else though?

It made me think when I was reading that article, Mitch, something that happened in both of our careers was, you know, you, you, you have the best of intentions. You're gonna open source this software and you hope you build a community around it. And, and Wow.

Eureka you do. It's a tremendous community. And then you find people who are basically building off of your contribution of your contributed source code.

Mm-Hmm. To build very successful business models Mm-Hmm. And companies.

And you say to yourself, that's not right. I, they're building off of mine. I wanna pull my software out of open source.

Right. We saw Rena Dresen and Ron Mm-Hmm. Right at Tenable Ron Gula, do this guess had around 2005, 2006, something like that.

Yeah. With Nessus Mm-Hmm. Um, and they just, they just stopped developing open an open version.

They still had a free version you could use, but it wasn't open anymore. And of course, there was the, the fork of open vase. Mm-Hmm.

Right. If you remember the, it was like a fork of nessus that it, it got some momentum. Mm-Hmm.

We recently saw this with, um, oh, hat, what's the big thing? Red hat and Tofu. Tofu.

What? No, what's the tofu? Excuse me.

Yeah. Uh, what did Tofu Fork, do you remember? Wasn't it Hashi?

One of the Hashi Terraform. Lemme look it up. Yeah.

No, it was Hashi's either Tar Terraform, maybe one of them. I'm trying to remember. I was getting confused.

I don't see it right off the bat. Um, yeah, open tofu, let's see, what was it? Oh, HashiCorp, you're right.

Yeah. Yeah. It is HashiCorp and I think it wasn't it Hashi's Terraform Product Project.

Terra Project. That was Terra. Yep.

Exactly. What It's Terraform. Sorry, sorry, I just hit a blank on that.

Yeah, no, HASI changed the licensing and I, look, I happen to believe that the last 10 years were a golden age for open source Mm-Hmm. Under this foundational kind of model where you had these foundations. Mm-Hmm.

But I think a lot of companies who contributed with the best of intentions, open source, started to realize it. It's, it's a tough business model to be uber successful in, and in many ways maybe they wish they had done it differently, and so they're changing their model. And then of course, you know, the, this is still, this Nessus 2006, again, you get some people in the community who, who go the other way and say, well, this my prerogative in open source.

I'll just fork it. You know? It, it's interesting because what I, what I saw happen just in 2023 is really two bifurcated strategies.

One is the, let's bring open source back and make it kind of close source, but we'll have an open source, something like it, right. Or like the, the Red Hats, et cetera. HashiCorp, the, at the other end of the spectrum there were smaller, more startup companies.

We're adopting a model of everything we do is open source. Everything we build into the software goes into the open source version, and we'll make our money by running it in a, like a hosted version of it. And, you know, as opposed to with a support model like we did with Red Hat in the early days, this was the, we'll operate it and run it for you and make it easy.

And that was their business model. So now I don't, there hasn't been somebody as big as Red Hat or whatever, HashiCorp that's done that, I don't think. But it was interesting that comp, that's the, we believe in open source.

There's a community of people who, you know, are very firm on their beliefs about it and will never use something commercial if there's an open source option available. Um, but yeah, I think people have gotten more real realistic about our investors are expecting us to make more money. I'm tired of justifying why we're doing this open source version.

Right. But I can't prove, demonstrate how much money, you know, maybe they'll prove how much it was worth when they stop it, but who knows? I mean, you know, the underlying issue is you gotta explain to your board why 97% of the people who use the software aren't paying for it.

Yeah. That, that's, yeah. They call that theft in other organizations, not saying it is here.

Yeah. But, you know, that's how a business person's gonna be like. But that's the model, you know, that's built into the model where it is.

You get 4% of people who pay for it. You're a success. It's look Mm-Hmm.

You're a Hall of Famer in baseball. If you get on, you get a Bates head three outta 10 ba at bats. Yeah.

Batting 200, you know, it's the same thing. Yeah. Batting 300 is Hall of Fame material.

Same thing in Open source. Anyway, it's a great article. People should check it out.

com, uh, article has more of a security bent to it mentioned, I was almost hesitant to put it on here and put it on Security Boulevard chats as well. But it, it's around a survey, um, a survey that was done. Let me just make sure I get this right.

S cyber attacks aimed at software supply chains are pervasive. And there's an article by Mike, uh, Vard. Mm-Hmm.

Um, look, I don't think the headline is radical. I think we all kind of knew this, um, software supply chain security is probably one of the hottest areas in security, and it has a particular DevOps, but because it is about attacking pipeline Mm-Hmm. Right.

And, and, and, and inherent in that CICD process, um, it just amazes me though, how quickly it's shot up. The charts here, the billboard top 100, right? Where the White House is weighing in and the federal government is weighing in and the EU is weighing in and, you know, uh, DevOps companies that now call themselves DevSecOps companies, of course, are kind of really building around this, as are some of the traditional AppSec vendors, right?

Mm-Hmm. Veracode all over this check marks is all over it. Um, software, supply chain, security, SBOs, hot, hot stuff.

You know, it's a confluence of multiple things happening over a period of time. Going back to SolarWinds, of course, but also Log four GA demonstrated how pervasive you don't have to attack your software. If I can attack something else that Yep.

A wide, you know, large number of people use, that's a great way to, you know, compromise and get into where you shouldn't be. Um, and it, and it's interesting because this is sort of a, the onion layered onion problem. There's like all security.

There's sort of, I would say the easier things to do at the edges. Like, let's make sure you're getting your images from, uh, a known source. You're controlling how software like images, uh, whether it's container, container image or, or open source software, how that gets into your dev process.

And there's basic things like, uh, security, man, se, secrets management, excuse me. Um, and making sure that's not in your code. And there's a lot of things like that that you could do.

But as you dig down into it, and, and, uh, I did a project with Red Hat last year around securing the CICD pipeline and getting into really taking each step of that, containerizing it, and then securing the access to that. So if someone got in the middle of your, kind of your dev, um, all the tool chains that you're using as part of your CSED workflow, they couldn't break in at one point and then get compromised the whole thing. It's how do you kind of secure each chain of the link so you can take it pretty far?

Um, and it's not super complicated, but it's more than just using good, secure images. I, I don't disagree at all. Don't disagree at all.

It's, um, I, I think, look, there's gonna be a lot of issues that pop up around this, right? The de the dependency issues that you're talking about. Mm-Hmm.

Is one. And the, and dependencies go forward and backwards too, right? So not just where I've used this software that I now have to go update, but software that was, or components that were in my software that depended on other things that got updated, I now have to make sure it updates through too.

And then that doesn't even count the APIs involved in and everything else. Yeah. So it, it's a, it's a big thing and it's not, it may not be new to most of our audience, but it's, it's certainly look software, supply chain security, I think every development team, and I can't say every, but most development teams have now taken this as, yeah, we have to really work on this and focus on it.

We can't just let it go. Absolutely. Be the next one with the problem.

So they're taking it serious as, which is great. Good for them. Well, they're gonna be forced to.

Mm-Hmm. Next up, Mitch, I wanted to mention an interview that Mike Azar did with, uh, Solomon Hikes, right? I think most of our audience is probably familiar with the name.

Mm-Hmm. Solomon Hikes. Solomon, of course, was the founder.

Yeah. CTO of Docker, Inc. And Guy behind kind of the Docker container, which really, you knows, I mean, that was the birth of Cloud native in many ways, right?

Mm-Hmm. Um, just a whole different way of looking at stuff and enabled, um, microservice based architectures enabled the cloud really es from virtual machines to containers to Yeah. Well, we moved from infrastructure as a service to platform as a service, right?

Yeah, exactly. So, of course, Solomon left, uh, Docker, I don't know, Mitch, years ago, or probably three to five years ago. I remember, and I hadn't really heard much from him recently, but I guess I must have put a little PR campaign in.

'cause I, I saw it pop up on a few sites in addition to Mike's video interview, which is available on tech drunk tv. Um, Solomon's new company is called Dagger. Mm-Hmm.

And, you know, segwaying off the last kind of segment we talked about software supply chain, he said, you know, he, in doing their research on this, the biggest issue they were hearing from developers was the supply chain issue, right. The pipeline issue. Mm-Hmm.

How do I do my pipelines securely? How do I do 'em efficiently? Um, you know, as fast as possible.

And so that's what dagger's about. And you know, look, I'm of two minds. It's, it's hard to catch lightning in a bottle twice.

Right. Recreating a success is no small challenge. Yes.

And I, you know, Solomon certainly captured some lightning in the bottle with Docker. Mm-Hmm. Doesn't necessarily mean it'll happen with Dagger, but he, he certainly seems to understand the mind of the developer Mm-Hmm.

Or the challenges that developers face. And, you know, I, I don't disagree with what he's saying that this is a, a problem. Well, it, it definitely is.

And, and, you know, all the experience that comes with having done Docker and gone through the successes and the challenges that that entails, you know, hugely valuable. You and I also know it's all about timing. I mean, there's, that's the part you don't necessarily control.

It's Docker was the right thing at the right time. We didn't know we needed, but it lit, it caught fire. And, you know, whether Dagger does that or not, we wish 'em the best and hope it does and does successfully.

Um, but that's the one thing I remember when I interviewed for one of the startup jobs I had, and I asked a very successful CEO startup, CEO. And he said it was, it was timing. It really was.

I mean, I made that went from a nice exit to an amazing exit. So, you know, that being aside, I think the other thing about Dagger that was really interesting is kind of solving the problem or working on the problem of the complexities of A-C-I-C-D pipeline. That you're trying to deliver software or build software in multiple environments.

You know, here's my Python environment, here's my node environment. Here's my, uh, software that I'm going putting into a secure DOD or Fed or FIPs kind of certification. Here's, I'm testing, uh, across these different variations of, of configurations from old code to new code.

I'm running a bespoke version of every of my application one time every time for a customer building a pipeline to do all that. And then say, now let's add this thing to, we're gonna do some ai, let's add that to all 15 or 20 or 50 configurations. That's, that's a lot of work.

And I think that's part of what he's doing with Dagger is how to automate that so that you're not writing just scripts and you gotta go change all that stuff by hand. I, I agree. Look, like I said, I, I under, I don't disagree with the problem.

Mm-Hmm. He's uncovered here. And I hope, I hope he comes up with a great solution for it.

I wish him the best. We'll, we'll keep a close eye on it. Um, I think that's all I've got in.

I think, did you wanna talk about code reviews? Was that one you wanted to hit on too? Oh yeah.

There was a, there was a great little, I think it's a great article for the DevOps aficionados out there. Right. The real hardcore DevOps people.

And, um, this was a little article, Mitch, why don't you wanna go over it? Go ahead. Yeah.

Remember talking, talking about the benefits, the purposes of code reviews. And if our developers of course know, we'll know exactly what that is. Uh, that's one of the things that I enjoyed most and learned the most in, in leading a development team was doing code reviews.

And not that I'm, I'm a better coder than anyone else on the team. I'm definitely not. They're, they're more efficient in, in experienced than I am.

But when you walk through the logic of something, and here's how I built it and here's how this works and how this function that calls that, and you, you see how things are put together in the software, in the architecture and the kind of design of it. And there's review for security and there's review for, you know, are you doing things well in the right way and, and best coding practices. Those are all good.

The thing I found the most valuable was, oh, you know what? We have a library that does that. So use that instead of writing your code or, you know, there's a microservice that we just enhanced that, you know, while we're all doing, running in 50 different directions, you wouldn't have known.

So there, there's economies that you get out of it of learning from each other or maybe experience levels. I've got a great, you know, algorithm for that I can show you. There's a really cool pattern of how to do that.

That knowledge learning and knowledge sharing I think is one of the biggest benefits. Um, I don't know if he exactly mentioned that in the article. Um, the other, his other point was keep it small.

You know, keep it simple, stupid, kind of the kiss principle, um, which trying to do a code review on a big application or a lot of sun, you know, you get tired about an hour, two hours into this, you're ready to pack it up and like, okay, the as looks good, let's move on folks. Yeah. So left time, take your time.

You don't have to blow your, well, it was, you know, how do you eat the elephant one spoonful at a time? Mm-Hmm. And to me, you know, so this, that's agile.

That's part of the agile process, right? To take this in bite-sized chunks Mm-Hmm. That you can digest easily.

You can work on easily without burning out. But, and then secondly, you know, that idea of code review with a team and com building rapport and comradery in a common sense is, is, you know, key to the culture you wanna foster Mm-Hmm. Whether it's DevOps or Agile or ITSM even, right?

Mm-Hmm. Building team in your, it, you know, building the team in your IT team. Mm-Hmm.

Is, is an important, important aspect that I think sometimes gets short shrift. 'cause we tend to focus on tools. Yeah, absolutely.

And this, this article didn't, it, it had a lot of recommendations, best practices, some really good thoughts. I would definitely recommend, you know, if you're doing development, do code reviews, check it out. It's a good, it's a good article.

Absolutely. It was title to Proving Efficiency with smaller code reviews is the name. Yep.

com. Mitch, I want you to bring up another subject. Okay.

We might as well announce it here. 'cause word's getting out and I don't want anyone to steal our, uh, headlines. Right.

So, you know, I think we've all been hearing over the last year, uh, DevOps is getting old. DevOps isn't cool. DevOps is not, they're not working as well as we thought.

Still relevant is. Yeah. It's platform engineering and SLOs and SREs and, and everything else.

Irrelevant and Mm-Hmm. You know, I feel like I'm watching the cable news channels 24 7, you know, but when, but when you go do your fact finding that search terms around DevOps are more popular than ever. Absolutely.

Yeah. com, which, you know, truth be told, used to be significantly behind Security Boulevard. Mm-Hmm.

Views. Mm-Hmm. Pages and everything has actually been growing much faster.

Yep. And is in fact just about caught up the data to the Boulevard site. Yeah.

Yeah. And so that shows to me DevOps is alive and kicking. And you know, I, I think I mentioned, I've mentioned it to you, Mitch, I might have mentioned it on our show or on Techstrong tv.

I had a conversation around this with a lot of DevOps leaders. Mm-Hmm. One of whom Jody Bonsai.

Jody is of course the founder of, uh, was the founder of AppDynamics. Mm-Hmm. CEO there he was.

ai harness DO io. And Jody said DevOps isn't going anyway anywhere. It's bigger than ever.

But what we're seeing is the evolution of the next phase of DevOps where instead of having cobbled together tools, we have coherent end-to-end platforms. Mm-Hmm. Where the cultural arguments and benefits that DevOps brings is sort of all ready baked in when they're accepted.

It's not like an aha eureka moment that you can have a cross-functional team that actually works together. That Agile is not going anywhere in spite of what some people say. Right.

com dammit damnit and, uh, you know, that's dammit and get op, but I need my cigar. But that's part of our mission, right? That's part our mission to, to kind of spread the good news of DevOps.

And, and that's what we wanna do. And as part of that, I know you are, well you, you are the leader at Techstrong Research. You are leading a new, uh, research projects.

Is it DevOps Next Mm-Hmm. DevOps next. Exactly.

And we're going to look at, you know, what's new and coming in DevOps, what are people hearing? And so I'd like to use the podcast as a way, number one, there's gonna be a lot of surveys or some surveys coming out of this that we'd love for you to participate in. Mm-Hmm.

But number two, if, if you have the time and, and so inclined, if you wouldn't mind being interviewed by Mitchell and his team as to what your views and uses of DevOps are, you know, we'd love to have that kind of data that we can pull into the report. We would Absolutely. I mean, it's one thing to take a survey and we, we do a lot of that and collect data and that's good for the analysis comparative kind of things.

It's another two sort of get the, um, you know, feet on the street, what's really, what are people really doing? What have they learned, what are the challenges? 'cause you can also validate some of the data, but more importantly you could put some real specifics around it.

And I think that will be one of the com more, one of the most compelling things about our report. It isn't just gonna be cold hard facts. Right.

Those will be their analysis of that. But let's really dig into where people are when we say scaling DevOps is a challenge. Okay.

Let's get into the details of why that is and maybe some of that'll appear in the report or on our podcast and we'll share those things. So we'd love to hear from folks if you wanna reach out. Yeah.

com. Um, and I, I anticipate this is, uh, second quarter, uh, yeah. When this will come out, you know, was we put some more kind of meat on the bones.

We'll know for sure. But, um, we wanna hear from everybody that would like to share with us. And there there's gonna be a lot of ancillary activities around DevOps Next Mm-Hmm mm-Hmm.

Including this whole campaign called Got DevOps, got DevOp. We're gonna be asking people to do like 10, 12 second videos, you know, about do they have DevOps? Do they love DevOps?

Do they like DevOps? Whatever or with the hashtag got DevOps and maybe we'll have some cool prizes out there for people who participate. Um, no Milk mustache though.

You don't have to have that. No, you don't have to milk mustache. I mean, if you did, you might have a better shot at winning the prize.

That's true. You would stand out from the crowd. Yes.

Um, but we're also, we're gonna be doing a, uh, a video, a limited, uh, video series on Got DevOps and DevOps next, as well as some webinars. And there'll be a lot of editorial stuff and as I mentioned, the social media, maybe even a panel or so at the RSA conference on the security aspects of DevOps Next. So we're excited by this.

com, um, and get ready for our got DevOps video campaign on, on all the usual social media, tiktoks and all of that stuff. So it should be fun. Yeah.

We have a, um, Mitch, i a round table coming up. We have a round table coming up the, I think it's the 23rd of this month, um, talk why I love DevOps kinda Right. And that that'll be sort of prelude to it.

And that's on DevOps on Down, isn't it? Yes, it's DevOps and Ben. Right on.

It's on uh, the 22nd at 11 o'clock. Why I love DevOps and some great folks are on that panel too. Very cool.

Alright, Mitch, I don't have anything else on DevOps. Well we do. We just don't have time for today.

Yeah, I think we're about outta time. We probably went overtime anyway, man, as usual. It's great.

Great doing another DevOps chat with you. I love it. We're doing it in different cities just like we used to.

Yeah, yeah, you bet. Apologize. We'll be back on next week with another episode of DevOps Chat.

But until then be well. com this is Alan Shimel and Mitchell Ashley, you just listened to another episode of DevOps.