Balance in Your DevOps Journey: At What Price? | DevOps Experience 2023

Hello everyone, and welcome to our keynote panel for this year's DevOps experience. You know, we've been doing DevOps experience now about six years, and every year I try to put together a keynote panel of the leading lights of DevOps. And this year, I think I got it.

Uh, we find, you know, we, we've been, we've had great panels over the years, but this year's panel's exceptional and I hope you're gonna enjoy our discussion. The theme of our DevOps experience this year is achieving balance in DevOps. com in 2013.

The players, the technologies, the mission seems to have morphed and changed and grown and evolved beyond recognition. And, and not just myself, but many are asking, have we, have we lost? What was DevOps is, have we lost balance in DevOps?

And if so, how do we achieve balance in DevOps? And, and that's really the theme of this year's DevOps experience. You know, new, new things like, uh, platform engineering and s r e and low code, no code.

And, and of course, DevSecOps. We're all, many of the companies out here are gonna tell you they're now DevSecOps companies, right? Um, ai, this whole generative AI thing and everything going onto it, it's pushing and pulling and stretching, DevOps in ways I don't think we would've imagined 10 years ago.

com. Um, it's gonna be a fantastic discussion. I want to introduce to our audience for people who may not be familiar with our panel, our panel members, and I'm gonna do it in order of my Brady Bunch Zoom here, though you're not seeing that on, on your screens right now.

I'm gonna start with my good friend, Shlomi Heim. Shlomi Shlomi, first of all, welcome. Thank you.

You've got the frogs symbol behind you, but why don't you just quickly say hello and introduce yourself. Uh, well, uh, hey everyone, great to be here. Alan, thank you for, uh, including me.

My name is Shlomi Heim, I'm, uh, the co-founder and c e o of Jfr. J oog is the provider of, uh, the software supply chain platform. Uh, we are actually the binaries, people taking binaries all the way from the, the developer keyboard to the edge and securing them along the way.

Excellent. Thank you, Shlomi. Welcome and thanks for being here again.

Next I wanna introduce you to Derek Holt. Derek, welcome to our panel, and if you wouldn't mind introducing yourself. Absolutely great to be here.

Uh, Derek Colt, the c e o of Digital ai. Um, we, we ultimately deliver AI powered DevSecOps solutions, to your point, DevSecOps Solutions, very, uh, very directly, but we do it purpose built for the enterprise. So we wake up every day thinking about the largest, most complex, most highly regulated companies, and how they go from idea all the way to deployed code.

Excellent. Thank you. And welcome, Derek.

Next, I'd like to introduce you to Anush Kaur. Anush is the C e O of CloudBees, the Bees Anush. Welcome.

Well, I already said you're c e o of CloudBees, but why don't you introduce yourself? Thanks so much, Alan. Yeah, it's a pleasure to be here, obviously with these team guests.

Uh, as you said, I'm the c e of cloudbase. Uh, you know, we're very similar. We're we're focused on enterprise buyers.

We're focused on build, deploying, secure software is the most important asset for all of our customers and our industry. Um, and we're fortunate to power some of the experiences behind some of the customers, uh, that, uh, that probably trust us. So, pleasure to be here.

Thank you. It's a pleasure to have you. Next I wanna introduce you to my friend Elizabeth Lawler.

Elizabeth, why don't you introduce yourself? Yes, hi, uh, thanks so much for having me, Alan, and I'm really excited about being on this panel. I am the c e o and founder of a company called adap.

We deliver a personal observability solution purpose built for developers. So we ship, run, shift, runtime, observability, analysis, and beautiful graphics of how software works when it runs to developers, where they work, which is in the code editor while they code. Excellent.

And thank you for being here. Our next, uh, guest needs no introduction to any audience in DevOps. I'll let him introduce himself though.

It's our friend KK koosa. K kk, why don't you introduce yourself? All right, thanks for having me.

So I'm probably best known as a guy who created Jenkins, and that was 15 years ago. So my developer productive passion just continues for that long. And I was up, you know, I spent a lot of time at vis, I was a C T O.

So like I go Vis. And then for the past three years or so, I've been doing another startup called launchable. And uh, what we are doing is to try to bring the power of data and AI to make the, you know, the Q team, the qa.

Um, so helping people make it easier to, for people to do is the tests. So Kk thank you. And, and for those I know this keynote, if you're watching the live stream of our event, is in the morning.

KK actually has a, a fantastic session later on today that you may want to watch around testing AI and some other things. Last but not least, our final member of the panel to introduce you to is she's a Renaissance woman. What more can we say?

Ashley Kramer. Ashley, why don't you, uh, introduce yourself. Yeah, thank you Alan.

Good to see you and everybody again. Um, I'm Ashley Kramer. I'm Chief Strategy Officer and Chief marketing Officer at GitLab.

And I'm also actually a former customer and buyer of GitLab at a previous company. Um, GitLab in a nutshell is, provides a DevSecOps platform that allows companies big and small to securely deliver better software. Faster.

Looking forward to the discussion today. Absolutely. And thank you for joining us.

We appreciate it. Alright, so as I mentioned, how do we achieve balance in DevOps? Well, in order to talk about how we achieve balance, I think we need to define what do we mean by a balanced DevOps strategy?

I, I mentioned before, there's so many things pushing and pulling and, and, you know, macro events and, and, and all on on what we used to consider our little DevOps world here. What is a balanced DevOps strategy look like today? It certainly can't be, let's throw everything on the developer, right?

They're humans too. So how do you define what a balanced DevOps strategy is in, in this brave new world we live in? And, you know, feel free or, uh, panel any one of you can jump in, just give each, you know, give each of you a chance to talk.

