Internal Developer Platforms (IDPs) - Simply Explained

1
00:00:00,000 --> 00:00:04,600
Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365.

2
00:00:04,600 --> 00:00:06,040
FM, I'm Mirko Peters.

3
00:00:06,040 --> 00:00:07,920
Imagine you need to launch a new customer app.

4
00:00:07,920 --> 00:00:09,160
You need a place for the code.

5
00:00:09,160 --> 00:00:10,120
You need a database.

6
00:00:10,120 --> 00:00:11,480
You need access to Azure.

7
00:00:11,480 --> 00:00:13,240
You need a build and release pipeline.

8
00:00:13,240 --> 00:00:16,080
Then you need logs, alerts and a way to see if the app is working.

9
00:00:16,080 --> 00:00:17,520
That sounds like one request.

10
00:00:17,520 --> 00:00:23,480
But in many companies, it turns into tickets, handoffs, Azure portal screens, copied setup nodes,

11
00:00:23,480 --> 00:00:25,800
and a long wait for someone from another team.

12
00:00:25,800 --> 00:00:27,360
Developers want to build the feature.

13
00:00:27,360 --> 00:00:31,240
Instead, they can end up learning just enough Azure, Kubernetes, networking and security

14
00:00:31,240 --> 00:00:33,160
to get past the next blocker.

15
00:00:33,160 --> 00:00:36,760
An internal developer platform or IDP changes that experience.

16
00:00:36,760 --> 00:00:41,200
In plain English, we'll look at golden paths, service catalogs, guardrails and where Azure

17
00:00:41,200 --> 00:00:42,200
fits.

18
00:00:42,200 --> 00:00:43,680
And one question will stay with us.

19
00:00:43,680 --> 00:00:45,960
Is an IDP just a portal with buttons?

20
00:00:45,960 --> 00:00:48,960
Or is there much more working behind it?

21
00:00:48,960 --> 00:00:51,440
Why developers need a better way to get things done?

22
00:00:51,440 --> 00:00:54,800
Picture a small team that needs to release a new customer facing service.

23
00:00:54,800 --> 00:00:56,760
The business has a clear request.

24
00:00:56,760 --> 00:01:00,000
It does need a simple page where they can check the status of an order.

25
00:01:00,000 --> 00:01:01,280
The developer has the code ready.

26
00:01:01,280 --> 00:01:05,040
The team knows what the page should do and everyone expects it to go live soon.

27
00:01:05,040 --> 00:01:06,440
Then the setup work begins.

28
00:01:06,440 --> 00:01:10,120
Someone creates a git repository, which is the shared home for the code.

29
00:01:10,120 --> 00:01:12,960
Another person needs to find the right Azure subscription.

30
00:01:12,960 --> 00:01:14,560
The service needs a network connection.

31
00:01:14,560 --> 00:01:15,800
It needs an identity.

32
00:01:15,800 --> 00:01:18,000
So it can safely talk to other services.

33
00:01:18,000 --> 00:01:20,640
It needs a safe place for secrets such as connection details.

34
00:01:20,640 --> 00:01:22,400
It needs a build and release process.

35
00:01:22,400 --> 00:01:27,000
It's called CI/CD, which means the automated steps that test and publish changes.

36
00:01:27,000 --> 00:01:31,360
Finally, it needs monitoring so the team can see errors before customers start reporting them.

37
00:01:31,360 --> 00:01:32,560
None of these jobs are strange.

38
00:01:32,560 --> 00:01:33,560
They all need doing.

39
00:01:33,560 --> 00:01:37,400
The problem begins when every new service starts from zero and each team has to discover

40
00:01:37,400 --> 00:01:39,160
the same answers again.

41
00:01:39,160 --> 00:01:43,200
A developer might open a ticket for access, wait two days, then receive a link to an old

42
00:01:43,200 --> 00:01:44,440
document.

43
00:01:44,440 --> 00:01:47,400
The document points to a portal screen that changed last year.

44
00:01:47,400 --> 00:01:49,880
After that, another ticket asks for a database.

45
00:01:49,880 --> 00:01:52,200
A third request asks for a network rule.

46
00:01:52,200 --> 00:01:56,040
By the time the service reaches testing, the developer has spent more time joining systems

47
00:01:56,040 --> 00:01:58,240
together than building the customer feature.

48
00:01:58,240 --> 00:02:00,000
You've probably seen this in your own work.

49
00:02:00,000 --> 00:02:02,000
The developer's intention is simple.

50
00:02:02,000 --> 00:02:03,560
Release a useful service quickly.

