CI/CD Design Patterns with Garima Bajpai and Michel Schildmeijer at OSS Seattle 2024

This is techron tv. Hey everybody. Welcome back.

Mitch Ashley here at Open Source Summit. I'm just talking about open source security forum and another conversation. But we're back here talking about all great things around DevOps and CICD software development, and I'm joined by a couple of very special guests who are working on a book, and we're gonna be talking about their project and what they're doing.

So, Sima, will you wanna introduce yourself? And Michelle, if you would do too. So, I'm Karima.

BI am based of Ottawa, Canada. People know me as the founder for the DevOps Community of Practice, which is in Canada. It has several chapters, Montreal, Ottawa, Edmonton, Atlantic provinces, and I'm also the producer for Summits Canada.

Um, I was nominated by Techstrong Group as DevOps Executive of the Year 2023. And I've authored, uh, a couple of books. Uh, the first book I can talk about is the strategizing continuous Delivery in Cloud, which came out last year.

And now I am co-authoring the book with some excellent, uh, CDF ambassadors. And we'll talk more about it. Uh, CICD design pattern.

Great. Great. Michelle?

Yeah. I'm, uh, Michelle Hil Bayer. I'm from the Netherlands, located in Amsterdam, or near Amsterdam actually.

And at the moment I work, uh, at a company and we are responsible for designing a cloud native infrastructure at the private cloud platform for the Dutch Ministry of Defense. And, um, I wrote a book back in 2011 about Java application servers, and now I'm co-authoring with Garima and some other authors, uh, about CICD patents, CICD patents. So CICD is not new topics.

A lot of books about that. A lot of training videos, but good content. You know, you both know you've written books, that's a labor of love.

You don't do that to say, oh, I think I'd like to write a book. You know, and a week later you've got a book. I guess maybe chat, TPT could write some nonsense for you, but, you know, it's a labor of love.

You really investing, especially four of you, you know, collaborating on this. What was the space in CICD, that topic that you said, you know what, nobody's talking about this and we need to help future with that. You know, if you like it or hate it, CICD is still evolving, right?

And the paradigm has shifted from, you know, what tools and applications we should use to like more tools and applications we should use, right? Mm-Hmm. So it's also introducing a lot of cognitive load on practitioners with all this plethora of tools and applications.

And even the standardization of these, uh, CICD poster, it's not very, uh, clear at this point in time because many organizations are steering their dialogue, including C-N-C-F-C-D-F-C-D-F came, uh, across, uh, uh, initiative, which is reference architecture for CICD, and we can talk more about it, but we see that we are in a phase where we have a little bit more maturity how these CICD implementations have happened to solve like specific recurring problems. Mm-Hmm. Now it's time for us to say, okay, we can standardize the poster of CICD keeping in view the deployments, which have already happened, right?

And then we can craft like some kind of a set of design patterns, which will be easy to deploy and integrate into, let's say your IDPs. And, uh, we can talk more about it, how we are structuring it and how we are strategizing it. But it's a new concept.

It's also a difficult topic because, uh, not, not, not everyone has talked about it. So obviously, um, yeah, we, we will introduce this topic and I think book was a great initiative, uh, to kind of introduce this topic to our audience. Mm-Hmm.

Yeah. I, I like that you're taking a patterns approach. You know, it's not like best practices, like there's some good recommendations.

It's more like kind of scenarios and different situations you would apply them. Like, here's what a singleton, we all know what a software singleton is, right? It's kind of the simplest pattern, but those are, one of the ideas around that is you can use those patterns to describe an architecture and a probes do this.

So, so I minded a gap between what's already common ground within software development, like using patterns for all kinds of scenarios and reusability and everything. And I kind of miss that somehow in this CICD uh, uh, ecosystem. So, and what we're trying to do is also to apply these common patterns which are already there.

Also apply it into CICD, actually, sorry. Mm-Hmm. That's, that's a little bit of the gap we are trying to fill in in this.

So if you're designing a software solution, you also can design A-C-I-C-D solution along with that software solution. Mm-Hmm. But it gives you a way to label it, talk about it so we know what we're referring to an approach, right?

Yeah. How to implement that. So there's four of you working on the book.

Yes, that's right. So that, I mean, we like to collaborate as developers in software and DevOps people, but I imagine you're probably not all sitting in the same place in the same room writing this together. Right?

How do you write a book with four people contributing to I? Yeah. I think, uh, the essential part is that we are passionate about the same topic.

So we have spent years in r and d and deploying applications. So obviously we understand that, you know, it's time for that mature D curve to happen for CICD. And then we all also work within the umbrella of CDF as ambassadors.

