Narrator: 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: 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: 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: Thank you. Thank you for having me. And hello to
everybody from Tenerife. A really nice place.
Eveline Oehrlich: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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