51
00:02:03,560 --> 00:02:04,760
The obstacle is not the code.

52
00:02:04,760 --> 00:02:09,320
The obstacle is the queue of setup work, decisions, permissions, and different tools.

53
00:02:09,320 --> 00:02:13,520
If the team can't clear that path, a small request becomes a slow project and customers

54
00:02:13,520 --> 00:02:16,280
wait longer than they should, there's another cost as well.

55
00:02:16,280 --> 00:02:19,880
When each team creates its own setup, the company collects many slightly different ways

56
00:02:19,880 --> 00:02:21,040
of doing the same job.

57
00:02:21,040 --> 00:02:23,080
One service has a good release pipeline.

58
00:02:23,080 --> 00:02:25,760
Another has a pipeline that only one person understands.

59
00:02:25,760 --> 00:02:27,760
One team stores secrets safely.

60
00:02:27,760 --> 00:02:31,040
Another team puts a password in a configuration file because they were in a hurry.

61
00:02:31,040 --> 00:02:35,800
A service breaks at 2am, but nobody knows who owns it or where its logs live.

62
00:02:35,800 --> 00:02:38,680
Support becomes hard because every service looks different.

63
00:02:38,680 --> 00:02:41,840
Security becomes hard because people have to remember every setting every time.

64
00:02:41,840 --> 00:02:45,160
And new developers spend their first weeks asking where things are instead of learning the

65
00:02:45,160 --> 00:02:46,760
product they joined to build.

66
00:02:46,760 --> 00:02:48,360
This is where platform engineering comes in.

67
00:02:48,360 --> 00:02:52,200
A platform engineering team treats the tools and shared setup inside a company like an

68
00:02:52,200 --> 00:02:53,680
internal product.

69
00:02:53,680 --> 00:02:54,680
Developers are the customers.

70
00:02:54,680 --> 00:02:59,240
The team listens to repeated problems, creates simpler ways to do common work, and improves

71
00:02:59,240 --> 00:03:00,600
those ways based on feedback.

72
00:03:00,600 --> 00:03:01,840
It doesn't replace developers.

73
00:03:01,840 --> 00:03:05,600
It doesn't replace operations, cloud teams, security teams, or architects either.

74
00:03:05,600 --> 00:03:06,760
Those people still bring their skills.

75
00:03:06,760 --> 00:03:10,520
The platform team takes shared knowledge from across those groups and turns it into something

76
00:03:10,520 --> 00:03:13,200
other teams can use without rebuilding it themselves.

77
00:03:13,200 --> 00:03:15,200
So what is an internal developer platform?

78
00:03:15,200 --> 00:03:19,440
Think of it as the company's self-service front door to approved building blocks for software.

79
00:03:19,440 --> 00:03:22,080
A developer asks for something in a simple way.

80
00:03:22,080 --> 00:03:26,440
Behind that request, the platform connects the right people, rules, tools, and automation.

81
00:03:26,440 --> 00:03:30,800
The front door can be a website, a command line tool, an API, or even a form stored with

82
00:03:30,800 --> 00:03:35,240
the code, but self-service only helps when the root behind that front door is already clear.

83
00:03:35,240 --> 00:03:36,240
Golden paths.

84
00:03:36,240 --> 00:03:38,600
The paved road for common application work.

85
00:03:38,600 --> 00:03:40,440
The first building block is called a golden path.

86
00:03:40,440 --> 00:03:44,200
A golden path is an approved, repeatable route for a job that teams do often.

87
00:03:44,200 --> 00:03:46,600
It doesn't tell every developer how to write their code.

88
00:03:46,600 --> 00:03:50,440
It gives them a known way to turn that code into a running service without starting the

89
00:03:50,440 --> 00:03:51,640
setup from scratch.

90
00:03:51,640 --> 00:03:53,280
Think of a well-planned office building.

91
00:03:53,280 --> 00:03:54,920
Each office room has a standard layout.

92
00:03:54,920 --> 00:03:56,480
The lights work when you arrive.

93
00:03:56,480 --> 00:03:58,320
Power sockets are already in the walls.

94
00:03:58,320 --> 00:03:59,800
The door locks properly.

95
00:03:59,800 --> 00:04:02,800
And if there is an emergency, the fire exit is marked and ready.

96
00:04:02,800 --> 00:04:04,760
You can still arrange your desk how you like.

97
00:04:04,760 --> 00:04:08,440
But you don't need to install electricity, build a door, or work out the safety rules

98
00:04:08,440 --> 00:04:09,880
before you can start your day.

