Decoding Platform Engineering: A Critical Dialogue with DevOps and CD Leaders – The CD Pipeline EP 11

Hey, everyone. Welcome to CD Pipeline. Uh, if you haven't watched this show before, I should tell you my name is Alan Shimmel.

I'm the CEO of Techstrong Group and cd. The CD Pipeline is a joint, uh, adventure, venture, adventure, whatever you want to call it, between, uh, Textron Group and our good friends at the CD Foundation, which of course is part of the larger Linux Foundation. And, and if you're not familiar with the CDF, you really should be.

They're kind of the leading organization that is advancing the whole CICD, uh, movement. And they actually are responsible for managing many of the leading open source projects within the CICD world, including kind of household names for those of us in here, such as, um, Jenkins, Spinnaker, uh, and more. There's about, I think, eight or nine different projects within CD Foundation, and we'll go over them.

But if we spend too much time on that, we're not gonna have enough time to talk about what I really want to talk about to. And that is the subject for this, uh, for this episode of CD Pipelines. And it's decoding platform engineering, a critical dialogue with DevOps and CD leaders.

That aside, we're gonna dig into platform engineering, and what do we really think about and how would it relate to ci i, CD, and DevOps and Agile and everything else? Let me introduce you to what I think is a monster panel we're gonna have on here. Uh, first of all, I want to introduce you to DSI sonika, and hopefully I got that as best I've done so far.

dsi, welcome back to our show, man. It's great to see you. Why don't you introduce yourself?

Uh, thank you so much for having me again, Alan. I love being here. Uh, my name is, as you said, is D Ika, and I am the current board chair of the CD Foundation, as well as a member of the spinnaker Technical Oversight Committee.

Um, I'm just excited to be here and, uh, you know, waiting to see what the panel has to say. Thank You. Hey, the dc not to put you on the spot, but I got three projects in and, and my brain froze.

Yep. Um, do you wanna do the rest to tell, just to remind our audience the rest of the projects in CDF? Sure.

Um, so you mentioned Jenkins and Spinnaker. We also have Acton, orus, uh, shipwright, and of course, CD events. Um, all of the projects, like you said, are, are centered around, uh, CICD, and we are trying not only to advance the, the, the community of cd, but also think about what's the next set of tools and beyond, and how will CICD impact platform and how should platform actually recognize and contribute to CICD.

Um, and all of that is around the software developers' lifecycle. So that is, that is our main focus. Excellent.

Missed a couple, My Friends. I thought there were eight, but I look, he's the executive director. I wasn't gonna call him on it, but Gloria, go ahead.

What? Uh, but you know what? Wait till I come to you and you fill it in.

I got you. All right. Next up, let me introduce you to, uh, Nina ani ne nema Ani, excuse me.

Yes. Yes. No problem.

Thank you. Ella. NN Ani.

Uh, I'm a principal architect with AWS, um, and it's been three and a half, almost four years that I've been working with, um, you know, enterprise scale, um, AWS customers on DevOps and platform engineering. Uh, we've been building a lot of solutions. I've been, um, a TOC member for spinnaker in the past.

I have, uh, contributed to Argo cd. Um, and recently we started an initiative called Cloud Native Operational Excellence that looks at building better DevOps platforms for enterprise scale users. Happy to be here to talk to you about DevOps engineer Nima.

i'd, I'd love, I'm first of all, thank you for being here, and I'd look forward to having your input on this. Um, next up, let me introduce you to Tiffany Ja Jaha. Guys, I have to apologize.

I have Invisalign today, and I'm still, they're two days old and I'm still learning to enunciate better. But Tiffany, if you could pronounce your name and introduce yourself. Sure.

Hi everyone. Thanks, Alan. Invisalign is tough.

Uh, I've been there, done that as well. Mm-Hmm. My name is Tiffany Chacha.

I'm so glad to be here with you all. I am an engineering manager at Autodesk, and I lead the platform, um, Autodesk Platform Services support. So we work with dozens of platform engineering teams internal to Autodesk to represent our developer community, which includes over 200 engineering teams, and we help provide that initial support for all of their software delivery needs.

So, touching on many of the tech stack that, um, here, the folks at the CD Foundation are, are really helping to nurture and, um, and help the community, uh, work with, with different tools and, and for the purposes of, uh, better software delivery. So, super glad to be here with you all to discuss this in more detail. Tiffany, thank you very much.

Yeah, I definitely think it's that, like the CHSH sounds that I'm gonna have problems with, but next up, luckily his name's fairly easy for me to pronounce. Andrew Fong. Hey, Andrew.

Welcome. How are you? Hey, good.