But, um, Anush, if you wouldn't mind maybe kicking off for us, would you, would you like to kick off the discussion? What do we mean by a balanced DevOps strategy? Yeah, the, uh, you know, when we think about it, the, what the, the struggle we have is that, uh, we can't define balance as an industry for our customers.

I think they help define it for themselves, and we need to make sure our solutions are appropriate. And, you know, one of the themes of this session is gonna be the balance between velocity and security. Um, and depending on whether you're a large customer, small customer regulated industry, non-regulated industry, mature company startup, uh, you're gonna have a different threshold with regards to what balance is with regards to those two very critical variables.

And those are two of probably 10 variables that companies optimize around. They optimize around talent, they optimize their own competitiveness. They have a different viewpoint of how critical software is in terms of driving end customer or end user differentiation.

So I think as an industry, what we do well and hope to continue to do better is be very attuned to the needs of our customers and give them the flexibility and choice to be able to determine the balance that's appropriate for them and be ensure that our solutions are catering to that. I think as soon as we start to impose our view of what the right balance parameters are, uh, I think we get into trouble because it's very likely that they will have an understanding of their environment better than we will. We just need to enable them to be able to be flexible in their choice and evolve that over time with a minimal amount of friction.

Anybody want to jump in on that? Yeah, I, I actually do think, you know, we can, we can guide people for the, the, like a successful patterns that we've seen some teams. 'cause we, we have a fortunate, like, we are fortunate enough to see multiple teams across the board.

And then, so I do think for example, this like the, uh, so Alan, you, you talked about everything getting put on the developers, and that was too early on in the days of the DevOps, like the idea was hatched, but now it became recognized as fully fledged things. And then, so it's only natural that the, it's now carved out to the specific, like, you know, the profession, like a platform engineering that owns the delivery pipeline, taking that responsibility away from the engineering. And then what we used to think like a prime model DevOps, like, you know, devs and ops working together in harmony happily ever after story kind of turns out to be more, more into the, like the responsibility shifting, boundary shifting between the devs and ops.

Um, that the, uh, the, that the content level, not that depth level. And I think it's that, that doesn't mean a profound shift, but it's not like, I don't think the world, especially the teams at the scale is turning out to be where, like the single role cover everything for security and capacities on the external factors and so on. So that's sort of where I think is the, like a golden success pattern, the balance, um, this, this trinity of these roles, um, working together.

Yeah, Alan, the other other thing I would add, and, and I think this is a, an interesting sort of over the last few decades is, um, we've found that sometimes the balance is really hard to measure because we, many organizations can't measure this process to end-to-end not just the DevOps piece, but from end-to-end, from idea all the way through. Because historically, a lot of the data is locked up in individual databases and individual tools often that don't know about each other and may, may or may not be integrated. So one of the things we start out out with and, and I agree with the previous views, Hey, understand what heterogeneous tools you already have today, help understand what good looks like.

Where are you at today, where you want to go? Clearly this is a journey, not a destination. If anything has been factual over the last few decades, it's that, but also let's measure it so we can take some of the opinion out of it.

A lot of this goes back to classic operations, right? Like where are there bottlenecks? Where, where do we, where do we have, uh, uh, you know, too much work in progress and all of those sorts of things.

And, and, uh, it's one of the things I think is super exciting, not only about the e evolution of ai, but also, um, the emergence of data lakes that can kind of break down the silos amongst all of the tools that are used in this business process of building and delivering software to start to allow us to actually even define what balance means ultimately. Yeah. I I don't disagree with that at all.

I mean, there's, getting your arms around what's out there is, is a little bit crazy. Um, I I just, you know, I worry, can, can you shift too far left Shlomi? Let me, let me throw that out at you because to me, this, this is one of the, you know, we've shifted left, we shifted left, we shift everything left.

Have we shifted too much left? Well, uh, I'm, I'm listening to, to my colleagues here, uh, I think that, uh, you know, defining balance is not just, uh, um, what the market defines for us. I actually think that the main thing that we are all, all of the companies in this panel are busy with is the balance between the developer task and what can be automated.

And, um, and the reason is not because of us, and the reason is even older than, than DevOps or DevSecOps or all the phrases that we put together. The reason is that the, is a demand for a faster, uh, delivery process. And there is a demand for a more secured delivery process.

And this is a 15 years old demand, uh, when software stop being delivered once a year. So the real balance is between the developers and the automation side. And, and by the way, just by the name DevOps DevSecOps, you can find, you can find these pieces of balance.

Now, when you look at the developer, there is also a breakdown of balance there. Like, how can I balance between how fast I am and how secure I'm, that's by definition is a friction. How can I balance between what I'm doing versus what the machine is doing?

AI is not automation. AI is yet another evolution of, uh, of automation and then with the customers. Um, what is the, the two angles of, of, uh, balancing?

It's how fast can we be and where should we be strategically? Uh, we see the cloud and we see the AI and we see all changes. And then the, the last, uh, sentence around balances, uh, the community, we started this open source.

All of us, we started, some of us are still very deep investing in open source and, uh, cost, um, even before Jenkins with Huson and, and GitLab and, uh, and of course jfr, but the open source evolution also demanded some balance between what we get from outside versus what we do inside. And you see more and more open source tools that mature to be enterprise tools, which was not the case 15 years ago. So I think that this whole balance thing is about what the developers have on, on his or her plate versus what can be automated.

And regarding your question about shifting left, that's exactly the answer. If we find the right balance there, there will be some shifting left. And, and I know that it's a very popular trend to speak about shift left, but as a platform provider, I I, I'm telling you right here, right now, we are shifting left.

