Fatih Degirmenci, CD Foundation, & Andrea Frittoli, IBM | OSS North America 2023

This is Techstrong tv. Hello and welcome back to the Open Source Summit in Vancouver. We're here with FA Deci and Andrea Oli from the Continuous Delivery Foundation.

I'm happy I didn't trip over all that. There's a lot of valves and things, but we're talking about a new report that these guys have put together and it really dives into the state of DevOps at its core. On one level, I think the report finds 86% of folks who are involved in some level of DevOps processes.

On the other end of it, it says maybe only 22% are going end to end. Yeah. So what's your sense of the current state of the DevOps community?

So thanks for hearing us, Mike. First of all, original state of city report is the report we published on a yearly basis when we have our, uh, event city. And this year's support is the 14 series as you highlighted, the report says the DevOps adoption, DevOps adoption is on 86%, which makes us feel good.

It is happening, the organizations are now adopting DevOps ops principles and practices. But I mean, look at some other findings in the reports such as if organizations are using contents delegation or contents delivery, there are some interesting numbers there That transformation settling when it comes to this individual practice. But when we think about end to end view of this contention and contents delivery, the adoption rate is pretty low actually.

Yeah. And like this may be explained based on different reasons such as DevOps transformations, not just about technology, but also organizational transformation, culture transformation and perhaps change in product structure to be able to do DevOps. So I think we left some way to go to make sure the organizations actually increase their adoption to DevOps and they need to look into organizational aspects, cultural mindsets, aspects as well.

When it comes to DevOps, that's at least what we think when it comes to seeing those numbers and adoption rates. So we need to put some more effort into, you know, getting organizations on board with the move forward with their efforts. So Andrea, I think when you guys started you had four projects.

The best known of course is Jenkins. Yeah. Now you're up to nine I think.

So when the goals that he just outlined in mind, how do you determine what projects you're gonna work on? What are the relationships between these different projects? Give us the tour.

Yeah, so, uh, that's a great question. So we have a new project that joined in the foundation and we really look for a project that can contribute to the, uh, city, uh, um, ecosystem. So that can contribute in different, uh, phases of uh, the entire continuous delivery starting from when the code is written to when it's uh, published to artifacts and when to go into production and monitoring.

So we look at the EL of the, the community, we look at the, how the community is active and engaging with, uh, with the rest of the, the, the CDF community. Basically how, how much interest they have in engaging and bringing value to, to the discussion. Um, so we have um, one of the new project that we uh, added to the city foundation, um, the school city events.

And it's interesting that you ask about, uh, how they collaborate between the project because in fact we, we have a, a problem, uh, in the, in the landscape that we want to solve that is about interoperability. So we have a lot of project in the city landscape also beyond the what we have with the CD foundation. Um, but there is a great need for interoperability.

And one of the projects that we have is actually a standardization type of project is city events where we want to provide a common language, a common data model for all this tools to um, be able to interoperate with each other and also to be able to produce data and evidence for um, the people that are using for our end user using these projects, you know, to collect data consistently across their tool chain. So to his point, the tool chain is fragmented and we need to do stuff to bring that together. So is it reasonable to expect that so many people would be doing end to end process in the first place?

Cuz it's kind of hard to do that on your own and put all that stuff together. So at the end of the day, is it a question of maturity on the demos teams or is it question of the tools we given? I think both contribute to this.

Like if we look at the ecosystem as Andrea mentioned, like in our landscape we have lot of ci cd technology system and other parts of the open source family. There are lots of technologies and sometimes it is important to take a step back and look at what's happening within the ecosystem and then see who is doing something about a specific problem for example, and then join the force there. So instead of spliting ourselves team, we can come together and collaborate on solving problems together, which in turn could help users of open source tools and technologies to actually look at tools that have larger communities with different ideas, different use cases.

And then that in turn helps organizations to be faster when it comes their adoption. Because like if the organization start with their DevOps continuously journey, they need to start of tool and technology selections. If there are too many tools out there, then it may be difficult for those organizations to understand which tools serve their purpose better.

Instead of asking all our users to know favor one or the other, we should actually combine our forces and bring the best out of different, you know, tools, put them together and give that to our users. I think, yeah, it goes both ways. And the third aspect I think that is important to highlight where project committees we have end user committees.