How are you today, Alan? Good, good. Um, so I am currently CEO co-founder of pvoa.

We are building intent-based delivery, so to as a force multiplier for platform engineering. Um, spent most of my career in infrastructure, uh, from a OL to YouTube to Dropbox, and, you know, we really think we're building a next generation of platform tools. Companies like Rep use us to manage a hundred percent of their infrastructure in production at this point.

Excellent. And welcome. Thanks, Andrew.

Okay. And then last but not least is my co-host, actually. And, and since our last taping, she has a new title and a new job to announce as well.

We'll give her a chance to say it right here, but she's all thanks to A lot of open source really helps on a lot of these foundations and a lot of capacities, my friend Lori LaRusso. Hey, Lori, welcome. Thank you, Alan.

And yes, so I just, um, started with Perona. So it's all about open source. I'm the head of community and it's my second week, so stay tuned for lots of good things to come.

Uh, lots of interaction with our users, and I'm really excited to help, um, to help kind of shape the future of, uh, of Percona and their community involvement. That being said, I am here because I represent the CDF and Alan, you get everybody every time when you ask us to list the projects. Didi, he did it to me, puts you on the spot, and you just forget some.

I mean, there's only eight, but when I say only eight, these are eight amazing projects. And so let me just give you the list. And I am cheating.

I do have my phone in front of me. Oh, okay. So no Calculators.

Yeah, as Didi said, we have CD events, uh, Jenkins, uh, Jenkins, X Ortus, screwdriver, shipwright, Spinnaker, and Techon. So we kind of cover the entire smorgasbord of CICD, and I am absolutely thrilled to have this, uh, conversation today, um, to have the spinnaker team with us, to have Andrew and Tiffany to really kind of dig in to this whole idea of platform engineering. Excellent.

com, I initially had a pretty visceral reaction to the platform engineering movement because I, I felt like they were, and maybe it was just a marketing p play, you know, saying that that whole DevOps is dead long lived platform engineering, and I, it was marketing, I think, or maybe not. We'll hear what you have to say. But over time, I've, I've softened and, and come to respect what platform engineering is trying to do, and I think it certainly does have its place in this continuum of how we build, so build and deliver software today.

Andrew, I'm going to start with you if you don't mind. And, you know, I, I'd like you to kind of succinctly tell our audience what do you think platform engineering is, or what should they think? What should they know platform engineering is, and how does it fit into the kind of, you know, into the, the, the bigger picture, if you will?

So, I, I tended to think of platforms as sort of three levels. One is sort of traditional, it, you know, where you have, you have the piece of software you install, like probably what we're all familiar with in the early nineties, early two thousands. Then we kind of move to this DevOps world of CICD.

I think that's kind of a level two maturity of like platforms. It's like, let's get self-service. It's our i internal developer platform, IDP sort of discovery tools.

I think there's like a third level of platforms, which I think is, goes very, gets flows, applies under the radar right now, which tends to be more about how you do app full cycle application development. So how does your RPC framework work? How does your, how do you handle monitoring?

How do you build an entire end-to-end application? Um, which is a very different place. And I think most organizations right now are somewhere between maturity levels of one and two in that mental model.

Um, and I think it's a good discussion today to see like, okay, you know, CDF probably focuses more on the level two versus sort of the level three, um, uh, like altitude. But I'll pause there. Is that, I see how that resonates with people on the, on the panel Guys, what reactions to that?

Come on. Someone's gotta have an opinion. Yeah, I, I think that's a, a good way to look at it.

I, I will, I personally think that, um, the platform movement in itself is more of an obfuscation of the tool sets below it. Um, and being able to have a rich set of tools integrate into the platform concept will be always be driven by the DevOps folks, will always be driven by, uh, CD folks who are trying to give excellence with the tools. Underneath.

The challenge becomes how do you take, um, a lot of different types of tools, uh, you know, and then create specialized platforms that, that meet your service needs and your service goals. Um, I, I think that's one of the reasons that, uh, the, the canoe project is so interesting. Uh, as they try and figure out, okay, you, you already have tools and things you'd like to use, how do we give you a platform on the fly with that that is, is useful and available?

Um, so our focus of course, in the CDF is the tool excellence and, and having that ability to, uh, separate your software delivery, uh, life cycle workflows, um, as well as making sure that the tools underneath your platform are excellent. Fair. Anybody else?

No. So let me, let me jump in then. I've been known to have an opinion now and then, so Andrew did a good job of delineating different levels, if you will, uh, of, you know, of, of engineering, of platforms and, and how, how this plays out in my mind.

There's a couple of things here that actually are good things. Number one, I think one of the problems we've had with in, in DevOps in general has been the move to just throw more stuff on the developer's back, right? DevSecOps?

