 I'm David Sandlands, principal solutions architect at Puppet by Perforce. This talk is about the 2023 State of DevOps report, platform engineering edition. We're going to talk a little bit about the history of the State of DevOps report, why this year we've kind of focused on platform engineering, some details about how the report was performed and gathered and then running through some of the core findings of the report. I'll also chip in with some of my own experience and background. Just to give some intros, for those not familiar with Puppet, Puppet is an infrastructure configuration company and a compliance tool set, first released in 2005 with both enterprise and open source products. And with a strong history in the DevOps community as a contributor and influencer. Myself, for my sins, I did 13 years in banking at Nat West Royal Bank of Scotland in the UK working in their historic very old school platforms. Hearing a very sad description of some days being an old school person because they used to work in Solaris and AIX and having to nod my head and say, yep, I did that too. And more recently kind of going through their digital transformation as they went to kind of an IaaS platform. So, the State of DevOps report, launched in 2013 and released annually. It's a survey looking to ask questions about how organisations are adopting DevOps. 40,000 people have been surveyed since its initial inception. What we found is that after kind of period of 2013 where there was initially a lot of progress, over the last four reports we've kind of found that only, we've only had growth from kind of 10% to 18% of organisations going from kind of middling evolution of DevOps to highly evolved. And the majority 80% are kind of remaining in this middle level. And actually in fact DevOps has become so prevalent with many of these organisations. They're not even kind of talking about it as a term anymore. That it's just the way they work and the way they've got used to working. So, as kind of part of this we've chosen not to kind of do the same general high level DevOps reports and we've tried to focus in on some of the common themes we see in the organisations who have reached a highly evolved state. And one of the patterns we saw was platform engineering. Because what we'd seen in last year's research was simply adopting automation and infrastructure code does not create a highly evolved organisation. A focus on improved organisational structure, team identities and interaction are the most kind of common attributes of highly evolved DevOps organisations. And that led to a clear pattern of platform engineering in that frame helping with those things. This doesn't mean you have to adopt platform team models to be good at DevOps. Rather it's just having that sort of well defined approach seems to help organisations to kind of path to succeed with DevOps. Particularly in the enterprise. And to kind of show, to talk about the numbers what we found was with platform engineering 65% of those who were towards the high end of DevOps evolution were using self service platforms compared to only 40% towards the lower end. So going forward for the state of DevOps report expect to see a lot more reports like this where we focus in on particular topics rather than our kind of historically more general. So for this year's report, the platform engineering edition platform engineering has obviously suffered from being a buzzword but we wanted to kind of zone in as to actually what it meant to organisations because just in the same way DevOps can mean very different things to different people we've wanted to kind of zone in so we had 438 respondents respond to the survey it was done in two ways we did it via a kind of snowballing method whereby we put out a survey via social media, web and via our partners and then via word of mouth it snowballed like a snowball rolling down a hill we also used a a professional grouping who were an independent non-profit to provide expertise and opinions so that our bias in terms of who we were likely to get to fill out the survey wouldn't completely show through and we also had a grouping of those who didn't use platforms to provide a control group on opinions The survey was conducted between the 14th of September and the 25th of October 2022 unsurprisingly the main industry to respond was technology and I'm hoping that's a nice big screen so hopefully you can see a breakdown of those plenty of organisations from government to finance to education and so on varying sizes of companies from smaller companies to larger and in terms of the platform team role it was obviously keen not just to have the opinions of people who ran platform teams because they are obviously going to have a good opinion of their platform and you know a mix of different team responsibilities I appreciate team names a bit strange these days so plenty of people that are on teams that are just called DevOps now but yes a good mix of different teams from kind of traditional infrastructure teams to teams involved in transformation so the kind of initial findings most platform teams are still new only 19% of respondents reported that the platform teams were established more than five years ago I think this is kind of from the thing we see that large scale platform teams up until recently have been predominantly the place of new big tech companies and despite how it feels in the industry they just make up a small sector of enterprise firms so for most now is the time to adopt and looking at how people felt about had they adopted platform teams at the right time overwhelmingly people feel it's the right time 23% sayings too late and only a very small section saying they felt it was too early why platform engineering so when we look at what led to the creation of a platform team for organisation it's not too surprising that increasing the speed of delivery comes out as the highest point followed by the need to scale and then looking at engineers taking too long to spending too much time working on the tools and actually their job and features because I think that was something we commonly saw was particularly in large organisations lots of teams are opened up to the freedom to develop what tools they were working in but that just gave them a bigger cognitive load to try to work out what they should be working on and in some organisations like my own background of banking there was plenty of teams that didn't realistically have the skills to do that well and further down the scale we'd also see there in terms of consultancy and leadership requests which is probably coming from the point of platform engineering being very prominent in a lot of marketing and buzzwords just now looking at the key goals seeing that problem solving is the highest probably reflects how platform teams aim to prevent other teams from having to keep repeatedly solving common problems and the rest of the answers can really be seen around enabling the users of the platforms with education and empowerment of developers and product teams featuring prominently of 47 and 40% and 46% answering to promote best practices within organisations I think that this kind of people centric approach naturally follows previous DevOps implementations where enterprises were too focused on the tech and the tools and kind of stalled in their DevOps journey as they kind of struggled with the various silos of people so going a bit more into the purposes of structure what capabilities does the self-service platform offer offered by the platform is the provisioning of infrastructure for developers is key with deployment operation monitoring and security being identified because I think if you look at kind of plenty of people said to me platforms aren't new there's been platforms there was a platform at the bank when I was deploying AIX but all it did was simply that one step of getting you an AIX machine configured to a specification the key thing is developers need to get something that's actually usable at the end not something where they have to keep stepping through different sections and going to one team to get DNS going to another team to get their OS and other teams to get them monitoring and pseudo rules set up if I'm focusing purely on a provisioning example so that's just not sufficient teams must be able to deliver value to their users and the majority of respondents are reporting that in terms of the number of platforms the reporting that they have between 2 and 4 while 30% have 5 or more and this to us indicates that platforms are emerging from different parts of the organization and we see this that they can emerge in different ways organically from volume stream developers looking to share the solutions with each other from particularly advanced and capable operations teams who have high levels of trust within the organization and also sometimes when you have progressive management who look to move the organization in a transformation we don't believe that anyone should be trying to force one platform to rule them all we think the focus should come from exactly those kinds of teams we've talked about there so talking about how centralized they are to be clear when we're saying centralized we're meaning whether if a platform is centralized we're talking about different business units using a platform together so 82% of platform teams are centralized and this pattern of centralization seems to be increasing over time with 52% reporting an increase of that centralization and 36% of those who are already using a centralized approach reporting that even more centralization would be better with decentralized teams we see that 37% believe it would perform better if they were actually more centralized and to be really clear here both users and operators are giving more or less the same answer in this area so it's obviously not just a platform team saying it would be all better if everyone just came to my platform now there's always going to be some need for decentralization there's going to be legality requirements whether that be a business unit in a certain region or whether if you're in a finance organization and your traders can't work on the same platform as your retail bank but the general pattern we see is for decentralization in terms of the benefits I think this is the thing that took me back the most because when I think of my experience of trying to introduce colleagues to things coming from exactly these kind of conferences and these kind of new ideas there tends to be a high level cynicism particularly when something's been a buzzword but we see that 93% of respondents are reporting that the platform team is a step in the right direction and 94% agree that the concept has helped their firms better realise DevOps and the impact on velocity has been surprising as well 68% agreed to increase their velocity what we did find was that this confidence and improvement was better over time and more than 53% of firms that had been practising platform engineering for more than three years reported their speed had increased a great deal while it was just 35% for firms who had implemented less than three years so again to highlight creating this level of change in a relatively short period is very impressive if we look at a lot of organizations who went through their general DevOps approach many of them spent 10 years even trying to adopt DevOps practises with very little success in some organizations so looking at how confident teams are in continuing to meet their goals we do see the longevity of the platform directly correlates to that confidence and given how cynical our industry can be and how cyclical things can be when you're dealing with, as I said something has been very commonly a buzzword we do find it noticeable that the majority are somewhat confident or very confident even less than three years but seeing the switch to completely confident of 27% over three years and a total of confident or very confident of 73% just shows that the platform builds over time looking at who needs to serve most by platforms it's very pleasing to see 30% see the whole company serve best 29% see developer teams which is exactly what you'd hope with platforms typically looking to serve your IDPs and what's interesting is the percentage you think it serves the whole company increases again when it's been over three years one thing some people may be worried about is in terms of seeing infrastructure teams as just a small chunk of that but what we do expect that because ultimately it's not really to service the infrastructure teams we're wanting the platform to service our developers and the infrastructure teams can feed into that process because we've never run infrastructure for its own sake ultimately it's been about getting onto the services and the tools on top of it excuse me so looking at some of the problems people are reporting with the platforms I think a large part of it can be about seeing setting expectations and creating awareness of the platform one of the things we can see the largest percentage here is the cycle slower than people expected and resistance to adoption of the platform and I think both those things focus down on getting that buy in and also creating a lot of companies are not very good actually making people aware of what their SLAs and SLOs are around their platforms and I myself, when we went from quite a rudimentary platform to a truly platform engineering platform we made that mistake and the first major outage caused a huge problem despite the fact it was well within our expected error rates so we'll kind of come into talking about how product owners can help with that a few slides but a lot of what we see in terms of the priorities for the next 12 months looks to kind of address that point of creating awareness about the platform and educating and enabling users of the platform and developers that's not what I was going to do so coming into the kind of needed product management skills when it comes to putting the right people and putting the right skills in place to actually do platform engineering most respondents seem to have the priorities in order when we asked about the most important skills a product manager needs to drive a successful platform we learned that platform product managers need to be great communicators they need a knack of problem solving they must be able to foster collaboration across teams and they got to be able to turn into core requirements that can fit a platform and they need a significant understanding of internal customers so we tend to find organisations who try and pull someone completely external from their organisation to perform this role can often struggle to understand the internal politics and complexities of that organisation so in terms of going more into the challenges 66% of respondents strongly or somewhat agreed that platform engineering team has a product owner who evangelises the product and services and this would be a huge worry for us is that without that individual doing that evangelism and helping that education and working with customers to establish the needs of the platform as we see the young platforms grow they could easily come into trouble now an interesting thing comes is 48% of respondents agree that senior management of the organisations do not understand the value of platforms and even a similar degree the respondents themselves say that 51% of them are equally confused about the concept so again I think this points to the importance of the product manager who should be in there to help this understanding both within their own platform team and within senior stakeholders and leaders again just to kind of hit that point treating your platform as a product is a key tenant of modern platform engineering while this is genuinely well understood the data tells us that organisations are under investing in those product management skills and one of the core problems I've seen is when people feel like the platform is well established that's often the point where they'll feel like well we've invested all this money now the platform seems stable we don't need this product manager and that will eventually hurt the long term future of the platform as nobody is there to continue the evolution of the platform so to kind of summarise up there's no room for complacency young platforms can expect rapid growth as they're evangelised and as people are getting a taste for self service industry and company cycles can affect this focus on product is very easy for these kind of soft skills to be viewed as easy to make redundant in downturns and you know we kind of see the key thing is platforms will fail if the only focus is the technology you know so again I know I've said it so many times but the platform has to be treated as a product not a project and I can think back to the bad old days of platforms when even doing something as simple as going from rail 8 to rail 9 was in fact a project and you had to kind of mug someone coming in to say your project is going to have to pay for us to deliver this and probably because I've just seen the meme so much and it's a little bit painful DevOps is not dead platform engineering has kind of been somewhat hyped in terms of that because it's been so successful and had such a big impact some people have been complaining claiming it's supplants DevOps but for me platform engineering is just another kind of theory that's due to its success it's kind of become a part of DevOps in the way that agile and other things have been borrowed into DevOps practices and for me I'll be interested in future DevOps reports to see the sustainability of these platforms with so many only kind of under three years old it'll be interesting to see how people are coping with growth how people are coping with changing demands and whether people are continuing to keep the awareness long after potential transformation programs have ended so with that you can get a full copy of the report with more of the graphs and more of the information to read at your leisure so thanks to the sponsors of our report thank you today for listening under any questions no worries also if anyone has any thoughts of things that should be in future state of DevOps reports let us know and we are over at the puppet stand over in the area and thanks for your time