I think those end user organizations, committees, they should also join rfl so they can guide us to, you know, have solving their problems together rather than being pure consumers. They become part of our community and start contributing and becoming maintainers of the projects they are using internal we. Is that an issue for us in this industry right now?

It seems like we're reinventing multiple wheels by different projects and different companies and maybe we need to figure out collectively where are we going to contribute to open source and then what are we gonna compete on above that? Yeah, absolutely. So that's something that it really come, comes out when we discuss, when we talk with the end users and every time we manage to get different end users of project in the same room and they started discussing and you see that they have, they're having the same kind of issues when they go at scales and they all have this developing their same kind of solution in-house to solve this problem.

So we definitely are like really interested in getting this end users talking together more and you know, bringing this knowledge uh, to the project so we can, you know, collaborate there and finding solutions rather than in-house. It Does seem like every organization has written their own scripts, has a lot of manual processes and they're all tweaking the same thing, but they did it individually and maybe we could all have the end users contribute more of what they've done. So maybe we need to hear more from the people who in the DevOps teams and say, Hey, not just the vendors, but what did you have to do to kind of extend this to make it work?

Exactly. Like when we talk about Con Air Foundation, we highlight what kind of personas we have within our community as contributors. Con Air Foundation has the practitioners from Andrew organizations and that is a critical aspect.

Cause if we can have those people taking part in common conversations as part of our special task groups or under our projects, then those people actually could bring their experiences, bring their challenges to our project C and then make those projects better. Let's kind of like collective effort results on better things. And that is something I think we discussed yesterday and we bumped into each other.

Like I think we need to take a discussion around this, like what is happening, where we are at moment, how we came here and where are we going from here, what we can do to improve. I think that's pretty important conversation to have to, you know, set the future and how the things will evolve. You need to put everybody in a room and lock the door.

Right, exactly. Yeah. Um, there's this debate going on, I'd love to get your opinion about it.

Um, so we've had C I C D forever in a day, but most people are just doing the CI part. Very few do in the cd and now the CD people are arguing about whether it's continuous deployment or continuous delivery. Should CI and CD be tightly coupled or loosely coupled or you know, what is the relationship between these two things going forward in your mind?

Yeah, I don't think they should be like tightly coupled. There's a lot of um, also knowledge and experience and specific to building artifacts and testing artifacts that you may have on the CI side and also in deployment in the CD side. But I think, um, and different, different users, they have different requirements.

So some tools work better for them. So I think it's good in a way to have like different tools for different scenarios. But I think there needs to be like interoperability between these tools on one side and also reference architectures or like examples of how to combine them for solving specific scenarios to guide the users, uh, to guide like our DevOps practitioners that want to solve certain problems.

You know, how to combine the CI and city tools together. Continuing the philosophical debate. There's everybody walking around saying, oh I'm a cloud native developer versus a monolithic developer.

Do I need different C I C D kind of platforms for each or can I use one for both? I think The main thing about the tools and technologies that debate when it comes to cic, the infrastructure scope, I think the organizations ask open source companies, we should be using the tools that serves us best. Like if tool X works in both context like mono versus microservices, there shouldn't be, you know, big push to move to at all because it's taught most about, I think that should be the guiding principle.

The tools shouldn't dictate us what we can achieve. We should pick and use the right tools based on what we need. And if one tool search the purpose, then it's good.

And I don't mean we shouldn't try to modernize our infrastructure. If the time comes, then obviously we need to go and look at what is the, what is the next generation tools and technologies that could help us to speed up, you know, delivering new products faster, fixing box faster. Of course that should be done, but I think it's case by case based and you know, up to the organizations.

And I, if I may add what Andrea, Andrea just said about CONT delegation, consider, cause I have my own perception, like if we think about CONT delegation, yes it is pretty foundational thing and Aaron must be doing that is this and even continu theory, what I think is like continuous delivery is a prerequisite to have continuous, sorry, continuous delegation is a prerequisite for continuous delivery. And continuous delivery is enabled of continuous deployment. Again, they're not tightly coupled to each other, but they are pretty heavily late to each other.

You can't achieve continuous delivery without continuous delegation. I think that is an important thing organizations should think like if they are doing their transformations and if they are done the continuous delegation transformation next step they should be taking that. And that is going back to their first question, state of CD that highlights like organizations to CI but not doing cd.

