Transcript
This transcript was autogenerated. To make changes, submit a PR.
You. Hi everyone,
thank you for joining in this talk about platform engineering adoption.
I hope you will enjoy and learn a lot from my
presentation. So let's start. I have prepared
today for you a talk about three practices that
will ensure the success behind platform
engineering adoption and make it more smooth.
Right. This is based on my experience and why
I feel confident to talk about this to you.
Well, during my years
working, I had the chance to work in Red Hat enabling
stream alignment teams and also platform teams. I worked in
the open innovation Labs team here in Ladam
delivering the DevOps mindset and practices
in different companies. And also in
my previous year I worked in display in the
global it center providing a
platform as a service for development
teams, providing the platforms that will
help them implement DevOps practices like CACD
code versioning. So I participate
and lead that platform team there. So all
the things I will talk for you today will
be based on this experience. So if you have questions or
doubts, just reach me out in the LinkedIn or you
can write me an email if you want. Right? So what
I have prepared for today is the three steps
presentation. First of all, we will go through what is platform engineering,
the what and why, why we should implement platform
engineering, what is the benefits? Then after
understanding the benefits of platform engineering, we will talk about the
challenges, the roadstones, because not all paths are
easy, right? So it's important to understand them
and be cautious with them to avoid the typical
errors. Even when we are adopting other kind of cultures and practices,
some of them are very common between them.
And last but not least, we will talk about the three practices I
mentioned at the beginning break and the reason for this presentation.
To avoid the possibility to fail or
fall down with the rollstones, this path of platform
engineering adoption has. So let's start
with the intro, the what and why of platform engineering.
So what is platform Engineering? It's a
discipline. This is the description you will be able to find in platformengineering.org
webpage. It was defined by Lucas
Galante, one of the leaders of platform engineering
movement. So he defines platform engineering
as a discipline. Discipline is basically something that
several people is doing, doing, trying to implement,
right? But it's not just a discipline, it's a discipline of
designing and building toolchains and workflows. And when
he talks about workflows and tool chains, let's talk about first
tool chains. Tool chains is a group of tools integrated
and fully configured to work together. And workflows means
how people work. So we are talking
about them together, right? The platform engineering practice
is focused on generate them together
to obviously enable self services capabilities
for software engineering organizations in this
cloud native era. So Lucas Galante was seeking to find
this thing for this definition of platform engineering to
make it understandable and generate this sharing understanding that is
a practice is the discipline of reducing
the cognitive load of the rest of the
teams to focus on their core business and have internal
customers using this platform as a self service
and reducing the possibilities of them to fail.
Because they need to learn and develop skills that are not focused on
or are not related with the core business they should be focusing.
Right? So why we
are looking for platform engineering? Why companies are
looking for platform engineering first of all is the standardization
and control. Because if you have all
teams in your company working as they want or with
the tools they want, or even with the same tools,
but implementing the tools as they can or as
they understand, it's difficult to maintain,
it's difficult to support at long
in the time, and also it's difficult to control how people
is managing these platforms to take the real profit and
to really implement the best practices.
All companies are trying to promote mainly behind the
concept of DevOps. So platform engineering
and DevOps will be very connected. Even some
speakers of platform engineering are saying that platform engineering
is the next level of DevOps. The next benefit
is reduction of cognitive load. The platform team
will focus on have the skills to prepare
the platforms for product teams and avoiding
them to have this knowledge that is not really
needed to build and deploy their
own applications, their own it core business.
So they will only will use in a smooth
way these platforms, reducing the knowledge they should
need or the expertise they should need to keep like
platforms of CI CD to run and build
their applications or platforms to deploy the applications
and manage the error environments. Also something that will
improve is the reliability and stability because
we will have an internal team focus on
the internal customer which will be these stream aligned teams,
dev teams or product teams. So they will focus to have a
real strong platform where the internal
customers will work over to promote a better
service for external users. So it
has a lot of benefits for companies that are implementing,
but it's not a smooth process. If you don't take
care of the main Roadstones, we will look here.
So if you want to go deeper before to go to the Roadstones,
if you want to go deeper on platform engineering, I will recommend these
talks that are available in the library
platform engineering YouTube
channel. First of all, Manuel Pay is one
of the writers of team
Topology's book were born this concept of platform
engine, platform teams. He talks
about what is a platform as a product and this is
one of the topics we will be talking here and is strongly
related with one of the roadstones we need to identify
and work on. The other one is Mayuri
Hyde is one of the collaborators of
Lucas Galante in this platform engineering community.
She's so smart and based
on her experience she talks about what's
happening with DevOps and platform engineering as practices,
as movement, how they work together and
finally, but it's really important, the state of
DevOps report for this year 2023, focus 100%
on platform engineering. So if you want to know more
how platform engineering is impacting in
the world, you can check the information in the DevOps
report. What are the Roadstones?
Where are the challenges behind platform engineering adoption?
Because sounds very great to have platform teams inside
my company taking care of platforms and solving
the live for my product teams and they will be able to focus
on only develop and build their applications without the
need to learn about how to implement CI CD or how to implement
cloud native deployments. Everything will be ready for
them, right? How we can adopt this
way of working smoothly without
the failure that some companies had experienced
in the past. So what are these problems?
Right. First of all, we need to understand that one
thing is what we believe, right? There is no easy path to
success. Everything we will do will have challenge.
So we need to take care of this, that platform engineering,
even when it sounds amazing as all
the benefits it brings, it's important to understand
that it's not a smooth adoption, it's something that you
need to take care because will have a huge impact.
Because we are talking about teams that will focus in internal customers
and they will provide services for all platform, all product
teams that will be using their platforms
to build other platforms or applications to external
users. So it has a direct
impact on the business of a company,
even when it's for internal customers, right?
So what are the main challenges? First of
all, all companies are in the same path, right? They are lack
on time, but they are receiving high
demand. Anyone is with enough time
to look at the applications or look at the platforms
in the infrastructure and take the time to solve
issues, solve bugs. They are all day working, they are delayed
on features, they are delayed in things they
need to do. So this is one of the main challenges in any adoption
processes and here with platform engineering is
one of the possibilities to generate failures
in your path. The other thing is ways of working and thinking.
The companies that are implementing platform engineering is
something for medium and big companies, it's not
for small companies because in small companies there are
small teams. Truly 100% focus on
everything needed for their business, right.
Small companies will not spend in, have just one team
for internal customers and prepare platform for the rest.
When they have two or three or five teams inside,
or sometimes they are externalizing the service.
So when we are talking about big companies or medium companies,
we are talking about a big number,
huge number of teams working together. And when
we talk about people working together, they have their own
ways of working based on the experience they learning
from other companies and the agreements they have
inside the team, right? So it's so hard to not
face out problems or to not find detractors in
an adopting process. And here in platform engineering,
adoption is the second possibility
of failure. And last but not least, people is
behind this, right? And today we have a huge problem
in it, which is the rotation of people, right. And how
to keep people aware, keep people motivated,
right? So this is another of the problems we
will probably face out. So the
first one is lack of time and high demand as I mentioned,
right, because it's a matter of time
we need to deliver. We have the challenge in
the marketplace. All companies are trying to win,
right? So all time they are running, they want
to deliver new features, they want to be competitive.
So there is no time to
be asked to achieve their expertise in all
tools. Let's talk about the product team when they
are developing a new application or developing a new feature of our application
and they need to start using new architecture solutions or
they need to change how they are implementing their applications.
There is no time enough to be expert on how
we will deploy my API or how I will compile
and manage my secrets or integrate my secret management
tool with my cloud platform as
a service. So this lack of knowledge
at time will be generating tech depth
for the team and at some time it will request
the price, right? And the other thing is
develop new skills. If they need to develop the skills
to work over the application, it's a core business for them.
They will not have the time for learn other
skills like how to manage the platform in production.
Right? This should be shared
with other teams to focus on generate better skills
inside the team. Rely on failures and outages,
reply on failures and outages if a product
team needs to reply to their failures and outages in their
core business application, what will happen? If they need to reply
also to the platforms they use during the development and deployment process
and keep the documentation updated.
It's part of the development or the product team live to
document everything, but also if
they need to document the platforms they are using will
increase more and more. The dependency and
the depth they have in the time. So the
demand is also a problem
because it will just increase. When you are doing the things good,
the demand will start to increase. So let's
imagine that we have a platform team supporting these
product teams that are developing applications and now they have
a cognitive load reduced. But now more
and more teams will start to use the platform.
And also if we don't have a platform team, we have only
one team developing and now more teams
are appearing because we have new business cases and we
need more applications. All them will try to use the same platform.
And this platform that start to be strategic
will start to be the point of failure,
because each team will try to do with
their own ways of working and more users
will appear with more doubts, more requests, more problems,
right? That's the problem of demand and lack of
time behind platform engineering adoption.
And what about ways of working and thinking?
It's very likely that you will encounter people
that are not agreeing with you,
right? Several times you will find
detractors because they want
to do how they are doing, as always, right? Because they
know how to do. They understand that
like this way it will work, right?
And what about the compliance flows?
What about the processes that are defined
by the company and we need to follow?
Sometimes this will stop the innovation,
it will stop how we can make platform
easily to be consumed by developers, by teams
that are behind the software delivery lifecycle.
And sometimes also we will see two specific requirements,
right? So specific at the level that you
will not be able to understand if this will be positive
for the team or it's more a bottleneck
to achieve the agreements and to achieve the
generation of the MVP or the solution to
achieve the market time.
Like some other problems related
to ways of working and thinking, what about teams that have different
priorities? Now I want to have my platform working here,
but the other team is thinking how I can building for these other
platforms and the language and understanding barriers.
Because sometimes companies are so big that they have teams
in different countries. I have suffered this in
some of the companies I worked for my luck,
I can speak different languages, but some teams in
specific countries, they don't have this luck.
And sometimes when they need to trade with other teams, it's difficult to
remove this barrier and generate the shared understanding,
right? And last but not least,
keep the team engaged right? Behind everything,
behind technology, behind platforms, we have people,
people that can be influenced by their
situation, their ways of thinking with
clear cognitive limits, right. Without understanding if
they can code test, manage the CI
CD platform, manage the code quality platform and all
the rules behind it, the configurations with a
lot of market temptation and with a technical
and practice dev. Because we will not find
probably all seniors engineers we want
to have, right? Our market is
full of different engineers with different flavors and
it will depend a lot on how they can work together to improve this experience.
So what are the three practices I have prepared to
win and face out these roadstones
and be able to jump over them, right. The keys of
success I have prepared for you and I have implemented
in some of the teams I have worked with good
results. The first thing is customer
centric leadership as I mentioned it, and you will
be able to see in the videos and talks I share with you.
Platform engineering generates a clear vision
of an internal customer. So this platform
team, they will need to focus and have very clear
and identify this customer. What is
basically the product teams or depending on the platform you are
working right or you are building. So the proximity to
these teams is very important for product teams and
this leader that is guiding the team should promote
continuously this proximity,
this vision of customer, internal customer
and guiding the team based on objectives,
goals that will generate the clear understanding
of priority. What is the needs, the real needs of my
customer? Generating a platform that will work for them,
not for the rest of the companies in the market. We need
to focus on the real needs of our internal customer
because sometimes this company has their own policies,
their own ways of work and the platform should
work for them without reducing all the cognitive load of
this platform. Of these product teams that will use the platform
to start using this should be smooth at the level
that they will just onboard the application and start coding and
focusing on their core business. So this leadership with
customer centric vision is clear,
is key for success to remove all the
problems behind the time and demand because
he will be able to decide what the platform
team should be doing and what they should be
focusing in the moment based on the real needs of the
customers. One other thing we have here is
practice what you preach, right? If you are building a
platform team and this platform team is creating
tool, is preparing tools and ways of working,
try to generate metrics, metrics to measure how teams
are using these platforms and these ways of working, but also
use these metrics to measure platform team,
right. How they are using this platform. To not
only say hey man, use my platform but
I'm not using it. I don't know how it works because from real
life, the platform team will understand
how the platform itself should work, how the flow
should be, because they will leave it from their
experience, removing the dependency of
ways of working on how people think, because they will live
in their own life, their own day to day,
how to use these tools and to measure, same way as product
teams should be measuring the platform and
also will help them to keep engaged, right, because they should
be using the tool as they are promoting to be used. The other
practice is form champions. We cannot have the
expertise, the specific knowledge in all tools we are
promoting in a platform that
we are offering as a service. Because a platform inside
a company is a toolbox. It's a group of tools interconnected
and prepared to be used in an
easy way inside this specific company. I'm talking about
platforms, not only the
technology itself, but also the infrastructure.
This platform team will need to work on documentation,
configuration, solve bugs, a lot of the things. So the
general knowledge is a
must for all of them. We are talking about t shaped people,
right? T shaped group of people. But to
form this deep knowledge, they should not go
through all platforms they have in the tool chain.
But instead of that, you should have
champions for each technology. Obviously they should have an
understanding, the whole team should have an understanding,
a shared understanding. And this will be the responsibility of
the champions also to reduce the cognitive load of
the leader of the platform team, guiding the rest of
the team to work over the specific platforms. They have the
expertise. In summary, we have
these three practices, right? The customer centric leadership.
They need to have a clear image of the customer. I mean the
platform team. They need to understand that they have these
product teams inside the company and they need to
provide the platform for them based on their real
needs. So the targeted objectives need to be clear also
and promote the closeness with the customer.
So this leadership will be one of the keys of success.
And if you have decided who is the best
leader for your team, for sure you will have one part
of your path with a
real high probability to have success.
But the importance of the customer centric vision for this leader
is critical. The second practices is practice
what you preach. If you have one platform,
understand, define what is the metrics to measure people using
this platform and use these metrics to measure
the platform team also and force them to use the
platform to build the platform right and recognize
and show achievements. What is better to show what a platform
is generating benefits. If you can show from your experience
here, you can come with DevOps practices
like the showcases and demo days well
come from agile world also. But to show from
the team, the platform team, how platform should be used
from the experience, the real experience. And last but not
least, this practice is very important. I have been using in all companies
I have worked is farm champions because one person
cannot have all the knowledge, deeply knowledge
and all platforms, all technologies we are working, right?
So form experts by tool and
delegate to them that they should lead
that specific tool as part of the group,
they should promoting which kind of trainings the rest
of the team should be doing, how to structure the
documentation, how to implement a configuration. They should
be this lead because the lead of a platform team will not
have enough time just to be expert on
all tools. They will be managed, right. And trust on them.
The champions should be people that are fully encouraged
to work as a champion inside the team. So they
should be these heroes of each tool,
but not behind unicorns inside the team,
right? We don't want to generate people that cannot be replaced
or people that cannot
have a background backup, right? So these
champions should be training and sharing the knowledge
they have with the rest of the team to fill the gaps,
right? And the leader should be promoting and delegating this
vision and deciding who will be the experts
of each tool. This is another of the
real good practices I have implemented and have worked for
me. So just to finalize, if you want to go
even more deep on these
three practices, I have been implemented also.
Nick Watt that talk
in the platform Engineering conference in 2022
talked about people, processes and platform a community
focused approach. This talk will reinforce
you the three practices I'm showing you today,
and you will be able to find much more of
platform engineering, the YouTube channel and
also in the platform engineering webpage,
platformengineering.org. I would invite
you to get involved in this movement and
share your experiences and your
keys of success, your practices to reduce
the failures in the past. Because as
idea platform engineering have helped a lot of
companies to go through their challenges and achieve
the metrics and results they have
been expecting. So thank you for your time.
I hope you have enjoyed this presentation and if
you have doubts you can reach me out in the chat or through
the LinkedIn link, find me in LinkedIn
or write me an email. I will be able to participate
and collaborate with you in any time.
Thank you and have a nice day.