Hi everyone. My name is Patrick Ewing.
If you're interested in platform, engineering, how to
get stuff done and do it the right way as well as a little
bit of devops controversy than this episode is for you.
Joining me today is Luca guy ante.
He does product at Humana Tech and he's one of the organizers
of platform. Con aperol is links to socials
in the description below. Check him out.
And with that being said, enjoy the episode.
How is I don't think I ever asked you this.
But how did you get into platform Engineering in the
first place? Like what was your kind of
Journey and where did you find it?
Yeah so we you know when we started human attack basically
we came together as a group of people we're not me but other
otters you know like our CTO for instance build the platform.
A Google and our CEO was also coming from experience building
platforms at companies like MacKenzie.
Z, and I'm blanking on the name. It's the, the LinkedIn
competitor Europe, but that the never really took off, but he
was building this like black still like very larger than
engineering organization, and he's building platforms there as
well. And basically, they just
realized we just realize like, hey, you know, and you know, we
can get more into that later, but there is this concept of
devops, which, in reality for her.
His company's means pretty painful day to day, but for dads
and for jobs and infrastructure, people, and kind of leading
engineering Innovations realized it already 10 15 years ago
because they had to onboard, you know, hundreds maybe thousands
of Engineers every year and they immediately realized, okay?
This approach of trying to expect everyone to do
everything, just doesn't scale and we need to build some sort
of platform layer. In between the operations by
offering team and the rest of the engineer organization to
make things more scalable. And so that's what they were
building and we realize, hey, you know, Spotify is in the same
are being abused in this game. And and so the idea behind you -
like was to sort of, you know, build a product that could
provide engineering teams, the core through configuration
engine to build that platform in the Enterprise.
And and so we came up with this concept, which it was, you know,
the internal developer platform and I mean, I want to make
clear, we didn't invent anything, right?
Like people had been building paw prints for them in good part
of a decade, the but there was a lack of community.
You know there was a lack of just share best practices,
common terminology framework just to like think about these
things and talk about them. And And that's where we
basically started hosting events for platform engineers.
And it was in Berlin in co-operation in Berlin and we
started doing a bunch of groups all over Europe and North
America. Now, we have about 20, 28
groups, I think in over 10,000 members, so that that category
crowd groans arts, and then we progressively start adding more
bits and pieces to the community.
So, we started adding a slack channel that known as Over 8,000
members really acting. That's really the Beating Heart
of the community. If you will.
Yeah, then there is pot fringing to org which is kind of the home
where you can see all the upcoming events as a job board
that there are, you know defining pieces around.
What is popular engineer do stuff like that.
And then we start and then we launch platform con last year,
which I think was the highlight of the community.
We had, you know, 7000 sign up, six thousand attendees just from
day one and people. We'll really really enjoyed it.
And so we're going to double down on that this year as well.
And and I think you know the platform engineering community
is really like, I find it really interesting because like on the
one hand you know provides this sort of safe space for people to
connect and share best practices and were stories about you know
their platform failures or successes and I think that's
that's great and that's what I think most deaf Community sort
of provide normally yeah. I think the interesting thing
about the platforming junior communities.
It also provides this layer around identity on top of it,
right? And that's why, I think it
resonated really well, especially in the early days
with very, senior practitioners. Because again, those are the
ones that had been building platforms are ready, they just
need to know what it was cold. They didn't have like, you know,
shared, you know, framework to think about this things and talk
about them. And so I think it was like a big
relief moment of like Ah that's what I've been doing, you know,
type of thing. And and that was really and so
and then we can building on top of that.
You know, I'm kind of okay, who is a platform engineer?
What is a platform and you do, how is that different from a
devops the necessary and so on and you know, how much does it
bother me, or make stuff like that?
And I think that's been really interesting for people.
And now we're seeing a second wave of I think less Your
practitioners as well because you know they've heard about
it's like, oh this is all new thing in town, proper
engineering, I hear makes good money.
Let me something sounds attractive in that way.
Yeah, I like the kind of the notion of identifying yourself
with something and it's interesting because for me, it
was really devops. Interestingly enough, because I
came from the operation side coming out of University, I
started in operations, then I missed kind of the software
development side of things. So then I read online.
Line and I saw terms of devops like bringing both sides of that
world together and I was like yeah this is really what I would
like to do and that's where I then trended towards more so the
software development side and we still have operational
responsibilities but I can imagine that if you've been
doing this kind of things and you've been labeled into
something and it's really not a good fit or you've always been
kind of an outlier in your role and then all of a sudden there's
a term on there and the roles and responsibilities are even
the things that you're doing something.
You've always Has been doing then.
Yeah, that's a really powerful thing for someone, they can
fully identify themselves with that.
And then build on top of that right, share kind of their
experience and perspective on that and then you create the
community that you've been building which is, which is
really powerful at the end of the day.
Totally. Yeah.
Exactly. And you can really see it right?
Like the created grows but it's it's also just really that, you
know, the engagement The Passion of people joining in.
Being there is, you can tell hit a nerve, you know, somehow.
Yeah. What would you say?
So, a platform engineer, I have a certain vision of it.
But what would you say, like the roles and responsibilities are
of platform Engineers, or more? So kind of that shared
responsibility that you've defined.
Yeah, so I think, you know, for me, so for look at like
platform, engineering, broadly like I Define it as The art
because it's more an art, I think, than a science of the
designing. I mean, it's both but I'll
become clear, why? It's not bad.
Designing, sort of, you know, and bringing together all the
different Tack and tools that you have, especially, you know,
in mid and large sized organizations, you know,
Enterprise engineering, orbs, and bring all of them into a
golden path. That basically does a number of
things, it enables developers self-service and at the same
time it reduces the cognitive load Ford individual contributor
for do for the engineers. Yeah.
And these golden paths are basically the superset of this
golden path. Is the internal developer
platform or IDP in short and and and the IDP is then built by the
possible range. Here, which is usually team
writes, apart from engineering team, our platform team and the
I think key principle is and also, I think what
differentiates platform teams and pot from Engineers from you
no more traditional roles like a SRI or devops.
Is this approach of platform as a product, which means you
really want to treat your developers.
The rest of the engineer organizations as As your
internal customers and you are really shipping a product which
means, you know, you are shipping features.
You have a p.m. usually and in fact, the product management
channel in the platform engineering slack is probably
one of the most active, you know, people always trying to
figure out if you like a lot of open things because they're
still, you know, there's still a lot of questions around like
what are the best practices? How do you get?
Buy-in when you get executive buy-in how do you roll out you
know oldest things that really like this this product questions
and you know and it's a team you know in a lot of cases you have
front and back in Q&A. So it's really like a product
team. Okay.
And this requires I think a really not just a different set
of skills. But I think importantly also a
mindset shift towards a, we're here to serve Serve our
customers. Who are the internal the, you
know, the internal developers and you really need to, you
know, think hard about how do you build that tide feedback
loop between the developers and the, the platform team.
So you can either eight and then you have rollout, strategies.
You know, where do you start? Usually we see successful
platform team starting from, you know, picking one Dev team
because, you know, in an ideal scenario, you have a green field
setup. Where there's nothing platform,
team decides, everything rolls it out, great.
That is pretty much never decays.
What we see is, you know, very complex, Brownfield Enterprise
setups where you have, you know, tens of different teams and each
one of them has their own preferences around.
I use Jenkins, I use, you know, Jenkins, plus r go.
I used Circle cycles that right and it's like, everyone has
their own Spirit like delivery setup.
And so then the the goal of Of the platform team becomes to
find that minimum common denominator.
That's sold as many problems at the same time as possible for as
many teams as possible. But then focus on usually, the
more advanced teams within the org, there are the ones that are
probably more comfortable. You know if the golden path is
not perfect and they can go off path.
Meaning you know, they can mess around with the Hem charts or
stuff like that and you know and then basically ones they nailed
that Start rolling out, team by team and making sure that that
minimum common denominator says, says through valuable for
everybody. Yeah, it's interesting to me
that you say that the platform team is kind of a
cross-functional team. So you have back in engineers
and even front-end engineers in that because I thought it would
just be people building that platform, right?
There's no real fronting component in there.
And then the challenge I would see is that you're building a
product and that product is for internal Developers.
So probably what you need to know out of more than anything.
I'll maybe not more than anything.
I think it's a big component is developer experience, right?
So what makes a developer experience really solid and
really good? Like what does that even mean
that you need to know as a platform team because otherwise,
the product that you're building is for the wrong developers,
right? Or you're solving the wrong
Solutions in that way. And I thought, then if you only
have one, let's say competency within that team that's going to
be harder because you're not going to have Developers that
like build features and stuff like that, and ship that out to
other customers or outside customers, I guess.
But if you say it's a real cross-functional team, then that
challenge becomes a little bit more manageable, I guess.
Like how, how does a team like that structure itself?
It's cross-functional, you mentioned.
Yeah, and I think it depends, you know, heavily also.
So the way, the way I think about platform engineering and
you know what we advocate for in the community Is a, you know,
providing platform teams with a an opinionated toolbox.
Okay, basically, to build opinionated workflows was that
mean that, you know, if you think about the key difference
between, I guess like a predecessor of the IDP, which is
a path of something like in a Roku four, people are familiar
with that. Yeah.
Um, you know what if past says is, hey, I have Looked at the
market and I have formula or the product team behind the palace
as I've looked at the market. I found the minimum common
denominator that I believe it's valuable for, you know, as many
things as possible. And I have ingrained that in a
framework, that is, you know, great to get started really
quickly but it's really not very flexible, right?
And so that work worked really well, like, right Heroku is Is
really popular, but it kind of, I think, you know, slide and out
at some point because people realize, it's great for you
know, Gregory Angels setups. Poor teams of a certain size we
usually, as a rule of thumb, say, you know, below 30 50
Engineers like it passes, probably, grade solution.
But if you go beyond that, you'll start having to be a lot
more flexible in the golden pots that you need to build for your
organ from the different teams. And so having a solution like a
process, becomes you Hard. And so the idea is hey, here is
a tool box set of principles design principles, you know,
best practices and so on to go and build your IDP and the key
thing about an IDP is that the platform team will depending on,
you know, what is the context of their engineering innovations
that they're working and shipping for is, you know,
they'll take the right path, sir.
The right level of abstraction. And I think that's really
important because, you know, you'll have different types of
users. So you'll have the Junior front
end, maybe that doesn't care whether the application is
running on GK e on E KS. What is running kubernetes at
all? Yeah doesn't matter.
Like I just want to say just want to you know deploy it a
simple change to their app and see and see the result and
contestant and some environment that's it.
But then you also have you know your senior back and maybe the
really laws messing around and llamo filed and help chards and
For free. So the question is, what do you
do, right? And that's where he becomes
really hard to take this, like, pass approach of like Boop.
Like here's the solution for all your problems.
It's unlikely to work and skill at an Enterprise size.
And so instead is how can you, you know, build a product team
that really has this tight feedback loop with the different
other product, enjoy the different Dev teams and And and
really, you know, builds his pads and all spots, option
options for for for everyone to kind of use and and, you know,
their feet, their few, sorry, their few kind of like key
principle that we do. You talk about when we talk
about platform, engineering, one is, you know, Platformers
product. The other one that I mentioned
earlier is you want to focus on this like common problems but
then The other, I think the other things that are really
important. Are you know this this concept
of being the glue is really valuable, right?
Like you really Fought For Engineers need to you know make
sure that they did the tie together, all these different,
you know Tech and tools. In one golden path that really
makes sense and that optimizes for reduction of cognitive load.
And and you know, frustration honestly, right because what you
see in a lot of you know lot of I think engineering orgs today
is you have a double up steam and you have the rest of the
developers and as the, you know, with with this converging trends
of cloud native kubernetes. I see get-ups, you know, and all
of it together and it's like crazy CN CF landscape was like,
huh? Is a thousand different tools
then. Now, you know, in a lot of
situations if I'm a developer and I just want to, you know,
deploy simple change to a Dev environment and test something
or I want to spin up a preview environment to do that.
You know, I've seen many Enterprise organizations where
that can take you like one or two weeks just to get an
environment just to get it in a database provision and so on.
And so that creates all sorts of waiting times for stration
foreign developers side and the on the operation side.
You're basically you become a glorified help desk.
That is just trying to put out fires and you know fighting kick
it off constantly and and so the DEA deal of having this glue of
building, this golden imbalance is is really to provide this
layer on the one hand for developers to just self-serve,
what they need to run their apps and services, you know, in
independently and then operations can focus on on I
think batter. More interesting problems.
Let's say then provision is saying pause for a sequel for
the tenth time. Yeah.
Interesting. One of the things that you
mentioned still kind of lingers in my mind in that but if you
start out on a Green Field like if you start on a Brownfield,
you can kind of find your common denominators because you already
know what people are using. You might want to standardize
some things here and there and then it makes sense to like have
a platform team specifically that Taylor stores your
internal. Purrs.
But when you said on a Green Field side of things, it would
be better if a platform engineer already starts with that.
That for me is hard because for me, it's like a chicken and an
egg problem, right? You first need to figure out
what your developers actually use, and what they need or
because they have to figure that out when the product with the
product they're building. So if you don't have that, then
how can you make a platform that already like is going to make
the developer experience better if the developers don't even
know what they're going to use at the end of the day, right?
If you're in a really fast mode, you might choose some databases
initially. And then later on figure out
that other databases are more apt for the product that you're
building. But if you from the start
already have a platform team, then they're going to have to
provision different things or their golden path is going to be
very flexible or malleable especially at the early on
stage, but you still think starting with a platform team,
kind of in a green field. Setting is a good step in that
way. What have you seen?
So I think that's a really good point.
I think, you know, from the platform team perspective that
is the dream, you know, because it feels easier, but I think you
bring up a really good point which is you, you then are
missing a initial starting point that tells you already what the
preferences of your developers are.
And and so I still believe it can be more ideal if you have
Those conversations those lines of communication with a
different Dev teams in place, right?
But yeah, communication is everything and I think that is
one of the things that I think Trends in the, you know, like
hopping to the right, like going from the serve like ancients is
admin that was living in a basement trying to figure out
servers like and then to the devops and not depart from.
Here. I think there is just like a
correlation on increasing like you need better communication
skills. Yeah.
And you really need to make sure that you can, you know, listen
to developers but not just developers that you're able to,
you know, sell up to management Executives to get full,
stakeholder buy-in and, and really think about all different
stakeholders. There's also one thing that I've
seen in large organization, like, examples Salesforce, Is
multiple platform teams competing, okay?
Right so, so then you add the extra layer of complexity where,
you know, you're really in a race with the chatter and, you
know, it's really which I think is healthy, it can be.
Obviously there can be some like, you know, pros and cons
like in everything. But you know may the best win is
is a good, you know, kind of like self-selection process and
an end that You're interesting because then it you're really
like not just a product but it company almost like you knew.
You really need to think about your distribution and almost
like your internal go to market versus the outer.
But that's that, that's really just for very large.
Organization was right? I can imagine.
Yeah, most companies it's it's hard to even get one often
teamwork. So but I mean it's for me it's
the ideal situation, right? And you might, you might think
it's strange because obviously if there's multiple platform
teams, why just not join them together?
Weather and make one Uber platform.
Like, I've heard a lot of stakeholders say that shouldn't
be joined forces and do that, but at the end of the day, like
bunching up a bunch more people. If you have a really big team is
going to have so much overhead in communication and sharing a
mental model of what. The thing is, we're actually
building or what problems were solving in that, if you separate
that, then obviously there's going to be at some point.
You can see some teams going faster or having better results
than other teams and then even with the teams that are not
going as fast, there's the Things there, right?
So if you then centralized that, then you can build the best
solution in there. Except that's going to have a
lot of people, a lot of resources and time and money in
that way. So then it doesn't sound as
efficient. But if you're looking at the end
product, the end result. Yes, I think at the end of the
day that will be better just by virtue of that which is
protocol. So, in large organizations, I do
see value in that for me, I'm really looking into kind of a
start-up phase in a more so project oriented thing because
that's kind of the team setting that I am.
In now with the project that we're doing and we envision
multiple teams working on this product that we're building in
different teams and cross-functional teams and a
future platform team, but, right now, the future is not there
yet. So we have platform Engineers
but they're in the kind of cross-functional teams that
deliver the product at the end of the day and they're very
close to whatever needs to be done, right?
And if that's if they have to build software they'll build
software but more. So when there's a platform
component, they already start figuring things out.
When it comes to In that and rolling that out and making that
easier for the future also. But I have seen that there needs
to be a balance in there because if you read leverage or really
focus on making it easy to roll out and making a configurable
and stuff like that and then the development team decides all
this is actually not like good for our use case anymore or were
shifting or pivoting because of new learnings then.
Yeah that kind of feels wasted. So I do feel like there needs to
be a balance in there, but the best way to figure that out,
it's the half the platform Engineers than beer.
Really close to the development team.
That's how I would start out. You need that feedback loop and
and also you need I think frankly.
But you know, platform team that doesn't fall in love with their
own product, right? Where it's like, no I built.
This thing is the perfect thing. Shut up, use that.
It's like it. And you keep either rating
because, as you said like, the needs will really change, right?
You have in some cases, you know, maybe like the Earth.
Beginnings, usually, and this is where I feel like I'm platform
is almost not needed, right? If you're like 20, engineers and
you're old, you know, see our Engineers, your old comfortable,
handing, your Hound charts, and your icy modules, and so on so
forth, then I mean you don't really need a pot from like that
would be an overhead at that point over Kaiba.
Like as you start scaling that becomes less and less true.
And then, you know, you have this like more Junior, people,
people that I've never used kubernetes before people that I
know. Ever used to reform before and
then you need to like, make that me on common denominator like
broader and broader and then you get to a point where, like, all
right now we really need this like, you know, high level
golden pots where, you know, for, for the senior back end.
That's been here for three years.
It's still like they can still mess around with with the files
but maybe we have some like bother plate templates that you
know, we control as a platform team and then for the more
Junior folks, you have just like it affect, you like it, click
off cui, you know, To to do things that obviously, like is
more restricted, feels more like a past, but that's fine for that
use case, right? And so you need to keep it
really flexible. Yeah, it's interesting to me, is
what have you or have you seen in the community?
People going more towards managed Solutions as well, or
managed Cloud Solutions. Like I get the Heroku example
and kind of a possible solution. A lot of cloud offerings are now
more so managed in the fact that you give it a configuration and
it scales up things automatically where people maybe
even choose less S4 kubernetes or even a more so managed
version then the operational overhead because it's managed
becomes lesser, right? So then I think also the strain
on the platform team is becomes lesser because of that but then
their role and responsibilities more.
So I think that's maybe my vision becomes more so
configuring that to the best way it can be right for the use case
and so on so forth and then the development team, doesn't really
have to figure out how to do that or what the best way is
because that's kind of a, it's kind of a different ballgame,
that's a Playing field in that way to optimize for what you're
doing. You need the knowledge to do so
in the first place. Yeah, absolutely, exactly like
that. Java platform team is really to
take this tool box. So that was talking about and
then, you know, and then there's different types of tool boxes,
right? Let's get a kind of like Get
live, only one doubts platform which I think, you know, is
still a bit tremendous missing entire that were they?
Yeah, of of it. Past really, if you're being in
for being honest, you know what we see in the vast, majority of
cases for like that your mid-sized to large sized
Enterprise is homegrown open source tools like past together
basically. And you know so you have your
like your terraform your are go you know some people put it like
a backstage on top type of thing and and and that that that's
great like that works for Of folks, what we see though,
especially, you know, for a lot of those like mid-sized, also,
to large-sized teams, that just don't have a lot of the
satellite platform engineering capabilities in-house.
Yet is you are Reinventing the wheel, right?
Because, yes, there's a tongues of Open Source, which is out
there, and it's great. But the challenge is, you know,
to figure out which tools work best with the chatter, you know.
No and there's really a lack of reference architectures and
blueprints right now, which is why, you know, we actually one
of the one of the tracks of platform.
Conditioner is cold pot from blueprints because I think we're
in we're getting to a second stage of the platform.
Engineering, you know, movement where at the beginning the last
like year and a half two years. It was really just about like
hammering, this ABO like hey, if you want real true, you build a,
you run it platform. Learning is a way of doing it
and the Enterprise, especially, and, and now people are all
right, I'm sold. Where do I go next?
Like, where do I start? And there's very little, you
know, when it comes to starting points and blueprints and just,
you know, share architecture is that people can look at.
And so that's something that we're focusing on community wise
this year. But, yeah, and so that's why I
think, you know, that's kind of, you know, the value prop with
With you money take is that is, you know, take this like or
configuration engine and then go build your opinion and workflows
on top of it for your org but don't try and reinvent.
The whole logic, you know, of configuration management and
how, you know, resources are provisions and all that stuff
because that's where we see a lot of teams just doing the same
work over and over again because, you know, everybody is
a special snowflake but actually, they're not really Get
that I mean it's interesting right because when new tools
come out step one is to figure out how to get this thing
working out how to get things done with it or how to use it to
leverage whatever you want to do.
And when you have a bunch of tools you do that, you get stuff
done with that and at some point you're like okay maybe this is
not the best way but this is our way and you talk to other people
and you learn about what they've done and then all of a sudden
you kind of have shared better practices until they become best
practices and those might be within your organization but if
you standardize that Then people that are new to that and there
are in kind of a starting phase. They don't have to reinvent the
wheel, right? Because then those that already
have done and figured out how to get stuff done, they can educate
those on what they've done and then all of a sudden you're
going to have a shared methodology of how to do the
thing in the first place and how to do it, right?
Because that's the most important part that makes it
sustainable towards the future and flexible, probably.
Because the future is kind of unknown in that way as well.
I like that notion of, like, figuring out your internal
golden paths and then even may be standardized It's never going
to be a silver bullet, right in, you're always going to have
options but at least kind of defining a blueprint for other
people to hold onto or to learn from.
I think that's very valuable. Totally.
Yeah. Yeah, exactly.
And yeah, so that's what we're trying to do.
And I think like you mentioned, you know, being being like you
know sustainable I think that's really that's really a key word.
where, You know, you really need to think hard.
I think. So, you know, let's say your
Google, of course, you need to like, build everything
internally because your requirements are going to bestow
specific and custom. And in fact, I mean, they have
like, tens of different platforms, right?
Because they're so huge. Yeah.
But you know you really need to look at like the ROI of these
things and think about. Okay, you know, how much can I
build Scratch, how much can I, you know, how much time can I
put into this? Because the average sort of,
like platform initiative that we see is a year to two years and
the issue a lot of times and something that, you know, in the
community we weren't people against is like, hey, it doesn't
end there, right? Yes.
People are like, yeah, build the popcorn.
Great. But you know, that's actually
where the work starts is, then you're like Ida rating on this
product and And that, you know, takes like ftes takes resources
and so on so forth. And so, I think that that's one
thing that also is this, I think Blueprints and Wilson another
track that is an impact to track.
It's more geared towards, you know, understanding the value of
the ndr i-- of platforms for management and helping Engineers
sell internally. But also making sure that
everybody oldest a Holder's internally all are aligned
around this concept of, you know, what are the expectations
of value creations and what are the costs because the costs are
really not trivial. So, it's important to keep that
in mind. Yeah, it's interesting because
what you mentioned, like, I can see that from a product building
perspective and obviously that then holds true if your if your
platform is your product. But looking at it, let's say I'm
a software team and people are building things and we're
working towards a goal. I've I've you have people that
really thrive in that kind of early on stage, right?
And then when your live as you mentioned, then you get more.
So faster customer feedback. So then you can iterate and test
your assumptions faster and move on to delivering more features
and more value in that way. But for some software Engineers
that stage becomes then less interesting because they really
like the early, the early start of things where they get to test
and they're really good at that fast.
Iterating testing what really feels good and what doesn't
based on the use case that they have and more.
So the But once they're live, that's not really their Forte
because then they're building on top of what they already have.
Is that kind of the same for platform Engineers because I can
imagine you build towards like releasing more value for your
developers that developer experience in that way.
I don't know if it's the same or comparable to going live with
certain features but I can imagine some are and then
obviously, once you are live at, once you're happy with kind of
90% of your platform and that then becomes or then you move
into kind of that iteration phase, I can imagine Even some
platform engineers then that's really not their Forte as well,
as that kind of comparable in that way.
Yeah, absolutely. You know, you have to kind of
like the 021 people, right? And then the, the OnePlus.
And, and so I think the same thing like, you'll have the
people that, and especially I've seen a medic a couple of sort of
like, senior consultants and people that have built a bunch
of platforms. And they really enjoy this, you
know, starting from scratch phase, where they enter into
company to disaster. Whatever, you know.
And, and then the the spend like, two three years and they
built it and Equipment while to set up the team.
And then you have another team that basically takes over from
there and, and off, you go, right?
And that's great. I think that is the ideal
scenario, to be honest. I think that the issue is a lot
of times people don't think about face too, right?
And it's like, oh, we have an issue pot from seems to be a
potential solution. Let's explore.
Let's build one. But without a Sorted initiative
internally to keep driving this and understanding this is not a
one or two years project. This is probably a, you know,
five ten years depending on the company.
Yeah, interesting. Also based on what you were
saying, I wonder, let's say you have a bigger or medium sized
organization, even a large one, and there's no platform team,
right? So we have separate development
teams, kind of doing their own thing even making their own
Solutions or choosing their own stuff, resource wise.
And what they need for production.
At some point, I can see is, it would be good to standardize
that, right? And a platform team, will kind
of build that solution towards that, but if there's no platform
team, who's going to advocate for creating such a team in the
first place, like, where have you seen that coming from an
organization? Is that the engineering managers
that a CTO? Is that the developers
themselves? Like, where does that in cling?
Or that idea usually come from? Yeah, that's really good
question. So I've seen it coming from both
On both sides of the equation. So either the you know the
engineer manager who's just really frustrated with her
Engineers you know not being able to deploy or yeah.
Just like her own day-to-day and like this sucks.
Like why does it take so long and but I think honestly
probably I would say 80% 70 to 80% of cases is actually the Ops
item of the equation. Oh, come because they're either
one say I think suffer, most in most cases.
So to give an example, if you are, so the Ops side of the
equation will suffer in pretty much in in Old Company sizes.
Yeah. Whereas the large company both
the developers and the Ops are really frustrated because this
problems the problems that platform engineering addresses
get worse as the As the engineering org size grows,
right? So you have you have a certain
point where it's just so bad for everybody involved.
That when you everybody's like, oh my God, yes, platforms.
Like let me sign now, but in a, if you think about maybe a case
where you have, you know, a couple hundreds engineers and
it's a more advanced engineering organization where you no more.
Confident like handling certain certain things and then they
really just need help with that like that.
I actually like the final 20% of you know, deployments
provisioning infrastructure stuff like that.
Then from the point of view, as a bit of the site tragedy of the
commons, right? Because from the point of view
of the company and the and the org engineering or get, it's
still a net positive to implement a pot fur.
But from the perspective of The Selfish perspective, Active of
the developer. Now I go from I just slack my
Ops Team and usually they get back, you know within a couple
of hours problem solved, great too.
Okay, now I need to learn this new, you know, platform thing.
It may be interrupts my workflow, you know, type of
thing. And so from their perspective,
it can be like a net neutral or maybe even a - right.
And so that's Where those are the scenarios where we see, you
know, the Ops / platform teams. I really Keen to push because,
you know, they're their reality still is a lot of take adopts
coming in, so it still sucks for them, but not so much for the
developer. And that's where I think.
Again, it's really important for the platform team and the
developers to have a really scared Vision around.
How do we, you know, no create an on-ramp for platform for
developers to, you know, access the, the platform and and make
sure that it fits into existing workflow as best as possible.
And that's really important, right?
So, for instance, one learning that we made as been to, you
know, most Engineers really enjoy, you know, they're really
used to like a fully code-based. Kind of like workflow, we're
going to deploy and everything is get bays and so on so forth
and so trying to impose a click hop cui type of thing where now
a little bit further than you can jump out of there, you know,
code based workflow into some UI and try and figure this thing
out that they've never really seen and you know, it's not like
oh I'm learning this new skill that probably means.
I get it like a pay. Raise the next job, not even.
Right. It's It's like it's just kind of
annoying now and that's where we see for instance platform
initiatives fail when they really focus on this like
dashboard like thing, why? Because a lot of times
especially from the perspective of, you know, management or
people that need to, you know, sign off on this like rollout
it's really great. The idea of having this like
service catalogs of having this you know, beautiful one place
one, you know, pane of glass to see everything but that's not
where Are the issues are. Usually the issues are around my
configuration management, infrastructure provisioning
their level deeper and and and it's not.
And so it's not about just putting, you know, there's this,
there's this guy Lee that build a platform where apple and he
wrote an article on platform Regina or get that is called
something like along the lines of if you put a, a pane of Glass
on top of a pile of shit or you see shit?
Yeah. And And that is, you know, the
idea of, you know, you really want to focus on what are the
core issues that that block developers in the day-to-day and
in our experience that's really around configurations and
infrastructure provisioning. It's not about, you know, how do
I template my service? You know, and then start from
there and so it's really important for platform team
Stooges. Figure out.
How do I fit this into into the developer workflow in a way that
makes sense? And that's where we see code,
fully code based interfaces, right?
Like using yellow flies, and stuff like that, as the, as the
best. Again, minimum common
denominator across the board, interesting?
Yeah, I think the challenge with the biggest challenge, I see for
a platform team is really just figuring out where the value is.
And that puts, I mean, that responsibility lies with the
product manager at the end of the day, right?
And because they're building a product to people that are more
technically oriented, right? Developers in the first place
does, the product manager also need to have like a lot of
technical knowledge in that way? I can imagine like a previous
life of developer experience would help in that, but that
might also bias them towards Solutions, which might be
outdated. Like I feel like there needs to
be a balance in technical information but not too much in
that way. Also.
Absolutely. And that is why, you know, if
you check out the product management channel on the slack
space, like day is one of the most is were probably I Find
some of the most interesting conversations and threats going
on. Because, yeah, as you said it
took a really fine line and really find that is that you
need to find. And then really think hard about
where in in this site value chain the most value lies in
terms of the problems that you can solve and one of the one of
the issues not to bash you know service kind of like the next
things. Like we actually work really
closely with their with their team, they're really acting the
community but like it, It's important to understand one of
the, one of the fallacies that we see a lot of teams full into
is, and my battery is dying. So I'll call you in a second,
but like is the idea of, you know, basically looking at the
de workflow of developers and chronologically.
And so they say, okay, we need to put fur and you know, we want
improved of X and Bubba. They start like, you know, top
down and Then they and then later.
Okay, what's the first thing the developer does?
Oh, you know, she creates a application as a service,
whatever. And so that's when they start
thinking, okay, how do we optimize that step, right?
And then it's like, oh service catalogs.
You can see all the services that other teams are using blah,
blah blah, and like that is okay in practice except that that
step like, you know, changing that step, you know, maybe
improves, you know, in your efficiency by one or two
percent. Yeah.
Instead of looking at light, where is the actual like hyper
painful? Par you know of the developer
dream. She's usually actually handling
the outer 10 tools that come after that, just to deploy
something or provision something, right?
And and and so that's where you know, you want to build a
platform that takes all of that into consideration.
But usually you want to start from where you can deliver more
value not. We're people start horn logic.
That's like one of the anti patterns, if you will then we
see emerge sometimes the interesting, I've never had that
role. But obviously, with my kind of
software engineering hat on or goggles on rather, I would sit
next to software engineers and either pair up on a problem and
see what they really face either in deploying their stuff, we're
putting their stuff into production, right?
Because that's kind of the end station of things, that's where
it ends for them. Once it's live, maybe even
looking at like the information the game from that, but still, I
think that experience will give you the most insights in the
pain points, right? And if that is built on time or
if that is kind of the tooling the other tooling that are
using, then that should be kind of your number one priority
because that's going to deliver. The most value that's going to
make their experience better or more efficient or it's going to
make them more effective in the first place and I think as a
team that is the responsibility. So starting with like it's
similar to being as close to your customers as possible
except your customers are developers in that way.
Yeah, yeah. And I think one of the issues
that we see Is when it's top down, you know, and it's like,
oh, we need to a, you know, CIO acts reads article.
Why about, you know, that's apologies that and like, that's
great. Like we need to roll it out and
then we see a lot of people coming in and like, so we have
been told we need to adopt this thing.
What do we use it for? You know, and just try to figure
out from there, which is, obviously not ideal.
And sometimes you just have this, you know, inefficiency is
especially in larger in large organizations, where are, you
know, platform teams, it's a, if you think about like a star up
in the wild, if you know, if you were going to try and solve the
1% problem instead of the 80% problem, you would just fail,
you wouldn't, you wouldn't build a sustainable business and the
problem is because you don't have a lot of times in this
large Orcs that that feedback in terms of like, you know, does
this team even make sense to exist then you just have you
know initiatives that make Sense.
Yeah that makes total sense to me.
One of the last thoughts I still have is kind of a controversy I
saw online where I don't know exactly where it came from, but
it was all over Twitter a few weeks back and was like that.
Whoops is dying and platform, engineering is the way to go.
What is your take on that? Do you see kind of a trend
declining for devops and people moving more towards like
building platforms as a product in that way?
Or will it work better hand in hand?
Like, what are your thoughts on that?
Yeah, so That was a really funny story.
I think and, you know, we, it wasn't actually us now they're
at the beginning, but we definitely saw it.
It came out from actually an interview of our CTO with a
YouTube YouTube channel. And then, you know, the recap
was this like very catchy Delta's that long live Popham
engineering and, you know, we thought.
Alright is brother, let's run with this and And that exploded
to an extent that I never thought, you know, it would, but
I honestly think it really trigger triggered.
A lot of people but it also triggered a really help the
conversation in the space that I think was really needed because
look I think from my perspective, one doubts came up
more than 10 years ago, the world was a very different
place. We mainly developed monoliths,
may be running on bare metal. We had, you know, incredibly
less complex infrastructure. There's no Cooper.
At ease. No get-ups know, all the cloud
native stuff they were talking about earlier and the initial
idea behind that was a great idea which is remove the
barriers between the vaginal and Ops and facilitate
collaboration. That's great.
But the reality of that is very different.
So many organizations don't pay, I think enough attention to the
culture or challenges which is, you know, not the fault of that
is not the fault of Ops or download sleep at all.
No, but they're just like, you know, with this increasing
complexity of all the strands, you know, coming together and
converging you the reality of devops is where we are
describing earlier which is developers are blocked, they're
afraid of messing something up. And then you have this role of
the devops which in itself is a bit of a contradiction that
that, you know, basically is doing oldest.
Take it off sand. And trying to survive.
And so, the idea of platform engineering, from my
perspective, and from our perspective, thinking journey
across the community is to enable true.
You build it, you run, which is the core tenant at the heart of
devops, right? And and what that means is now
developers can actually self-serve tacking tools to
deploy run and operate their applications.
And Aces and they can actually do that without depending on
your Ops devops Team and your opt-outs team can actually focus
on building a platform for developers or on essary
maintenance, reliability, and, and just better challenges.
Then, you know, setting up old is this like fighting take
adopts constantly basically. And so, I think that
conversation is a really healthy conversation to have especially
because You know, I've so another thing that happened is
at as Humanity tag. We went to cube con Detroit and,
you know, you have to submit your booth designs two months in
advance. And this is when we had to like
the whole like, you know, that which is that, I think, I
literally just started, I was like, oh, this is great, like
this is gonna get a lot of conversation.
Sorry, that's it. And then this whole thing
explodes, completely out of hand and then we're like.
All right now, Is our books. And but it was incredibly
interesting because you had all these people that was Engineers
that would walk up to the booth really angry so much that I'm
right, because there were like what the fuck like adults
engineer. I'm a lot.
Like what are you talking about? And, and I kid, you not every
single one of them, by the end of it was like, we hugged it
out. They all walked out with our
doubts, is that t-shirt, which is a sick design.
And, and they were like, thank you.
This is actually really important conversation to be had
in the community. And I think on the flip side of
that, the people that were more protective are, you know, the
people that sell devops there are, you know, within that like
loud minority, you know, Twitter bubble which is also very much,
you know, mirroring who are the sort of exhibitors, I keep Khan.
Yeah, and And I think are the people that have a interest, you
know, in gating is Concepts and and and I think are straight up
in some cases a little bit delusional because they live in
this world where, like, oh no, devops is here to make a word
about a place. Like, no, it's not.
It's a philosophy that started as something that is incredibly
valuable, but the reality of people not working in selling
doubts, but Actually living devops and their engineering
organizations is quite different in a lot of cases.
And so I think there's been this growing gap between, you know,
the industry experts and the actual practitioners and they
don't really speak. And so that's what we are hoping
to kind of address with the pot from engineering community has
created a space for people to address these things and
honesty. And you know, I think like most
disciplines and trends like Eventually it morphs into
something else and eventually you have a ingrained cast almost
that protects it because they've just, there's so much invested
interest in that, you know. So, very likely, it will happen.
The same thing. Probably for the apart from
engineering at some point, but I think now we're hoping that it,
it just freshens up the conversation because I think
it's needed. Yeah, I think that's a, I mean,
It's a trigger and it's a marketing thing right there.
Whoops is dead. But the people that come to you
angry and want to start that conversation.
Those are the most passionate people you're going to get
because they care, right? If they didn't care, they
wouldn't walk up to you. They wouldn't be like, what the
hell is this? They care and they want to have
that conversation and if you can bring the value to them and have
that conversation a healthy way, I think that's just a win-win on
both ends, right? Because then you share
experiences, you share perspectives and then their
Horizon gets broader in in and of its own to the point where
they get the Sure. And they love The Fray.
I think that's really cool. Hey, that's a really key point
that you bring up, which is having two healthy conversation.
And that's one thing that I've realized what we were a cube
Khan, which was like, okay, it's great to have this in-person
interaction where you can really take the time to explain what we
mean. Right?
And then that trigger is really, you know a great top of funnel
like drive into that conversation that you have the
conversation, the issue with the online version of that was you
know, because it got Not so viral the velocity of that
message was just too high for the velocity of the
conversation, to catch up to it. Which meant, I think, in a lot
of cases, people got it without any context and and then I think
you can do more harm than good. Which is why we completely drop
that and we're rephrasing it more towards, you know, you
know, keep talking about the challenges that was burnout and
like other ways of phrasing it but not necessarily that whoops
is dead but it's funny. There are still It's funny to
see six months later. Still all these articles popping
up literally every week on? Like is that v dad my take and
I'm Frank that can't see them anymore.
This is a yeah, that I mean it's super catchy and I yeah, that's
it. That's how I got.
Oh yeah, that's how I saw them as well.
I want to know if I want to round it off here, Luca.
Is there anything you'd still like to share with our audience
that's listening in? Um, I mean, come check out the
platform engineering community. So pot from engineering to or
apart from con.com, those are kind of the main sites.
And then from there you can join slack which as we said is go
over. 8,000 practitioners super-active.
Pop link on 23 is coming up in June 8 and 9 is we recently just
relaunched the website couple weeks ago is completely free is
virtual so everybody can join and we're going to have you know
probably 100. 5,200 amazing talks.
And I think that's, that's really good place for people to
start. If you want to, if they want to
check out platform engineering. See what it's all about.
Yeah, sounds awesome. I'm going to put all those links
in the description below as well as links to Luca social Luca
diaunte. I hope I pronounced that
correctly. It's Italian.
So Allah put his social in description below.
Check him out. Reach out to him.
Let him know you came from her episode.
And with that being said, thank you for listening.
We'll see you on the next one.