Uh, at one point in time, he was an ambassador last year, and some of us are also ambassadors this year. So we have a common ground to work on. Of course, it is challenging because it's a new topic, and it also gives us an opportunity to brainstorm our ideas, you know, with the relevant community of practitioners, which the four of us are bringing together our experiences.

So it's incredible that we will come up with something which is more useful for the entire community You got. And you also gotta test it among ideas and Of course, and align all our ideas that that's really because, uh, if you have say about 20 chapters, then the first chapter still has to be the same on the same line as your last chapter. And also with four authors, that's really a challenge.

So first of all, we're, we're writing and we get all these editorial reviews back, and then we also have to have some reviewers who are more on the technical content. So more like the third party review, because we don't want to, to do our own reviews. But that's, that can be challenging.

So we're, we, we set up a slack chat, uh, channel and everything, and we try to align, uh, what we are writing and, uh, find a structure in every chapter, getting a little bit of the same structure in every chapter, the same approach of how we, uh, describe things and how we put in diagrams and everything like that. So yeah, that's, uh, it's A good way to break it down too. 'cause you, you wanna continuity in the voice, right?

You don't wanna sound like four different people describes, you know, very different terms or language, but you wanna kinda read it. It's so that's familiar pattern or structure, right? Yeah.

As you're going through the book and saying, okay, great, I understand this, and maybe somebody's greater at a going technical depth, there maybe introductory topics, kind of fix your specialty, I would imagine. And each of these authors have their own sweet spots. It's, uh, you know, handpick of, uh, we have handpicked the authors because we want to bring more usability of the book towards the practitioners.

So we are not only writing theoretical concepts, but we are also eluding the fact that, you know, we have implemented these, uh, design patterns in specific industries. So we have brought in people who we have hand paint, who have done this job, have, who have the experience to deploy these, uh, patterns in the industry. So it is also coming from the practitioners, by the practitioners to the practitioners.

Mm-Hmm, That's good point. You're not making this up or, you know, is it your own ideas only? Right?

You're relying on a large body of work. It's not an ivory tower, which we are, uh, putting things downwards like some architects usually do, but yeah, we're trying to be as practical as also, uh, theoretical of course, because yeah, you have to have a starting point, but also the implementation part is very important. Yeah.

Where do you, where do you think CICD is going? Yeah, we talked about, this has been around a long time. It's evolved.

It's matured. Yeah. It probably will be here for a long time too.

But you think, do you see any kind of substantial changes about how we think about CICD? Yeah. Well, in spite of speaking of the buzzwords, AI is becoming, of course, uh, an important factor within.

Yeah. So I think that part will be more, more and more important. But first of all, I'd also, I work with a lot of companies who haven't even started using CICD in a, in the manner, which it should be.

So, mm-Hmm. I foresee, uh, a, a, a huge change in that as well. So more adoption of CICD and more end-to-end solutioning of CICD and more focused teams on particularly, uh, building CICD for, yeah.

For teams. So to that point, there was a, uh, CDF through court, the state of CICD to summarize it, if I don't remember the title exactly, but I think it was around 20% that people are doing Yeah. The responder are doing CICD, which was kinda shocking to me.

But when you've been doing it a while, it seems out extraordinary that people aren't doing it. Yeah. But it tells you there's a long ways to go for adoption.

It Is, yeah. And one more thing to reflect, even if you are doing CICD, you are at a different maturity curve, right? Every organization has different maturity curves.

Some people have started to adopt it, some people are scaling it. Some people have multi products, and they have multiple pipelines. Pipelines on top of pipelines.

And, um, the last category would be injecting more emerging technology into your pipelines, right? So there, there is a mature D curve definitely, of how these companies are adopting CICD and what are the next steps. Uh, you know, you asked that question and I, you know, I would like to answer this with one, uh, you know, uh, statement that, how the good and fair software would look like in five years down the line.

Mm-Hmm. Would green coding, green software, responsible ai, all these things, do you care for it? If you care for it?

I think you have to watch out how CICD is evolving, right? And with these design patterns and the reference architecture and everything, what is coming along, I think we will have a better security posture for CICD. We will have more responsible AI injected into it, and we will be more conscious about sustainability of our, you know, software products.

That's a really good point, because, you know, AI has kind of its own workflow, right? Mm-Hmm. And data plays a different role in, in LLMs and things than it does necessarily in a normal business application.

And a lot of experiments are happening, right? People are going out and trying out generative AI and playing with it. But at some point, the fact it becomes real, you're gonna put it into your software.

You don't wanna just say, well, you gotta change your whole CICD process. 'cause mine's different. You know, how do we think about how AI flows into a pipeline of work?