Yeah. Let's make our developers security people, they're not security people. They, they care about security testing.

Well let the developers do more testing, right? Uh, the developers are probably the highest paid people in the food chain right there. The idea of just throwing more stuff onto their plate until, you know, the, the, the proverbial straw that breaks the camel's back doesn't seem like a very efficient way of doing things.

And that includes having the developers try to architect and maintain their platforms, right? So the idea of having an yet another team and, and the idea of building another silo, I get it, is anti DevOps. But the idea of having a team that helps facilitate a, a working platform instead of tools that the developers can then do what they like to do, which is code makes perfect sense to me.

I also think that a lot, and back to Andrew's, you know, kind of delineation of the different kinds of platform and platform engineering, I think a lot of the ops functions that we've historically had that maybe would give it short shrift in the whole DevOps movement are still very valid and necessary. And platform engineering gives those ops functions, a a new home, a new fresh breath, a new name, if you will. And if that's all it does, it's still helping shine the light on these very necessary, uh, functions, these very necessary tools and processes and so forth.

I think this is a good time for Tiffany to kind of jump in because this is in essence what she does, right? Like manages the team of, so, Tiffany, what are your thoughts on what Alan just said? Yeah, I actually, I love how everybody mentioned sort of two underlying factors when it comes to platform engineering that I, I'd like to highlight for anyone who's listening, the first being that sort of scale slash customer facing or developer facing aspect to it, right?

A lot of, like, I, I think there was a lot of initial pushback on platform engineering as sort of this replacement to DevOps. But when you think about it, the reason why we've introduced platform engineering or platform solutions is to better address the needs and concerns of the developers that we're serving. And so, in effect, dev platform engineering is almost like the DevOps practices scaled in a way to meet enterprise or bigger organization needs.

And doesn't have to mean that you have a thousand person and a organization or you know, a thousand developers that you're, uh, serving, but it means that there is a sort of stakeholder management or community involved in the usage of the different solutions and automations that you have in place to deliver your software code. The second aspect that I think is worthwhile to highlight in platform engineering is the sort of evolution of like, the creation of a platform, which I think a lot of traditional DevOps didn't necessarily have their development or their work tracked in a roadmap and in sort of this, this sort of more traditional dev, uh, development oriented workflow. So one thing that we're starting to see is, you know, these platform engineering teams, the way that they're set up is they'll have a product manager, they'll have a roadmap, they'll have plans that sort of mix, uh, development work, platform development work with operations work, right?

And that further extends the collaboration with security teams, networking teams, infrastructure teams. So I, I do think that there's a lot of, um, now like a, a home for DevOps oriented work that traditionally didn't really have that much of a home in traditional DevOps. So I will say that there's a lot that kind of got introduced with platform engineering, but I, I think it's a wonderful idea to look back at, you know, what does platform mean to you?

And like, what does it mean to build a platform? Because at the essence of it, that's what platform engineering teams are doing. Can, can I, can I jump in?

Um, sure. On that? I, I think one thing, and I think, um, that said this earlier, that, um, like c, like CNCF and CDF are focused on tools.

I think that the number one difference between platform engineering and the way, like the approach of DevOps, the approach of SRE and all the rest, right? Has been that it's workflow oriented as opposed to tools oriented. And I think if you start from the tools, you fail every single time, um, because you're look looking at a very specific slice of the, of the workflow, and you're not actually looking at the totality of what the, of what's trying to be accomplished.

So I gotta jump in. com, I have to say, anyone who tells you that DevOps is focused on tools, does it know DevOps, right? If you speak to Patrick dubois or John Willis or Damon Edwards or any of the people who started the DevOps movement tools is always third, it's about culture, right?

It's about culture, it's about people. It's the tools. Tools are interchangeable today.

Today it's Jenkins, tomorrow it's spinnaker to the next day, it's something else. But DevOps isn't about if, if you, if you are focusing that DevOps is tools, you got it wrong. So I, I want to, what I say there is that what you said is a focus on culture.

What I said is workflow. And I think workflow is a product. Culture is not a product.

You cannot sell culture. Um, and so culture is an attribute of leadership, right? And leadership actually has to actually do that, right?

And so what you've pointed out is that leadership is failing at creating a culture. Um, but what they're, and what they're doing is empowering the social Only of DevOps isn't working. I, I assume you're assuming DevOps doesn't work, and it must be a failure of leadership and culture.

I, I, I disagree with that. Um, if that's the case, I think if you're gonna Developer, yeah, Excuse me. Uh, I would say that if that's the case, right?