We're shifting, right? We are shifting up and down. We are talking about the edge, and we are talking about the developer, and we're talking about the hacker that today's come from the runtime environment through the binaries and, and address the developer.

So what type of shift is that? Is it right or left? I dunno.

I just know that I see in the market the demand for a comprehensive full solution that balance, that Fair. I'll move on to another question. Unless Coach kk, were you raising your hand too?

Yeah, Yeah, go ahead. Okay. So you, you asked Ner can we shift too much to the left?

And yeah, I mean, some people did, did shift too much to the left, uh, because it was nice, like at my own Jenkins project, it every time you have to go through like one hour of testing before you get more, well, one hour is a long time to wait. I mean, that's the example, like shifting too much to the left. Um, so there are like, you know, for example, like we, we have a product that help people shift a little bit more to the right and achieve the balance.

But that said, like by far in the majority of people, you guys should need to shift a lot, a lot more, a lot faster to the left. Um, and, uh, you know, that, so I, I think it's, uh, that that's still the majority program, at least all the, the people who you know, who are looking for help that, uh, yeah, Absolutely. Well, I may I, can I jump in?

No, sure. I, you know, I think, I think that shifting left is, is a, it's a noble goal and it should, you know, the people who are ultimately responsible for making the decisions that impact structural co, you know, structural security of code and, um, you know, secure coding practices or the quality of the design choices need information from downstream systems. But it doesn't mean necessarily that you can open up the fire hose and expose everybody to every platform system in SaaS in order to get that information.

And I think what you see now in this sort of evolution and new emphasis on some more developer eccentric centric experiences are, is that, you know, you can't drink the whole fire hose and make a, you know, make a, in order to make a small decision. Yeah, as a coder, you know, you have to be able to, I think the balance and, and potentially some of the descriptions of burnout that come from the market come from having to take in so many sources, sources of information, and so much, you know, uh, context from so many different places in order to make high quality coding decisions as a developer. And I think, you know, in many ways, I think everybody was hoping that like AI would be a little panacea for this.

And it's not. Um, but I think that the emphasis on automation and the emphasis on new tooling to rationalize some of the, of the quality of the information that developers receive in order to make decisions in real time is really what people are trying to optimize for. If you think about the balance of shift left, And I'll, I'll jump in there because Elizabeth said something that's something that's top of mind for us at GitLab, which is the quality of the code.

So we thought we had this great, you know, these great solutions of helping developers write their code faster. Well, GitLab just ran a survey last month and it showed, and it was a cast a pretty wide net. Um, only about 25%, sometimes less of a developer's time is actually spent with hands-on keyboard writing code.

And so our fun fundamental worry is if you focus too much on that, you are forgetting about improving existing code, understanding the code testing and maintaining the code and, and all of the other things that come with that. And so we're looking at a holistic approach, how, how do we help our customers have a balanced strategy balance where we're helping people automate the mundane or shift left earlier in the process so it becomes a natural part of the developer's day all the way through the security and the operations, um, what, what they're working on. And so from, from our perspective, we've almost seen too much of a shift where we think this is gonna solve everything.

And, and we see, if you don't take that holistic approach of everything it takes to deliver secure quality software, um, companies are gonna be in trouble. And that that's what we're trying to, to lean into when they look for this balance. You know, it's interesting, I was at Swamp up in San Jose.

We had coverage, I think it was in the New York, uh, DevOps World CloudBees event. And now actually you are mentioning it. Both of you at your events mentioned that developers spent 30% or less of their time actually on code.

It was, uh, a bullet on your backgrounds during your keynotes. Ashley's survey says 25%, certainly all three of you couldn't have gotten together and, and job that number. So there, there has to be some truth to this then, right?

We've certainly had customers challenge us and take it to their head dev, like lead developers, and they actually validated it. They said they thought that wasn't true. And I just had a customer tell me last week, yeah, my, my five best developers told me.

That's absolutely true. So, yep. I'm Sorry.

I'd say this is the third time now. Um, let, let's talk a little bit about DevSecOps though, right? Almost maybe with the exception of, of KK and, and Elizabeth, the rest of you all mentioned DevSecOps.

And, and what's funny is I was there when a lot of your companies first burst on the scene and it was, they weren't DevSecOps companies, right? I I was a security person. I loved the idea of having it.

Um, you know, so the question is how can we ensure that we're placing the right amount of emphasis on security without compromising speed and efficiency? Anush, you mentioned it right in your opening, right? It's, it's velocity versus security was I, I think the term you used, but we've shifted so far left it, it, you know, GitLab's, a DevSecOps company, JFR, how much of your emphasis is on security today have, is is it warranted?

Is it enough? Is it not enough? I know, Elizabeth, you guys are right there too with this, as is CloudBees, as is Derek's company, right?

So I, uh, maybe I, uh, I'll jump in first. Uh, I don't think that JFO is a DevSecOps platform. Um, I, I actually think that DevSecOps is a result and it was not a strategy.

It's a result of what the market demanded, and it's not a strategy. And you will find some companies tomorrow, like Jfr, like others that might call themselves the ai, uh, company or whatever trend will come. And, and I'm avoiding fluff.

I will be very direct. We should protect the software delivery process, and we should make it efficient as we can. In order to do that, you have to identify the primary asset that you are after.

And some will say it's your source code, and some will say it's your binaries and others will say whatever. But the facts are that after episode, like lock four J and n p m and pi pie, and all of these episodes that got the White House to issue, uh, a report about it shows that hackers are coming after developers, developers became the target. And therefore all of us are busy not only to provide them with a quality of code or a quality of binary or a good testing, uh, model, but also to provide them with a secure environment to relieve, uh, the pain that security might bring.