99
00:04:09,880 --> 00:04:13,040
A golden path does the same kind of work for a common application.

100
00:04:13,040 --> 00:04:15,520
Imagine your team needs a standard web service in Azure.

101
00:04:15,520 --> 00:04:20,320
The path might start by creating a Git repository, the shared place, where the team keeps its

102
00:04:20,320 --> 00:04:21,320
code.

103
00:04:21,320 --> 00:04:24,160
It can add starter code so the team doesn't begin with an empty folder.

104
00:04:24,160 --> 00:04:27,800
It can set up a built pipeline that checks the code and prepares it for release.

105
00:04:27,800 --> 00:04:29,720
From there the service needs a home in Azure.

106
00:04:29,720 --> 00:04:33,920
That could be Azure app servers for a regular web app, or another approved hosting choice

107
00:04:33,920 --> 00:04:35,600
that suits the company's needs.

108
00:04:35,600 --> 00:04:39,640
The path also connects logs and alerts, so the team can see whether the service is healthy

109
00:04:39,640 --> 00:04:40,840
after it goes live.

110
00:04:40,840 --> 00:04:43,360
There's one more part that people often miss at first.

111
00:04:43,360 --> 00:04:47,120
The service itself needs to prove who it is when it talks to other Azure services.

112
00:04:47,120 --> 00:04:51,960
Instead of keeping a password in code or a settings file, it can use a managed identity.

113
00:04:51,960 --> 00:04:55,080
Think of this like an employee badge for the application.

114
00:04:55,080 --> 00:04:58,800
Azure can recognize the service and give it only the access it needs.

115
00:04:58,800 --> 00:05:01,360
Notice how much setup sits behind one simple request.

116
00:05:01,360 --> 00:05:05,120
The developer should not need to choose every Azure resource, every security setting,

117
00:05:05,120 --> 00:05:07,280
every release rule, and every monitoring connection.

118
00:05:07,280 --> 00:05:10,240
Those choices matter, but most should already have a sensible answer.

119
00:05:10,240 --> 00:05:12,120
So the request can stay small.

120
00:05:12,120 --> 00:05:15,840
The developer might enter the service name, choose the team that owns it, select development

121
00:05:15,840 --> 00:05:20,640
or production, pick the programming runtime, and choose from a short list of approved options.

122
00:05:20,640 --> 00:05:23,160
That is enough for the platform to start the right setup.

123
00:05:23,160 --> 00:05:25,760
Behind the scenes, the platform creates the Azure resources.

124
00:05:25,760 --> 00:05:27,040
It applies access rules.

125
00:05:27,040 --> 00:05:29,200
It connects the service to a safe place for secrets.

126
00:05:29,200 --> 00:05:30,720
It adds the deployment settings.

127
00:05:30,720 --> 00:05:32,400
It links the service to monitoring.

128
00:05:32,400 --> 00:05:35,120
The developer sees the result, not the pile of setup work.

129
00:05:35,120 --> 00:05:36,440
This is why defaults help.

130
00:05:36,440 --> 00:05:39,000
People often think more choice always means more freedom.

131
00:05:39,000 --> 00:05:43,400
But when you're trying to release a small service, a long list of cloud choices can slow you down.

132
00:05:43,400 --> 00:05:44,720
You may not know which option fits.

133
00:05:44,720 --> 00:05:48,320
You may pick a setting that works today but becomes hard to support later.

134
00:05:48,320 --> 00:05:52,960
A good default removes choices that should not need a fresh debate every time.

135
00:05:52,960 --> 00:05:54,760
It gets the first deployment out faster.

136
00:05:54,760 --> 00:05:57,960
It means support teams recognize the setup when there is a problem.

137
00:05:57,960 --> 00:06:01,880
It also means a new developer can follow the same route as an experienced one, rather than

138
00:06:01,880 --> 00:06:05,600
relying on old notes or a helpful person in a chat channel.

139
00:06:05,600 --> 00:06:08,400
But a golden path must not become a locked hallway.

140
00:06:08,400 --> 00:06:10,280
Some applications have unusual needs.

141
00:06:10,280 --> 00:06:14,240
A team might need a different hosting model, a special network connection, or a service

142
00:06:14,240 --> 00:06:16,160
that the standard path does not cover.

143
00:06:16,160 --> 00:06:20,200
If the platform says no without a route forward, people will build their own workarounds

144
00:06:20,200 --> 00:06:21,440
outside the platform.

145
00:06:21,440 --> 00:06:24,600
That creates the exact confusion the platform was meant to reduce.