Then you'd look at things like the DX surveys and all the rest, the NPS scores of engineering organizations, right? They'd be significantly higher if it was working, right? So all like, let's, let's forget DevOps, forget everything else, right?

Let's just take from, uh, from a factual standpoint, how do engineering organizations feel today, right? And they feel disempowered. They feel like they can't get their work done, and they feel that, um, that the workflow is broken, right?

So now we can, we can say that there's like, doesn't really matter 'cause we can just go back to first principles. It doesn't really matter what, um, how we got there, right? We have a problem.

So from first principles, right? Like we can split it apart into three pieces, tools, technology or tools and technology, culture and, uh, workflows and, and the product of the said thing, right? And we can look at each of those independently, right?

And we can say, how, how, how are they, how are they doing? Right? Um, from we know that there is no workflow, right?

We can look at the, the, the engineering teams are basically saying there's no workflow, right? If you look at the surveys that like that come out today, then you look at the tools, they like the tools, they're just complicated and they'll fall in the middle on culture, right? And so, like, all three of those today have some deficiency or some major deficiency.

So I'm not saying DevOps is failing. I'm saying that like in totality, right? Like it's not actually producing on either side of it.

So, Andrew, let me ask you a question. You are looking at today's surveys. Let's go back before there was a DevOps.

Do you think it was Nirvana and everyone was happy? Do you think it was bad? I'm say 12 ago.

I'm not saying, oh, I, I don't know if it matters what 12 years ago looked like. It only matters what today is, right? Because it's like, the question is how Might we, well, you know, there's an old saying, when you get a little older, you'll learn this.

Those people who don't learn history are destined to repeat it. Oh, it's learn. And what i's telling learn.

You, I've been in this game for 30 years, and when you go back 25 or 30 years ago, there weren't a lot of happy campers. There are a lot of burnt out people. And the, and the, the, the banging between developers and operations and, and testers and security was pretty bad.

Things have gotten better. The, were they perfect? Are they perfect?

Will platform engineering make them perfect? No, they're never gonna be perfect. It's the nature of the beast.

Oh, I think that's totally true. I think that the, the one thing that changed, right? Because like, um, the one thing that's changed, right, is if you look at the current set of talent coming up through the industry, they've never seen anything but a cloud native world.

And so that shifts the perspective of what they expect and how they expect the tool chains to work, right? And how they expect culture to be and how they expect, right? And so if we, we can look back and say like, historically, yes, it was not great, but we also have to look at like, again, from first principles, like what does the current set of talent in the industry look like, right?

What do they, what do they want? How, how have they expressed? How are they expressing their needs?

And if you, and then you project out five years, right? Like, what do they want is not the world. Like, 'cause they've, they've seen enough of what's here today that they're saying, you know, I'm 25, I've never seen anything besides AWS and now I'm a tech lead.

I'm getting, you know, my career path is the X. And they're saying like, look, I need a different set of tools. I need a different way of operating.

Um, I'm not saying platform engineering is nirvana. All I'm saying is that, uh, that the, that what is there today doesn't work for the current set of talent in the, in the industry and coming up through the industry. And they're basically saying they're rejecting it.

So I'm gonna jump to Nima 'cause I've seen you nodding your head on quite a few points. Um, speaking of companies, he listed yours, so why don't you kind of weigh in a little bit and give Andrew and, and Alan a chance to kind breathe for a second. Yeah, definitely.

Well, I mean, very interesting conversation so far. And I think, you know, when I look at DevOps and the evolution to platform engineering, I think for me at least, things have changed are that, you know, practices of deploying to production are actually increasingly becoming more complex. And if you look at, um, you know, deployments, I think, you know, there are, or when you look at DevOps engineering or platform engineering, you have to look at the capabilities that you want to kind of deliver to your, um, to your end users.

And I think it's becoming increasingly more complex to think about the capabilities that are available or the requirements that your developers have, right? There was a point in time where the only requirement for deploying to production was that you actually find a server, you drop your binaries there, and then you are kind of open the HCTP portfolio, the world to access your application. Things have changed quite a bit.

Right? Now you have to deploy to cloud, you have to look at continuous delivery, you have to look at running tests, you have to think about security, secret management, identity access, you know, load balancers, DNS servers. So there's a lot more that you need to think about.

And I think DevOps engineering was actually giving you practices and patterns that would solve it. But one of the things that I think we, we are seeing now is that there is a lot more tools now that can act, that can give you the requirements that you have that can actually provide you with the set of capabilities that you require. So I kinda agree with what Tiffany said earlier, that, you know, platform engineering is created to solve for this scale.