Now, if you are focusing on the asset and you are focusing on the real threat, um, then you will find some tools that are, um, in some, some, um, cases might be overlapping and competing, if you will find them, uh, coexisting, because I don't think that anyone else can protect the, the software packages and the binaries all the way from the public hub to the runtime environment. And we are not in the business of, uh, protecting other assets. So identifying the asset, looking at the target is what create the comprehensive solution.

Um, and that also lead to platform engineering and how you accelerate delivery in a secure way. So, uh, I think that that helped us a lot. Not only that, when we, uh, grew inorganically, when we had to buy a company, uh, we acquired ViDu two years ago, it's a mature security company that we acquired and established the j o security.

It was around the asset. It was not around the solution. And that, that for me, um, had a very clear point on the strategy.

Yeah, I I think one Oh, oh, go ahead, Ashley. Thank you. Um, so, so yeah, I, I agree on DevSecOps strategy less category for sure.

The evolution of the category of DevOps and the way that we think about the strategy that underlies it. I think we, we tend to talk a lot 'cause we all sell products about the technology. It's way bigger than that, right?

It's how the people change the way they work, the processes that either we implement on the people or do things like shift security left, so it becomes a natural part of their process. So, uh, so I agree with, with Shami that it's not necessarily the strategy, it is the category, the shift people are looking to make. And to me, it breaks down to addressing all three of those.

We see way too many customers try to, to figure out how to we'll solve the technology first, or we'll change the way that people work, bring in better developers first. It's gotta be all three. And when I used to run engineering, I saw this firsthand, um, when I was a GitLab customer.

That's why I brought it in to solve it. Yeah, I think one of the other things I would, yeah, I was just gonna add, and I, I, I think, you know, obviously the, the category has evolved from a, from a, um, from a branding perspective, right? But, um, the, the one thing that we are, are really kind of dedicated to and focused on is it requires inside out protection in addition to outside in protection, right?

So we talk a lot about embedding security into the, into the supply chain, and so DASS and SaaS and all the other things that need to happen. And that's very appropriate as we take code into production. But what we're seeing is that's not enough.

Um, we just issued a, an application security report. We do this on an annualized basis. 57% of all apps were under attack, right?

That, that as part of this survey. So 57%. Um, and so that also highlights the, the, the need to have more, um, uh, built in security.

So code obfuscation, antit tampering, and in production monitoring and having the ability to react. Now again, we're working with a lot of financial institutions, a lot of, you know, larger scale that maybe would be, would be more obvious targets, but 57% is a large number. And, and so it's really important, we think, to put security into the DevOps process, but also to acknowledge the fact that there are more things to be done when, um, you know, attacks are at an all time high.

And, and I don't think any of us would think that that's gonna change, right? That's gonna only increase as, uh, more and more of commerce is, is obviously digital. Yeah, absolutely.

This is such a fascinating topic. I see everyone is unmuted, so we can't wait to jump in. Um, The, uh, so, uh, when I was at Cisco, I was in the security business, and I had this line that I used to use for CISOs, which is, hacking is a business model.

Uh, and for all intents and purposes, we need to increase the barrier for the business model to be profitable. And that means embed security where security needs to be embedded, such that the, uh, cost of entry or the cost of hacking is high. But where I, I just wanna come back to why we find ourselves in this problem, which is, you know, seven years ago it was very popular to tell your developers go fast and break things.

Why? Because someone went to, you know, a webinar and heard it from Mark Zuckerberg, even though Mark Zuckerberg changed his tune a full 12 months later. Um, so for all intents and purposes, we were in this space where we said to developers, you need to go fast.

Velocity matters. And what did they start to do? They assembled code.

They manufactured code, they got it from third party repos. They got open source code in an effort to actually go faster. Not surprisingly, if you believe that hacking and the security industry has always been driven by economic gain, hackers saw where the vulnerabilities were, and they always go to the watering holds where they believe they have an r o i that's the greatest.

And that led everyone to this. So I agree with Shlomi and with Ashley, which is, we ended up here because in some ways the market told us that the vulnerability risk associated with software and production had gone non-linear. And it was log four J that woke up the industry's eyes to the fact that that could have catastrophic consequences.

But we started to see it from our customers much earlier because the telemetry that they gave us got them very, very concerned. So we are naturally in this phase, and look, we're not alone, right? So if you look at what Palo Alto is doing, and then you look at what pure plays are doing, uh, like Bionic, which CrowdStrike just acquired, security vendors are recognizing that the most vulnerable, uh, digital asset is the piece of code that goes into production.

So they're approaching it from their security vantage point. We are approaching it from our proximity to the developer and platform engineering and startups are approaching it from either of those, neither of those, and saying, forget about those two. We think we have a purpose built solution that basically adds to the 40 purpose built solutions you already have in your environment.

And I think it's gonna be a very, very interesting time to see how the market shakes out across both the global 2000 and the 20,000 other companies to say, what is the right approach? I think our industry has an advantage because we have the proximity to the asset that's been created and protected, and the entity that's actually doing both the creation and the governing, which is developers and platform engineering. But I think we're only gonna be successful if we provide value that balances the needs of the developers, the needs of the customer, the needs of the C I O and the needs of the platform engineers.

So log, so log four J came up a few times in my mind that that actually left an interesting lesson that, uh, you know, that there, there was no way of knowing that these things had like existed in advance. So like all the scans and so on that, that people are advocating turns out that was not useful. What was really useful, I think this came out from the Sonotype report or something, that they noticed that there are some companies who could or is quickly able to update their software to like remove the unnecessary, like a progno dependencies.