The things we need to be thinking about that then, Right? I'll start this way, the, you know, a question back that, you know, what, why do you do CICD and what is your business objective around it? Mm-Hmm.

Whether it is improving your developer productivity and enhancing the poster so that the developers have lesser cognitive load and they can build products and features instead of, uh, caring about what infrastructure, what pipelines, what tools they're using. Mm-Hmm. If that is the case, I think, uh, that's the answer to the question, right?

So we want the CICD pipeline to obviously integrate with, um, emerging technology. Generative AI is just one of them, but for the right reason. Mm-Hmm.

So we don't want to say that, you know, now 75% of our developers should use generative ai. We should start with why should they use generative ai? Mm-Hmm.

Is it because you want to reduce the cost, you want to increase developer productivity, or you just have to improve the innovation posture of your software centric products? Also, like to mention for the end customer, what delivers, what does it deliver for the end customer? And that, that's a huge value too.

So as now I'm at, at this project, like building this private cloud, and it's for the Ministry of Defense and it's delivering zero touch deployments, uh, a portal for the, the end customer to re request, uh, an environment or whatever they want, uh, uh, rolled out automatically where they can, uh, de deploy their applications or their, uh, other stuff they'd like to do with it. And that's the added value using CIC as well. I, in my opinion, so not only for developers, but also for the end customer to deliver it at speed and at Yeah.

At at, at high trustworthy for them. I feel like we're in the newsroom and you're like, one of the pages walked by. Yeah.

So, right. Um, so the two topics always come up. AI is one, security is the other about securing the CICD pipeline and approaches to that, we haven't, you know, really talked about historically, right?

How do we secure that part of our workload? And is any of that part of your discussion in the book, Right? I mean, I'll answer it first and then I will give it back to Michelle because he's the subject matter expert.

Okay. There we go. So obviously this is one of the needs which we foresee that, you know, why, uh, companies which have a lot of regulatory and compliance are hesitant to onboard to emerging technology.

Mm-Hmm. And we need to have some kind of, uh, you know, uh, common vocabulary for baselining, how CICD with security and compliance would look like. So we call it domain driven design pattern.

So obviously it has a specific layer of security, you know, authorization, you know, roles. Uh, how do you define that and how do you, uh, have access points on different applications? How do you treat your code?

Um, obviously there are other, uh, applications and tools which you can extend into your pipeline because, uh, from a regulatory and compliance perspective, it's a mandatory checkbox as well as there is a lot of approvals on the way you go along when you're releasing your software, right? So we are removing that barrier of introducing emerging technology within CICD with this domain driven design pattern, because it also gives you trust that it's already implemented. You know, it's already deployed in so many locations and so many CU customers and clients have tried and tested it.

So it removed that fear of onboarding to emerging technology, right? Right. Not so emerging, right?

We telling you should You, you've given away a lot of it. But of course, the shift left, uh, uh, thing is of course important to, to embed it as as soon as you can within your development process as well. And also implement it all the way onto your production release.

Mm-Hmm. Like using all kinds of tools you want, like, uh, container image signing, uh, vulnerability scans all along your, your, your pipelines and your, your environments and everything. So you needed every step and every, uh, point within your, uh, CICD.

You have to embed some of these parts. Like also, uh, quality gates within you for your code, um, code quality and all those, uh, things should be embedded I, to my opinion, from the beginning already. So, yeah.

Good. Well, I'm excited, excited for this to come out. Yeah.

I know you probably don't have a hard date, or maybe you do. So what's your timeframe on releasing the book? We are looking forward to Autumn at this point in time.

Obviously we don't have a date as such, but of course it's, uh, prelaunch has already happened for this book. Uh, you can still find it on Amazon. Uh, it's not up for grab yet, but obviously you can watch out for the dates And tell us the name of the book so folks know what to look for.

CICD Design Pattern Designer. Are we good with four names on it? So four names.

Okay. And we won't talk about whose name is in what order. No, I, well, thank you so much for being with us.

Thank you. And tell us about it. Look forward to it.

Come back when the book's released. Oh, sure. And, uh, we'll have a conversation.

You can get your other two authors with us here and why that conversation. Okay. Excellent.

Thank you for having us. Of course. Absolutely.

Thank you. Thank you for being on our other, uh, shows and panels, and we'll get you on some things too. I'd like to do that.

Thanks. Great, great. Wrapping up a day, our first day here at, uh, the Open Source Summit.

Amazing conversation book authors, people writing code, contributing how projects are being secured, how things are connected to government activities, all kinds of things we've talked about here. So look forward to more great interviews coming from the Open Source Summit. Stay tuned.

Thank.