You know, how many engineers you want to support, how many applications you want to support, and how many users you want to support. But more importantly, how you can actually provide consistency for all your application developers to actually do the same thing over and over with less deviation across the board. And how you can actually make it simpler for your application developers to think about, you know, deploying their applications.

How can you reduce the number of, um, you know, requirements that they need to address and provide consistency and reliability, right? So if you start thinking about DevOps engineering in the context of capabilities that you want to provide, and then the tooling that you want to support to provide those capabilities, and then to kind of create the culture and create the set of practices so that as your application developers change teams and, you know, move from one side of organization to the, to another side of organization, they actually have to deal less with, um, you know, the new set of tooling, the new set of overhead. I think that's the purpose of platform engineering.

So when we look at platform engineering, at least in the context of conversation that I have with AWS customers, it's about creating that consistency. And it it's about reducing choice, um, and, you know, giving you the right wiring, uh, for the set of tooling that you have so that eventually you can bring, bring that scale and consistency to your application developers, right? Um, I think it's important to think about consistency when we talk about platform engineering.

The whole effort of engineering is to make sure that we have consistent, reliable and secure practices over and over available to application developers. I'll, I'll make you pause there, but I, I'd like to hear Whatever. No, I, I agree with you.

The only point I would take Neir is I, so I personally was never a big believer in the term DevOps engineer. I don't, I didn't think that was a real job or a real function. I do think a platform engineer is what that role should be, right?

Making that platform totally. I think we have CICD architects, engineers, if you will. Um, but I think at the end of the day when we talk about this, it's about how do we let the developers work faster, better, more quality, and more in concert with ops?

And whether those ops or platform engineers or something, what, whatever you're gonna call 'em today or yesterday or tomorrow, it it that, that it has to be a better connection, a better fit where people's you wanna call workflow processes are more defined. It's, and so it allows 'em to go faster, better. And that really is what we're, we're after here.

I think. I think one thing that we also need to be careful about is that, you know, um, if you look at the CNCF landscape, and this goes back to what Andrew also said initially, there used to be a point in time where you could deploy Jenkins or you could deploy a spinnaker for your application developers. And they pretty much had everything they needed in order to deploy to production, right?

Spinnaker did a particularly good job in, you know, creating that developer workflows and having like an all inclusive tool that you could give to your application developers and kind of define their practices. It, now, if you look at the CNCF landscape, there's like 370 different projects and each one of those projects only addresses a subset of the requirements or the capabilities that developers need in order to deploy to production, right? So when we think about platform engineering, it's a matter of figuring out first of all, which one of those 370 you want to to choose, and how you want to compose those tools with one another to eventually bring the practices closer to what they used to get with something like spinnaker, obviously there's more to it, right?

But spinnaker did a lot of stuff at one point, and, you know, a lot of the customers that I talked to at AWS are the ones who, you know, wear on a spinnaker or uses spinnaker for a long time, and now they're in the process of modernizing their platform, but they need to rebuild that spinnaker experience with these 370 different tools that are available to them. So the engineering aspect is deciding about choice, is deciding about composability, is deciding about the capabilities that they wanna expose, and the engineering aspect is them putting them together for, for the cohesive experience to become available to the application developers. So since we've mentioned Spinnaker, um, and I talked about this before we went online, uh, Andrew had a really nice, uh, LinkedIn post the other day about Spinnaker.

So when Nima talks about how, you know, it used to do one thing and now you have to really like rethink your processes. Andrew, what, like, what are your takes on this? Because I know you've got some, some opinions.

I think that Spinnaker was, so, I think Spinnaker is built for an era of individual machines. Um, and it's been adapted for cloud native workflows. Um, you can see it in sort of how it's been built.

I think it fails on a couple dimensions. One is manageability from, like, you need a team to manage it and set it up, but like, like every single thread, right? If you go into or Slack is just like, how, how do I set this up and how do I upgrade this?

Right? Um, that's like one big part of it. And I think the other part is what Nima touched on is that the composability of it is low.

You have to be a developer to compose on top of it. Um, there's no way to squat new backends into it without actually being a, almost a full-blown developer. Um, and so that I think limits the ability for it to stay as a central orchestrator.

Um, I think what it has done exceedingly well, and I think the most underrated, um, blog post probably in the last five years in delivery is the managed delivery blog post from Spinnaker. Um, that entire post is my opinion, like probably what the next three to five years of c of CD should look like for teams. But it's very, very, it flies under the radar.

Um, but that post, it's like, I think the website is managed delivery, literally managed do delivery outlines exactly the pattern, in my opinion, that people should be looking at. Um, it flies under the radar and it's not, it, it requires a lot of leadership buy-in to get started, I would say, because it is going to separate responsibilities in a way that people are not used to. Um, but if you do it, it actually things flow way better from what we've heard.

