The Future of DevOps with Paula Kennedy
We sat down with Syntasso COO Paula Kennedy for a live Ask me Anything (AMA) event to talk about the future of DevOps and how it pertains to the rise of Platform Engineering. You can read our recap below, or listen to the full recording on YouTube and follow us @Seaplane_io for details on upcoming industry events!
Thank you so much for being here with us Paula! Our conversation for today is about the past, present and future of DevOps and how it pertains to platform engineering. Can you explain to us the difference between DevOps and Platform Engineering?
It's a great question and you're right, it's something that seems to come up quite a lot. I think there's confusion with anything, but naming things is hard and there's confusion around terminology.
For me, DevOps has been around a long time. I've been personally a co-organizer of DevOps days London since 2017, so I've seen some some fantastic people coming in and speaking and talking about their experience in DevOps. I think, for me personally, platform engineering is an evolution of DevOps. Obviously there was some buzz last year about “DevOps’s being dead” and “Long Live Platform Engineering”, but I don't think that's actually true. I think what we've seen is DevOps has been useful for trying to bring developers and operators closer together to have collaboration, and it somehow has evolved in some places to be a job title or a set of tooling. But really, DevOps, at the heart, is about culture. What it was originally set out to do was to bring developers and operators closer together so they could collaborate and so that they could basically get stuff done faster. For me, Platform Engineering has exactly the same ethos. Platform engineering is really about trying to enable developers to get things shipped out to customers faster. It's just a way of being able to reduce cognitive load on developers because, as we've seen with DevOps, developers should build it and run it. Amazing. But when you do that in practice, it suddenly means, as a developer, you're trying to manage everything from infrastructure concerns up to delivering software, and that's a lot. Like, that's really a lot of things to worry about.
And as you try to scale DevOps in an organization, that just ends up with lots of teams all trying to solve the same concerns. So lots of teams trying to figure out infrastructure, lots of teams trying to figure out security and duplication across the business. I think where we're seeing platform engineering evolve from is developers are getting burnt out- they've got too much cognitive load. They're drowning in work, and then you've got platform engineers who are able to sort of centralize some of those services, take over some of those concerns, and really try to focus on developer experience, which then makes it easier for developers to get their role done. But developers are still self-serving the platform if they can and then the sort of building and running it themselves. They're still doing DevOps, and then the platform team itself is doing DevOps because the platform team needs to develop the platform as well as operate the platform. When I think about it, I draw a diagram. It's not DevOps in the old model and it's not DevOps in a kind of “everyone has to do all the Dev and Ops.” It's sort of like the platform team does DevOps of the platform- they build them on the platform. And then the software application teams do DevOps, but they're Ops is self-service of the platform, so they have to worry about a lot fewer concerns, but they're still building and running their software.
You mentioned that DevOps is more about the culture and platform engineering is about the execution- the DevOps team is building the platform itself so other people can use it. The reason why we needed DevOps to exist in the first place was because they were working separately which caused major issues. Do you see any issues with letting go of that culture of DevOps? Or is it just another iteration of the culture?
I think it's another iteration, because when I think about what a platform team should be trying to focus on, the mantra that we have, that I feel like I've been saying for quite a while, is “platform as a product”. But what we actually mean by that is if your platform is being treated like a product, you've then got customers- sort of users of your platform- and those customers are generally developers. There are probably other parts of the organization, but let's say it's focused on developers. Therefore, you need to do your customer research. You need to give your customers a good experience. You need to make sure that the thing that you're offering them is the thing that they need. The natural conclusion of that is, as a platform team, your focus is developer enablement- developer productivity. So you are going to go and talk to those developers and figure out what they need, and then give it to them. That in itself is a very strong collaboration and a very strong culture of working together, as two parts of one whole, as opposed to the traditional Dev and Ops who've got different incentives and are, like you say, battling against each other. To me, platform engineering is not even a culture shift from DevOps- it's just an added iteration on it that says, actually, that collaboration should be built into how the platform team works.
How do you measure success in terms of developing and building products?
It's a really interesting question because you're right, there's been there's a lot of focus on how to measure success, and I think there are lots of different ways you can tackle it. When I talk to customers, if I'm talking to a platform team, what I try to ask them to understand is what's important to the business. I have a lot of conversations around objective and key results setting as a platform team or KPI- key performance indicator- setting as a platform team. And I think in an individual team, you have to think about, what does the business care about? Is the business focused on cost savings? Is it focused on the number of releases to production per day? Whatever the business is really focused on, that's what the platform team should be trying to measure their impact on. Because that's how the platform team can demonstrate their own success within the business.
I think, more holistically, if you're an organization that's thinking about whether to set up a platform team or call it that, like you say, the chances are you've got some people somewhere running your platform whether you call them a platform team or not. But if you're looking to organize and have a more formal structure around a platform team, and trying to weigh up whether that's worth it or not, I think there are things you can try to look at. Platform teams are very good at being able to potentially do charge back to users for certain services, so it's a good way of being able to look at costs if that's something you care about. DevOp happiness, it's a bit of a vague one, but I've seen people using net promoter score quite effectively as a way of being able to survey your developers regularly, get their feedback, see how they're using the platform. And then, obviously, there's kind of the DORA metrics about the frequency of deployments. There are lots of metrics that you can then look at, kind of mean time to recovery. The things that are more industry standard, you can look at and say “well could the platform team contribute to this measure? And if so what's the current measurement and how could we improve on that?”
A question from the chat: When something breaks, how do you fix that without finger pointing and blaming? How do you address and assign the success to the right team?
It's a challenging thing to work out, boundaries of responsibilities. When I get asked a question like that I tend to point people to Team Topologies. I don't know if you've read that book, it's a book that came out, I think, in 2019 by Matthew Skelton and Manuel Pais. They talk about it a lot publicly, so you can find videos online that they've done. One of the concepts in the book is about how to organize teams to allow flow of value across the business and how to have frictionless boundaries, but also clearly defined responsibilities. A good example would be having an API boundary between a platform team and an application team. Let's say, if your platform is available as a self-service API, whether it's got a user interface or whether it's command line interface, if you've got a clear sort of boundary of responsibility between what the platform team is offering and that platform team has its own service level objective, service level availability, etc. and then the development team understands what they're getting, and there's a clear contract an API between what they can expect how they can expect it, then if something goes wrong, to answer the question, it should be easier to then identify kind of where the responsibility lies if you've been able to define those those boundaries.
What do you think we need to figure out as a Platform Engineering community, looking forward into the future?
I've heard people describe that a challenge we saw with DevOps was there was no “DevOps Manifesto”, and there was no clear prescription about how to do DevOps, which then led to, over the last 10 years, lots of people kind of selling you DevOps, like “DevOps in a box” or “sprinkles and DevOps on it”. And it is very unclear what you're getting, but people are selling you DevOps. I saw there was an interesting article, and probably a talk as well, from Nigel Kersten which was around “are we gonna make the same mistakes with platform Engineering that were made with DevOps?” If we don't give people a clear instruction manual, let's say, or some clear direction or some clear guidance about what we, as a community, think platform engineering is, are we leaving ourselves open to misinterpretation and people selling you platform engineering? And again, you don't know what you're getting. And tools coming along saying “this is everything you need out of the box” when it maybe isn't, so maybe that's what's missing. What I'm really grateful for is that there are lots and lots of people talking about it right now, which means there are some really smart people thinking about this subject, which is fantastic. And whether we as a community can come together and have some definitions or some guidance, or something that folks can agree on, I know that in the Cloud Native Computing Foundation- CNCF- there's a a working group that's putting together a whitepaper on platform engineering, which I think is a really great site. It's been kind of a community effort from lots and lots of different people. I'm hoping that that might be something that people can rally around and say, “well this is this is what we mean when we say platform engineering.”
Do you see any issues with trying to define platform engineering in one whitepaper or one definition, given that the combination of tools and use cases possible are virtually endless?
I think you've answered the question to be honest, because DevOps was never designed to be “here's the set of tooling that you use”- it was about kind of automation, but it didn't specify automation, it was about measurement, but it didn't specify any particular tools. It was the principles, but without the technologies. And I think we have to do the same with platform engineering. I think there are so many choices.
In the Team Topologies definition, they try to focus on the smallest, thinnest viable platform. Really, a platform just needs to be a way that helps developers go faster. So it could just be the example they give us, like maybe it's just a Wiki with a set of instructions that the app teams can access so they know how to do things to be able to ship faster. What we need to really, really avoid is just being prescriptive about the tooling. Because technologies will change, and like you say, there could be 100 different options today and 100 new options tomorrow for the same thing. What we should try as a community to focus on are the practices and the sort of the “whys” as opposed to the house. It's like “why do we need to do this?” Because we want to help developers go faster. “What do they need?” What they need, in this example, they maybe need just five things and we're going to standardize around these and these are going to be good enough until something else comes along. And then as a platform team you should be focusing on meeting the needs in the best possible way to help those developers, and then as technology evolves, you can drop some things and pick up some new things, but make sure that the platform continuously evolves without somebody kind of coming along and saying “this tool is the answer to platform engineering” because I think we know tools change all the time.
It’s funny because that turns it back into a philosophy, rather than building a platform. It’s more about the way you think about it and the way you rally your teams around it, rather than the tools and infrastructure that you use. So in that sense, it almost comes back to being what DevOps wants to be in the first place.
I agree, but I think there's more guidance we can give. For example, my team's been working on something we're calling a “platform maturity model”. The kind of aspects that we've been looking at are developer experience, and what does good look like, or funding of the platform, what does good look, what kind of architecture of the platform at the very highest level, what does good look like. What we're trying to do is we want to share this with the community. This is kind of a work in progress, but what we're trying to do is it's thinking about the aspects that are important without specifying tools. I think the same with DevOps, but DevOps was very high level and then more stuff was added over time. I think with platform engineering, we can specify “these are the concerns that are important to identify, to address, to evolve” without saying “okay it's these 50 tools that you have to integrate together into a platform.” I think we can be slightly more prescriptive than kind of where DevOps started, but without having to specify a shopping list of tools to go.
You guys are sharing that with the community?
Yes. I sent it out to a few folks today. We’ve done an internal draft of our ideas. I’ve shared it out to some folks to take a look to try and get some feedback, so it’s not just things my team have been through. And then the plan is to send it out to folks and they can look at t, they can throw it away if they think it’s useless, or they can contribute to it, or they can use it.
Since you’ve been in this industry for nearly 20 years, what do you think is coming back, where the past becomes the future?
I have a concern which I hope isn't going to happen, but I thought I'd mention it. When I started my career, it was quite fashionable for companies to outsource a lot of stuff. I started my career on an outsourced customer support desk for IBM, so dealing with customer support for 100 other companies who outsourced it. My next move was to a company which outsourced a lot of its software development. The thing I was thinking about recently we’re in a post-COVID world, where there's a strong appetite for developers to work from anywhere. Work from home work, from anywhere. And it got me thinking about will we see- and I like I said I actually hope this isn't the case- but it got me wondering about will we see the emergence of companies looking at their software development teams, realizing that software developers can work from anywhere, in multiple time zones, and collaborate quite efficiently with the business and with each other. Will we see the emergence again of companies deciding that they can outsource some of their software development to people in locations that are more cost effective. Like I say, I am hoping that's not the case, but I could see some cost-minded executives somewhere looking at the cost for developers and thinking “well if they don't all have to be together in the office do we go back to a world of outsourcing development teams to to other places?”
What is your worry there, as we potentially move into that new world?
I think it's based on past experience. I'm particularly thinking about challenges I faced where the people who are software developers were based in a different country. I mean, admittedly, this was a long time ago and we didn't have Zoom for example, so everything was done via email. So maybe my fear is is rooted in past trauma as opposed to current technology. But certainly, 20 years ago, trying to collaborate with the software developers that were in a different country was very difficult. It was almost exclusively over email, which made communication very, very difficult, and small bugs, small issues, took an exceedingly long time to resolve. Maybe you're right. Maybe outsourcing whole development teams to other companies to do, or to individuals to do, is actually, these days, fine. Maybe it's fine. I just have a past history of it being more challenging. We've seen the wires of kind of developers as king-makers and bringing all your development teams in-house and kind of software eating the world. I'd like to say I just wonder if now, people could be anywhere, so therefore you can use people that are in different companies to do your software development for you- does it go into that kind of model?
We’re at the end here, thank you Paula so much for being here. Feel free to continue the conversation here or on the Reddit.
Thank you again to Paula for her time! You can learn more about Syntasso on their website and follow them on Twitter and LinkedIn for updates.
We host regular platform engineering events (like this one!) so be sure to follow us on LinkedIn and Twitter and join us for our next live AMA with experts like Paula!
Some quotes in this transcript have been edited for clarity.
