Transcript

Narrator 00:02
You’re listening to the humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas, and learning, or the skil framework.

Luca Galante 00:16
So usually, it’s already quite a hurdle to convince the executive and all different internal stakeholders to start and drive a platform initiative that can and should last for years.

Eveline Oehrlich 00:33
Welcome to the humans of DevOps Podcast. I’m Evelyn early Chief Research Officer at DevOps Institute. Today we have with us drumroll, Luca Galanti is a product owner. And our title of our podcast is a conversation with a thought leader on platform engineering, I just talked to look at finding out from where he is coming to to us, I will not give it away. But he’s in a very beautiful place. Hopefully, all of you listening into us will be in a beautiful place, having a nice cup of whatever in front of you enjoying our conversation. So let me give you a little bit of background on Luca, he actually routinely speaks to 10s of engineering teams every month, tons of engineering teams, not 10s. But tons. Every month, he summarizes his learnings and takeaways from looking at hundreds of DevOps setups into very crisp and insightful reads for everyone in the industry. And that from beginner ops to cloud experts. So Luke, welcome to our podcast.

Luca Galante 01:42
Thank you. Thank you for having me. And hello to everybody from Tenerife. A really nice place.

Eveline Oehrlich 01:49
Yeah, he gave it away, thank you give it away. That is your choice of giving that away. I’ve been to tenerife myself and it is a beautiful place. So enjoy it. Thank you give us a little bit more background on your current position and what you do Luca, totally

Luca Galante 02:09
happy to so I run product at humanI tech. But I guess I’m more known in this pace as one of the core contributors to the platform engineering community. I moderate the slack there where we have almost 10,000 People actually I think we’re going across 10,000 Next week, I host platform con which is the first ever platform engineering conference, I write a newsletter that goes out to six or 7000 people. It’s called Platform weekly, it goes out every week. And yeah, so I talk a lot about platform engineering. And as you mentioned in the intro, also kind of discuss what the benefits can be with a lot of sort of like infrastructure, DevOps, and so on teams

Eveline Oehrlich 02:54
all over the world. Fantastic. And I think that’s why of course, we are very interested in talking to you. Just again, for your benefit Luca, our audience is really wide spectrum from beginners, DevOps from more advanced, we have practitioners, we’ve got site reliability engineers, we probably got a few platform engineers on the call on our on our podcasts listening in, we’ve got testers, we’ve got system administrators, we’ve got leaders, we’ve got individual contributors. So just so that you have a bit of a bit of a background. Now, the term platform engineering has gained steam, and to the tune of folks, manual players. And Matthew Skelton who I both know, mentioned, actually this topic in their book, in 2019. I did some research with a vendor partner of the DevOps Institute, also in 2020, on site reliability engineering, and we saw the term show up there, then as well. So you’ve been, as you said, a core contributor to this platform engineering community. And we’ll have later on for all the listeners a more details on where you can get involved. But before we go any further, I always love to make sure that we have a definition. So what is the definition of platform engineering? Totally. So

Luca Galante 04:29
the way I think about it is platform engineering is really the art because it’s more of an art than a science, in my opinion, of effectively taking all the tech and tools that you have, especially in an enterprise engineer organizations and binding them into a golden path that enables developers cell service and in general reduces the cognitive load for the individual contributor and the sum of This golden path that are built by the platform engineering team for the rest of the junior organizations is often referred to as an intern developer, or IDP for short. And the focus of an IDP is really that of improving developer experience, by lowering cognitive load to developers, while also streamlining the kind of like infrastructure and operational setup, on the other side of things. And a sort of like key principle that we advocate for in the community is platform as a product. And so really have platform teams focus on building and shipping a platform as any other product to the rest of the G organizations, which is really their internal customers and the developers. And so that’s kind of how we define platform engineering, in turn developer platform, which is the product of platform engineering, and the two main actors in that transaction, which is the platform team, on the one hand, apart from engineers, and the developers, their internal customers on the outer.

Eveline Oehrlich 06:12
So IDP, that’s something for everybody to do note down. And so typically, where does such a team sit? If I think of the organization, today, reporting to application development, infrastructure operations DevOps, and you cannot say it depends on what’s the typical. What’s the typical team these folks sit in, in terms of the organization?