Um, just like talking to people that have adopted the managed delivery pattern. Um, but it is flies under the radar. I don't think they did enough to publish it and like, actually push on that.

If I had to say one thing to c ncf F like, or CDF, like that workflow is substantially better than everything else Out there. That's like we should do. com or Cloud native now then.

Yes, Andrew, if you want to take that up, I'm giving invitation. We'll put it on Cloud Native Dead, Larry. Uh, so did DC as person on the Spinnaker TOC and the CDF, uh, board chair, like, why are we missing, why are we missing this?

Why are, why is this the best kept secret? Um, you know, what, what's your take on that? Like, how, how did we deviate from something that could be so big?

Or how do we then push this forward and really kind of shine a light like Andrew said, that we should be doing? I, you know, I've heard a lot of wonderful things today. Uh, let me just say that first, I think the contributions of everyone has has been really, really, this is a great topic.

We should extend this to more shows around this topic. 'cause there's so much to unpack here. Um, and I think that, that, that's one of the core challenges because even in the managed delivery scope, you're still saying, Hey, there's a group of people who have to understand how to code and, and use this tooling to accomplish a thing.

So that, that doesn't shift into Andrew's point about needing a team to run Spinnaker. I I completely understand that. It's a, it's a very flexible tool.

Um, and it's that flexibility that gets, you know, folks in trouble. Uh, and so, you know, we in the spirit community, uh, recognize this and are working to make the lower the bar to entry. So that's one of the things that we're actively working on.

But I, I, I will call out that the thing that we're, I'm not hearing about is the other people who are moving into the space of needing to use these tools like data scientists, um, who need to be serviced and don't have this depth of understanding on all of the pieces. Is this the same thing that's happening to the developers? And so we are talking about all of the pieces, like we, we've mentioned that there's a software developer lifecycle workflow that we need to account for, and that those are gonna be different and different people have different needs in that space.

Managed delivery gives you that flexibility to kind of move around in that space. But you still need someone to be the expert to kind of guide that proc to practice and then map out very, very clear templates that people can use and say, okay, this is the way you get this to production. 'cause most of the, the developers that we're actually talking about, they, they having them having the need for them to learn all of the different pieces of the platform and understand how they come together and understand the DNS and understand all of the configuration, that's a lot of challenge for a new developer coming out of college who's never seen these things.

It's a lot of challenge for the guy who's been working on one thing for 25 years that this, like he has focused in on it on a product or a feature, and then it's like, Hey, stop, learn all of this new stuff for something you're gonna use once or twice. 'cause once it's set up, it should just work. And that's one of the things I will point out about spinnaker is that once you get it up and it's just going, it just works.

And so I I I will, I will point out that managed delivery actually, uh, discourages the use of templates and encourages exactly. That's point. It's, that's my point.

It's just about requirements, right? Right. It's just saying like, define requirements for it, not, not templates to, you're not supposed to have to go understand DNS to use managed delivery.

You're supposed to be able to just deploy with your requirements of my application requires X, Y, and Z at the app level. Um, right. But coming from the opposite direction, if you are a CEO and you're going, Hey, I want everything stable, I wanna be sure that people are following the best practices, you, you want something that, you know, isn't just like, Hey, giving your set of requirements, like everybody's gonna do this thing, is the mindset, at least in the conversations that I'm having in the community with leaders that like, no, how do I make sure that, you know, there's DevSecOps, there's all these other pieces that need to be checked off.

I need a way to ensure that people are going through all of the steps all the time. And, you know, you're, you're now mixing the, the managed delivery aspect and this is how it's suggested to do versus how leaders want their businesses to run. And this is the crossroad why this conversation is so interesting.

Right? No, totally. I I mean, I think that the, my take is that, this is where I go back to sort of like what you look at.

Uh, I I tend to look at it as, okay, there's a leaders that you're selling to today, and then there is the people that have only ever grown up in cloud Native. And if you come from a world of where you look at something like Kube, right? Like the, the, the irony right, is under the hood, who Kube is not implemented as a checklist, it's a convergence system, right?

And so like all of the tech right, that's there, all of the tech that's there, that works the way people think it works, doesn't actually do the thing they think it does. Yeah. So guys, we're in the middle of a research thing here at, at Techstrong on a, a large project called DevOps, uh, DevOps next, right?

And we're looking at kind of what's next in DevOps, 12, 13 years in. And it, it's based on surveys of people. It's based on interviews and it, but it's also based on what people are reading on our sites, cloud native DevOps, security Boulevard.