146
00:06:24,600 --> 00:06:26,600
So good golden paths include an escape hatch.

147
00:06:26,600 --> 00:06:29,320
This is a clear control process for special cases.

148
00:06:29,320 --> 00:06:32,680
The team explains what they need, the right people review it, and the result can become

149
00:06:32,680 --> 00:06:35,640
a new approved path later if other teams need the same thing.

150
00:06:35,640 --> 00:06:37,480
The golden path helps create a service.

151
00:06:37,480 --> 00:06:40,920
But after a company has hundreds of services, teams need another answer.

152
00:06:40,920 --> 00:06:44,800
How do you find a service, understand it, and know who looks after it?

153
00:06:44,800 --> 00:06:45,920
The service catalog.

154
00:06:45,920 --> 00:06:47,960
Your company's map of running software.

155
00:06:47,960 --> 00:06:49,640
Creating a service is only part of the job.

156
00:06:49,640 --> 00:06:53,640
A few months later, someone needs to change it, support it, or find out why it failed.

157
00:06:53,640 --> 00:06:55,080
That is where a service catalog helps.

158
00:06:55,080 --> 00:06:58,840
A service catalog is one place that records the software your company runs.

159
00:06:58,840 --> 00:07:03,080
For each service, it can show the name, the owning team, links to documentation, the services

160
00:07:03,080 --> 00:07:06,440
it depends on, its current status, and the right support links.

161
00:07:06,440 --> 00:07:09,160
Think of it as a filing cabinet with labeled folders.

162
00:07:09,160 --> 00:07:13,600
Without it, information ends up scattered across old chat messages, bookmarks, documents,

163
00:07:13,600 --> 00:07:16,640
and the memory of the person who built the service two years ago.

164
00:07:16,640 --> 00:07:19,880
That person may have moved to another team, the service is still running, but nobody feels

165
00:07:19,880 --> 00:07:20,880
responsible for it.

166
00:07:20,880 --> 00:07:23,280
A catalog gives the company a reliable record.

167
00:07:23,280 --> 00:07:26,400
You might open it because you need to use an API, which is a way for one application

168
00:07:26,400 --> 00:07:27,400
to talk to another.

169
00:07:27,400 --> 00:07:28,840
Before you use it, you need answers.

170
00:07:28,840 --> 00:07:30,000
Who owns this API?

171
00:07:30,000 --> 00:07:31,000
Where is its source code?

172
00:07:31,000 --> 00:07:32,280
Which database does it connect to?

173
00:07:32,280 --> 00:07:33,440
Is it healthy right now?

174
00:07:33,440 --> 00:07:34,880
And if it stops working overnight?

175
00:07:34,880 --> 00:07:35,880
Who receives the alert?

176
00:07:35,880 --> 00:07:39,760
Those are simple questions, yet they can take hours to answer when there is no shared place

177
00:07:39,760 --> 00:07:40,760
to look.

178
00:07:40,760 --> 00:07:44,160
Imagine you join a new team and are asked to update an order service.

179
00:07:44,160 --> 00:07:47,520
Instead of searching through team's messages from last year, you open the catalog.

180
00:07:47,520 --> 00:07:48,720
You find the service page.

181
00:07:48,720 --> 00:07:52,640
It shows the owner a link to the code in Azure DevOps or GitHub and the runbook, which is

182
00:07:52,640 --> 00:07:55,040
a set of instructions for handling common problems.

183
00:07:55,040 --> 00:07:59,000
The same page can link to an Azure Monitor dashboard and application insights, where you

184
00:07:59,000 --> 00:08:01,840
can see errors, response times, and live activity.

185
00:08:01,840 --> 00:08:04,560
It can point to the Azure resources the service uses.

186
00:08:04,560 --> 00:08:08,640
It can also list dependencies such as the payment service or the database it needs before

187
00:08:08,640 --> 00:08:09,640
it can work.

188
00:08:09,640 --> 00:08:11,240
That turns a mystery into a starting point.

189
00:08:11,240 --> 00:08:14,880
It also helps people see the difference between a catalog and a portal.

190
00:08:14,880 --> 00:08:18,160
A portal is usually where you go to ask for something or manage something.

191
00:08:18,160 --> 00:08:22,160
You might use a portal to create a new service, request access, or trigger a task.

192
00:08:22,160 --> 00:08:26,040
A catalog records what already exists and gives you the information needed to understand

193
00:08:26,040 --> 00:08:27,040
it.

194
00:08:27,040 --> 00:08:28,360
Sometimes the two sit in the same website.

195
00:08:28,360 --> 00:08:30,480
That is fine, but they do different jobs.