Luca Galante 06:41
It’s gonna be hard without the independence, about answer. So, you know, the reality is, we see very different kind of, sort of, like organizational designs, depending on really the size. More importantly, right. So you’ll have teams of 100 200, engineers, where they report directly to the CTO, you have, you know, come massive companies that we work with 1000s of engineers, and obviously, the platform team does not report directly to the seat to but to some VP level, probably responsible on developer experience, or cloud infrastructure, or cloud ops. You know, you have your kind of, like, Director of dev x had a plot firm, those are the type of like titles that usually lead these initiatives.

Eveline Oehrlich 07:31
So to some extent, I have also seen them as a shared services group, of course, that name is not really Vogue, right? Who wants to be a shared services group, but I’ve seen them as a as a as an added value to, to that team, it kind of depends on as you said, so I said, it depends. I didn’t tell myself, I was not supposed to say that. So but thank you, that was really, really good. Now, again, the goals of this team, you alluded to it a little bit already, but give us what are their goals?

Luca Galante 08:06
Totally. So the the main goal of the platform team really is that of figuring out what the what is the minimum common denominator, across their entire engineer organizations have problems that the developers have, right? So you really want to start from not Oh, hey, let me through, like build a platform with the latest shiny new tech, because I’ve heard somewhere that it’s cool. And I should, I should take a look at that. But really take a look at you know, the complexity and the reality of your brownfield enterprise setup, where you usually have, you know, many different development teams with very different stacks and delivery setups, you know, you have the ones that prefer using your circle CI applies aren’t go, the ones that are on Jenkins, the other ones are using something again. And so you kind of want to take a look at all of that and get an understanding, alright, what is the minimum common denominator that souls the attacks, the largest possible problem surface, and that’s really the starting point of a platform team, together with pinning down precisely a mission and a role for the platform team that gets marketed internally to the rest of the organization, because that’s really important. In order to make sure that your platform initiative is successful, is to make clear that everybody makes sure that everybody understands, hey, you know, this is not another infrastructure SRE team. This is a product team. And so this reconnects to what I was mentioning in the beginning, which is really the core tenet of platform engineering and what clearly differentiates a platform team from a DevOps infrastruc Archer essary team is this product mindset, right? So is the idea that you need to build a very tight feedback loop with the rest of the engineer organizations, which again, are your your customers, and make sure that you iterate on top of this minimum common denominator are problems that you identified at the beginning. And keep shipping teachers and keep improving the platform by building different is different types of golden paths that we mentioned different in the definition. And this is really, the I think the make or break for a successful platform team is the ability of listening and communicating clearly, internally, internally to the organization. And understanding what are the best golden paths that I can design for different types of users across different types of teams. Right. So as an example, you’ll have, you know, your senior backend engineer that really enjoys handling their Helm charts and icy modules and some weird Yamo files and scripts that they’ve put together. If you, you know, build a platform that is very you, hi, Avi, and completely abstracts all of that away from them, they’ll fill, you know, they have no context, and they’ll push back on your path from initiatives and that platform initiative will probably fail. On the flip side of that you might have, you know, a junior front end engineer, that doesn’t care whether you’re running on Kubernetes, or somewhere else, they just want to deploy their code, see, you know, test some changes, and if you go and so for them, it might make sense to have a much higher level of structuring, whether it’s through UI, or usually what we find, on average is still you want to do something code base, because developers don’t like to be abstracted away into UI. But that clearly shows you meet two different types of golden paths, and two different levels of contexts that you provide to people. And, and so the key ability of a platform engineering team, is that of is that of? Sorry, is that a listening and, you know, being able to put together this different golden paths for for different apps to users?

Eveline Oehrlich 12:31
You know, what it makes me think of a Rubik’s Cube when you were talking about these examples, right? We have very different types of paths as you sit for these different types of teams. So that’s quite a challenge for for such a team or that gets me to another question, or I’m assuming that multiple platform teams are there?