And there are other who like really struggle to drive it on. So to me, like what that taught me is like a key thing to achieve is the speed. Like you're constantly updating a dependency to the latest and greatest.

And that's a tangible practice that the developer always wanted to do anyway, and then they can. And to me, like that is actually the fastest best defense against this. Like, I don't ongoing, I don't think anybody should be getting a message that, oh, I'm gonna red out the log framework or that we should be be, be careful more about the scans.

It's the, it's the speed of update that that makes you, that does it a bit best defense. Yeah. You know, it's interesting you mentioned Sonatype.

Of course, they maintain a large, uh, uh, repository. Jfr maintains some large repository. And I've always wondered why we didn't, I, in my simple mind, I called it a repository firewall.

Like, I'm not gonna let you download a bad or an outdated artifact or a piece of code. I'm gonna force you to get the latest and greatest. And, but we can't do, but we don't, they don't do that.

Sonotype doesn't do it. Show me, I thought I saw Jfr announce something though, where you are checking right in the I d E for latest versions. Yeah, so actually Alan, it's, it's a, it's a very good question.

And, uh, J four curation is addressing that pain. Exactly. Um, we, we put a firewall between the public hubs.

Nobody writes from scratch anymore. It's, it's all news, right? We all know it.

And, uh, all the developers are bringing some, some software packages, and now even machines are bringing software packages. So what we did with J four curation, by the way, demanded by the community, it came from, from the, from the, from the field, not the, from the fog's brain. And what we build, we build this firewall protecting the, the, uh, importing of binaries, including the dependencies and the metadata and ML ops and everything that, uh, is a binary form protecting it according to the company policy.

And, uh, you know what is interesting? We spoke about a lot of technology balance. There is also a balance between different positions that just now happening, the C I O and the CSOs becoming one that we see more and more enterprise organiza organization that the C I O and the CSOs are becoming one organization.

And this firewall to set the policy between the public hub, the third party hubs, and the single source of record within your organization is extremely important. And, and yes, this is, uh, one of the things that, uh, we announced lately at, uh, swamp Up Excellent anush. I wanna come back to you for a moment.

You, early on in the first round, you mentioned speed, you know, velocity versus security. You know, there's an old song, two Outta three Ain't Bad By, by a guy named Meatloaf who unfortunately passed away. But I was, you know, one of the things about DevOps for me is I wanted my cake and eat it too, right?

I wanted all three, I wanted, you know, better quality software, more secure, fast and automate. I wanted it all. And, and part of the promise of DevOps was if we could automate more security, we would be able to go faster and, and be more secure.

But maybe we can't have it all. And two outta three isn't bad. But to me, well, we being naive, or, or, or what Elizabeth, you know, I mean, you've been in this space a really long time.

What do you think? Yeah. Uh, so I, yeah, my first company was a cybersecurity company.

It's a club you don't leave, right? So, um, uh, so yeah, I think really it's about, you know, you, you know, in talking about balance, I do think you can have your kick and eat it too in some, you know, it's just putting the emphasis on the right part of the process, right? So we've been talking about having, you know, um, uh, having, um, you know, pack, you know, package and dependency managers that are automatically checking for updates.

It could be, you know, if you look at CW cws top 25 and Owas PEP 10, they're all, they, many of them are design related concerns. You need to give people insight and information as they're making those decisions to make better ones. Then the decisions feel less onerous, they're cheaper, they're faster, and you get overall better, better source of quality.

So, you know, I, I think that you can, I think you can, I think you just have to do it at the right moment. You know what I mean? It can't be, you know, what you don't want to do.

And the worst experience is when you push everything and you find out, you know, hours later, if it takes that long for your tests to run, that you have all of these issues and you need to start over at square one. And then if you look at, I know there were mentions of how many, how much time and energy developers spend coding, but you look at how much time is spent on rework and it's 40% of a work week. You know, that's not valuable either.

So, you know, I think what we're, I think what we're trying to figure out perhaps as a group is how do we communicate and perform, inform and provide context the right moments in time for all of these issues? And it was interesting, I had a discussion with, um, someone in the financial services industry, a tech leader there, interestingly. And they talked about a lot of the static code analysis, um, um, uh, uh, products that they use.

And certainly they have downstream, um, das products and things like that that they use, but they were still relying on education primarily for many of the security decisions and in terms of application security. And that is a huge challenge. It's a big, it's a big burden.

And if you're in that position and there's not innovation in the space, then I do think you can't have your cake and eat it to, but if there's all of the innovation that you see on this panel going on around trying to provide prompts, provide more guardrails, provide more standardization, provide more, um, packaging and testing for people to be able to achieve those goals, I think it's possible. It's just about where you're gonna put your emphasis and are you gonna put either the tools or the testing or the technology in place, Alan, the other, the other kind of, uh, separate but related topic, right? If we expand security to include governance and compliance and quality, like, I think all of, in many ways, all of those things are related.

'cause in the end, as a user, I care about all of those things, not one of them, right? And, and one of the things I think we're gonna see over the next four or five years is I think we're gonna look back and say some of the early pipelines we created, I would use the word, they were sort of dumb pipelines. They were one size fits all pipelines.

They were unaware of what was actually coming through the pipeline. And so most enterprises had to apply the highest level of governance, the highest level of compliance, et cetera. Whether it was a brand new feature that was coming through that had a bunch of database schema changes and was super, super risky, or it was just a defect, you know, change that we, we made the button yellow instead of of green, right?

