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