Maybe that is the thing they should be striving to move toward. There some folks that say CD was never realistic because every platform was a snowflake anyway. And it's only now with Kubernetes that we have some common API that we can write to.

So is that gonna advance the conversation for adoption of cd? And then is that kind of what GI ops is part of that conversation? How are all these things related in your mind?

Hmm. Yeah, I think there can be different approaches to CD and GIS is definitely a valid, very strong approach and there is effort in standardization around GID ops. Um, I don't think it's a panier for all for everyone.

And so you can, I think to what FAT said, I mean there are different tools and it's, it's not only about a specific tools or specific approaches. There are tools that works better in different, in different context. Um, I really think it's um, but we should enable people to, to use those tools, uh, provide interoperability with between them, provide guidance, get the end users and we said, um, talking together so that we can bring the, the right features into the tools that that they need.

It's Not a one size fits all kind of world. </unk> No common thing regardless of the product structure where it gets deploy the industry. Like we have end users within CD Foundation contributing to our projects from finance, telco, mm-hmm Webscale and some of those, you know, products are going to our phones, some of them are going to radio based stations, some of them are going to, you know, point of sales and some of these things they will never be containerized.

And that requires us as the CD foundation to look at this important more broadly. It's not just cloud Native ES gives us common know API and standardization array, but what about the other things that are not contentized or that will never be contentized. So that is an important message they've been trying to pass.

Like if you are working with contents delivery, we can have those conversations here. We, we are kind of agnostic to type of work. This is a common need for everyone.

Let's work together. If there are differences we address them as well as part of our road force. One of the big issues here at the show course is security.

Where does that fit in the context of your foundation and um, you know, what do you think ultimately is gonna be required? Do I need to make the existing projects more secure or do I need to add other projects or what's your thought? I think both and even more like if you think about software supply chain, what goes through that software supply chain, you take open source packages, you put them into your products and then you do stuff with them and then you ship them to your customers.

And the backbone of that supply chain is actually your five mine, your production systems. And it's pretty important to, you know, work with the continuous delivery both from practices perspective as to secure that part. So software supply chain becomes more secure and it comes to what should we be, we be working with, of course our projects must be secure as well, like Jenkins spin Tecton in addition that our projects should provide their users to run their pipeline in a secure manner.

On top of that, we must make sure what's happening at any given time in our pipelines are also not possible to temper it and it's always observed and they are doing what they're supposed to. So what goes through those pipelines also don't, you know, cause trends or for our, so I don't see supply chain too far furniture, they're actually pretty close without one. The other one doesn't really become secure except You cannot walk down the street today without somebody jumping out and telling you about their great new AI thing.

Where will AI fit in the whole DevOps workflow and you know, what's real and what's not or what's possible? Yeah. Oh Yeah, yeah, that, that's a great question.

So I think, um, to the point Fati is mentioning, I mean it's important to collect data, you know, and know what's going on in in your pipeline. And we have more and more points in the pipeline in the workflow where we can emit data. And that's one of the things also that we are really talking about in the context of the city events project.

Like every, every tool producing data. And so when we collect all this data in an advanced storage, you start having a lot of data that you can use to take decisions based on policies or algorithm, but you can also start using these data to build data models and take AI driven decision eventually. So, you know, take branches in your workflow, take decisions whether you want to promote a certain artifact further in your pipeline based on uh, AI or machine learning models.

So I think that's, that's a good great opportunity in that space. More research to come. Um, what's your sense of, if I look at the world today and we talked about multiple architectures, but there's code running up in the cloud all the way out to some flavor of a network edge and everything in between.

Is the weight of this getting too heavy for us to sustain or you know, can we really handle where all the places we want to put all this software or do we even think about this? I think like, this is really interesting talk because like I was having a conversation with one of our committee members and like, okay, all this know cloud based environments, exercise and so on, the number of place, the number of target environments are exploring. And I think we also need to take a step back from continuously now within the domain to think like pipelines traditional pipeline approach doesn't really scale with help us support us moving forward.

Maybe we should take a different look into how this ecosystem should evolve, how the Cary practice should evolve. And I think one of the reasons contemporary foundation exists to actually look into far future as well. Not just work at today's technologies, but look at emerging trends, look at upcoming challenges and try to find answers to some of these difficult questions.