And here's an interesting thing, and, and Andrew, it goes to what you were just talking about about for today versus tomorrow and and beyond. We all think cloud native is dominant and cloud native is dominant on new applications. Like if you have a greenfield, you're, you are building it in a cloud native environment.

But that doesn't mean that there's not a, I don't want to curse a, a bunch of of work, a bunch of applications, a bunch of infrastructure out there on AWS and the others that are not cloud native that we can't, you know, maybe over time they'll be converted, maybe not, right? There's, but there's a lot of stuff that's not cloud native. Even something as like DevSecOps.

'cause I come from a security background, I think of course everyone is, you know, looking at DevSecOps and moving security left and and whatnot. But the fact of the matter is a relatively small amount of enterprises have kind of really adopted DevSecOps. You know, we tend to live in a bubble and, and people on this panel as well, where, you know, we're always looking at the latest and greatest we're the, the classic early adopters of, of new technology.

But when you look at that mainstream, right, and the classic models of crossing the chasm, 35% of the mainstream is a little earlier, and then there's 35% later adopters, and then 15 or 20% laggards or whatever it is. I think it's important to remember there's still a crap load of people who used Jenkins, right? The last CDF survey, 40% I think was the number of people doing C-D-C-C-I-C-D use Jenkins.

And, and I'm not disparaging Jenkins by the way, I'm just saying that those are the numbers. So it's good to say what we want it to be and what it should be, but we also have to recognize what, what our listeners, what our watchers here are dealing with. A lot of them, you know, say, I wish I could do cloud native, but a lot of 'em say, I wish I could implement some of the stuff, you know, that we we're talking about here.

But a lot of them can't, unfortunately because they, they're stuck in legacy land that's not Lego land. But, um, so I think, you know, we need a pack. I'm sorry, Dan.

Yeah, so I think one of the things that I, I, I get this question a lot, you know, working with a lot of AWS customers, there's a lot of legacy applications that run, not necessarily on Kubernetes, but other parts of AWS there's a lot of applications on premise that, that customers use. Um, so one of the things that is important to, to kind of remember is that, you know, there is a separation between how you manage your applications and how you run your applications. And I think a lot of the conversations that we have at least recently with a lot of the customers is that, okay, if you wanna go towards modernizing your DevOps practices and your platform engineering, you can have the management piece be modernized and still you can create the ability for this modernized platform to manage your legacy application, right?

It doesn't contradict that, you know, you have a stuff running on bare metal, right? It doesn't contradict that there are parts of your application that have Jenkins and, you know, kind of execute the workflows for them. Um, it is important to recognize this part of the modern modernization work that you wanna put in place.

There needs to be some piecemealing work that, um, you know, goes into play. And part of that piecemealing is going to involve, you know, revamping your platform and having your platform kind of, um, you know, uh, cater to the legacy application as well. So I, I don't necessarily think that people need to think that they're stuck with their legacy application only because they're using legacy tooling.

No, there is hope, there is a pathway to migrate to more modern stuff. It's going to take a little longer, it's going to be more, um, you know, there's gonna be more challenges and it's gonna require more efforts. But, you know, the path to migration is there and I think that's an important message to get out and let people know.

Absolutely. Absolutely. Guys, this was a lively discussion, but we're coming up on time.

Tiffany, I feel like we haven't heard enough from you though. I'm sorry to pick on you, but what do you think ha having ing to all this? Any thoughts?

Yeah, I'd love to touch back on the managed delivery component because I think Autodesk and that ecosystem kind of sits in between level one, level two and level three, given that there's just been so much history at Autodesk with, you know, initially having like executables things that you download on the desktop and then now like moving towards a more cloud ecosystem. And a lot of that has changed and we see so many different kinds of workloads. Like in my day to day, I see so many different kinds of workloads.

And one thing I've realized is that while you can have those ideas of modernization and like, oh, you know, this would be the ideal. A lot of times you have to be okay with sitting in the middle of all of that because it's work in progress. Like, we have a ton of things that are configured as code, right?

They're not necessarily templates, they're not necessarily self service. And the way that you get your, uh, your code into production is, your applications into production is through configuration as code. And it's a lot of configuration and it's custom configuration.

And that's not even including the fact that you might have a complex workload, right? And that's something that is really helpful for people to like note, especially as they're developing platforms and engineering the solution is like, how are you gonna bring the rest of your community with you? Um, and that's something that, um, a lot of people forget as well.

Like, you know, we get so busy, we have the frameworks for the platform engineering, then we forget the culture piece of it, right? So how do you throw in the culture piece of it back in and ensure that developers have a good sense of like, where this is going and is it sustainable and, and all the things related to that. So I, I just wanna sort of leave the, the open-ended question of, of that because I, I think a lot of support work developer relations type work is not really mentioned a lot in the conversation around DevOps, but it is very integral.

