Loading video player...
Thank you for being present here. Uh
platform engineering, internal developer
platform, internal developer portals,
backstage, getport. These have been the
buzzwords revolving around uh DevX and
we will touch base a lot of these words
today in our talk around uh why you
should think of your internal developer
platform as a product and uh how this
can help us uh to bring the developer
happiness and to make developers life as
easy as we can so they can focus on
delivering the business value.
Okay. So to introduce my name is Ninat
Desai and I work as a staff engineer in
platform and S domain at Infraoud and
improving company. In past I have been
speaker and have conducted workshops
around GitOps and progressive delivery
at KCD, Bangalore and Chennai. Uh
outside work I do like reading and
cricket especially test matches. Rut.
>> Uh, hi everyone. I'm Rut Kadikar working
as senior SR at Infraoud and I
specialize in Kubernetes, observability,
SDLC, reliability. Uh, when I'm not
playing with technology, I like to play
flute. So yeah, that's all about us. uh
for the agenda for this session um we'll
talk into the current explosion of tools
in SDLC and how that is it is actually
hampering the developer experience and
all and how a welldesigned internal
developer platform can help to mitigate
these issues and uh increase the uh
experience of a developer and finally we
will walk with some key takeaways uh who
are starting with this journey so to
make it more interactive I'll play the
person of a developer and inad my friend
here will be a platform engineer.
>> Sure. So let's start. Assume that I am
an developer joining a big company and
it is my dream company. I know that this
company builds some cool stuff. They
have continuous deliveries and
deployments and uh you can see how
excited I was. Okay. So induction is
over. Uh I'm dreaming that I have
stepped into cloud and coding
everything. But I am greeted with the
wall of config creatures and DevOps
demos.
So as usual I am assigned with a mentor
and uh I go to him and I say that I want
to start contributing but uh he's giving
me the reality check that uh okay we
need to start for getting on boarding
getting access created getting started
and blah blah blah blah. So the first
thing is getting access created. I am
following with the ID teams and uh you
know I thought that onboarding will be
smooth but nobody mentioned that I have
to maintain a separate sheet for
tracking all my loginins.
So I am still waiting for my accesses
and hearing all the updates in the
meetings. While my team is deploying the
code I am getting deployed to every
calendar invite instant. So again I
thought that okay now let's start with
some documentation till I'm getting
access and everything. But hey, the very
first thought was is there a tool to
find a lost documentation because you
have to first solve the mystery where
the documentation lies and then if it is
found you have to decode the 2019
version of the system that no longer
exist. So again I go to my mentor asking
for the documentation and this is it. So
yeah, we get into the call and after 43
tabs, nine repos, five pipelines and a
secret conference rabbit hole later, I
still don't know where the main app
lives. So uh you know uh is like this is
the problem with every developer and at
that time I thought that uh you know
memory form why memory foam is becoming
the standard because remembering all
these tools is really difficult just a
pun intended. You might be wondering
what I was doing two three weeks later.
What was working working for me? It was
just Slack and Teams meetings after
meetings. So what wanted to start with
the sprint goals was ending up with
sprint ghost and uh my spirit was
shipping faster than my app. So every
developer uh more or so has to go
through dungeons of docs, valley of
meetings, chaos of CI/CD to earn their
real first merge in any big
organization.
And uh I was feeling that am I alone?
No. Many people many developers in such
organization face the similar problem
due to no standard onboarding, tribal
knowledge, tools sprawl and no context
or attention to the security or uh cost.
So we developers are uh not overwhelmed
with the tools but the number of tools
and the context switching and the uh
result of that is fragmented developer
experience and slower deliveries.
So only we are suffering. No, there are
other personas in any organizations who
are also suffering with similar kind of
issues.
>> Do you need some help mate?
>> Wait a minute. Who are you? Hey there.
So I'm a platform engineer who has
recently joined this org uh to solve
some of your day zero, one and two
problems. And trust me, I'm not here to
just throw YAML or config files at you.
In my past or as well, I have built the
internal developer platforms and systems
that can scale your happiness, right?
But before I jump into the thick, right?
Let me briefly introduce myself. See,
uh, anyone can build automation stuff
like what we have done as part of the
DeOps or SR world, right? But here my
job is bit different to build those
platform or systems, right? that will
make sure to take care of your
day-to-day developer experience and your
happiness.
>> But I have been using this uh platforms
before and more or less it failed like
some gatekeeper processes created by
DevOps and infra teams and that created
some dependency on those teams. What are
you making different this time? Uh
that's a great question and I know we
unknowingly built the guardrails while
trying to simplify the infrastructure
space and uh but we have learned our
lessons hard way and uh quoting Gregor
hope right any platform don't win their
end users by mere force or mandate they
win by being the most transparent most
easiest and most empowering way
especially for developers to let their
work get done. Okay. So you mean that
you will provide me some autonomy to
make my own choices but without making
it harder for me.
>> Exactly. See if using platform is harder
than skipping it. Developers like you
will always skip it. Right. So this time
the internal developer platform that I
will build will have a low friction as
much as possible clear docs fast
feedback and actually the golden path
paved in a way that it will give you
more freedom. But isn't giving more
freedom may lead to uh chaos like it may
there might be outages security issues.
>> Well and to avoid that while building
this platform I will build it into two
different aspect as you could see here
the core part is something that I will
take care of and the flexible part
flexible periphery is something that I
will let you to have a whole autonomy
over.
>> Can you elaborate on this uh core part?
>> Uh I would say it's a reliability with
freedom. uh think like road, electricity
or clean water. These are the things
that we expect to be provided with some
governance, right? Same way I will build
all the end to-end infrastructure, the
code pipelines, GitOps way of doing
deployments, unified observatory system
and automated security, everything baked
in a standard rock solid manners.
>> But what if I uh require a specific
database or I prefer React or Angular?
>> So that will fall under your flexible
periphery. You want to use MongoDB,
Kafka, React, pick whatever fits your
need. We will make sure that this core
part is as modular and as APIdriven so
that you can plug in the flexible
periphery part based on your needs so
that you can innovate freely without
having any chaos.
>> Got it. Got it. But uh we had these
engineering or PRA platform practices
before like automation, CICD. Aren't
they enough? Uh good pract practices
definitely help uh but they are not
enough. Like when we were uh building
infrastructure, we were earlier only
thinking about the technical success uh
which was expected output but what about
the outcome? Have we really putting
effort to move the needle forward for
our developer? Is that making life like
your uh developers easy? So that's where
we have realized that we need to shift
our mindset from just being a infra
builder to actually a product thinker.
So earlier we were focused on the output
but this time it will be about the
outcome and importantly adoption. This
time I will make sure to continuously
measure if whatever I'm building is
really helping and making your life easy
and then based on your feedback I will
keep improving as much as possible and
that's the shift we want to highlight
here. So when you will start treating
your internal developer platform like a
product that's how the perception and
focus should change right treat it just
like the product that you are building
for your end users but this time your
end users are sitting next to you in
your office right and help them to not
only let's just build tools and script
but the entire self-service path so that
it would be just a oneclick way for them
to do the things and yeah
>> so I'll admit this looks cool and it is
a very huge task. So how do you even
start with this?
>> Uh one word answer is market survey. I
have already taken that step by the way
and I'm talking to all the developers in
our org and trying to figure out the
things that they want to know
interviewing them trying to find out the
top three friction points and see if
there is any overlap between the work
that two development teams are doing.
>> So any new complaints or is it the same
crack?
>> Well, it's the same thing over and over
again. Onboarding took too long. repo
have no consistent structure nobody know
what's the right way to deploy something
so instead of trying to solve all the
problems I will try to focus on a shared
painoint first and then try to develop
them as a platform with a product
mindset
>> so how this platform with a product
mindset will trans translate into what
you will do differently this time
>> uh to sum up it start with research
sitting with developers like you
watching the workflows of your
day-to-day task and then finding the
pain point that create the most friction
and frustration for you and then
building the thinnest viable platform
you can say just the smallest set of
tools and APIs that will help you to fix
some of your day-to-day problems and one
more thing this time I will make sure to
put effort not only on the technical
side but on the advocacy marketing side
as well and on adoption side as well.
>> Okay. So coming to my original problem,
how would have been it different if
there was a uh platform as a product
mindset?
>> Let's do one thing. No, you start
sharing the problems that you had faced
and then I will try to help you with
what answers or ways that I'm trying to
build for you to solve some of those
challenges.
>> Okay. Though so very first problem was I
was onboarded and it was taking too much
time to get accesses. It was long time
for me to start contributing
>> and we saw this happening repeatedly
across all the teams. All the developers
just wasting their days while waiting
for accesses. So this time the internal
developer platform that I will build for
you will have everything centralized.
You just raise a Jira ticket or any form
of ticket and it will trigger all the
end toend automation workflows that will
provide you all the accesses same as of
what your team already have it.
>> This sounds amazing and it will save a
lot of time and frustration.
>> Yeah. So next problem was about
documentation. So there it was all
scattered that there was not a single
point to start with
>> and we have been all there right
irrespective of if you are a developers
or a platform engine or SR or whatever
you would like to call it as and it was
costing a week per new hire for us and
so this time I will make sure to have
everything centralized in my developer
portal which is a subset of the
developer platform all the documentation
wiki pages APIs related information
everything will be available at just one
shop stop for you
>> this is really helpful. So let's say uh
I had an idea and I wanted to uh you
know create a service around it. I spent
a complete day creating the repo, wiring
CIS, creating Docker files, configs,
etc. And also I made to I had to make
sure that I'm not violating any security
policies. All I wanted was a clean
compliant starting point.
>> Uh let me show you something that I have
already built for you and which will
help you to solve such a problem. This
is one of you can say IDPL just like a
cubectl utility. Consider it just as a
one of the client interface that will
give trigger to all my internal
developer platform. You want to started
with uh bootstrapping a repo in a
standardized way, right? Just use that
idpectl command. Pass the name of the
repository that you want to create or a
microser that you want to build and the
language in which you want to build. If
you want to deploy it immediately in
dev, you pass that githubs kind of
parameters, right? And let me show you
it live to you.
So what you'll be able to see I'm just
passing that command okay and just
passing the language in which I want to
develop and in few seconds what you'll
be able to see is the repo already been
created for you. Now if we go into that
repo right what you'll be able to see
everything is inbbit you have a standard
app file been created a docker file been
created a CI part has been created and a
configuration manifestation for that as
well it has been taken care if we go a
bit further into that one level deep you
will be able to see in this sample
application file I have taken care of
the instrumentation part as well which
will help us to emit some of the metrics
for you I have already created this
docker file so containerization aspect
is also already been taken care for you
and this is a standard build and CI file
that we will use across the ag right and
beyond that I have already created a
sample unit test case file for you as
well and apart from that most important
I have created a task file for you which
is a modern version of make file you can
say that will help you with all your
day-to-day local testing part right and
most important thing this repo will have
a developer guide as well in place for
you that will help you to know how to
make best use of this repo and get your
work moving forward.
>> This is amazing. But what if I want to
deploy this service in a prod like or
staging like environment?
>> So I have already built another feature
for the same. Let me play it for you. So
this time instead of using the IDPL or a
client utility, I'm just showing you the
developer portal like a backstage. I am
again passing the same parameters. Now
you want to deploy it, right? So the way
in command line we have githops option
you have that option already available
here. Now what you can do is just
trigger that operation and you will be
able to see that already a standard CI
pipeline already all those stuff that I
showed that has been created. Apart from
that a standard Argo CD application file
is already created that will help you to
deploy in a standardized manner. Let me
fast forward it for you to make it easy.
So as you could see app web server kind
of a sample largo application file been
created that will take care of your CD
part as well.
>> Okay but what if I want to see the
performance of the application.
>> So remember I showed you the
instrumentation part. Apart from that
this time I have made sure to bring some
custom boiler plate dashboards as well.
Graphana dashboard that will get
deployed on top of uh this all the
automations that I have done for you.
And let me show you. You'll be able to
see this dashboard is available for you
a custom you can say you can use it as a
boiler plate and build on top of that so
that you can see the performance of your
application. Right? And if you are
thinking I'm just focusing on the
Kubernetes part that's not the case
here. If let's say you want to build the
resources which are outside Kubernetes
you want to build S3 bucket or you want
to let's say do the RDBMS anything those
as well I will make sure to take care
for example let's say you want to create
an S3 bucket right as a developer it's
again a context switch and load for you
to understand something about the AWS as
well instead of that what I will do is I
will have the minimous parameters
available here let's say you want to
create a S3 bucket right just pass
fewest possible parameter s that you can
uh possibly have there and just trigger
the operations and what you'll be able
to see is immediately in few minutes uh
S3 bucket been created for you. So that
way the context switching also will be
reduced for you still if you want to see
that S3 bucket is already in place for
you.
>> So I don't have to look into Terraform
or any other ISA for such things.
>> Exactly. So this is actually very good
and I'm very impressed. So self-service
environment, CI/CD templating and
metrics and logs where I need to see
them. So this looks good but honestly
I'm very curious how do you even build
this?
>> So that's a great question and there's
actually more than one way if you want
to build something like that and it
depends on how much flexibility,
scalability and the scale that you
needs. But generally there are these two
approaches. One is you can say portal
ccentric or plug-in uh first approach
and other is a API first approach. We
have seen uh recent uh adoption around
the developer portals where uh de
developer portals like backstage are
getting used and then you use all the
community based plugins available and
then build those capabilities for you.
It's really great approach if you are
focused on a UI first workflows approach
but it has a bit of limitation that you
are tightly coupling all these features
or capabilities inside your developer
portal itself. The other approach is the
API first or platformd. In this
approach, what we can do is we instead
just directly g call from your
interfaces to your all the automations
we build a API layer in between that you
can call it as a back end if you want
and then this single layer by which you
will be able to trigger all these
operations right. So you don't have to
be aware of all the end points. It's
just a single layer. And uh another
advantage of that layer is you'll be
able to see that you bring with that the
auditing and uh security things as well.
You will be able to see who has
triggered what kind of operations inside
that.
>> So you mean to say what you showed me
earlier was the best of the both world.
>> So a developer like me if is preferable
to CLI or UI, he can create the services
accordingly and it will use the same
backend workflows. uh very consistently
and securely.
>> See, you are already speaking like a
true platform engineers, right?
>> So, but wait um you know uh CLI UI it's
okay for interfaces but I have seen many
people uh referring to backstage as IDP.
>> I would say it's a developer portal and
not a developer platform. It's a subset
of your developer portal. I would say if
you want to understand it consider a
developer portal is like a face and your
developer platform is the actual muscle
who does all these thing take example of
your mobile app right all the
transaction that you are able to see
it's it's just showing you on your
mobile the actual work is getting taken
care by the back end that we have inside
or the capabilities that are running in
the back end it inside it if you want to
understand this space in much deeper way
I highly recommend you to watch this
portals and platform two piece in parts
video. It's a part of a platform called
I think by Abby and it's a great video
for you to understand if this approach
can help you to solve your org's needs
and to tie it all together right to make
it easy we always know web app DB right
to take that analogy your developer
portal is like your app the backend
layer and the automations that you can
consider like your app and all the
actual infrastructure for the sake of
understanding you can consider as your
infrastructure platform or the things
that you create.
>> So you mean to say don't jump into
straight into uh building a shiny
portal.
>> Yep. I would say start with the bottom
and not with the top.
>> But did we forget our friends?
>> Nope. So now as you as a developer are
able to ship things faster, right? That
way then the QAS won't get bugged at the
last moment to do the testing or miss
out. Apart from that what we have seen
is half of the time QAS are facing the
issues around the environment itself
getting down and to avoid those issues
we can on the fly create the QA
environment with things like virtual
clusters or name space that way we are
able to solve their problems and about
the engineering managers right I see
half of the time maybe they fly blinds
they are always unsure if their team is
going with the right velocity what's the
cost their team is creating for their or
so for them we can surface the
durometrics on top of our developer
portal and if they want to understand
the cost factors that also can be pulled
inside our uh CLI or the developer
portal so they understand the uh PHOPS
part of the this entire journey as well.
So all right so let's say you have built
a platform uh created golden paths
exposed APIs but how do you know that
this is actually helping the developers
>> and there are these three ways or three
frameworks that I can recommend to you
uh dora space devx all three have
slightly different purpose dora can help
to the engineering managers stakeholders
to understand if the engineering efforts
are getting translated into the business
value or not space is a framework that
can help you to understand more about
the developer productivity and the third
is a DEX which has been developed by
Abinoda as a you can say DX team and
that framework focuses on three pillars
about feedback loops cognitive load and
flow state basically it checks about the
developer experience to talk a bit in
detail about that if the feedback loop
if let's say me as a developer
committing the code and if the CI build
itself is taking 30 minutes right I'm
losing my momentum it feedback is coming
too slow for me second could be the
cognitive load right if me as a
developer has to go from one tool to
another tool to another tool. It's a
context switching and with that context
switching I'm having a cognitive load on
myself. And third thing is a flow state.
Are we creating that environment for our
developers where they can go into their
zone and do their work uninterrupted or
are we calling them just for a five
minutes meeting and they we are breaking
their state. Right? These are some of
the frameworks that I can highly
recommend you as well.
>> Okay, I really love this. So you are not
just measuring the CPU load, you are
measuring the mental load also.
>> Exactly. So what key takeaways you will
suggest for anyone who is starting with
this journey?
>> I would say your internal developer
platform aren't just the uh stacks of
tools or automations. They are a product
with real users who are sitting in
office with just like you. And for any
product team to become successful, the
platform team will have a win only when
they solve the real problems. Not just
build cool tech, right? Focus on
developer experience, not only on output
but outcome. And treat developer teams
like a partner teams and not as someone
uh for whom you will dictate them. And I
would say beyond metrics, you should
treat feedback and trust as a core
metrics, right? And uh as Rob Zubed from
I would say uh he's from CircleCTO he
has put it in very apt way that your
platform success isn't measured by how
compliant your development teams are
with your tooling. It's measured by how
thankful they are how many times in a
day or a week they are feeling thankful
to have someone like you around. So one
word or one line I would say think like
a product managers work like a partner
and deliver like a platform engineers.
And again if you are still further
interested I would suggest you to
download this platform engineering
reference architecture that we have
built for someone who is newly starting
this journey and that should be helpful
to you all. Thank you.
>> Thank you.
Any
questions?
>> Should we take silent as a no?
>> I think
not much.
uh do we have a template say for example
common used IDP portal or a template
>> so when you say template it's about the
workflows and automation is that what
you are referring to
>> uh something see most common like every
developer is required is like
documentation what you are talking about
or common tools which which are required
so is there anything that we use
>> uh rather than we build it.
>> So you can go with IDP portals like
backstage and all they have uh certain
uh blueprints and plugins that you can
utilize for documentation and maintain a
uh correct documentation around that.
Hi. Uh here yeah so you have given the
backstage as a solution for uh which you
can say on the left hand side what you
said uh the product right the API first
one what are the solutions that you are
projecting to make the API first
products.
>> So what we have built is with using
graphql server and uh for this uh we
have used posgress but right now there
are neo4j databases in the market. So
strawberry framework, graphql server,
fast APIs that we have used as uh you
know back end for this.
>> Just to add I would say start with what
in-house capabilities that you have if
you want to start with building your own
developer platforms.
>> No, that's fine. That again requires you
said start small. Backstage gives you a
u the standard way of doing it. how to
do the cataloging, how to do the
templates, how to do uh all other stuff,
right?
>> But for the API first side of things
where you said you need to build API
first and then to plug in into
backstage,
>> what are the products or just like you
said Neo4j? What are the other
open-source products which together
could make it a API first platform and
then to integrate with backstage?
>> So basically it can be anything. It can
be a template u uh you know embedded
with uh any API using any server you
want like as we mentioned we went with
graphql. It can be anything what
developer or your developer is uh
comfortable with and that with that you
create the API and then expose it via
CLI or CT uh UI.
>> So actually backstage has provided a way
as well or in as part of their
documentation which can help you to
understand how to build those custom
plugins and APIs on your own.
So he's going with the back end how you
>> Hello. Okay.
>> Yeah. Uh just uh adding on top of the
question related to data uh
documentation. Uh just wanted to add one
more thing. Uh what we are doing in the
backstage is uh uh in in our company
like we have created MCP server on top
of backstage as a plug-in. So all the
documentation for all the things that
teams are using they are putting it on
backstage. Now on VS code uh you can
just integrate the MCP server and you
can start asking questions and it will
just go through all the documentation
and you don't have to go out from your
VS code to any other place and you'll
get the answer there and there itself.
>> Yeah. Yeah. That's a next step I would
say uh with the agentic capabilities.
>> Hi.
>> Yeah. Uh my question is more around how
many plugins you have used from
marketplace to build these uh solutions
that you uh demonstrated and how many
you had to build inhouse.
So as part of the demo that uh I showed
most of those things I uh built inhouse
you can say the cost part that I was
showing right those are the for those
purpose I use the uh marketplace or
community based plugins uh like cube
cost was the one of the plug-in that was
available for uh backstage I would say.
>> Yeah.
>> Yeah. So my question is um not related
to backstage or UI more related on the
fundamental of the uh platform itself.
So u one challenge we saw while creating
those developer uh platform or product
sometimes if you create too abstract
layer so maybe developer uh miss the
context like what all things are getting
created behind the scene and that could
be a bottleneck while doing any
troubleshoot in case of an issue. So how
uh did you face sim similar issue while
in your case and how how you maintaining
the right balance to where developer
also understand what is getting created
at the same time give enough um tool so
they can create resources.
>> So basically uh abstraction helps
developers that is but uh one way is
documentation whatever you are
abstracting that should have a good
documentation what is it it is doing
back end. Secondly, what we also think
is platform uh as a product is a
collaboration. It is not just the
platform team working on it because
developers are also uh you know building
a product itself has some developing
capabilities and I have seen that
developers are very curious if they are
into it. It can be a collaboration. They
can uh put contribution to the plugins
and all in in that way the uh what you
can say the gray area where uh this mis
uh uh knowledge is there that can be
overcome. uh to add to what uh Rutarat
said right uh know if we know our
customer well we understand what levels
of abstraction we should build like as
you rightly pointed if we build too much
abstraction it becomes a too much basic
primitives that will again create a
cognitive load on them so ideal approach
is start with one pioneering team right
understand how much abstraction they are
okay to have and then see if that's the
same thing matching for other
development teams as
Don't tightly coupled for a one team as
well. That part you can leave as part of
the what I was highlighting as a
flexible periphery. That customization
part you let them take care you take
care of only as a core aspect for uh
from the IDP perspective.
>> Go ahead. Thanks.
>> Hi. Uh I had a another question. So as
platform engineer, how do you now deal
with organizational
challenge? Because for example IDPL you
have Python example. So now those teams
are blocked on your centralized API
layer if they want to ship something
sooner and then platform teams are
generally limited. So now uh how do we
make their experience better because
they would want them those teams who are
offering these solutions themselves may
have different workflow and will be now
blocked on one centralized
system. uh Spotify has a great story on
that aspect. They built a core aspect of
the things right but again as you
mentioned to avoid developer becoming
again dependent on uh the core team they
suggested all their microservices or
development teams uh to build their own
plugins that you can just plug inside
the main core aspect. So involve see
that's the typical nature of developers
like if you don't involve them from day
one and if they if you just meet them
once and then after 3 months if you come
back saying I am building this for you
they will say forget it meanwhile I will
develop on my own so that's the reason I
was suggesting consider them as your
partner speak with them as frequent as
possible to engage them see if they are
also interested to contribute and uh
with help of the uh API approach right?
You suggest them how they can also
contribute back to the plugins. So in uh
Spotify's journey as well the main core
part is the one that their platform team
managing but whatever development teams
needs on their own they are letting them
that autonomy to build that things with
the framework that they are providing.
>> Yeah. Hi.
>> Um yeah nice insights. Thank you. Uh we
are recently getting it started with
backstage and my question is uh on the
back end side right where you have shown
like S3 details you have passed but like
after that terapform module it what what
you used and what is your suggestion for
the back end is it like GitHub action or
like you are calling genkins or yeah if
you could give us some insights on that
part which will help us to develop our
own. Basically there are two uh like uh
basically we are using uh right now we
are using terraform but you can also use
cross plane for that. Okay because with
both are them good. It is up to the
organization who have like they want
desired state to be maintained. So
crossplane can be a good fit. You can
for easy and uh uh you know uh fast
update with terapform. You can go with
terapform but you can go with terapform
uh templatization. So for here we have
uh gone with Python templates uh and
terraform to create those templates and
those are plug-in with the API.
>> Okay. And that is getting executed in
the backstage pod itself or that is
calling some API.
>> So that's where our back end uh inter in
between layer that I have we have built
right that layer make sure to trigger
all those standard workflows or golden
paths that we have created and in place.
>> Yes. So your workflow where it runs
right is it like GitHub action or GitHub
action
>> for this demo? Yes, it's a GitHub action
that we uh used.
>> Thank you.
>> Again, it's about the your in-house
expertise start with that is what we
would recommend.
>> Yeah.
uh if I think as an platform engineer if
I want to have customization over
whatever the resources that I'm
developing how uh your platform is
supporting okay and as a security
engineer if I think I need to have a
control over the customization that
anybody brings into into the platform so
are there any controls that you have
made for both
for security purpose right the platform
as a product mindset is very helpful
because all the security are embedded uh
the compliance is embedded in the
customization. So if somebody's creating
S3 bucket in the template itself we make
sure that the security uh like your uh
you know encryption and everything I'm
just giving an example that is already
embedded in the template. So if anybody
creates a bucket it is compliant with
security and uh that part uh embedding
the uh security compliance that you can
talk with your infosc team or security
teams and get it certified that okay
these whatever whoever will create these
services are secure right from start.
What if what if the platform engineer
wants an customization on top of
whatever the pre-built uh templates are
already available. Let's suppose I want
an S3 bucket but for some reason that S3
bucket needs to be publicly available or
an EC2 instance that needs to be having
a certain uh type of access access
restriction also access allowance also
like for that are there any uh setups
we can talk because if it is not like
going into security compliance then
there should be some change management
or something that should process brought
in the picture and it should be
correctly signed. hand off from the
stakeholders then only it can be
customized accordingly.
>> So I have a question. So uh in a typical
R&D type of uh development environment
right so uh we will have a lot of uh
things to explore like lot of tools etc
right so in that case uh the IDP product
which is already built right it it also
has to keep evolving and it has to keep
getting added with the features. So I
mean uh is there a way where uh we can
add features etc during R&D? So
basically the idea of product mindset
what we have seen is iteration. So was
first you start with uh the shared
pinpoints and those are with more
friction in day-to-day life it will help
that will be a priority list and once
that is achieved you
uh you get all other features also those
are actually hampering developer
experience and all. So accordingly,
iteration after iteration you can your
uh groom your product accordingly
>> and that's where the road map thing
helps to consistently going talking
understanding the next pinpoint or
features that we should build. So that's
that's where the product mindset comes
into the play.
>> Yeah. Okay. Thank you.
>> Yeah. I have one question. So what are
the best practices of implementing the
IDP portals? Let's suppose which will
not give us a vendor logging sort of
system because when we talk about when
we building an IDP platform on the Azure
if we want to sometime we need to move
on to AWS then we will not able to do
that easily because it has the login and
how the portal is created is based on
the Azure only not the AWS. So is there
any possibility we can have that IDP
port IDP portal which can cater the both
the platforms or uh other platforms as
well. So if you're considering the
platform now platform can be deployed on
any AWS or Azure but if you're talking
about portal then those portal I think
if if you take backstage right backstage
can be deployable on Azure can be
deployable on AWS. So if you're building
your own portal then that can come into
picture
>> and oss is the way always to avoid that
vendor locking things I would say and
make sure
>> open source solutions backstage is one
of them.
>> Yeah because let's suppose today my
application is running on some Azure
service and I am I have already
developed an IDP portal on top of that
and now I need to move that same service
onto the AWS. So is it not easy like we
need to change few things around that we
need to build IDB according to that
portal then we can move that into that
>> that's where I would say uh when you are
building try to have the loosely coupled
architecture right so that these parts
that's where the plug-in part or the API
parts comes into the play so you don't
get locked into the system if you so so
that's the reason I'm suggesting to go
for the common framework that can
connect or help you to switch platform
from one to another rather than just
hard coding or hooting for one
particular uh cloud or any solutions.
>> Okay. Thank you.
>> Yeah.
>> So my question is uh regarding the
config and state management from the
DevOps end is that when you create these
tools we have one uh API based tool that
we have written in Golang. So what
happens is uh the configs and states you
have to maintain for these stuff like
you have shown that itself becomes a
challenge. So what is your experience in
maintaining that state and configs? Uh
you know
>> uh githops is a way I would say uh are
you talking about the back end part or
the configuration files of all the
applications and all? Yeah, the config
or YAML files whatever you are using on
the
>> yeah githops is generally way we
consider uh as a way forward consider
git as a single source with if any
change has to go into that system it has
to go via git alone and uh it's already
already we are version controlling so
that way we don't have too much uh get
troubled with those issues. Uh okay and
uh how do you uh templatize the config
so that uh like uh like uh let's say 20
lines are required by the developer to
fill in uh it's a since it's a uh CLI
tool uh how do what thought process do
you put in to templatize it into lesser
number of lines like uh
>> so yeah go on
>> so templates you create earlier first
and then you make the parameters out of
it and you make sure that again how much
let's say developer is having uh not
good experience with filling all those
things there comes your expertise like
how you can abstract it in the form of
template like with one template with
region I'm going with tier one or tier
two that I can autofill based on one
parameter so that I think you need to
sit with developer and create that uh
template according
>> so common you can once you talk with
different development teams you
understand exactly what things they
need. Generally uh generally what we
have seen is uh they don't care about
what are the underlying parameters or
AWS specific customization or things
that we have to pass for example that S3
bucket all that he cares is about his
bucket name and the policies. So having
that conversation as early with your
customers helps you to understand what's
exactly is they care for and then you
abstract rest of the things uh from from
them in a common virus format. Yeah.
>> Thank you. Yeah.
>> Okay.
>> Thank you all. Thank you for
>> Thank
Don't miss out! Join us at our next Flagship Conference: KubeCon + CloudNativeCon North America in Atlanta (November 10-13). Connect with our current graduated, incubating, and sandbox projects as the community gathers to further the education and advancement of cloud native computing. Learn more at https://kubecon.io IDP as a Product: Where Developer Happiness Meets Platform's Excellence - Ninad Desai & Ruturaj Kadikar, InfraCloud Technologies As a developer, are you overwhelmed by the growing number of tools just to ship code? Struggling with visibility into cost, performance, and reliability? Torn between enabling developer autonomy and enforcing governance? The answer to all these challenges lies in building an Internal Developer Platform (IDP) like a real product. With clear ownership, iteration, and a focus on your internal users—you solve for both scale and usability. An IDP unifies onboarding, CI/CD, infrastructure provisioning, observability, cost visibility, and more. You’ll learn how an IDP can streamline the entire developer journey while embedding security and operational best practices by design. We’ll discuss prioritising Developer Experience (DevEx), aligning platform capabilities with developer needs, and avoiding becoming a bottleneck. Whether you’re a platform engineer or an engineering leader, you’ll walk away with actionable insights to make your platform a true enabler at scale.