196
00:08:30,480 --> 00:08:32,520
One is the front desk where you make a request.

197
00:08:32,520 --> 00:08:35,440
The other is the company's map of the software already running.

198
00:08:35,440 --> 00:08:37,600
Microsoft tools fit naturally into this picture.

199
00:08:37,600 --> 00:08:41,560
A catalog entry can connect to Azure Monitor for health data, application insights for

200
00:08:41,560 --> 00:08:45,400
app details, Azure DevOps or GitHub for the code, Teams for the support channel, and Azure

201
00:08:45,400 --> 00:08:47,400
itself for the resources behind the service.

202
00:08:47,400 --> 00:08:50,000
You do not need every detail copied into one screen.

203
00:08:50,000 --> 00:08:52,920
You need clear links that take you to the right place without guessing.

204
00:08:52,920 --> 00:08:54,760
Ownership is the quiet benefit here.

205
00:08:54,760 --> 00:08:58,360
When every service needs an owner, fewer services become abandoned.

206
00:08:58,360 --> 00:09:02,200
During an incident, support staff can quickly find the team that knows the service.

207
00:09:02,200 --> 00:09:06,400
The team can see the dashboard, read the runbook, and check its dependencies instead of spending

208
00:09:06,400 --> 00:09:09,280
the first hour working out what they are looking at.

209
00:09:09,280 --> 00:09:13,160
A map helps people find the road, but it cannot stop unsafe driving.

210
00:09:13,160 --> 00:09:15,400
Guardrails, freedom inside safe boundaries.

211
00:09:15,400 --> 00:09:18,000
A service catalog helps you find what exists.

212
00:09:18,000 --> 00:09:22,320
Guardrails decide what can safely happen when someone creates or changes something.

213
00:09:22,320 --> 00:09:25,560
Guardrails are rules and approved, defaults built into the platform.

214
00:09:25,560 --> 00:09:29,920
They let teams work on their own while keeping the company's security access and cost rules

215
00:09:29,920 --> 00:09:30,920
in place.

216
00:09:30,920 --> 00:09:33,920
Without guardrails, there are usually two bad choices.

217
00:09:33,920 --> 00:09:36,440
The first is to approve every request by hand.

218
00:09:36,440 --> 00:09:40,800
A developer asks for a database, an Azure role, or a new environment, and the request

219
00:09:40,800 --> 00:09:42,520
waits for someone to check it.

220
00:09:42,520 --> 00:09:47,000
That may feel safe, but it creates queues, people lose time, and the people doing approvals

221
00:09:47,000 --> 00:09:49,680
spend their day checking the same routine requests.

222
00:09:49,680 --> 00:09:53,800
The other bad choice is to give everyone broad access and hope they remember every rule.

223
00:09:53,800 --> 00:09:57,320
That feels fast until a password appears in source code, a service is created in the

224
00:09:57,320 --> 00:10:01,520
wrong region, or a test environment produces an unexpected Azure build.

225
00:10:01,520 --> 00:10:02,840
Guardrails offer a better path.

226
00:10:02,840 --> 00:10:06,360
If a request follows the approved rules, it moves forward automatically.

227
00:10:06,360 --> 00:10:10,400
If it needs something unusual or risky, the platform stops it early and points the team

228
00:10:10,400 --> 00:10:11,680
toward the right process.

229
00:10:11,680 --> 00:10:15,160
Identity sits at the center of this, think of Microsoft Entra ID as the reception desk

230
00:10:15,160 --> 00:10:16,560
for your digital workplace.

231
00:10:16,560 --> 00:10:18,840
Before someone enters, the reception desk checks who they are.

232
00:10:18,840 --> 00:10:22,840
It also checks which rooms they can enter and what they are allowed to do once inside.

233
00:10:22,840 --> 00:10:25,240
A developer signs in with their company account.

234
00:10:25,240 --> 00:10:28,720
Azure ID can place that person in the right group based on their team or role.

235
00:10:28,720 --> 00:10:32,860
The platform can then allow that group to create a development service, view a dashboard,

236
00:10:32,860 --> 00:10:35,000
or manage a specific Azure resource.

237
00:10:35,000 --> 00:10:37,920
It does not need to give every developer permission to change everything.

238
00:10:37,920 --> 00:10:39,320
This is called least privilege.

239
00:10:39,320 --> 00:10:43,000
In plain English, people and applications receive only the access they need for the job

240
00:10:43,000 --> 00:10:44,000
in front of them.

241
00:10:44,000 --> 00:10:45,320
No more.

