In this episode, join special guests Nigel Kersten, KasparvonGrünberg, Fatih Degirmenci, and Ronan Keenan as they discuss the recent surge in popularity of platform engineering and how these teams are fast becoming vital to enterprise success.
In this episode, join special guests Nigel Kersten, KasparvonGrünberg, Fatih Degirmenci, and Ronan Keenan as they discuss the recent surge in popularity of platform engineering and how these teams are fast becoming vital to enterprise success.
In this panel discussion they explore:
Ben Ford [00:00:18] Hello and welcome again to today's episode of Pulling the Strings Podcast, as always, powered by Puppet. My name is Ben Ford. I lead our community and our ecosystem teams here at Puppet and I'm pretty active in our community; we may have run across each other every now and then. Today we're doing something a little bit different for us. We're holding a roundtable panel discussion, so you'll hear maybe a little bit less of my voice and a little bit more of the guests. Maybe that's a good thing. Usually I do a quick introduction of the guests right now, but with this format, we'll sort of do it more hot potato style, kind of a quick introduction to speed things up a little bit, to sort of go around the panel quickly and ask everybody to introduce themselves because this is the first recording of 2023. We'll also add on something that we're excited about changing or something new or interesting that we're looking forward to in the new year. So it's going to start off with my old coworker Nigel. So hey Nigel Kirsten, Field CTO at Puppet. I was actually just looking something up there to try and make sure I got the pronunciation right. I just discovered this really slightly obscure version of broccoli called brassica. Over here from Italy that got sent to me in a veg box. This year I'm going to be excited about exploring the rest of the species of brassica. I also just learned this year that the broccoli family is much larger than we realize. It is like broccoli and cauliflower aren't really that much different from each other, even though they look very different. I have Wikipedia right here in front of me, so I can tell you that the family includes cauliflower, cabbage, kohlrabi, brussel sprouts, broccoli and collard greens, which I think is pretty amazing. If you ever make your own broths at home, do not use any of these plants in it because they'll make your broth taste very bad. Welcome to cooking with DevOps platform engineering stuff. You want to pick the next person to go, let's go to the next show.
Kaspar von Grünberg [00:02:11] So I'm Kasper. I'm the CEO of Humane Tech. We do a bunch of tools, at this point, to build internal developer platforms and in 2023 I am very excited about horses. Actually, I just moved to the countryside and I am rediscovering my love for horses.
Ben Ford [00:02:30] I remember when I was a kid, I rode a horse one time and I fell off and maybe many years later I should be getting back on a horse. But I don't know. That's a big deal to me. That sounds very exciting.
Kaspar von Grünberg [00:02:43] Fly to Berlin now. I'll help you master this.
Ben Ford [00:02:48] That sounds great. Who's next? Fadi.
Fatih Degirmenci [00:02:51] My name is Fadi, and I work at the Lance Foundation, leading the contents of Foundation, which is an open source community, hosting some of the popular open source content that are projects such as Jenkins, Spinnaker, Persia. For 2023, I will try to reduce my caffeine consumption because I drink a lot of coffee and I will start drinking more cortado because it has higher milk.
Ben Ford [00:03:19] It sounds great. Are you drinking coffee today?
Fatih Degirmenci [00:03:21] I had twice, in Sweden we drink a lot of coffee. So that is something I need to improve and it is my consumption.
Ben Ford [00:03:29] Right on. Well, that leaves Ronan.
Ronan Keenan [00:03:31] Hi everyone, Ronan Keenan here, I am director of research at Puppet and Perforce. This year I'm looking forward to traveling a lot more. So top of my list is to get back home to Dublin and Ireland and visit certainly more than I have in recent years. So that's something I'm very much excited about.
Ben Ford [00:03:51] I think we're all excited to travel a little bit more. I have my first conference planned for just a couple of months from now in Ghent, and I haven't been there since 2020. Very much looking forward to it.
Ronan Keenan [00:04:04] You should both swing by London. If you're going to be in the area, we'll get to actually hang out. I like that idea. Maybe you can come with me to Belgium, Ronan, and then we can all go hang out with Nigel for a couple of days.
Ronan Keenan [00:04:14] Yeah, we can do a quick European tour.
Ben Ford [00:04:17] Beer and fruits. Well, it wouldn't be fair to ask everybody to say the one fun thing about 2023 without doing one myself. Mine's a little blase. My partner and I picked up the motorcycle habit over pandemic. So this is still kind of new to us, but it's a lot of fun and I'm really looking forward to spring weather around here, like the ice makes for real treacherous riding over the winter. So that's one of the things that I'm really looking forward to in the coming months. Let's go ahead and kick off our panel, sort of set the stage. So I think maybe the obvious first question. Let's just sort of start off by someone explaining what is platform engineering? Maybe Nigel would be a good person since you talked about SODAR earlier.
Nigel Kirsten [00:05:13] So how about I'll jump in with the definition we did in SODAR. I don't want to make this sound super prescriptive in a way because I think there's lots of other folks in the panel who could appends to it and augment that. So I'll give you the sort of type definition we worked with, which is like, first, let me start with the preface that we are terrible in technology at naming things, and the word platform has been used and renamed and abused in the last 27 years that I've been working in tech, at least, to mean many, many different things. And so here what we're talking about is delivering services generally, infrastructure, but often sort of high level ones as well to your development teams. And basically, if you think about this as the discipline of designing and building self-service capabilities for your developers, the goal here is generally to minimize cognitive load and to enable your software to be built more quickly and in a less frustrating manner. The big thing that's sort of been different about previous attempts at platforms which have been around for quite a while, is that folks are taking a product mindset to this. They're not just building capabilities inside their organizations that people have to use. They are treating their users as a market and building products, trying to design things that they actually want to use and that they keep continuing to invest in. So that's sort of what we worked with for the State of DevOps report. But you know, this is a big space and very keen to hear other folks.
Ronan Keenan [00:06:38] So if I can I chime in really quickly, I think that's completely spot on. I'm always now, I mean we've all been talking about this for years now and, you know, it's evolving. Our understanding is evolving. I think that pure focus on cognitive load and the developer side and the self-service element always implies that it's about, "I need something, how do I get it? How can I get things that help me work without having to ask other people?" And I think there is a second very important element to all of that, and that is standardization and building systems, which are platforms, if you want, that drive standardization by design. So I'm a developer. I am building something. Developer self-service, the aspect of developer self-service helps me on the day one operation. I need a database. I need this, I need this. But then if I'm following certain paths, the systemic set up drives standardization by me using the system, I am streamlining and standardizing. The system itself keeps the difference in configurations, for instance, the config drift low, all of these things. And it gives me golden paths that make it easier for the entire organization to actually manage and maintain the engineering or the software landscape. So that's increasingly important in my personal definition of platform engineering that it's not only day zero, but it's actually day zero to day end, it's the full thing.
NIgel Kirsten [00:08:26] This is fantastic. Like, I think what you've done there is you've unpacked a bunch of the sort of assumptions and benefits, and that may be sort of somewhat too terse definition that I gave it. But standardization is totally it. And I think one of the ways I really like the way you talked about standardization by design and golden paths is that there's sort of an old school IT standardization and centralization mentality, which was about "we're going to define what everyone has to do and then make them do it". But I think the difference we see around platform teams that you were getting at in your description there is that platform engineering is about taking a more agile product like development focus of going, well, we need to standardize, but it needs to be something that works for everyone, that's flexible enough. But also, as you say, the the benefits of standardization are for the whole organization, not just the individual developer, which I think is missed in that sort of type definition I had. I sort of think and this is one of the interesting topics around this whole space I find, is that good platform engineering is about balancing sort of local optimization for the individual users and global optimization, which is things like standardization.
Ben Ford [00:09:33] Yeah, and it seems like it would make sense to to make that definition flexible enough so that that standardization moves along with the needs of your users and your customers and your company so that you're not holding yourselves to the same golden image you were pushing out four years ago. You're growing with the company needs.
NIgel Kirsten [00:09:51] Totally. And I think this is one of the reasons why everyone's always talking about feedback loops when it comes to platform engineering and just like if you're building a product for users, you need some kind of a feedback loop. You know, what do people actually think about it? This is why we get all those endless surveys at the end of using all the products these days. And every time you go through a customer interaction, you being prompted on your feedback because it actually matters in terms of the uptake. And this is one of the biggest failings I've seen, particularly in large organizations, is that there's absolutely no feedback loop between the producers of the platform or the operators and the consumers of it. They often have no way of actually talking to each other. And without that sort of feedback loop, you can't be sure that what you're building is actually solving people's problems.
Kaspar von Grünberg [00:10:38] And I think what's really important to state is that you cannot not build the platform, right? You cannot not do platform engineering. People always ask like, how do we get started with platform engineering? The thing is, you know, you're already doing it. The question that you need to answer for yourself is, do you want the platform to basically dominate you or do you want to shape the platform actively? Right. If you just have a bunch of CI scripts and Jenkins and like a huge amount of different things tied together and lots of version control systems, and you have these large deployment infrastructure set ups, I mean, you have a platform, right? But I think what platform engineering is advocating for is to say, okay, how can we bind these things into an experience that if the developer chooses to follow that experience and, you know, it's 2023 now, we're not forcing them, but we're nudging them to do that. Well, if they follow that, then they get certain benefits and that is, you know, self service standardization by design, speed and delivery and then all of these things. But you cannot not have a platform. Right. The question is, do you shape it as a product?
Fatih Degirmenci [00:11:52] Now, I just want to add something to what you just said, Kasper, like how do we start with platform engineering and as you mentioned, many organizations are already doing some kind of platform. Like if you think about developers, some developers, they just do the same thing over and over again and they realize it is boring and they start automating things. They start creating tools, they start turning into services, sharing them with their team mates, which get used by other teams in the organization. So I think the point, like the standardization, alignment or streamlining is pretty critical here because doing such things that are pretty important for developers, teams coming with these ideas and coming up with platforms themselves, but putting something around these things are making them more visible and shared across all organizations is critical as well, which is like standardization or alignment aspects.
Nigel Kirsten [00:12:47] I think that's a really good point because there's often and this might be my Ops background and enterprise background, but there's often this sort of perception that, you know, development teams are all cowboys who all want to do everything different ways and they're going to keep throwing new problems and ways of working. And it's the poor Ops people and IT folks in security and order and compliance who are trying to keep a lid on it all. But in my experience, it's immensely frustrating when you're a developer in a software team and there's a million different ways to do everything. And you don't have a standardized release process or testing frameworks. And there's often a desire, particularly once you start moving between development teams and org, when you're building software, that standardization to a certain point is really good for the individual developers as well.
Kaspar von Grünberg [00:13:33] So one of the things that always struck me is that if you look at, you know, the teams that we all think are amazing, like the Google engineering team and I always thought of the GitHub engineering team and organization, the level of standardization, the level of abstraction, if you want to use that term, I'm, you know, a very, very loaded term. But let's use it is very, very high. And I was always wondering how is that possible? You know, these great engineers that are actually self-selecting to deal with that level of abstraction all embrace that. And I zoomed in a little bit, had a look at this. Why is it possible that these teams have it and then everybody else doesn't seem to want to have that? And what I found interesting is that great platform set ups are not set ups that abstract you from something that, you know, keep you away from something. But those are opaque abstractions. They're always only an offer. You know, you're like, make a contract with me and you get certain benefits, but you don't need to do that contract or and if you follow my golden path, our systems will tell you exactly what happens under the hood. There is nothing hidden from you. It's very clear. If you need something, we will give you something. The platform will mesh that automatically. But you know exactly how this was meshed. Why this was meshed. There is no, it's never a black box. The design is always very mindful of the human. In my experience, software developers do not have an issue with being abstracted away. Our whole industry has a history of, you know, repeatedly moving from one abstraction to the next. But you can never take context. So no abstraction at the expense of context. As long as you give context and you are careful and mindful people are actually more than happy to use great delivery systems and to comply to a higher degree of standardization because it ultimately benefits them.
Nigel Kirsten [00:15:39] I really like what you just said there because you just sort of hit the nail on the head. I think of, you know, we talk about self-service. And for those of you who are listening, who came from sort of more traditional sort of enterprise background, we've had ideas like self-service software catalogs for a while. But the problem with them was always that they were a black box, as Kasper was just saying that, you know, abstractions are really powerful, but when you click a button, then it's fantastic when it works, but when it's not quite doing what you want and it's a complex series of tasks and you have no insight into what's going on, that's not reducing cognitive load, that's just increasing it.
Ben Ford [00:16:15] Yeah, one of my first engagements with Puppet when I was pro services, shoot over a decade ago, was actually building an internal developer platform for one of our clients and it had all of those drawbacks you're talking about. It was one click, but if it didn't work, you had to go into the Git repository and fiddle with a bunch of code to figure out what was going on. And no surprise, it never actually went anywhere because it wasn't serving the needs of the the actual users of it. So this is not anything new at all. This is this is a very, very old idea. Maybe could we talk about some of the like the history and origins behind this and why it seems like it's rising in popularity so quickly now? Like, what has shifted now that has made platform engineering more popular than it was five years ago, for example?
Nigel Kirsten [00:17:10] I think we've all been introduced to platforms in the form of the big cloud provider platforms. I think that's a huge driving factor. People have gotten used to self-service in all sorts of roles inside technology and they've gotten used to being able to have that service provided to them in in a way that feels much more like a product. Also, I think, you know, Ops teams have been massively overloaded. Developers have been getting frustrated. I think it's just a convergence of a whole bunch of things. But for me, the cloud providers is a really big part of it.
Ronan Keenan [00:17:41] Yeah, I think it's the this evolution of cloud native. That's not backed by data in any ways, I'm just, you know, spitting in the air. But what I did is I just looked at the uptake of container adoption as a proxy for cloud native adoption. You can see that, you know, early start in 2006 and then you can see the first teams go mainstream cloud native in the early tens and the real wave actually hits 17, 18, 19, 20. And then what I'm observing in individual organizations is that they go into the cloud native world and then you have that paradigm of you build it, you run it, and everything is new and shiny. And cloud native for some reason is supposed to be easy and then, with a delay of 4 to 5 years, they start realizing, hey, you know, you build it, you run it doesn't really work if you let every single react developer do everything with TerraForm. People are overwhelmed. Delivery speed is going down, people are frustrated, takes a while, takes a couple of reorgs. And then they realize that doesn't really work. You can't just throw everything at everybody. You need to structure things. You can't overwhelm people. You're actually abusing their mental health to a certain degree by telling them, Hey, you're now doing everything. You're introducing shadow Ops, where senior people now have to help juniors, you know. And in my interpretation is that if you just take the lag function of cloud native and you delay it by four or five years, you have the uptick in platform engineering and that's or in internal developer platforms. And yes we've been speaking about this for years, but we were somehow the early adopters, but now the enterprise is cloud native for a while and they're realizing that it's just not working.
Fatih Degirmenci [00:19:36] This complexity in the cloud native microservice and so on, I think like if we think about like ten years or more ago, things weren't as complex as they are today. Currently the developers know they now need to deal with many tasks to build and run highly complex, disparate and interconnected systems. And this is going to take us the very first things we discussed like cognitive load and so on. And as customer highlighted, the effects are now becoming more visible and organizations are trying to perhaps reduce the load from their development team so they can focus on value adding activities or business logic more than like infrastructure, automation and such things. And just to get what I just said, I think complexity is a big factor why platform engineering is becoming more critical.
Ben Ford [00:20:30] Kasper, you said a moment ago that we didn't really have a whole lot of data back in some of these ideas up. I'm curious, Ronan, you just ran a lot of analysis on a lot of data that we have. Are you seeing trends? Are you seeing things that might be able to back up some of these ideas that the people are saying or or maybe contradict?
Ronan Keenan [00:20:51] Yeah, exactly. I was just going to jump in there and say that like one of the key drivers for platform engineering, at least from what our data is showing, is that it's delivering on its benefits. So there's a huge positive reaction to platform engineering among organizations that have adopted it. So for our upcoming SODOR report, we did a survey of organizations that have adopted platform engineering and really there's widespread positive sentiment, and that's because it's delivering on its promises. So a couple of minutes ago we'd been discussing about standardization, and we've seen that the majority of organizations that have adopted platform engineering are seeing increased standardization due to platform engineering being adopted. And then as well, the majority of organizations are seeing increases in speed. And I think also going back to a point Nigel made about the whole organization benefiting from platform engineering. Yes, our data is backing that up as well because we asked our survey respondents, well, who were the main beneficiaries of platform engineering? Is it individual developers, certain development teams or infrastructure teams? And actually, the top answer was that the whole organization is the key beneficiary from platform engineering. So we are seeing it live up to the promises of standardization, widespread benefits, increased speed. So, so far, so good. Really, our survey respondents are almost unanimous in saying that platform engineering, it's certainly a step in the right direction.
Nigel Kirsten [00:22:23] I think what's really interesting writing about those findings is if we contrast them with the first few years of the State of DevOps report where we were focusing on DevOps adoption inside the enterprise, where the picture really wasn't that clear, there was a lot of optimism, a lot of goodwill at the beginning, but we weren't seeing the concrete benefits and it took a lot longer for folks to, I think, work out how to deliver those benefits to the whole organization rather than just a small team of DevOps folks and a few others sort of working together. This was the biggest surprise for me for the findings this year. Like anecdotally, I've seen lots of sort of really good results, but to see the data actually backing this up and the people are seeing really concrete results from what is a relatively young movement in our space. For a lot of folks, it was just really it was really good to see.
Ronan Keenan [00:23:15] Yeah. And I think what's particularly interesting is the majority of organizations that we surveyed, they've only adopted platform engineering within the last three years. So and even within that pretty short time frame, the benefits are real. For example, like nearly 70% are seeing an increase in development speed and 42% of those organizations say that speed is increasing a great deal. So that basically means it's very noticeable. It's not just incremental, but it's actually having a real impact. So certainly the results are real. And I mean, it's not fair to say, but I don't want to paint a picture that every single organization that has adopted platform engineering is saying yeah, we're seeing amazing results. There is a subset of maybe 25% or so of organizations who do say that, yeah, you know, it's not really performing quite to the level that we'd expected or hoped, but by and large, for the majority, they are seeing those real improvements.
Kaspar von Grünberg [00:24:15] And I, I have the I'm regularly doing platform engineering workshops and have a lot of enterprise people in there. And we're looking at how do you approach this? How do you and I'm always asking them in those sessions, where do they start, right? I mean, this feels like such a daunting thing. You have this large engineering team and now you need to start platform and you know, what are the things that you actually start with? And I think, you know, because that space is so young, there are a lot of fallacies people run into. There are a lot of things like a lot of teams start with things that feel most obvious like, Hey, would be so great to have a shiny UI to create a new microservice, and then you go ahead and ask them, Okay, well how often do you create a new microservice? Like 20 times a year. Okay, so how do you do it right now? Well, we go into GitHub and then we press a button to do a template and then we execute the template and then we have the new service. Okay, so now the last six months of platform engineer what did you do? Well, we use this new JS open source thing and we now have a UI and you press a button and then. Okay. And what happens if you press the button? Well, the button does call to the GitHub API and they actually clone a template and then, well, so you spend six months actually doing the same thing you do right now. And I think what I want to say is that because this space is so immature, if you want, a lot of folks are still struggling a little bit to understand where to start, how to prioritize, how to do the things that really drive return on investment rather than the things that might look great for product management or the C level. And so I think we just there's still just a lot that we have to learn as an industry on how to actually approach this and really treat things as a product.
Nigel Kirsten [00:26:06] That was all so much good stuff there. I think I would see, like in your experience doing most of the workshops and things, what are some of those common mistakes you're seeing folks make? Like if he were to give you a cut top three list of, Hey, don't do this.
Kaspar von Grünberg [00:26:23] Yeah. I have a top ten list that I keep repeating and top ten Fallacies and Platform Engineering wrote a longer piece in it. But the top three things are really: number one, the prioritization fallacy, that you don't actually sit down before you start working and you do user research and you ask your engineers and you don't only ask one engineer, but you ask many different engineers. Okay, what are the things in your daily workflow that you really struggle with? And the thing is, those aren't the most obvious ones. Like as a hint, it's usually not the creation of a microservice, which feels obvious. It's usually not the onboarding of a developer because if you look at the lifespan of an application versus how much time do they actually spend on creating, this is just a very, very short period of time that you're optimizing. So the first one is the prioritization fallacy, and I'm always telling people, Hey, sit down, do ranking, do user research and then start. Number two is the visualization fallacy. There's a tendency, and I'm seeing that everywhere, to say, Hey, we're just visualizing stuff in fancy dashboards. And then we believe that something miraculously improves and you're seeing very, very low ROI on that one. And then the third one is the everything and everybody at once fallacy, like people starting to build these gigantic platforms that can do VM all the way to Lambda and, you know, the developers don't have to think at all. And it's so great, that almost always fails. And so I'm always saying, okay, prioritize the right way, don't do the most obvious stuff. Take a step back and look at one technology, the lowest tech denominator if you want and build something small, that's great. And that impacts the daily work of a first lighthouse team. Make them your champions advocates and then let them pull the organization and iterate as a product from there. So I would say those are the top three.
Ben Ford [00:28:31] So I have kind of a loaded question for you all. Is platform engineering sort of could we consider it to be like a natural evolution of DevOps or is it more like a paradigm shift or a pendulum swing or reaction or something very, very different? How would you characterize it?
Nigel Kirsten [00:28:46] I would say really quickly I think it's a natural evolution, but it's also a bit like it's a bit of a category to compare the two. I think there's a lot of common DevOp philosophies that were in DevOps that are required to do platform engineering well. But I also think those philosophies are required to just do technology well inside a technology company. So I think they're different. But there is a view that there's a natural evolution that, at large scale, to succeed, you're going to have to work out how to centralize certain capabilities so that you can more efficiently deliver them to more people.
Ronan Keenan [00:29:23] Yeah, And certainly following on from Nigel's point, we do see in our survey data this year that there are certainly strong linkages between platform engineering and DevOps. For example, when we look at what are the most common roles that are making up a platform, team DevOps roles are number one, they come out on top, even talking about increased standardization as a key benefit. You know, we've seen in previous research that we've done over the years how standardization has been identified as a key part of the DevOps evolution. So there are several linkages there between the two. And we did also ask in our survey about developing explicitly about the relationship between DevOps and platform engineering, and we saw over 90% of our respondents said that platform engineering is helping them to better realize the benefits of DevOps. So there's certainly a view among organizations that have adopted platform engineering that platform engineering can be a vehicle at least to to get more out of the the promises of DevOps.
Nigel Kirsten [00:30:24] Very complimentary practices.
Kaspar von Grünberg [00:30:27] I think that's so spot on, Ronan. I think of DevOps like a philosophy, I think of platform engineering as a practice.
Ben Ford [00:30:44] So what do you think that we have to look forward in platform engineering? Are there new areas to be explored or new ideas to flesh out?
Nigel Kirsten [00:30:53] I'm going to jump in really quickly, which is I think everyone's always talking about infrastructure in terms of platform engineering. What I'm really excited to see is what are those higher level services people start delivering? Just as Amazon came out with EC2, everyone got really into infrastructure as a service, but a lot of the creative explosion has happened on much higher level services and I'm really curious to see what happens in the industry around those.
Kaspar von Grünberg[00:31:16] I think one of the big things that we're still showing people is reference architectures. What an internal developer platform looks like? It looks different in every single organization. There is not the one. Otherwise you have a platform as a service, but there are certain repeatable patterns. And one of the things that I really want to spend a lot of time on is looking at these reference architectures and publishing them for people to actually build their own platforms with these things. I think we are a little everybody is a little too, I'm showing you this one thing and what to do this one thing and what to do. I'm really looking for stuff that says, Hey, this is how a golden path looks. We're using these buzzwords, right? And I mean, I've been heavily using those buzzwords for the last years, but we're not very precise in how could an actual implementation look like. And I think at this point, I've seen dozens and hundreds of them. You know, they are there. There are repeatable patterns. The platforms do have a lot of similarities. And I'm so looking forward to actual content, product content, around these reference architectures.
Fatih Degirmenci [00:32:32] From my perspective, I think like cloud formation enables all pursue what they're best in doing, like developing software and delivery aspects like software for all aspects are equally critical as well. So I think you will probably need more focus on content aspects, you know, to explore these aspects more because it becomes very difficult for developers to deal with, you know, hundreds of pipelines, thousands of lines of YAML files when they are creating their pipelines. And so I believe platform engineering will help with these aspects as well as software flow.
Kaspar von Grünberg [00:33:07] Yeah, and I don't want to advertise products, but it's an open source thing that we just put out and it was more of a side thing. It's called Score, like a workload specification, that allows developers to on an abstract level describe how their architecture looks like and then it's actually localized if you want and the actual executable configurations are created. And I'm just mentioning this because the uptake is so crazy. So we've been using it for years. We said, okay, this should be open source. We put it out November 6th. We started communicating it November 15th and it has just surpassed, I think 7,500 starts now, which is, I don't know, six, six, seven weeks. And I'm saying that because that shows how much attention, how much traction there is on these higher level abstraction topics.
Nigel Kirsten [00:34:00] Where do we go get it?
Kaspar von Grünberg [00:34:00] It's score dot dev, like the scoring on a musical sheet.
Ben Ford [00:34:07] Well, this road map looks very, very exciting. I am really looking forward to seeing what comes up next, see where we go in the future. This is a real exciting time. Like I mentioned briefly earlier, I'm going to config management camp in Ghent in just about a month. And one of the interesting trends that I noticed is this is a historic long-lived conference, we've always talked about configuration management, and this year a lot of the talks are kind of leading towards platform engineering, talking about some of the very same things we're talking about here. So like the whole industry is making the shift with us and it's so much opportunity for things in the future. So as we close up here, I think kind of one of the big trends that I'm hearing, the thread that I'm hearing here is that platform engineering isn't like a brand new kind of DevOps or new ideas. It's sort of like natural evolution of how we think about our tooling and about our platforms and like this little shift in how we think about our own customers or users and then the needs of their customers and users, and like the things that we could do that can enable this entire ecosystem and help make everybody's life a little bit easier by giving them the tools that they need and they want to use to standardize on better platforms for everybody. And just a plug here, of course, you can read about it in the annual State of DevOps report that Nigel mentioned and Ronan mentioned earlier, coming up very soon. Ronan, do you have an idea of when people can expect to hear from anything about this?
Ronan Keenan [00:35:54] Yeah, our target launch date is January 18th, so not too far away. So yeah, lots of in-depth findings and results that we're really excited to share.
Ben Ford [00:36:05] That is very exciting and hopefully we'll have this podcast published before then and people can still look forward to it, right? Let's, let's hope on that. And anyways, that is a wrap for today. Thanks for being here. Thanks for listening. And thanks, all of you for your fascinating ideas and insights here. I found myself scribbling down notes frantically trying to remember all of the brilliant things that you all said and that I want to remember. But I guess that's what the transcript is for. So this will be one to go back and read the transcript very carefully and get some of these statements back out there. So thanks everybody, for being here.