Luca Galante 12:59
That’s a great question. It depends, if I can use that, sure, you know, so usually, in the vast majority of cases, no, actually, you know, it’s, it’s already quite a hurdle to get over to convince, you know, to get the executive and all different internal stakeholders buy in, to start and drive a platform initiative that can and should last for years. So usually, in the vast majority organization, we actually see one team, but obviously, the ideal scenario is actually having multiple teams competing with each other. And so we, I can, I can link in the show notes there. I’ve spoken a couple of times with Arne Erickson is a also really key contributor of the platform engineering community and other platform engineer.org blog, and he has a rolled out the what was the successful platform initiative of Salesforce about five to eight years ago. And in our conversation, he tells a story of how they work internally with I believe three or four outer different platform teams. And this you know, highlights again, what I was talking about earlier, which is the importance of you know, communication and internal marketing skills, which really positions the the platform engineer to have a different skill set and your kind of like usual infrastructure SRE that is more focus on you know, reliability, scalability, maintenance, and so on. Because really, you again, you are shipping a product and a key part of shipping a product for everybody that has done so well know, is distribution, right, and building that relationship to your customers. And so nowhere is that Sure. And then in larger organizations where you’re actually competing and so you’re basically building a almost a go to market motion. within your law firm design,

Narrator 15:04
you want to get ahead in your career and we can help. DevOps Institute certifications will validate your knowledge and give you the skills you need to succeed in a key area of DevOps. With our certifications, you’ll be able to prove your subject matter expertise, and enhance your professional credibility. advance your career today with DevOps Institute certifications, get started by visiting DevOps institute.com.

Eveline Oehrlich 15:31
So you mentioned already a variety of benefits of platform engineering team, let’s not dwell further on that one. Because I think there is plenty of good things you already said. But challenges and your when you mentioned one already, which is the actual making sure that executive spying? So two prong question first, what are some other challenges besides making sure that you market that? And then how and what is the best way to actually market that if I’m the CIO of company X, and you are now coming to me? How would you market that?