242
00:10:45,320 --> 00:10:50,520
Azure also gives platform teams ways to set rules across larger parts of the company.

243
00:10:50,520 --> 00:10:54,680
Management groups help organize Azure subscriptions under shared rules.

244
00:10:54,680 --> 00:10:57,600
Azure Policy checks whether resources follow those rules.

245
00:10:57,600 --> 00:11:01,080
A company may allow services only in approved Azure regions.

246
00:11:01,080 --> 00:11:02,520
It may limit certain resource types.

247
00:11:02,520 --> 00:11:07,480
It may require every resource to carry tags such as the owning team, cost center, and environment.

248
00:11:07,480 --> 00:11:10,200
Those tags sound small, but they answer questions later.

249
00:11:10,200 --> 00:11:11,280
Who owns this resource?

250
00:11:11,280 --> 00:11:12,280
Why are we paying for it?

251
00:11:12,280 --> 00:11:13,920
Is this for testing or production?

252
00:11:13,920 --> 00:11:17,480
Without those answers, Azure can quickly become difficult to manage.

253
00:11:17,480 --> 00:11:20,720
Policies can also check security settings before a resource is created.

254
00:11:20,720 --> 00:11:25,640
For example, a database may need encryption enabled or a storage account may need to block public access.

255
00:11:25,640 --> 00:11:31,520
The platform can apply these expectations every time, rather than asking every team to remember them from a document.

256
00:11:31,520 --> 00:11:32,920
Secrets need the same care.

257
00:11:32,920 --> 00:11:37,160
A secret could be a database password, an API key, or a connection string.

258
00:11:37,160 --> 00:11:39,120
It should not live in the application code.

259
00:11:39,120 --> 00:11:42,880
It should not sit in a pipeline file where more people can see it than necessary.

260
00:11:42,880 --> 00:11:46,000
Azure Key Vault provides a protected place to store those secrets.

261
00:11:46,000 --> 00:11:49,760
Even better, a service can often use a managed identity instead of a password.

262
00:11:49,760 --> 00:11:54,640
The application proves its identity to Azure, and as your grants the access already approved for that application,

263
00:11:54,640 --> 00:11:59,160
there is less secret handling for developers and fewer passwords that need replacing later.

264
00:11:59,160 --> 00:12:02,160
Security checks also continue after the service is running.

265
00:12:02,160 --> 00:12:06,440
Microsoft Defender can help spot risky code, weak cloud settings, exposed secrets,

266
00:12:06,440 --> 00:12:08,280
and signs of threats across the platform.

267
00:12:08,280 --> 00:12:11,320
This does not mean every developer becomes a security specialist.

268
00:12:11,320 --> 00:12:16,400
It means the platform brings useful checks closer to the normal work of building and running software.

269
00:12:16,400 --> 00:12:18,080
Cost needs boundaries too.

270
00:12:18,080 --> 00:12:21,680
The self-service request should not accidentally create the largest database size,

271
00:12:21,680 --> 00:12:24,200
run forever, or appear without an owner.

272
00:12:24,200 --> 00:12:29,880
Approved sizes, budgets, tags, spending alerts, and resource limits help teams see costs early,

273
00:12:29,880 --> 00:12:31,400
while there is still time to act.

274
00:12:31,400 --> 00:12:34,120
Good guardrails do not turn the platform into a ticket machine.

275
00:12:34,120 --> 00:12:39,720
They remove the slow approvals for normal work while keeping clear boundaries around access, security, and money.

276
00:12:39,720 --> 00:12:43,560
Teams can move faster because the safe choices are already built into the path.

277
00:12:43,560 --> 00:12:46,080
Those safe building blocks still need one more thing.

278
00:12:46,080 --> 00:12:52,120
When a developer makes a simple request, automation has to turn that request into a working service.

279
00:12:52,120 --> 00:12:54,920
What happens after you click Create Service?

280
00:12:54,920 --> 00:12:58,520
So a developer opens the platform and clicks Create Service.

281
00:12:58,520 --> 00:13:02,400
That request might come through a web portal that might come from a command line tool.

282
00:13:02,400 --> 00:13:04,600
It could be an API call from another system.

283
00:13:04,600 --> 00:13:08,440
Some teams may even make the request through a small form stored in their git repository.

284
00:13:08,440 --> 00:13:09,680
The front door can change.

285
00:13:09,680 --> 00:13:13,280
What matters is that the developer describes what they need in a short, clear way.

286
00:13:13,280 --> 00:13:18,480
You might ask for a web service called Order status owned by the checkout team with a test and production environment.