Like who, who do you have in your organization that's going to nurture the community and ensure that, you know, everybody's included when, when it comes to automating different workflows. So just something I'd like to, to leave everybody with here. Thank you.

Thanks Tiffany. Andrew, your closing thoughts? Um, my closing thoughts are, I think it is an exciting time to be working in the space of platforms right now.

Um, I think that there's, that the amount of change just in the last 18 months is so high that it's like, it's really nice to see people actually caring about the space and realizing that it can be a force multiplier for organizations as opposed to cost centers, which is great to see. Also, Andrew, we didn't catch your company's name, if you wouldn't mind. Oh, wanna go check in?

Uh, proa Proa. Perfect. I just wanna make sure people can get there.

Nema, I don't think you have to spell out AWS but your closing thoughts. Um, yeah, I agree with, um, with, um, what everyone else said. I think this is super exciting times for platform engineering.

I think there is, um, there is a lot of, um, new, um, technology that is coming out on a daily basis. There is a lot of interesting new challenges that you see. Um, you know, companies like credit, uh, Upbound, um, you know, you name it Acuity, they're solving at different levels of the platform stack.

And I think, you know, as these new solutions come out, it becomes more and more interesting for people to wanna compose this together and build that platform. So I think we're gonna be constantly on the lookout moving forward and deciding about what are the tools that solving, improving that, that productivity by smaller percentage. Um, but those smaller per percentages at a scale, they come at huge value.

So, um, engineers are gonna be on the scouting, um, phase. They're gonna be looking out for these new technologies and pick up things so that they can improve the productivity of their application developers. Certainly exciting times.

Excellent. Thank you to dc You wanna give us some closing thoughts? Yes.

I, I just wanna say that, you know, a lot of this conversation centers around cloud and I, I, it brings me back to my original conversations as I was beginning to join the CDF with Ericsson and some of the things that they needed to deploy to just aren't cloud, right? And you, you have this whole space of other things that need to be accounted for and these platforms as we move forward. And I think that's what the CDF is thinking of, like everything else from the tools perspective and how we connect this to make better platforms.

Um, I'm, I'm gonna give a, a, a plug for something that NEMA is working on, which is the Canoe project. I, I encourage folks to check that out, just the thought process behind that. io.

And, um, it, it is, it is building platforms from tools that you, that you already have. And I think that's a, a great way to approach it and extend it beyond just this conversation of cloud. But how do we get that to like our, our data scientists?

How do we make this available to all of the other things that you might need to reflect to as well? Excellent. org is that it?

Doo Excuse me. Okay. Check that out.

Laurie, take the last word. Thanks Alan. And again, thank you so much for this partnership with Techstrong.

I think one of the things that, uh, that I love about this show and I love about this CDF, is this idea of community. And so I highly encourage you to join our Slack channel and get involved in the conversation. You can have your own hot take conversation and really kind of dig into why people think the way they do.

Why are they doing business the way they're doing business, why this is such an important topic and how it can really level up your team and your skillset. And, you know, it's all about finding the solutions that work best for your company and being surrounded by individuals that can help you get there and have these kinds of dialogues, which help you think more about what you're doing, how you're doing it, and maybe you go hard left instead of what you thought was a hard right. You know?

And so again, the Continuous Delivery Foundation, it's a great place to have these sorts of conversations. And so Alan, thanks to the panelists. This was so much fun.

I look forward to maybe coming back in a few months to see what's changed, what new innovations you guys are talking about, and, um, and bringing these topics again to light. Absolutely. Hopefully not a few months.

You can visit it before that. Speaking of CDF though, just a quick plug. Open Source Summit's coming up in Seattle, uh, soon.

Yes. CDF is doing things there. Yeah, so we'll have CD Con, uh, we'll be in a room.

It's two days on, um, Wednesday and Thursday, I believe. Uh, we'll have a state of the Union. We'll have panels, we have lots of talks lined up.

We'll be there with swag in the back of the room. Lots of cool stuff to give away and lots of cool things, uh, on the agenda. Cool.

Wanted to make sure we hit that. Thank you guys. Thank you all, Andrew.

We hope your child feels better. Thank you. We, we, I think a lot of us have been through that kids are resilient, but it just, you know, watching them be sick is not easy.

Um, but to all of you, thank you so much. This was a really great, lively discussion. I have no opinions on this at all, so I apologize.

But, um, until our next show at CD Pipeline, keep up what we're doing and until then, everyone be well. Bye-Bye.