And your questions very difficult to answer. But I think there are different things. Like for example, one of topics we discussed within the community is intent based pipelines.

Again, pipeline already is there because we don't know what has to use like intent. Like what I want to, what is my intention that may be late to AI as well. Okay, I want this container which to be built using this call base and should be deployed to this data center should be deployed to this edge.

And I state my intention and the CD framework, whatever that thing is, to do that without me needing to go and put really decorative instructions. It should be based on my intention. I want that product to be shipped there.

You do that part based on what I want to happen. So it's kind of, I think that's why I like our community a lot. I mean there since the very early days and this type of conversations, if you are not part of the community, it's not possible to be part of those conversations.

Even aware of those conversations, but they are happening. Do we need to lighten up then on what we think of as DevOps? Because in some ways DevOps is like water, it just finds its own level inside an organization.

And maybe we shouldn't be beating up everybody about exactly how many processes and procedures they're using. They're using what makes sense for them. Exactly.

I think this is like tools selection. Like if you don't have to use all the tools available, you use what you need to use. You don't have to maybe stick to the book, follow the book one by one.

We just take ones based on where you are and we build from there. No, it's good to like ambitions and so on, but sometimes it might, you know, slow things stone. Cause you might feel, oh we are not doing this right.

No, you are doing it. You already started. Just take your time and move based on your needs and your face.

Well, a couple of chapters from different books and build your own, right. Yeah, yeah. Um, one of the issues that does come up in this complex world is when we talk about continuous deployment all the time, but a lot of the folks I talk to say, you know what, the only thing harder than deploying software is rolling it back.

Can we make it any easier to roll it back? Yeah, yeah. I mean we can, I mean there is, um, a lot of automation and there are interesting, uh, projects happening in, uh, in this, in this space and basically to, to react, uh, to issues in production that you might have in production to detect what, what it might, um, have went wrong.

But I think it's, uh, to enable this automation, again, the important thing is to have the data and to send the right signal. So to have all the data about, um, a release that was made, a deployment that happened, a configuration that was changed, a certain metric, a certain test that you execute to validate your services that are failing. And so with all this data you can basically take, um, automatic decision about solving this kind of issues and having like remediations that won't take, uh, won't need even human intervention.

So they could happen in the matter of, uh, of uh, yeah. Seconds or minutes. So what's on your wishlist for here?

I mean, you've got the report out, you're kind of still early days in the whole foundation and what's next up on the list? Yeah, The first two years of the foundation was covid. You know, they shouldn't talk about it anymore, but we have to in CDF context.

So we are four years old. I think Monday we made out of announcements. Like our projects are doing lots of great stuff.

Like c France is one of them, tech is the other. And Tel is another project we have. I think this like we are on this upwards trajectory, I think, and I hope we will impact people's lives positive.

Like when you ask this question, I mean I ask like impacting people's lives positively. What is the relation between hundred zero and people's lives? Like if you can have, there's whole World peace in there too.

Hunger and, but if you think like we're all humans, open source is a big family and we are all, you know, fighting for the greater good and if something we do within our community, perhaps someone somewhere, then that makes me personally happy. Cause I know that is used by someone and that person appreciates that. I don't know that, but it's happening.

I think the community, our community and other open source communities, if we could continue on this path and ate them closely, then it'll make everyone's lives better, our lives better, our teammate's lives better. We using the software that flows through these pipelines, their lives should be better. So that is like, again, maybe wishful thinking, but Hope Springs eternal.

What's your best advice to folks who are watching this and what's that one thing you see people doing in the land of DevOps that kind of just makes you shake your head and go, Hey, I think we could be better than that. Hmm. Well, I think, I think one, one thing that I would recommend, if you're doing changes to your DevOps setup, don't do it.

Don't do it. Do them for the sake of it. So, you know, measure what you're doing, you know, talk to the people and see where change is needed and do changes in the direction to improve.

You know, like the environment for the people and the results that you can measure. So that would be my recommendation. All right folks, you're heard in here.

I think there's an old saying about measure twice, cut once still applies to software as well. Guys, thanks for being on the ship. Thank you very much for hearing us.

Thank you. Thank you so much. You'll be back tomorrow.

We'll be back tomorrow. This is our last interview for the day and we hope to see you all again in 24 hours.