287
00:13:18,480 --> 00:13:20,480
Then the platform starts work behind the scenes.

288
00:13:20,480 --> 00:13:23,840
One request can create a new code repository with a standard folder layout.

289
00:13:23,840 --> 00:13:25,720
It can add a build and release pipeline.

290
00:13:25,720 --> 00:13:28,120
It can create the Azure resources the service needs.

291
00:13:28,120 --> 00:13:29,840
It can give the service the right permissions.

292
00:13:29,840 --> 00:13:31,440
It can connect monitoring.

293
00:13:31,440 --> 00:13:35,560
It can create a documentation page with links that help the next person understand the service.

294
00:13:35,560 --> 00:13:37,360
The developer asked for one service.

295
00:13:37,360 --> 00:13:41,520
The platform completed a chain of work that normally crosses several teams and tools.

296
00:13:41,520 --> 00:13:46,280
This works best when the request describes the result, not every technical action needed to reach it.

297
00:13:46,280 --> 00:13:50,080
For example, the developer says, I need a web service running in test.

298
00:13:50,080 --> 00:13:56,880
They do not need to say create these exact Azure resources, connect these settings, add these permissions, and run these scripts in this order.

299
00:13:56,880 --> 00:13:58,600
That approach is called desired state.

300
00:13:58,600 --> 00:14:04,200
In plain English, you describe what you want the finished setup to look like and automation creates it and keeps it that way.

301
00:14:04,200 --> 00:14:10,880
If the expected setup changes later, the platform can compare what should exist with what actually exists, then correct the difference.

302
00:14:10,880 --> 00:14:12,760
You can think of it as a written order for a service.

303
00:14:12,760 --> 00:14:14,200
The order says what the service needs.

304
00:14:14,200 --> 00:14:19,120
It does not ask the developer to personally visit every Azure screen and assemble the parts by hand.

305
00:14:19,120 --> 00:14:20,720
Many teams keep that order in Git.

306
00:14:20,720 --> 00:14:22,640
This is where GitOps fits into the picture.

307
00:14:22,640 --> 00:14:28,200
GitOps means the requested setup lives in a Git repository alongside a history of every change.

308
00:14:28,200 --> 00:14:31,000
Someone can review a proposed change before it takes effect.

309
00:14:31,000 --> 00:14:32,240
The change has a record.

310
00:14:32,240 --> 00:14:35,320
Automation reads the approved files and applies the setup.

311
00:14:35,320 --> 00:14:40,320
If a team changes a service from one environment to another or asks for a new database setting,

312
00:14:40,320 --> 00:14:42,680
the request does not disappear into a chat message.

313
00:14:42,680 --> 00:14:48,320
It becomes a tracked change that gives teams a clearer record of who changed what when they changed it and why.

314
00:14:48,320 --> 00:14:53,200
It also means the platform can rebuild a known setup instead of relying on somebody's memory.

315
00:14:53,200 --> 00:14:56,400
Azure gives you several tools that can sit behind this process.

316
00:14:56,400 --> 00:15:00,040
Bicep is one option for describing Azure resources in code.

317
00:15:00,040 --> 00:15:05,800
Terraform is another popular option that can describe Azure resources and resources from other cloud providers.

318
00:15:05,800 --> 00:15:12,560
The platform can use one of these tools to create the hosting, storage, databases and network settings that the service needs.

319
00:15:12,560 --> 00:15:17,720
For the build and release work, a company might use Azure DevOps pipelines or GitHub actions.

320
00:15:17,720 --> 00:15:23,280
Those automated jobs can test the code, build the application and release it through the approved environments.

321
00:15:23,280 --> 00:15:26,520
For hosting, a simple service might run in Azure App Service.

322
00:15:26,520 --> 00:15:31,720
A company with container-based applications may use Azure Kubernetes service usually called AKS.

323
00:15:31,720 --> 00:15:36,040
The developer does not need to become an AKS expert just to get a normal service running.

324
00:15:36,040 --> 00:15:38,920
A platform can provide approved application templates,

325
00:15:38,920 --> 00:15:45,320
ready to use namespace, which is a separated area inside Kubernetes or a prepared environment for a team to use.

326
00:15:45,320 --> 00:15:49,040
The deeper Kubernetes setup stays with the people who run the shared foundation.

327
00:15:49,040 --> 00:15:55,120
Sometimes the company needs stronger separation between teams while still sharing the same underlying Kubernetes capacity.

328
00:15:55,120 --> 00:15:57,360
A tool such as VCluster can help with that.