Luca Galante 16:10
To me? Yeah, that’s a great question. So I think the you know, there are two basically set of challenges. One is a, you know, set of technical challenges. And again, I think the, the best sort of like starting point is looking at the current reality of your engineer organizations and find that lowest common tech denominator that can be used across all different teams and start from there. And that by the way, just as a quick tangent, is something that we see a lot of people miss, as a as an idea. Because I feel like the fallacy is a lot of people think, hey, if I could only start Greenfield, right, and so I’m a new platform teams and your platform initiative, let’s start from scratch, right. But by starting from scratch, and kind of dreaming up of your ideal bathroom stack, you are missing out on a key piece of the puzzle, which is listening and, and effectively building on top of the information that you already have available. And so actually, almost paradoxically, we’ve see the most successful part from initiatives really are in very complex enterprise setups, there are very, that are very sort of nuanced, and the in the different stacks that people use, and then learn and build on top of that, and then and then from their, from their they get started. The other set of challenges is what we mentioned, which is basically internal marketing. And then there there are, there are two, I think different levels. One is the first one that you mentioned, which is basically you know, your your kind of like executive buy in. And I think the main line of argumentation there is one around ROI. And especially in you know, times like now and the macro situations that we’re living through is paramount, I think for engineering management to understand the impact that a platform can have. And the impact is not only on your kind of Dora metrics, right? So obviously your lead time deployment frequency, what is it change failure rate and MTTR? They all improve? Right? Massively, you have a crazy drop in OPS overhead in ticket what we call ticket ops, right? So basically, operations team constantly being stuck. And then on the other side of the fence, developers having to wait so you know, waiting times drop ups, overhead drops, you also have your kind of slo metrics, improving like security, stability, reliability, all improved because you get a much better audit of who deploys what, where you can easily do dis rollbacks between deployments. And so your entire delivery setup gets extremely more efficient. But I think the other thing that sometimes can be a little bit, maybe harder, like it’s a little bit less quantitative, potentially, but it’s the, you know, crazy drop in frustration across the engineer organization, right? Because in a lot of in a lot of teams right now, the reality of DevOps is developers being completely overwhelmed by increasingly complex cloud native tool chains that adults fully understand and in fact shouldn’t because it’s not their job. And so when they just want to, you know, spin up a pre environment to test a little changed is now all of a sudden need to touch 1015 different tools and three or four different scripts and completely, are completely overwhelmed by what we call, you know, this cognitive overload. And, and on the flip side of that, so what happens is then they basically either ping their most senior colleague, that senior backend engineer we mentioned earlier that likes, you know, messing around with their Yamo files, maybe. But then what you end up having is your most senior and most expensive resources, shall I say, being effectively blocked and blocking outers and becoming a bottleneck. So that’s another point for your kind of like sea level conversation. Yeah. And then on the flip, the alternative with that, again, as you’re like infrastructure and ops team completely stuck, basically constantly fighting ticket ops and putting out fires. And so there’s really widespread frustration on both sides of the aisle. And that’s really what platform engineering sets out to improve is really living and enabling true DevOps, true, you build it, you run it, and not the kind of like half baked version that we ended up with in the last decade, effectively. And so that’s really kind of like your pitch to sea level. And obviously, you know, you can, you can take smaller parts of that and go pitch to your developers and operations team on the other. After that, I think what’s important there on the operations side of things is that you make really clear again, that you you’re differentiating between sort of more traditional operation role, right. So it’s not like a platform team replaces an SRE team, you still need to care about how your load out your load balancing across all your production regions, and clusters, and all that good stuff. But you need to spin up this separate set of skill sets and roles that really focus on shipping a product and you need to make sure that that is really aligned the mission. And the vision of the platform engineering org is aligned with the rest of the serve like infrastructure teams to make sure that there are no friction, there’s no friction there. And then the third sort of group of stakeholders, obviously, as developers, and we kind of touched on this earlier, but the idea here is, you just need to listen a lot and make sure that developers have a clear idea that you are improving their day to day math and lead by enabling them to self serve the tech and tools they need to run and operate their operations in fulsome service completely independently. But at the same time, you’re not doing that by providing them some past like, some class like tool that abstracts them away from the underlying tech and tools. And again, this will matter more or less, depending on the user. If it’s a more senior user that is, you know, used to handling low code stuff then. Or just like low level configuration stuff, they will be very sensitive to the type of golden path that you design for them. And that’s where it’s really key that that you know that that information flow is really optimized. And then also, finally, I think there is a conversational roll up strategy. Again, you can think of it as any sort of like go to market, who are your early adopters, where you start. And I think, you know, we’ve seen a lot of successful platform initiatives starting by working with the more advanced development teams that usually are the ones who are going to be more comfortable with your cloud native stack, you know, they’re not afraid of Helm charts, or TerraForm, modules, and so on. And so it will be easier to start by sort of like with them, laying that foundation with something that is not so abstracted, and then progressively move to maybe more junior or less experienced teams or just teams that frankly, don’t need to be so deeply in touch with the underlying stack of things. And for them build a potentially more abstracted, simpler golden path. So those three groups,

Eveline Oehrlich 24:28
I can just hear your passion on this topic is just phenomenal. Luca, you are phenomenal. I want to say that one more time. You are phenomenal. Now I have two more questions. One is related to the platform engineering and that individual skills. And the last one is a fun question. So let’s do the hard work first. skills as you know, we hear the DevOps Institute are really engaged in skill building upskilling and all those wonderful topics and you mentioned one Skill already, which was listening something I have to tell my husband, he should become maybe a platform engineer, and then he would improve his listening skills. But no, he has no chance. But that was one skill. You said, what are some additional two, maybe two other skills you want to highlight? If I want to turn into a platform engineer, what should I have as a skill?