And as we start to have better intelligence and we start to break down these data silos, we are seeing, and we're, we're delivering this today and with many of our customers, is building intelligence, understanding the risk of a particular change that's coming through because we know what work items went into it. We know what user stories, we know what code changes. We know where we know what teams made the changes, and we can, we can understand the, and learn over time impacts in, in production.

We should be able to start to build intelligent pipelines that ebb and flow based on what's coming, coming through them. And I do think we'll look back on the first decade or so of, of DevOps and say, okay, we were, we were on the right track, but we kind of hard coded everything we needed to, to, to allow for much more variability there, understanding what's coming through the pipeline. I have only, uh, one comment, uh, Derek, when you say turn the, the button from yellow to green, you have to remember that Ashley is a yellow logo company.

Jfo is a green logo company. Not my don't switch buttons. Fair enough.

Right? Yeah, noted. Just saying, just kidding.

Just kidding. We're too serious. We're too serious here.

That's good. Okay, I'll, I'll add to the, uh, seriousness because when, uh, when Alan, uh, said, uh, you know, there's a song I remember called Two Outta Three and Bad where I thought you were going was, uh, I've got the looks, you've got the brains, let's go make lots of money. Um, I would take either of that.

Um, but I hear you. I think we're just, just tied to that. I don't think we were naive to come back to your question.

I think the bar just got raised. So for all intents and purposes, right, the more successful we became as a community in terms of providing solutions that delivered on those outcomes, the more the customers wanted, that's their solutions to do more and their teams to do more. So if you ask 'em to say, in the 10 years we've been doing DevOps, right?

And 2009 was when the word was created. So let's assume that, you know, some of our customers started experimenting with it four years later, once a w s became clear as sort of the platform of choice for modern development, and they really started embracing containerization in 2018 and beyond. So most of our customers are somewhere between sort of five to seven years into this journey that, that we call DevOps.

And every one of them will tell you they're pushing code out, uh, with higher velocity, with higher quality, with greater levels of resilience and security. That being said, success breeds success. So as they look at that, and they said, you know, to the point Derek made, which is, Hey, I have in instrumented 5% of my applications on modern pipelines.

I've got 95 that never actually came on the bus. So maybe that 95 now becomes 75. And so as an industry, we're having to do more.

And as we do more, we, we attract the attention of nefarious actors, which is why we're having the security discussion, right? If we weren't successful, I would argue that the hackers would've looked elsewhere, but it's because we are successful, but they're focused on the constituency that we care about the most, which is developers and compromising the experience of an application that is so critical to our customers that our customers will pay to actually protect it, right? You only protect what you care about.

So in some ways we are adapting and reacting to, I would say the interest level and the excitement that our customers feel towards modernizing their software journeys. Um, and as usual, there's gonna be supply and demand apps where the customer is ahead of us in sometimes or in other cases, we're ahead of the customer Fair. I'm gonna move on to the next question unless someone has a follow up to this.

No. Okay. Don't, Don't do it.

It, it, we will stay with this, uh, question. Yeah, No, we can, we can chew on this bone all day. I get that.

Um, so platform engineering, some of you were on my panel last year and I, I took exception. I, I forgot what show I was at, but they said, you know, DevOps is dead long lived platform engineering. And I said, oh, nonsense.

Platform engineering is just another piece of this puzzle here. And I think we've come to accept that, but however, it has had an effect on our world, right? We are looking at this new, maybe it's not a new category, it's a new name for a category that already existed, but, you know, it's part of the ops thing as well, but it, it's kind of setting up environments, it's peeling back some of the stuff we were throwing on the developer's plates, which may not necessarily be a bad thing however, but in doing so, are we, are we taking a step backwards by creating more silos?

Again, when one of the biggest things about DevOps was doing away with the silos and, you know, so again, achieving balance. How do we balance putting stuff on the developer's back versus creating more silos by things like platform engineering, SREs, and, you know, all of these roles within our pipeline and S D L C, um, kk you wanna go first? Go ahead.

Yeah, if anything, I feel like the, the lack of the platform engineering is what creates silos. Because I've seen all too many, these large scale DevOps support team. It's like every product has, every team has empowered to do things their own way and then it results in like, you know, hundred silos, impossible to, to, you know, be people.

So I, I, I, to me, it's like a platform engineer. It's a great way to remove silos. Okay.

Yeah, I think, I think for me, it's, it's all how you introduce, whether it's, you know, we've heard it be called internal developer platform, platform engineering team. Um, you could have the same friction between product managers and engineers, right? Product managers are developing all these plans.

Engineers have their own systems. So what do we do? We have all of these, some of our products provide this capabilities where they can come together in one place and do the planning and do the handoffs and have the co that cohesion.

So when I think about the emergence of platform engineering, it's all how you introduce it. Don't make it a, I did my work, throw it over the wall to you, or, Hey, I need this fixed bring force that collaboration, whether it's, again, via the people process, technology or all three, and then you don't create that silo. It just becomes a natural part of the, the process.

But it also frees up those developers that were spending time on it or those other people, um, that should be delivering value to customers versus working on things like the actual, um, the developer systems. Anish. Derek, any comments on?

Well, I, I think the, the, the thing I was just gonna layer on, 'cause I agree there, I actually think this is more of a people process problem than a, than a technology problem. I'm not saying that the technology part isn't real, and, and we've got capabilities, I'm sure many of us do. Um, but, but really it is about that collaboration and, and, and, and coming to a conclusion.

'cause platform engineering could also help you automate the same silos that KK just highlighted too. You could just do it at even of a higher volume than it was already done before. So I think like the collaboration, go back to the earlier comment, DevOps just where the words came from, right?