329
00:15:57,360 --> 00:16:01,680
It creates virtual Kubernetes spaces for separate teams on a shared host cluster.

330
00:16:01,680 --> 00:16:09,120
Each team gets an environment that feels more like its own cluster while the company avoids creating a full physical cluster for every small need.

331
00:16:09,120 --> 00:16:11,080
VCluster is one possible building block.

332
00:16:11,080 --> 00:16:18,160
It is not a requirement for an IDP. Neither is bicep, terraform, Azure DevOps, GitHub actions, AKS or any single portal product.

333
00:16:18,160 --> 00:16:21,360
Tool choices matter, but the bigger question is simpler.

334
00:16:21,360 --> 00:16:27,080
Does the platform remove real friction for the people building software or does it add another screen and another process?

335
00:16:27,080 --> 00:16:31,120
That question leads directly to the biggest myth around internal developer platforms.

336
00:16:31,120 --> 00:16:34,760
One IDP is not and where Microsoft 365 and Azure fit.

337
00:16:34,760 --> 00:16:37,960
An IDP is not backstage or any other single portal product.

338
00:16:37,960 --> 00:16:43,120
A portal can be the screen people use, but the platform includes the people who maintain it, the standards they agree on,

339
00:16:43,120 --> 00:16:46,640
the automation during the work and the ways developers interact with it.

340
00:16:46,640 --> 00:16:50,400
It also does not replace DevOps, cloud team security teams or architects.

341
00:16:50,400 --> 00:16:56,440
Instead, the platform team turns their shared knowledge into reusable paths that every development team can use.

342
00:16:56,440 --> 00:17:01,080
Azure supplies, much of the foundation behind those paths, compute storage, databases.

343
00:17:01,080 --> 00:17:04,200
Networking, monitoring, policy and security.

344
00:17:04,200 --> 00:17:10,040
Entra ID connects identity across Azure, Microsoft 365, developer tools and internal systems.

345
00:17:10,040 --> 00:17:17,880
Teams often becomes the everyday work layer where alerts arrive, approvals happen, support links live and service notifications reach the people who need them.

346
00:17:17,880 --> 00:17:21,960
Start small, pick one painful workflow, one team and one golden path.

347
00:17:21,960 --> 00:17:23,480
Listen before you build more.

348
00:17:23,480 --> 00:17:27,240
That brings us to the practical first move, start with one useful path.

349
00:17:27,240 --> 00:17:30,680
Find the request developers repeat most often and dislike doing by hand.

350
00:17:30,680 --> 00:17:34,760
It might be a standard web service, a background worker or a managed database.

351
00:17:34,760 --> 00:17:37,560
Choose one narrow offer, then make the request simple.

352
00:17:37,560 --> 00:17:41,560
A name, an owner, an environment and only the choices that truly matter.

353
00:17:41,560 --> 00:17:47,800
Behind that request build the approved Azure setup, identity, secret storage, deployment logs and ownership record.

354
00:17:47,800 --> 00:17:53,520
Put guardrails in early, require an owner, apply cost tags, limit locations, check the security baseline,

355
00:17:53,520 --> 00:17:58,760
create a catalog entry automatically with links to code, documentation, dashboards and the support contact.

356
00:17:58,760 --> 00:18:04,600
Then measure what changed, waiting time, repeat tickets, failed setup steps, adoption and developer feedback.

357
00:18:04,600 --> 00:18:09,000
Each useful path becomes another working part of your company's digital office building.

358
00:18:09,000 --> 00:18:14,760
An internal developer platform is an internal self-service system that helps teams build, release and run software safely.

359
00:18:14,760 --> 00:18:18,760
Its building blocks are simple to name, even if the work behind them takes care.

360
00:18:18,760 --> 00:18:26,600
Golden paths for common work, a service catalog for ownership, automation for repeatable setup, guardrails for safe choices,

361
00:18:26,600 --> 00:18:30,520
identity for access and visibility into what is running.

362
00:18:30,520 --> 00:18:34,920
Try one exercise this week, write down one developer request that appears again and again,

363
00:18:34,920 --> 00:18:40,040
then list every handoff ticket approval tool and person involved before that request becomes a working service.

364
00:18:40,040 --> 00:18:43,160
That list shows you where a first platform path could help.

365
00:18:43,160 --> 00:18:46,040
Before building a portal, learn the foundation beneath it.

366
00:18:46,040 --> 00:18:49,640
Look at Azure landing zones as your policy or as your DevOps foundations.

367
00:18:49,640 --> 00:18:52,360
A button only helps when the system behind it knows what to do.