Luca Galante 25:25
Totally well, so I mean, from a technical perspective, obviously, you want to have a solid understanding of all your kind of, you know, infrastructure, especially cloud native tool chain, right. So your Kubernetes I see infrastructures code, see ICD workflows, good ops, you know, throw your boss word of dude, you were, you know, obviously, you wanna, you want to have those bases covered. But I think the vast majority of people that will approach to platform engineering, sort of topics coming from a, kind of like, your infrastructure DevOps role will already be familiar with that. I think, really, and I want to kind of de risk of repeating myself, but I think that there are two main things really, that I see. One is product mindset. And so that’s really the shift that maybe if you are coming, sort of like, more green to this is, or, again, from building and shipping products, that’s not a big shift. But I think if you aren’t coming from your kind of more traditional infrastructure and DevOps role, it might be a more important shift, mindset wise that you need to make. And, and that’s, I think, really key, right? And, and so that’s obviously like the part of the listening and having this mindset and really starting to think, Hey, your developers are your customers. And that’s all that matters. And so then obviously, there are oldest topics that have emerged from there. The the kind of fundamentals of product management, right, that we all know, so user research product, roadmap, MVP being, how you think about adoption, and that’s just to mention a few, right? So really just taking everything we’ve learned in the last few decades around product management and applying it to effectively infrastructure and gluing together your tool chain into a product, a platform that makes sense for your end users. And then the other one is communication broadly, and, you know, obviously, part of vision is listening. But the other part is speaking. And so the speaking part is again, like how do you think about internal marketing? How do you think about stakeholder buy in? And how do you make sure that you are adapting to the different type of lingo to communicate incentives clearly, right. So the way you communicate to sea level, and you talk about ROI, and you talk about, you know, your decrease time to market, you know, developers don’t care about that. Right. So then when you talk to developers, it’s really about, you know, their developer, velocity, I mean, even velocity productivity or more stuff for sea level, it’s really about just getting them stuck and talking about, Hey, your waiting times will drop. And, you know, this is how this is how we can improve your day to day immediately. And I think they’re a key. A key part of the communication is how you plug into their current workflow, we thought without interrupting. And so that’s, I think, is really important. But yeah, those those two things, really product mindset and communication skills are, I think, the major thing and if you were to plot on a graph, your kind of evolution of that buzzworthy sort of roles and titles from your SIS admin, to your infrastructure to your doubts in the near future, apart from engineer, you know, if you had time on the x axis and sort of like communication on the y axis, then you know, they would plot on to the right, and that’s, that’s, I think, kind of how you want to think about it, right? Like platform engineer is basically a DevOps engineer that listens and communicates better.

Eveline Oehrlich 29:20
Beautiful. Wow, that sounds like a really exciting career choice to make if anybody out there wants to know more, there is plenty more to get involved in. I just say that there is a fantastic report and I think you will look about the author of it. It’s called the state of platform engineering. So if anybody is interested in then just look for Luca Galanti and type in state of platform engineering, because there is all these different ways of getting involved in Slack channels and communities and events. Super. This was extremely insightful. I think. Now Now comes the fun part. So besides doing these great thought leadership pieces, doing your work, talking to people like me and platform engineering, what do you do for fun Luca?

Luca Galante 30:13
Um, well, so as I mentioned at the beginning, I’m currently on Tenerife. And so it’s been really fun over here. I’ve been living out of event actually, for the last couple of weeks and surfing mostly, really early in the morning, because we’re one hour behind here. But that’s, I think, one of the things that I do for fun, you know, just just being in the water being in nature, that’s, that’s really good times for me. And the other one, frankly, as a good Italian is just eating and drinking good wine. So, you know, simple, simple person simple needs, but does go pretty far for me.

Eveline Oehrlich 30:51
Fantastic. We have to meet in person, I have a van. I love Italian food. Oh, amazing. I cannot serve you with so I do like the water. So maybe we get to meet one time somewhere in a place. Maybe Jennifer, this has been fantastic. Thank you. We’ve been talking to Luke. I like Galanti product owner, product master, and really a great thought leader on platform engineering. Luca, thank you again so much for joining me today on humans of DevOps podcast.

Luca Galante 31:23
Thank you so much for having me. And if they can, if I may, just because you mentioned the the events. If people want to learn more about platform engineering, I would encourage them to check out platform eg.org. And that’s really the home of the community and platform khan.com. That’s the event that’s coming up in June this year. It’s free, anybody can sign up and we’ll have the best of the best really of DevOps and platform engineering thought leaders there. So I invite everybody to join us over there.

Eveline Oehrlich 31:56
Great, thank you, humans. Yes, humans of DevOps podcast is produced by DevOps Institute. Our audio production team includes Julia pape, Daniel Newman, Schultz and Brendon lay. Those are the three folks I want to have a shout out to because they’re wonderful. I am humans of DevOps podcast, executive producer Evelyn earlyish. If you would like to join us on a podcast, please contact us at humans have dev ops podcast at DevOps institute.com. Do I sound like a virtual agent? Maybe? Anyway, have a great day. I’m Emily, talk to you soon.

Narrator 32:39
Thanks for listening to this episode of the humans of DevOps podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember, you are part of something bigger than yourself. You belong