Was kind of getting these two organizations together more effectively. Um, and, and I think there's now even more constituents in that. So I think it's a great movement.

I think it should help as was highlighted. But it's only gonna help if we all break down some of these silos around the people and process as well. And we have the tough discussions to make sure that we're making the right decisions.

Otherwise you could create, you know, kind of chaos at volume, not, not sanity at volume, right? Yeah. Uh, Alan, I'm reminded of the, uh, the presentation from Netflix, right?

You don't have a DevOps problem, you have a culture problem. So That's right. I think it's, we all have solutions to, to address parts of it, but I think the organiz, this is the challenging part, right?

Because ultimately DevOps is a people and process problem, which is why organizations struggle with it, which is why things get complicated when there's organizational churn or departments that get merged and different philosophies get introduced as to where responsibility should lie and where authority should lie. Um, and we're constantly adapting to that across all our customers. Uh, our technology can do a lot more, but I think at the end of the day, uh, the human beings, uh, are, are a key part of it.

Great. Ellen? I might be the, the oldest person in the phone, so I still remember the days that I'm older.

I'm older, but, okay. But thank you. We'll not fight over it, but, uh, I still remember the days in the industry that, uh, companies like big companies provided the platform, and it was only platform, if you will, a developer.

Actually, you were miserable. You were forced to walk with something that, uh, was inefficient that, uh, that was kind of forced from the, from the top down. And then what happened, and this is the, the era that j o was born at.

Um, it all went to best of breed. Everything, every, the open source kind of, uh, exploded. And, uh, a lot of great tools came from, uh, from, from the bottom up.

And everything became best of breed. Um, mainly due to the open source success. And I think that what you talk about now and platform engineering is, is also kind of, uh, uh, emerging in response to that is that it also became very complex, the complexity, um, that now organization, especially enterprise organization, like think about 10,000, 50,000 developers organization that have to manage their code, have to manage their dependencies, have to manage their security, have to manage their delivery.

That became, um, a complex that drove, uh, or, or emerged the, uh, the platform engineering. And the goal is to still the same goal. We have to accelerate delivery of application.

We have to improve the engineer's experience, and we have to improve the engineer's, um, um, efficiency. So I very much agree with Koka, adopting platform engineering actually remove bottlenecks in silo. Um, and whether we like it or not in today's software world, it's, it's much more complicated to to manage it without a comprehensive solution.

And this consolidation will happen whether we like it or not. Fair guys, we have time for one more area. I wanted, and I'm gonna combine two into one and and get your thoughts on it.

So look, uh, during Covid the plague, you know, I, we saw the, I saw sitting with my desk and I have a unique vantage point when I sit here, I talked to all of you, low-code, no-code became a, a big thing, right? And, and to me, low-code, no-code kind of split into two things. There's, you know, low-code, no-code for citizen developers, people who aren't really developers, but just wanna do some rapid application development and then low-code, no-code to make developers develop using less code, make it easier on developers.

So let's called low-code, no-code for developers, for professional developers. And it, it's had an impact there. There's no doubt about it.

It, it's had, it's having a huge impact. The other big thing, look for the last nine, 10 months now, is generative AI sucks oxygen out of every room. We, we had to create an AI site here just because it was eating up all the news stories on our other sites.

I, I had nothing else to write about because AI sucked it all up. So we said, all right, we're gonna start at AI site and put it all there so we can go back to talking about what we always, but you know, all kidding aside this, the both of these trends and they, they, they do sort of overlap at some points, but both of, you know, in AI writing code, they're gonna have a tremendous impact on the developers who are watching this, on the developers who you guys, who your companies serve today, right? On your customers.

How do we, what role do you see? How is this gonna change the developers' everyday life? Who wants to go first on this one?

I can go first because I'm kind of gonna go, I love it. Actually no, no, I'll go back to my, that woman. Go, Go back to my first.

So sure. Maybe more junior developers, um, can write code faster. Maybe more of the intermediary developers become 10 X developers because they have this assistance.

But let's go back to that stat. You said 30%, I said 25 close enough of the time is actually spent on writing that code. We cannot forget about everything else because then we're just gonna have a bunch of non-secure code, not at quality that can't be merged with other branches that can't actually go to production.

So I, I'll repeat 'cause I'm so passionate about it, it's just part of it. And then my other caution to anybody looking into using this, back in April, I went on a European tour. It spoke to a lot of CTOs over there.

In our customer base hype cycle is like peak, right? We just wanna know what you have for code suggestions. Great news GitLab had something in beta, we could talk about it.

But you know, my questions, I was asking about competitive tools, they were looking at, do you know what's happening when your team is using generative ai? We won't, we won't say with whom, but regardless, do you know if you are leaking your IP inadvertently to go train models that maybe your competitors will be leveraging? And so I think we're at the tip of the hype now.

So now that, that was back in April. Now when I talk to them, they ask those really great questions. You know, what models are you using underlying to do things like code suggestions?

What is happening to the very, very private, we sell to highly regulated industries, often highly confidential IP that we're giving to the gen AI prompts that you're providing. So now we're, we're at this moment where I think people are starting to grasp, it's great, it's buzzy, it's going to help, but there's also all of these other factors to consider and take very seriously. I agree with that.

Okay, Go ahead. Uh, take it. Yeah.

This low-code, no, I was thinking of a low-code and no-code thing because really indeed interesting. And one why, like a discovery in the past few years is there's a whole world of those folks. Um, and, uh, but I, I still feel like they are not making their way into this, like organized what I think of as a organized software development that folks in this panel is dealing with.

But there's also some interest from like in that world. So the, the the, you know, this world domain seems to be remaining separate, but there's some interest in this other world to try to adapt some of like what we think of as a mature DevOps practices. And I was thinking like, I don't know your people really want that.

Um, so I'm curious if that happened. 'cause it seems like opportunity for us to be, you know, be more relevant and help the broader part of the world. But I like, is that happening in any of you guys?

Is it you guys seeing low code, no code that's on your radar there? I i, I think we're seeing it. I think I would say, um, what we're seeing a lot of is using it from rapid prototyping and then if you wanna make it actually a production application, you go back and build it again, right?

So there, there is a little bit of, hey, we, we get started there, but, but, um, we don't, we don't expand, um, beyond it. But just to layer on too, and, and, and as you, what you're finding is similar to what we're seeing too. And, and clearly it's early days on the generative side, but if anything, number one, you've gotta believe that all the shift left and the automation and the removing the burden from the developer and security built in and all of these things, if you're gonna have 3, 4, 5 x the amount of code they become not like nice to haves.

They're like mission critical to take advantage of some of the productivity gains, right? But, but number two, and I think this is sort of a statement of where we're at today. If you train copilots on all the code, by by definition you're getting a junior developer, right?

By definition, because not all the code in any repository is all good code. So I actually think there's gonna be another turn of the crank here because do I want 5,000 new junior developers or like a Nike's mix of some senior developers and and and whatnot. So I think you're gonna see a lot of evolution.

You're already seeing it on what do we train the data on? Like what do we train these models on? And I would much prefer if you have it at scale, to train it on all the greatest code in the world and then get, then really get superhuman strengths.

So you're seeing these sort of verticalization of, of some of these, of these large language models with the training data being the, the differentiator, not necessarily just the model itself. Well, I mean, uh, the large, the large language models don't encompass any runtime data in their, in their code suggestions. It's all static, right?

It's basically, it's, it's a super duper linter and as someone who, who has availed herself of that and gone down, you know, the hype cycle a little bit in terms of its actual, um, you know, gains of productivity. I think that, you know, what, what it will do is kind of what you said, but I think it will be a benefit that benefit to the industry is that it will turn course junior developers into editors, right? They will now become, I think, more critical to consumers of the code that they're accepting as suggested by the ai or potentially suggested by, you know, um, uh, a low code or no code.

That's right. Um, um, framework. And so I, my hope is that we'll get out of thinking of junior developers thinking at the syntax level and thinking more at the structural coding level earlier, you know, um, maybe earlier in their training, you know, just as you think about how junior, you know, young students who've maybe come out of CSS programs, have never had experience with like testing platforms, et cetera.

These things will become, I think, thinking about quality at a higher level will become more part and parcel because if you, if your AI can write your test cases, you'll be writing test cases while you're still doing your homework, you know? Um, so I think that we'll see an evolution of people kind of rising to become, uh, much higher level critical thinkers, I think, um, when it comes to development. Okay.

I think, uh, uh, Alan, well listen. The, the all, uh, AI or die, um, motion is for real. It's going to stay.

If someone here thinks that this will vanish and will be gone as a trend, it's not, it's going to be the magnitude of, of the cloud and the internet and, and big things that move the industry. Uh, but when we speak about low-code and no-code, um, it's before the Chachi PT and the co-pilot GitHub co-pilot kind of revolution. It, it's something that we know for years as Ska man, uh, mentioned, and the old drag and drop and, and quick, um, kind of movement, uh, uh, efficient developers.

It's, it's a, it's a different trend. I, in this form, what I see, maybe I'm wrong, I see infrastructure providers. So I think that, uh, for Jfr, or I'm speaking on, on behalf of JF Rog, the low-code, no-code and, and d AI and all of those things that are happening, just like two years ago we spoke about security.

It is our responsibility to provide the infrastructure that will support the involvement of what happened in the market. Now, we can avoid that, and we have a lot of good friends that were pioneers of the DevOps market, and they are not here with us anymore because they missed a trend. They either miss Kubernetes or they miss cloud native, or they miss cloud, or they miss a lot of things.

But we, it, it is our duty to provide our users the right infrastructure to build whatever they want. They want low-code, no-code, AI security, DevOps automation, comprehensive platform solution consolidation. This is an infrastructure job.

And therefore our, all of us here are part of mission critical coexisting platforms that the organization are adopting at the enterprise. They are not playing with ai. They are taking serious strategic decision as they did 10 years ago regarding the cloud.

And, and I'm for one, grateful to be, um, part of, of, of this change in the market. And ai, unlike what my colleagues here said, AI will replace some of the developers that we know today. I don't think it will be senior or junior.

I think it would be a completely different setup of what, uh, the machine does versus what the human people, human, uh, being does. Go ahead, say the last word. Yeah.

With the passion that Shlomi has just demonstrated in the last five minutes, I'm gonna nominate him to be speaker of the house. Okay. Well, there is a vacancy.

I think he, he's better off at J Frank who needs that aggravation, who would bought that job Anyway. We Should, I should speak less and do more guys. That's, uh, maybe we could All do, As Franklin said, Guys, we could talk about this all day.

And then some, we, we, we barely scratched the surface of the questions that we prepared for the panel, which by the way was, uh, Chat G p t prepared these questions I, I put it into, so there you go. Um, and then why did you Need us? Chachi PT could have Answers what did an say?

But anyway, I don't think we're quite there yet. Guys. com.

Elizabeth Lawler app map. Correct? Correct.

And of Course, Ashley Kramer from GitLab. Thank each of you all, all each of you. What a great panel.

What a great discussion. Enjoy the rest of DevOps experience, everyone. We'll see you soon.

Bye-bye. Thank you. Thank you.