1
00:00:00,000 --> 00:00:05,760
Welcome back to another edition of the M365 podcast.

2
00:00:05,760 --> 00:00:09,600
Today's episode is all about building Azure the right way.

3
00:00:09,600 --> 00:00:12,080
Many organizations have migrated to Azure,

4
00:00:12,080 --> 00:00:15,880
but creating a cloud platform that is secure,

5
00:00:15,880 --> 00:00:18,360
scalable, automated, and the developer friendly is

6
00:00:18,360 --> 00:00:20,000
a completely different challenge.

7
00:00:20,000 --> 00:00:22,960
Jeff is a cloud architect specializing in

8
00:00:22,960 --> 00:00:24,320
Azure platform engineering,

9
00:00:24,320 --> 00:00:26,680
Azure landing zones, infrastructure as a code,

10
00:00:26,680 --> 00:00:28,600
platform engineering, Azure DevOps,

11
00:00:28,600 --> 00:00:31,680
and Michael of Cloud on that two framework is also an

12
00:00:31,680 --> 00:00:34,280
active community contributor through blogging,

13
00:00:34,280 --> 00:00:35,680
YouTube, and speaking.

14
00:00:35,680 --> 00:00:38,680
Today we will discuss how enterprise

15
00:00:38,680 --> 00:00:40,920
should build Azure platforms that

16
00:00:40,920 --> 00:00:44,360
develop us equally love to use while keeping

17
00:00:44,360 --> 00:00:47,840
governance and security under control.

18
00:00:47,840 --> 00:00:49,600
Welcome to the M65.

19
00:00:49,600 --> 00:00:50,640
Jeff.

20
00:00:50,640 --> 00:00:52,520
Thank you very much.

21
00:00:52,520 --> 00:00:54,280
Thanks for having me.

22
00:00:54,280 --> 00:00:55,720
Yeah.

23
00:00:55,720 --> 00:00:58,320
For listeners meeting you the first time.

24
00:00:58,320 --> 00:01:03,320
Who is the F Strhoy outside of Microsoft technology?

25
00:01:03,320 --> 00:01:05,160
Outside of Microsoft technology,

26
00:01:05,160 --> 00:01:08,160
that's an interesting question.

27
00:01:08,160 --> 00:01:13,680
Well, both inside and outside of Microsoft technology,

28
00:01:13,680 --> 00:01:18,960
I would say I'm the guy that likes to pick things apart.

29
00:01:18,960 --> 00:01:24,560
I've done so as a kid when my parents gave me a toy or something,

30
00:01:24,560 --> 00:01:26,680
like a remote control car.

31
00:01:26,680 --> 00:01:29,920
I remember the first thing I did instead of driving it,

32
00:01:29,920 --> 00:01:32,920
I found the screwdrivers from my dad,

33
00:01:32,920 --> 00:01:34,680
and this is a remote holding,

34
00:01:34,680 --> 00:01:37,280
curious on how it works.

35
00:01:37,280 --> 00:01:39,600
And I still do that.

36
00:01:39,600 --> 00:01:42,960
It's a bit easier to do that in Azure,

37
00:01:42,960 --> 00:01:45,640
where you can delete stuff that you've broken.

38
00:01:45,640 --> 00:01:49,480
Obviously the toy in this case got broken and I ended up

39
00:01:49,480 --> 00:01:52,800
crying because it didn't work anymore.

40
00:01:52,800 --> 00:01:56,640
So I tried to learn from these things also outside of

41
00:01:56,640 --> 00:01:59,280
the Microsoft area.

42
00:01:59,280 --> 00:02:02,640
So what I usually love to do is to work with my hands.

43
00:02:02,640 --> 00:02:10,000
I'm a big fan of creating furniture and anything would relate it actually.

44
00:02:10,000 --> 00:02:14,800
And how did you find into the Microsoft ecosystem?

45
00:02:14,800 --> 00:02:19,640
Well, that's I guess by luck or by fate,

46
00:02:19,640 --> 00:02:21,040
whatever you want to call it.

47
00:02:21,040 --> 00:02:26,240
Originally, I'm actually a GIS specialist.

48
00:02:26,240 --> 00:02:31,240
I'm pretty sure most of the listeners are not familiar with this term.

49
00:02:31,240 --> 00:02:35,000
It's called geospatial information systems,

50
00:02:35,000 --> 00:02:40,240
which is basically the mapping, the anything map related.

51
00:02:40,240 --> 00:02:45,240
So I started out as a geospatial information systems consultant.

52
00:02:45,240 --> 00:02:50,480
And I ran into on a certain project into a guy who was working

53
00:02:50,480 --> 00:02:51,560
with Microsoft technology.

54
00:02:51,560 --> 00:02:54,800
So we were doing the backend to all mapping.

55
00:02:54,800 --> 00:02:58,400
And this guy built the websites, the portals and everything.

56
00:02:58,400 --> 00:03:01,640
And when I worked with him together, I saw what he was doing.

57
00:03:01,640 --> 00:03:03,480
I was like, oh my god, this is cool.

58
00:03:03,480 --> 00:03:05,360
I want to do this as well.

59
00:03:05,360 --> 00:03:07,960
So I figure out in which company he worked.

60
00:03:07,960 --> 00:03:12,560
And I just called them out is like, I don't know what needs to be done,

61
00:03:12,560 --> 00:03:16,400
but I want to be do it to do whatever this guy does.

62
00:03:16,400 --> 00:03:21,600
So that's how I started with Microsoft technology.

63
00:03:21,600 --> 00:03:27,000
Basically, they got me into a spot as a dot net developer.

64
00:03:27,000 --> 00:03:31,200
So that's how my journey started.

65
00:03:31,200 --> 00:03:35,600
Yeah, I think as well has also a map skills,

66
00:03:35,600 --> 00:03:39,000
yeah, the services, right?

67
00:03:39,000 --> 00:03:39,760
Yeah.

68
00:03:39,760 --> 00:03:44,720
And I like this is this is the the the main thing about Azure.

69
00:03:44,720 --> 00:03:45,400
It's huge.

70
00:03:45,400 --> 00:03:49,400
I would love to meet the person that knows all the services.

71
00:03:49,400 --> 00:03:54,240
And he goes for me, I know quite a number of them, but not all of them.

72
00:03:54,240 --> 00:03:57,600
And maps is always eluded me.

73
00:03:57,600 --> 00:04:02,560
I've never had in the last almost 15 plus years.

74
00:04:02,560 --> 00:04:07,240
I never had a project where I was able to do anything with the map service.

75
00:04:07,240 --> 00:04:11,600
So maybe maybe it's my curse.

76
00:04:14,600 --> 00:04:22,360
When you look back, what project thought you the biggest lesson in your career?

77
00:04:22,360 --> 00:04:27,600
The biggest lesson, that's the ones where we make the biggest mistakes

78
00:04:27,600 --> 00:04:30,600
and the most painful ones, I would say.

79
00:04:30,600 --> 00:04:38,000
For me, if we talk like just the career perspective,

80
00:04:38,000 --> 00:04:42,440
not Azure specific or within Microsoft domain,

81
00:04:42,440 --> 00:04:49,840
I think my biggest lesson was that I am a very mediocre.net developer.

82
00:04:49,840 --> 00:04:55,000
What meant that I, I, I, so I like to be competitive.

83
00:04:55,000 --> 00:04:58,240
I like to be as good as I can get.

84
00:04:58,240 --> 00:05:01,760
And in dot net that's never happened.

85
00:05:01,760 --> 00:05:05,600
So that ended up with a bit frustration, but like with any kind of frustration,

86
00:05:05,600 --> 00:05:08,560
you can get something cool and beautiful out of it.

87
00:05:08,560 --> 00:05:14,520
So when I had that frustration, I noticed that's,

88
00:05:14,520 --> 00:05:18,720
there's at the company at, I was at that point,

89
00:05:18,720 --> 00:05:23,640
it was like a huge gap, like two big islands, the classic infrastructure people,

90
00:05:23,640 --> 00:05:27,880
because this was like pre-cloud error, like close to cloud getting started and

91
00:05:27,880 --> 00:05:32,440
everything, but just pre-cloud error and application,

92
00:05:32,440 --> 00:05:35,280
dot net developers, any kind of other.

93
00:05:35,280 --> 00:05:40,920
And I, I thought about this like, well, if I, if I'm a mediocre developer,

94
00:05:40,920 --> 00:05:43,880
maybe I'm gonna be a better infrastructure guy.

95
00:05:43,880 --> 00:05:49,440
So I switched to infrastructure, obviously not overnight.

96
00:05:49,440 --> 00:05:56,960
And I took all the, all the lessons that I learned in being a developer with me.

97
00:05:56,960 --> 00:06:00,640
And I would say that was my biggest learning moment,

98
00:06:00,640 --> 00:06:07,720
at least is I realized that infrastructure engineers had no clue on

99
00:06:07,720 --> 00:06:12,280
the standards and best practices and they were not benefiting from them.

100
00:06:12,280 --> 00:06:16,880
And so I evolved into that direction and I believe we call this DevOps these days.

101
00:06:16,880 --> 00:06:26,640
Yeah, you have to say, the other services, but yeah,

102
00:06:26,640 --> 00:06:32,760
the good thing is Microsoft rename it a regular, so it makes more simpler for people.

103
00:06:32,760 --> 00:06:36,760
And yeah, the other good thing is the cloud technology change,

104
00:06:36,760 --> 00:06:38,600
incredible fast.

105
00:06:38,600 --> 00:06:42,680
How do you stay ahead with our burning out?

106
00:06:42,680 --> 00:06:44,280
Oh yeah, that's, that's a challenge.

107
00:06:44,280 --> 00:06:50,920
I would say if you want to be what I like to call ahead of the curve,

108
00:06:50,920 --> 00:06:54,240
it needs to be a lifestyle.

109
00:06:54,240 --> 00:06:57,360
It cannot be a just a job.

110
00:06:57,360 --> 00:07:03,760
So what drives me is that curiosity, like opening up the,

111
00:07:03,760 --> 00:07:06,960
looking how the car, the remote control car work,

112
00:07:06,960 --> 00:07:08,920
I still have the same thing with Azure.

113
00:07:08,920 --> 00:07:15,880
So whenever something new comes up, I would like to see if I can find the screws

114
00:07:15,880 --> 00:07:22,080
and unscrew it and look how it runs, what the inside are.

115
00:07:22,080 --> 00:07:28,160
So that's my main motivator to not burn up from a practical perspective.

116
00:07:28,160 --> 00:07:34,320
My day starts after I wake up, I start looking through some new feeds,

117
00:07:34,320 --> 00:07:36,360
articles that I have on my phone.

118
00:07:36,360 --> 00:07:41,720
Okay, while we were sleepy and the US was awake, what new stuff did they release?

119
00:07:41,720 --> 00:07:48,960
And then I make a selection on which topics are closer to my heart,

120
00:07:48,960 --> 00:07:55,040
or maybe topics that I'm working on one of my clients and go deep into those.

121
00:07:55,040 --> 00:08:00,080
Because I would say the, now talking about it, I'm realizing that

122
00:08:00,080 --> 00:08:07,040
the second factor of not like burning out or going in same is it needs a purpose.

123
00:08:07,040 --> 00:08:11,000
So in my case, if a client has a problem, a challenge,

124
00:08:11,000 --> 00:08:16,920
I get super hyper focused and excited to see if I can solve that as as effective as possible.

125
00:08:16,920 --> 00:08:22,240
Okay, that's interesting.

126
00:08:22,240 --> 00:08:24,720
So you have this knife style.

127
00:08:24,720 --> 00:08:28,160
So you do it so, so, so long.

128
00:08:28,160 --> 00:08:33,600
How do you keep exciting to work so many years with Azure?

129
00:08:33,600 --> 00:08:43,640
How it's, I don't know, actually, they come up, Microsoft comes up with interesting services.

130
00:08:46,520 --> 00:08:53,720
Quite often and services that are available are being reiterated as well.

131
00:08:53,720 --> 00:08:57,720
Sure, there are some things that I consider boring, but for me,

132
00:08:57,720 --> 00:09:02,920
that landscape is so fast that it still keeps me entertained.

133
00:09:02,920 --> 00:09:09,720
And if I get bored with something, I like to see if we can,

134
00:09:09,720 --> 00:09:14,760
or I can set up the same automation, but in different areas.

135
00:09:14,760 --> 00:09:21,280
So for example, a colleague of mine was working on M365.

136
00:09:21,280 --> 00:09:26,360
And at a certain point, I was like, yeah, I need something else to do.

137
00:09:26,360 --> 00:09:31,360
It's slightly different focus and he asked me like, well, how would you set up M365?

138
00:09:31,360 --> 00:09:38,040
And then I figured out that there's a whole open source project, which is called M365DC,

139
00:09:38,040 --> 00:09:39,640
desire state configuration.

140
00:09:39,640 --> 00:09:43,880
So which is basically infrastructure code, but for M365.

141
00:09:43,880 --> 00:09:49,400
So I dove into that, figured out how it worked, looked at the concepts and everything,

142
00:09:49,400 --> 00:09:57,000
and helped him set it up, which was kind of like a holiday or a break for me to not work on Azure.

143
00:09:57,000 --> 00:10:01,960
When so when I returned back to working on Azure, it felt fresh and new again as well.

144
00:10:01,960 --> 00:10:09,480
Awesome. Yeah, I don't have a platform engineering.

145
00:10:09,480 --> 00:10:15,400
I think that's one of the, yeah, actually hardest topic in cloud computing.

146
00:10:15,400 --> 00:10:21,000
How will you explain platform engineering to someone who's only family or

147
00:10:21,000 --> 00:10:23,080
with traditional infrastructure teams?

148
00:10:23,080 --> 00:10:27,000
Yeah, that's a good one.

149
00:10:27,000 --> 00:10:39,000
Platform engineering is, I would say your building standardized, sell service tools.

150
00:10:39,000 --> 00:10:42,680
I would like sum it up into that.

151
00:10:42,680 --> 00:10:45,320
It's understood.

152
00:10:45,320 --> 00:10:46,600
So there are two aspects to it.

153
00:10:46,600 --> 00:10:50,520
One is you build you standardized everything as much as possible.

154
00:10:50,520 --> 00:10:54,040
So any kind of repeat you want to automate and

155
00:10:54,040 --> 00:10:56,760
standardize it into something that can be reusable.

156
00:10:56,760 --> 00:11:04,200
A second point, which is completely different to traditional infrastructure self-service.

157
00:11:04,840 --> 00:11:15,240
So you build something that another team can use without relying on your availability expertise, etc,

158
00:11:15,240 --> 00:11:17,480
which helps you also to scale obviously.

159
00:11:17,480 --> 00:11:27,800
And the final one I would say is a common is a bit of having understanding and knowledge

160
00:11:27,800 --> 00:11:30,200
of what a platform needs to do.

161
00:11:30,200 --> 00:11:34,440
And often our platforms are built for developers.

162
00:11:34,440 --> 00:11:43,320
I consider as a platform specialist that's my main consumer is the developer.

163
00:11:43,320 --> 00:11:49,640
So I try to keep a track of what developers do the way their practices are.

164
00:11:49,640 --> 00:11:56,040
So I would say if I would have to explain it, that's a combination of those three things,

165
00:11:56,040 --> 00:11:57,160
those practices.

166
00:11:57,160 --> 00:11:59,560
Like DevOps is also a practice.

167
00:11:59,560 --> 00:12:02,840
I would say platform engineering is to a certain extent also.

168
00:12:03,560 --> 00:12:05,320
A practice of those three.

169
00:12:05,320 --> 00:12:15,880
So then we have, I think we have to stop only moving workloads to Azure, right?

170
00:12:15,880 --> 00:12:21,160
Can you elaborate on that a bit?

171
00:12:21,160 --> 00:12:31,960
Yeah, I think a lot of companies say, okay, we are on prem.

172
00:12:31,960 --> 00:12:34,280
And now we move all to Azure.

173
00:12:34,280 --> 00:12:37,560
What's wrong on the thinking?

174
00:12:37,560 --> 00:12:39,560
Ah, yeah, like that.

175
00:12:39,560 --> 00:12:48,680
Yes, yes, and well, the fundamental mistake that happens here is thinking that Azure or any other

176
00:12:48,680 --> 00:12:55,560
cloud platform, but I know most about Azure, so I'll stick with that is a data center.

177
00:12:55,560 --> 00:13:00,120
It's not a data center and you should not treat it as well.

178
00:13:00,120 --> 00:13:09,080
I think that's the most fundamental, the biggest mistake or anti-pattern that exists

179
00:13:09,080 --> 00:13:14,840
when we're talking about moving workloads, applications, anything to Azure.

180
00:13:14,840 --> 00:13:21,480
If you consider it a data center, you can build Azure into a data center,

181
00:13:22,120 --> 00:13:33,240
but then you're not really reinventing yourself, getting the max, the most of what a cloud platform is,

182
00:13:33,240 --> 00:13:41,560
and you're making it extremely expensive because building things in the way a data center is hyper

183
00:13:41,560 --> 00:13:47,240
optimized for on-premise infrastructure. A cloud is not optimized for that. It never will be.

184
00:13:47,240 --> 00:13:54,360
It is much, much more than that, so you technically can do it, but it will not bring you the benefits

185
00:13:54,360 --> 00:13:57,160
of why you usually go to Azure.

186
00:13:57,160 --> 00:14:03,160
And what separates a good cloud platform from a great one from your perspective?

187
00:14:03,160 --> 00:14:05,560
A good one from a great one.

188
00:14:05,560 --> 00:14:06,440
Yeah.

189
00:14:06,440 --> 00:14:16,920
I think a good one is automated, and well, follows basically like Microsoft's cloud adoption

190
00:14:16,920 --> 00:14:25,400
framework standards, etc. A great one understands the business need that the developers,

191
00:14:25,400 --> 00:14:29,320
that are or the workload or the application teams, whether you want to call them,

192
00:14:29,320 --> 00:14:35,080
that are using a platform. So it's tailor fit to that specific business case.

193
00:14:35,080 --> 00:14:40,600
Because taking a generic enterprise landing zone and deploying it,

194
00:14:40,600 --> 00:14:44,760
that can be done relatively fast, especially with everything that is now available in

195
00:14:45,560 --> 00:14:52,840
Lysap in Terraform, for even in their DRSD case for Python and Pulumni.

196
00:14:52,840 --> 00:15:00,280
So that's a good one. That one fits all the criteria, but taking that one and tailor fitting it

197
00:15:00,280 --> 00:15:04,680
to your organization's specific needs, that makes it a great one.

198
00:15:04,680 --> 00:15:14,440
Did you see some, what's the biggest architectural mistakes you see organization do when they

199
00:15:15,400 --> 00:15:17,800
are starbaths as a reduction?

200
00:15:17,800 --> 00:15:25,880
Thinking that, well, it's not, if it's okay, I'll broaden the question a little bit, it's not

201
00:15:25,880 --> 00:15:34,360
just architecture. I think the biggest mistake is thinking it's a technology exercise.

202
00:15:34,360 --> 00:15:42,040
It's not. It's an adoption exercise, actually, which means that it's people process technology.

203
00:15:42,680 --> 00:15:49,480
And in those three technologies, often the easiest one. You can hire great engineers, consultants,

204
00:15:49,480 --> 00:15:55,160
etc, especially if your budget allows for it and they will build the technology. But if the rest

205
00:15:55,160 --> 00:16:05,800
of your organization isn't ready for the modern ways of working, that go hand in hand

206
00:16:06,840 --> 00:16:15,080
with a modern way of doing clouds, so not the traditional data center one, you will never be successful.

207
00:16:15,080 --> 00:16:28,280
Because your organization will rub against the processes that are needed to run your cloud.

208
00:16:28,280 --> 00:16:35,960
So a very simple example in a cloud, you want to be proactive instead of reactive, often

209
00:16:35,960 --> 00:16:43,720
traditional systems, IK-SEM kind of systems, they work with incidents. Ideally in a cloud,

210
00:16:43,720 --> 00:16:50,360
if you set this, it's things up into a great platform, you're working majority of the times

211
00:16:50,360 --> 00:16:58,360
proactive, you prevent things by having certain environments like, for example, a canary environment,

212
00:17:00,440 --> 00:17:07,240
which stem from the canary in the coal mine that miners like in the 1800s used to take victim to make

213
00:17:07,240 --> 00:17:11,560
sure that their options general levels are still okay. If something happened to the birds, they could

214
00:17:11,560 --> 00:17:18,680
safely get out. If you don't adapt these kind of principles, which is primarily a people and processes

215
00:17:18,680 --> 00:17:24,280
adoption, then you'll run into even more trouble than you have in your traditional

216
00:17:24,280 --> 00:17:31,560
and param systems with traditional processes. Yeah, let's a little bit talk about the

217
00:17:31,560 --> 00:17:39,800
Azure Landings on topic, or let's not run you to the concept, what exactly is the Azure Landings on?

218
00:17:39,800 --> 00:17:51,160
That's a good question. In layman's terms, so actually have our awesome blog post,

219
00:17:51,160 --> 00:18:00,760
if I say so, how did myself? Let me see if I can paraphrase it in less than two minutes instead of

220
00:18:00,760 --> 00:18:13,400
15 minutes. In layman's terms and application, let's roll back. Microsoft calls everything a lending

221
00:18:13,400 --> 00:18:20,120
zone. This is where you mentioned Microsoft rename certain things. The naming can always be improved

222
00:18:20,120 --> 00:18:28,040
on because if everything is a lending zone, how do you know what is what? If you let's take it from

223
00:18:28,040 --> 00:18:35,320
the outside and peel it layer by layer. At first, you have the Azure Landings on. This is your whole

224
00:18:35,320 --> 00:18:41,480
Azure environment. Traditionally, we used to call this a tenant, but the tenant practically doesn't exist.

225
00:18:41,480 --> 00:18:49,800
That contains everything. It contains the core services that are needed for your applications

226
00:18:49,800 --> 00:18:55,160
to be able to run for your lending zones, application lending zones, wants to function, etc. So those

227
00:18:55,160 --> 00:19:01,560
core services, they are called the platform lending zone. That's usually security, management,

228
00:19:01,560 --> 00:19:08,200
networking, and identity. So the service is that everybody rely on this regard. They are called

229
00:19:08,200 --> 00:19:13,560
the platform lending zone. They are built conceptually the same way. That's why it's called a

230
00:19:13,560 --> 00:19:21,720
lending zone every time. This is one of the, if I can add on your previous question, things that you

231
00:19:21,720 --> 00:19:26,600
can do fundamentally wrong. If you don't build it that way, that they're fundamentally the same,

232
00:19:26,600 --> 00:19:32,920
or conceptually the same, this is going to give you a bit more challenges. Speaking of the platform

233
00:19:32,920 --> 00:19:38,840
lending zones, the platform lending zone is clear. Next, the bread and butter, why you do all of this

234
00:19:38,840 --> 00:19:44,120
setup are something called the application lending zones. And those are depending on how many

235
00:19:44,120 --> 00:19:52,440
applications you have. And an application lending zone is basically a set of Azure subscriptions,

236
00:19:52,440 --> 00:20:01,160
depending on how your environments are and the current standard is having at least one subscription

237
00:20:01,160 --> 00:20:09,640
Azure subscription for environment. Those subscriptions are pre-prapped by your platform team to provide

238
00:20:09,640 --> 00:20:20,200
you with utilities. And those utilities is your own virtual network, maybe a key vault storage

239
00:20:20,200 --> 00:20:26,760
account, some logging, log analytics workspace, depending on your constraints. And because those

240
00:20:26,760 --> 00:20:33,080
subscriptions live in a, have a certain purpose, you usually have some Azure policies depending on

241
00:20:33,080 --> 00:20:40,920
let's say GDPR or any other compliance security compliance regulations applied on top of them.

242
00:20:40,920 --> 00:20:48,360
That combined is what we call technically a application lending zone. So if we would translate that

243
00:20:48,360 --> 00:20:57,080
into layman's terms, look at it this way, you are your application lending zone is a house.

244
00:20:57,080 --> 00:21:04,040
And your water electricity, et cetera, those are also utilities. So the utilities that I just

245
00:21:04,040 --> 00:21:09,720
mentioned, like virtual network, maybe a key vault, depending on the configuration storage account,

246
00:21:09,720 --> 00:21:17,720
a place to do your security and other kind of logging are also your utilities.

247
00:21:18,200 --> 00:21:24,120
So you get a house, the house is maybe multiple floors or multiple rooms,

248
00:21:24,120 --> 00:21:31,080
those floors you could see as subscriptions, the rooms could be seen as resource groups, one layer,

249
00:21:31,080 --> 00:21:39,720
one-depth layer lower, and that house is part of a neighborhood. And that neighborhood is then

250
00:21:39,720 --> 00:21:47,960
service by the platform lending zone, which contains security, contains management. So somebody

251
00:21:47,960 --> 00:21:54,200
takes care of the sidewalk, somebody takes care of the road. So the lanterns that you can walk

252
00:21:54,200 --> 00:22:03,480
here when it's dark. And so conceptually, it's a house that's placed inside a neighborhood. And

253
00:22:03,480 --> 00:22:12,040
finally, you have a team that operates that house, your workload team, your application team,

254
00:22:12,040 --> 00:22:17,800
and those are your people that live inside that house.

255
00:22:17,800 --> 00:22:30,120
Yeah, also, that's a good example. A lot of companies are, I think, a few I work with,

256
00:22:31,000 --> 00:22:41,320
there are, yeah, there are, how should I say nice? Well, I make that, I ask other than the question,

257
00:22:41,320 --> 00:22:46,200
how much should organization customize Microsoft's reference architecture from your perspective?

258
00:22:46,200 --> 00:22:51,560
Sorry, KKK, you repeat the last part? I lost you, I apologize.

259
00:22:51,560 --> 00:22:57,240
How much should organization customize Microsoft's reference architectures?

260
00:22:58,200 --> 00:23:04,840
How much they should customize it? Yeah. Well, that depends a bit on their case,

261
00:23:04,840 --> 00:23:11,480
but I would say in an enterprise organization, if you take the Microsoft enterprise lending zone,

262
00:23:11,480 --> 00:23:19,000
it's a very good starting point. It is very generic. And I think if you're part of an enterprise

263
00:23:19,000 --> 00:23:25,320
organization, you should always customize it to your needs because it is not designed as a

264
00:23:25,320 --> 00:23:31,400
tailor fit. It is designed to, if you're not sure how to start, where to start, that you are at

265
00:23:31,400 --> 00:23:41,880
least starting from a good solid foundation, which provides reasonable levels of security

266
00:23:41,880 --> 00:23:48,680
in compliance for you. But I would say anything, any organization that is an enterprise organization

267
00:23:48,680 --> 00:23:55,720
should take that base and should build on top of that and create their own version of that.

268
00:23:55,720 --> 00:24:02,280
It's like with ice cream, everybody loves vanilla, right? But I'm pretty sure most of us have

269
00:24:02,280 --> 00:24:07,640
their own tailored taste that we like. So I would do the same comparison here as well. It's good to

270
00:24:07,640 --> 00:24:15,560
start with vanilla if you're unsure, but as soon as you grow into your next maturity level,

271
00:24:15,560 --> 00:24:21,080
which regards to cloud, that would be definitely the first thing to do is start thinking, okay,

272
00:24:21,080 --> 00:24:27,080
how can I customize it? And it's for two reasons, I would say. One is to make sure that security

273
00:24:27,080 --> 00:24:33,880
compliance that your organization needs to abide to because of regulatory, etc, is

274
00:24:33,880 --> 00:24:39,720
very often custom tailored to your specific business. And the second part is the one that I already

275
00:24:39,720 --> 00:24:47,640
mentioned, to get the most out of your cloud, you need to understand what the business drivers

276
00:24:47,640 --> 00:24:54,680
are for your cloud. So listen to your product teams, your workload teams on what they need and focus

277
00:24:54,680 --> 00:25:09,000
on that. That would be my feedback on that. And how has Microsoft guidance involved over the past?

278
00:25:09,560 --> 00:25:17,000
few years you've worked in with Azure Islandings on? When I started, it was very poor. I'm

279
00:25:17,000 --> 00:25:25,000
going to be honest. It was very poor. So figuring things out was quite difficult. And I'm talking about

280
00:25:25,000 --> 00:25:35,320
more than 10 years ago. So for example, Microsoft was at that point, I think also very

281
00:25:38,280 --> 00:25:46,440
in a discovery phase, okay, what do we want with it? What's it's a great set of services that we have,

282
00:25:46,440 --> 00:25:53,240
but in which direction are we going to bring them? A good example, way, way back. There was a movement

283
00:25:53,240 --> 00:26:00,680
where Microsoft said, we don't want you to use subscriptions. Please do as much as possible in

284
00:26:00,680 --> 00:26:06,600
resource groups. And there's still a use case to do this. So don't get me wrong. It's not a

285
00:26:06,600 --> 00:26:12,760
fundamentally wrong thing if you do it consciously. But these days, the trend is to use subscriptions

286
00:26:12,760 --> 00:26:20,280
to separate like environments because they contain natural boundaries, which you cannot pack,

287
00:26:20,280 --> 00:26:28,280
you cannot make a mistake with configuration, etc. So these kind of guidance, way, way back,

288
00:26:28,280 --> 00:26:35,880
was the opposite of what the people that were actually using Azure were doing. However,

289
00:26:35,880 --> 00:26:41,880
this has been streamed right, especially in the last three years. The cloud adoption framework is

290
00:26:41,880 --> 00:26:49,080
super mature. The examples that are there are the enterprise lending zone is really a good starting

291
00:26:49,080 --> 00:26:56,760
point. And I think my most favorite one that I think shows like the mature, the biggest growth in

292
00:26:56,760 --> 00:27:04,360
maturity from Microsoft stack is the very Azure Verified modules. So these are modules either in

293
00:27:04,360 --> 00:27:11,880
by supporting Terraform that Microsoft provides official support about if you have a Microsoft

294
00:27:11,880 --> 00:27:18,200
support for your environment and you're using the Verified modules, date to my knowledge,

295
00:27:18,200 --> 00:27:26,200
provide the same support, SLA, etc. for those modules as well, where you can literally take

296
00:27:26,200 --> 00:27:32,200
infrastructure code modules that are maintained by Microsoft in combination the community

297
00:27:32,200 --> 00:27:38,680
and deploy them and use them to deploy your own workloads, which is I think like the amazing step.

298
00:27:38,680 --> 00:27:47,960
Yeah, I have started the last week with the Microsoft Cloud Adopture Framework course on learning.

299
00:27:47,960 --> 00:27:54,680
Yeah, the Cloud Adopture Framework is comprehensive, but also intimidating.

300
00:27:54,680 --> 00:27:57,000
It's a bit of a bible, all right.

301
00:28:01,080 --> 00:28:07,560
Do you introduce the cloud adapter framework to organization without overrunning them?

302
00:28:07,560 --> 00:28:19,480
With care. Well, Cloud Adopture Framework is broken up into different, different parts.

303
00:28:19,480 --> 00:28:26,280
So they have one for Greenfield, they have quite a lot for Brownfield and then it's broken up into

304
00:28:26,280 --> 00:28:33,880
getting the business case, it has an area for setting up the team structures,

305
00:28:33,880 --> 00:28:40,600
management, organization, etc. And finally, they like for me the bread and butter,

306
00:28:40,600 --> 00:28:44,040
what I really like about it is the design areas.

307
00:28:44,040 --> 00:28:51,640
And so what I try to do is not to introduce them, hey, this is the Cloud Adopture Framework.

308
00:28:51,640 --> 00:28:59,320
Here, please read this 500 plus pages, which is way too much, even if you use like an MCP server AI,

309
00:28:59,320 --> 00:29:07,320
whatever to go through it, it's still too much. So architects I introduced to them, for example,

310
00:29:07,320 --> 00:29:14,600
design areas and we start with some core design areas because the number is quite,

311
00:29:14,600 --> 00:29:21,240
is still quite complex and security for those I introduced to the security design area.

312
00:29:21,240 --> 00:29:29,400
And operations, folks usually to the management or the DevOps design area or combination of both

313
00:29:29,400 --> 00:29:36,440
a bit. So I give them their own little piece of the puzzle and when they are

314
00:29:36,440 --> 00:29:42,600
I have consumed it and get used to it, then we zoom out a little bit and zoom out a little bit.

315
00:29:45,560 --> 00:29:53,640
That would be my suggestion and if you're talking about an organization setup, how would I do this?

316
00:29:53,640 --> 00:30:01,080
The first step is to form something called a CCOE and manage this knowledge distribution from

317
00:30:01,080 --> 00:30:11,480
there, which is the Clouds I always forget where the, basically your Cloud enablement.

318
00:30:15,480 --> 00:30:25,240
We think about either the CFOE or so ask, where did you see the framework or which areas

319
00:30:25,240 --> 00:30:28,600
in the framework deliver the quickest business value?

320
00:30:28,600 --> 00:30:36,200
Which areas of the framework deliver the quickest business value? Well, it depends a bit on your

321
00:30:36,200 --> 00:30:41,720
business case, why you're going to Azure. If your business case is to

322
00:30:43,800 --> 00:30:51,400
empty your data center because otherwise you'll need to let's say within a year, everything is out

323
00:30:51,400 --> 00:30:58,680
of support or something like that. So you need to quickly move out of the data center.

324
00:30:58,680 --> 00:31:06,040
Then the area with regards to how would I lift and shift, basically as much as possible or if

325
00:31:06,040 --> 00:31:13,560
where we have traditional work through machines would gain the biggest business value.

326
00:31:13,560 --> 00:31:21,320
If you're going to Azure for innovation, then obviously the easiest answer to that is AI,

327
00:31:21,320 --> 00:31:28,920
but I would say in combination with data and platform as a service services.

328
00:31:28,920 --> 00:31:36,760
So it depends on the business case from which area you the company goes. For startups,

329
00:31:38,360 --> 00:31:44,360
platform as a service services are the best ones because with Azure functions, you can create certain

330
00:31:44,360 --> 00:31:50,120
logic, Azure function logic apps combinations, you can create certain solutions which will

331
00:31:50,120 --> 00:31:55,400
give you tremendous value and have an operational cost of less than 10 euros a month.

332
00:31:55,400 --> 00:32:05,400
They have also, I have here a book, and I will read it, the error well-identified to the framework.

333
00:32:05,400 --> 00:32:10,840
Is this the same or is it something other?

334
00:32:10,840 --> 00:32:17,880
There well architected framework is exist side by side with the Cloud Adoption Framework.

335
00:32:17,880 --> 00:32:25,800
So the Adoption Framework introduces you into Azure like, okay, how would I adopt?

336
00:32:25,800 --> 00:32:31,960
And this is in line with some previous questions that you asked with regards to, okay,

337
00:32:32,920 --> 00:32:40,120
how would you adopt Azure properly? Adoption framework doesn't just speak about technology part.

338
00:32:40,120 --> 00:32:45,400
It speaks about people and processes. What processes do I need to adapt? How do they need to be

339
00:32:45,400 --> 00:32:54,120
adapted? How do I do operations? How do I, what kind of profiles do I need from people to upskill them?

340
00:32:54,120 --> 00:32:59,000
How does the work over traditional subchanges now?

341
00:32:59,000 --> 00:33:06,040
He or she needs to do things through code. So it's much more comprehensive than just the technology.

342
00:33:06,040 --> 00:33:16,040
The well architected framework actually focuses primarily on the technology and how to design it

343
00:33:16,040 --> 00:33:28,440
architecturally sound, not just the platform, but also there's a super great focus on workload

344
00:33:28,440 --> 00:33:34,520
design reference architectures. There are some advise advisory recommendation

345
00:33:34,520 --> 00:33:42,600
assessments that you can do for yourself. So it is more technology focused and it zooms in,

346
00:33:42,600 --> 00:33:48,760
okay, when you are ready with your adoption and you want to build your first technology part,

347
00:33:48,760 --> 00:33:53,480
how can you build them properly without building that data center that we talked about?

348
00:33:55,880 --> 00:34:14,120
I think or can we understand the framework as an operation model or it's more a documentation,

349
00:34:14,120 --> 00:34:24,360
I don't know. There is a explanation in the adoption framework on the target operating

350
00:34:24,360 --> 00:34:30,920
models that can be that are viable in Azure. You can have a centralized team etc. Again,

351
00:34:30,920 --> 00:34:36,920
that depends a bit on your business case why you can move to Azure. So I wouldn't say that the

352
00:34:36,920 --> 00:34:48,120
well architected framework is the operating model. It is more, so it is more on how to do things

353
00:34:48,120 --> 00:34:55,560
right. For example, it contains six pillars, reliability, so it reliability, let's say you want a certain

354
00:34:55,560 --> 00:35:03,320
service and you want to provide a high level SLA with great reliability. How do I do that? What do I

355
00:35:03,320 --> 00:35:12,600
need? Just deploying let's say a VM doesn't make it reliable, maybe SQL set is good or maybe I need a

356
00:35:12,600 --> 00:35:19,800
failover in a different region, just a couple of use cases. So reliability pillar explains based on

357
00:35:19,800 --> 00:35:26,440
the specific resources that you use. How can I ensure that the workload meets the uptime and

358
00:35:26,440 --> 00:35:32,520
recovery targets? There is a security area that talks about protecting that workload from

359
00:35:32,520 --> 00:35:40,520
attacks from a certain level of attacks. Let's say I'm a government organization with Azure

360
00:35:40,520 --> 00:35:50,920
and I'm a very high state target for foreign attackers. They need to probably take care of focus on

361
00:35:50,920 --> 00:35:57,560
different security aspects than a startup, right? And then you have cost optimization, operational

362
00:35:57,560 --> 00:36:03,880
excellence and performance efficiency. And cost optimization, everybody would love to reduce their

363
00:36:03,880 --> 00:36:13,240
Azure bill. So that's a great way to start. An operational excellence basically tells you how to

364
00:36:13,240 --> 00:36:20,920
build observability monitoring in an automated system. And finally perform performance efficiency,

365
00:36:20,920 --> 00:36:30,360
latency stuff like that, gentle testing, scaling, chaos, engineering stuff like that that comes into

366
00:36:30,360 --> 00:36:38,040
mind with. So it really explains to you how to build those infrastructure resources and not

367
00:36:38,040 --> 00:36:47,880
so much on how to operate the whole thing. Yeah, I think yeah, say a governance security is also

368
00:36:47,880 --> 00:37:04,440
good words we can talk about. Sorry. That's something as a policy. What role do you play in

369
00:37:04,440 --> 00:37:14,680
every environment? Asher policy. So basically those are your guardrails. Those are your guardrails

370
00:37:14,680 --> 00:37:23,880
with regards to doing certain things, disallowing certain things, monitoring certain things,

371
00:37:23,880 --> 00:37:35,560
and final one, fixing certain things. And personally, the most fundamental one is when we deploy

372
00:37:35,560 --> 00:37:42,520
something in Azure, let's say for Europe right now, it's a very important topic that we don't

373
00:37:42,520 --> 00:37:50,200
deploy certain things outside the European economic region, right? So Azure policy plays here as a

374
00:37:50,200 --> 00:37:56,840
a guardrail and enjoying if you configure an Azure policy does is you only allow to deploy in

375
00:37:56,840 --> 00:38:01,240
let's say Sweden, Germany and West Europe, which is Netherlands,

376
00:38:01,240 --> 00:38:08,200
practically speaking. So when you try to deploy something, you get an error, second,

377
00:38:08,200 --> 00:38:14,840
hey, you're not allowed to deploy in those regions. So that's the most fundamental one. But in my opinion,

378
00:38:14,840 --> 00:38:23,560
the Azure policies are so much more so you have something called a remediation policy or the

379
00:38:23,560 --> 00:38:31,560
policy state called deploy if not exist. And I think this is where policy not just plays a guardrail,

380
00:38:32,280 --> 00:38:40,200
but an active helper to your application teams workload engineers. If you configure these kind

381
00:38:40,200 --> 00:38:46,440
of policies, correct? You can do things, for example, let's say I have a web app and my policy

382
00:38:46,440 --> 00:38:56,440
make sure that when a web app is the pool point, it is deployed over SSL. So it's CTS and not

383
00:38:58,520 --> 00:39:06,200
not an on secure connection. We everybody would like that, right? But we don't want to focus on every team

384
00:39:06,200 --> 00:39:12,120
taking care of that themselves. So we can create a remediation policy or deploy over that exists

385
00:39:12,120 --> 00:39:20,600
policy that when a team deploys runs a deployment, which deploys a web app, it will automatically check if

386
00:39:20,600 --> 00:39:27,880
the check check box for SSL is enabled. And if it's not enabled, it will enable that for the developer.

387
00:39:27,880 --> 00:39:34,920
So the developer in this case or the engineer is not bothered. And this is a very simple thing.

388
00:39:34,920 --> 00:39:39,480
They should be bothered with, but there are more complex options, complex scenarios. They're not

389
00:39:39,480 --> 00:39:46,200
bothered with the compliance things. They know their platform takes care of them, not just by saying,

390
00:39:46,200 --> 00:39:51,720
policing them around saying you're not allowed to do this, but actually helping them to do the right

391
00:39:51,720 --> 00:40:06,040
team. And what misconceptions have companies often, when they come to GAWA and secure Azure?

392
00:40:06,040 --> 00:40:17,480
What misconceptions they have? The biggest misconception in my opinion, and this depends a bit on the

393
00:40:17,480 --> 00:40:22,120
maturity of the organization, but let's say they're relatively new to Azure. So in traditional data

394
00:40:22,120 --> 00:40:28,120
center thinking is still there. And traditional data center thinking is we will want everything needs

395
00:40:28,120 --> 00:40:33,400
to be network integrated. And second, we will use network as a primary security program.

396
00:40:33,400 --> 00:40:43,080
If we, Azure is built on zero trust concepts and there are many variations, definitions of zero trust,

397
00:40:43,080 --> 00:40:49,080
but the easiest way if you want to know what Microsoft think about is there's a whole white paper for

398
00:40:49,080 --> 00:40:56,280
Microsoft on zero trust in Azure. So I suggest Google that one and read it. But what it says is

399
00:40:56,280 --> 00:41:04,040
identity is the primary security perimeter. So with regards to security compliance, this is the

400
00:41:04,040 --> 00:41:11,080
first and the biggest misconception. If you focus just on networking, it will not be enough because

401
00:41:11,080 --> 00:41:19,880
you're no longer protected by a physical data center with all kinds of break person, even physically

402
00:41:19,880 --> 00:41:29,960
a access control system with a security guard who sits there, etc. You are running your services

403
00:41:29,960 --> 00:41:37,000
in your own landing zones, but it is still public cloud. So because it's public cloud,

404
00:41:37,000 --> 00:41:45,960
identity is a much more important security perimeter than networking is. So just

405
00:41:45,960 --> 00:41:53,240
putting everything network integrated and saying now I am secure is just going to make

406
00:41:53,240 --> 00:41:59,800
your Azure very expensive and you're moving. This is one of those steps of building a data center

407
00:41:59,800 --> 00:42:06,760
in Azure. Sure, there are areas that need additional security layers. Those you network integrate

408
00:42:07,320 --> 00:42:17,480
when you actually have reason to do so. When you don't, please don't focus on the identity part

409
00:42:17,480 --> 00:42:22,520
because any resource in Azure when you enable network integration for those, especially the

410
00:42:22,520 --> 00:42:32,200
past resources, you automatically need more expensive or in some cases the most expensive SKU for that,

411
00:42:32,200 --> 00:42:39,240
which is going to cost you a lot of money, you will feel secure, but you are not really, you're not

412
00:42:39,240 --> 00:42:45,240
you're not as secure as you would think you are if you would compare it to a traditional data center.

413
00:42:45,240 --> 00:42:55,240
And what role do you do is infrastructure code as code apply in the governance risk and compliance

414
00:42:55,240 --> 00:43:06,680
topic? Well, infrastructure code helps in a way that well first it is traceable. So if you,

415
00:43:06,680 --> 00:43:13,960
especially if you do with bicep the deployments, you're deploying through the Azure resource engine,

416
00:43:13,960 --> 00:43:21,960
the air engine, which tracks all the deployments that you have done. There's a lot of logging available

417
00:43:21,960 --> 00:43:31,400
on activity log, who did deployment or which managed identity or even traditional

418
00:43:31,400 --> 00:43:37,560
app registration that the deployments or it helps you to trace on who did the deployment and what

419
00:43:37,560 --> 00:43:45,240
got deployed because you can check out which kind of bicep files, for example,

420
00:43:46,520 --> 00:43:52,440
used to do the deployment or which configurations were changed. That's the first one, but because it is

421
00:43:52,440 --> 00:44:01,960
code, it enables us to adapt security much earlier than when the resource is already deployed in Azure.

422
00:44:01,960 --> 00:44:08,200
Let's say we don't have that Azure policy that enforces SSL on our web app.

423
00:44:09,160 --> 00:44:17,880
When we find out that it's not there, we're already too late. So this is the mindset part. We will

424
00:44:17,880 --> 00:44:24,520
be reacting and we would theoretically maybe have a leak or we would need a security department to

425
00:44:24,520 --> 00:44:30,120
verify that there was maybe an exfiltration that took place because SSL was not enabled.

426
00:44:30,120 --> 00:44:38,200
So what we can do is because it is already defined as code, we can verify certain things

427
00:44:38,840 --> 00:44:46,440
through the code, we can do static code analysis, we can do the whole well-architected practice checks

428
00:44:46,440 --> 00:44:54,360
while the resource, let's say this web app is still defining code, which reduces the risk of

429
00:44:54,360 --> 00:45:04,440
misconfiguration being applied to the actual resource. We will find and test and fix our misconfiguration

430
00:45:04,440 --> 00:45:11,720
before we deploy things in Azure, which is the shift-left approach. That's the biggest plus for

431
00:45:11,720 --> 00:45:17,160
infrastructure code when it comes to security and blind to my opinion.

432
00:45:17,160 --> 00:45:28,440
Another topic is, I don't know, but I heard a lot of companies say we want self-service cloud platforms.

433
00:45:29,880 --> 00:45:40,360
What would that actually look like? How does a self-service look like? Again, here it depends on the

434
00:45:40,360 --> 00:45:47,880
type of company that you are. If you are a company that has 900 developers where you have a lot of

435
00:45:47,880 --> 00:45:58,840
self-built code that you maintain, which is or business value to you, then a self-service looks

436
00:45:58,840 --> 00:46:09,560
more from a developer portal where you help the developer to deploy the code in the right way.

437
00:46:09,560 --> 00:46:18,520
You can have, for example, triage where a developer deploy has developed a piece of code and you run

438
00:46:18,520 --> 00:46:25,320
it in a container. Let's use that as an example. You can help the developer to a self-service where they

439
00:46:25,320 --> 00:46:34,440
can select what's the best run time for the code is. It can be a full-blown AKS as you can

440
00:46:34,440 --> 00:46:42,440
be in a service, but that's a platform on each home. But you can also run that code as a container

441
00:46:42,440 --> 00:46:48,440
in an app service or container instances and there are a couple of more of these choices that you

442
00:46:48,440 --> 00:46:57,240
can make. So if your organization's developer-heavy, helping developers making this choice and helping them with

443
00:46:57,240 --> 00:47:04,120
which Azure Verified Module already helps us with a lot, helping them with already building

444
00:47:04,120 --> 00:47:12,600
blocks to get started, that's where the self-service comes in. However, if your organization is more

445
00:47:12,600 --> 00:47:22,600
static, they run off the shelf, commercial off the shelf applications, then you'll much more

446
00:47:22,600 --> 00:47:30,840
the organization will be more helpful from a self-service perspective on how to operate, how to

447
00:47:30,840 --> 00:47:39,240
use disaster recovery for these kind of commercial off the shelf applications because often those

448
00:47:39,240 --> 00:47:47,560
applications run in virtual machines. So in the focus, self-service comes more in, okay, how can we help

449
00:47:47,560 --> 00:47:56,120
these teams to use the right SKU to maybe shut down the virtual machines to disaster recovery,

450
00:47:56,120 --> 00:48:02,520
help them how to do in-place restores and stuff like that. And the focus is more on the

451
00:48:04,280 --> 00:48:11,880
auto-making traditional operational procedures and not so much on helping them with infrastructure

452
00:48:11,880 --> 00:48:18,040
code. So it depends a bit and these are two like extremes, there are a lot of scenarios in between.

453
00:48:18,040 --> 00:48:27,720
If you have, for example, very mature teams, developer teams, say in first example,

454
00:48:27,720 --> 00:48:33,480
then what they want is they want to be left alone as much as possible, just give them a

455
00:48:33,480 --> 00:48:40,200
definition on guardrails and give them as much self-service on the platform part. So a very mature

456
00:48:40,200 --> 00:48:47,560
team usually loves to have a self-service with regards to firewall rules. They can configure that

457
00:48:47,560 --> 00:48:55,400
and not be dependent on a central platform teams. So these are like P3E examples that I would

458
00:48:56,360 --> 00:49:05,480
I don't know if you want more. This is so, that's okay, thank you. What did you think,

459
00:49:05,480 --> 00:49:15,160
how do Azure DevOps or the end get fit into platform engineering?

460
00:49:15,160 --> 00:49:22,360
Into platform engineering, well, the first part I think in platform engineering is practice for

461
00:49:22,360 --> 00:49:29,240
you preach, in your own dog, food, etc. So whatever you build, you need to consume and run it yourself.

462
00:49:29,240 --> 00:49:38,760
So here Azure DevOps or GitHub is a good addition because whatever you build as code,

463
00:49:38,760 --> 00:49:47,080
you can figure and deploy and run it yourself. Which regards to Azure DevOps, I think

464
00:49:48,600 --> 00:49:53,960
well, the focus is on GitHub as DevOps is definitely at least to my current knowledge while we're

465
00:49:53,960 --> 00:49:58,920
recording. I don't know how it will be in the future. It's not a good platform, it's just a second

466
00:49:58,920 --> 00:50:07,080
if they will get their features slightly later, slightly delayed, but they're pros and cons to

467
00:50:07,080 --> 00:50:14,920
both platforms. So what often happens, which regards to Azure DevOps is the platform that we talked

468
00:50:14,920 --> 00:50:22,280
about, gets extended. So you don't get just those four subscriptions that we talked when purely Azure

469
00:50:22,280 --> 00:50:27,240
as your application learning zone, you also get an Azure DevOps project, for example.

470
00:50:27,240 --> 00:50:36,520
And the Azure DevOps project enables the platform engineers to provide the application teams

471
00:50:36,520 --> 00:50:42,280
with ready service connections and ready pipelines already configured with the right permissions,

472
00:50:42,280 --> 00:50:50,360
right scopes to deploy from day one, deploy their code. They enable platform engineers to

473
00:50:50,360 --> 00:51:00,360
provide demo setups or pre-built, let's say pre-approved in some organizations, do that,

474
00:51:00,360 --> 00:51:07,080
pre-approved building blocks. I would still based them on the verified modules, but I've seen

475
00:51:07,080 --> 00:51:11,960
combinations where organization provide them with pre-approved building blocks of things that

476
00:51:11,960 --> 00:51:20,520
they cannot do. So it's more of an extension of Azure where you run your pipelines,

477
00:51:20,520 --> 00:51:27,320
a piece of compute, you can abuse those pipelines to create a piece of compute.

478
00:51:27,320 --> 00:51:35,240
And I think they're like a storage vault for all the blueprints of everything that you do in Azure.

479
00:51:39,160 --> 00:51:50,760
And what does your meaning show platform team think like of developers as customers?

480
00:51:50,760 --> 00:52:02,280
Yes, I think so. In an organization where developers, where the organization has a lot of

481
00:52:02,280 --> 00:52:09,400
developers that deploy their service, yes, then developers are their customers. Because

482
00:52:09,400 --> 00:52:22,280
in my opinion, if my platform doesn't satisfy my developers, obviously with guardrails,

483
00:52:22,280 --> 00:52:32,200
then it's either a failed platform or a hobby. Because if we unpack on the hobby part a little bit,

484
00:52:33,000 --> 00:52:38,680
a hobby doesn't have, doesn't generate business value. That's my definition of hobby. It's a

485
00:52:38,680 --> 00:52:44,760
fun thing. I can build a fun cool project that completely doesn't make any sense to anybody else,

486
00:52:44,760 --> 00:52:50,360
just for me. And it creates a lot of joy for me, but it doesn't generate business value. And

487
00:52:50,360 --> 00:52:55,000
obviously there are successful hobbies that generated a lot of business value to people,

488
00:52:55,000 --> 00:53:05,800
but in a basis, they don't. So if we take, if you would Google right now on what is Azure, you'll end up

489
00:53:05,800 --> 00:53:13,000
on Microsoft article. And that article says Azure is our combination of services that provides certain

490
00:53:13,000 --> 00:53:18,200
things. And the final part of that sentence, I think the sentence is still there. I haven't checked

491
00:53:18,200 --> 00:53:24,920
it for a while, but I would assume it's still there. It's the sentence ends with which you can use

492
00:53:24,920 --> 00:53:32,920
to build your solution workloads with the tools of your choice. And that last part is I think is

493
00:53:32,920 --> 00:53:40,760
something that platform engineers should shoot like take as their guiding line as their core reference.

494
00:53:40,760 --> 00:53:49,880
We need to support the developers to do what they need with their tool choice. And that doesn't

495
00:53:49,880 --> 00:53:56,680
mean that everybody can use any kind of tool on an Azure platform. You can still like put guardrails

496
00:53:56,680 --> 00:54:05,160
around it, pre select certain tools, but in the basis, when that happens, let's say, we have three

497
00:54:05,160 --> 00:54:14,040
main developer languages. Let's say we support Python, Java and all that. Then we need as a platform

498
00:54:14,040 --> 00:54:21,000
engineers to ensure that developers that use those tools, those languages are comfortable that they

499
00:54:21,000 --> 00:54:28,200
would love to use the platform that we built otherwise for who are we building that platform.

500
00:54:28,200 --> 00:54:41,640
Also, I think a topic when we talk platforms, what do you think about the IDPs in the

501
00:54:41,640 --> 00:54:48,920
initial developer platforms? Is this the future? Sorry, what do you mean with IDPs? I'm always

502
00:54:48,920 --> 00:55:01,320
careful with the internal developer platforms. It's I have the all the time one on YouTube and

503
00:55:01,320 --> 00:55:10,760
LinkedIn. Oh, yeah. Well, there is an anti pattern in the cloud adoption framework defined.

504
00:55:11,320 --> 00:55:19,320
And it's, well, it's not an anti pattern. It's defined as a conscious choice that you need to make

505
00:55:19,320 --> 00:55:28,280
and something to be aware of. So I kind of see this as an anti pattern. So if internal development

506
00:55:28,280 --> 00:55:39,720
platform provides additional value on top of what Azure portal provides great, but there's very

507
00:55:39,720 --> 00:55:54,280
how to say this slippery slope that's a lot of IDPs are not doing right. So they're basically

508
00:55:54,280 --> 00:56:03,080
slipping. They want to compete with portal.azure.call. And you will always fail because Microsoft has

509
00:56:03,080 --> 00:56:08,840
the biggest number of developers, engineers and focus. And they are also the ones in control of

510
00:56:08,840 --> 00:56:17,720
the portal. So whatever tooling you build, you need to think of how can it have on top as an

511
00:56:17,720 --> 00:56:24,840
additional value, which is specific to your organization, to your developers, and not try to just

512
00:56:24,840 --> 00:56:32,200
copy the Azure portal and combine certain things in automation because you will always lose.

513
00:56:32,200 --> 00:56:39,160
Microsoft will change things, will modify things and you'll be competing with something that your

514
00:56:39,160 --> 00:56:46,760
organization already bought and paid for, which is portal.azure.call. So I don't think they're the

515
00:56:46,760 --> 00:56:55,160
future. I think they are a good addition for certain specific use cases, but does every organization

516
00:56:55,160 --> 00:57:01,240
need them? No, definitely not. If you have the commercial of the shelf applications, I don't think

517
00:57:02,040 --> 00:57:09,480
a full-blown internal developer, developer, or will be of added value to you as an organization.

518
00:57:09,480 --> 00:57:16,120
You'll probably have more than enough with a GitHub Azure DevOps combination with your Azure portal.

519
00:57:16,120 --> 00:57:23,480
Where you do your discovery in the Azure portal, where you do certain visual things in your Azure

520
00:57:23,480 --> 00:57:32,440
portal, dashboard, etc. And you do everything as code in your GitHub or Azure DevOps.

521
00:57:32,440 --> 00:57:44,360
Yeah, oh, we are. Oh, it's really now. Okay. Then, yeah, how the impact of AI, I think, Microsoft,

522
00:57:44,360 --> 00:57:51,800
of every AI, how big is the impact from AI on your side as Cloud Engineer?

523
00:57:51,800 --> 00:58:06,600
So for me, because I have been growing up as a Cloud Engineer, Architect, etc. For me,

524
00:58:06,600 --> 00:58:16,440
I love AI is especially GitHub co-pilot and my huge fan of that because I can do, let's say,

525
00:58:16,440 --> 00:58:24,840
my work eight times faster, at least, at least. So it enables me to do so much more work.

526
00:58:24,840 --> 00:58:32,920
That would be my biggest one for junior engineers.

527
00:58:34,360 --> 00:58:41,720
It's a blessing in a curse, in my opinion, because we all know AI lies. Even GitHub co-pilot

528
00:58:41,720 --> 00:58:49,560
sometimes hallucinates and says certain weird things like, you know, bicep, having a certain function

529
00:58:49,560 --> 00:58:56,040
that simply doesn't exist, but it saw it in Terraform. So it made the assumption that it probably

530
00:58:56,040 --> 00:59:02,760
exists there or it read some blog posts from somebody who's still reviewing things, etc. So

531
00:59:03,560 --> 00:59:10,120
I can relatively easy see, hey, now it's lying to me, this is not possible. I can correct it and say,

532
00:59:10,120 --> 00:59:19,160
hey, you're doing things that shouldn't be done. For a junior, they have a much tougher time

533
00:59:19,160 --> 00:59:27,800
in figuring out that they were sent into the wrong direction. Awesome. Yeah, so I have an

534
00:59:27,800 --> 00:59:35,240
every session and rapid fire round. I give a short sentence and you give a full answer.

535
00:59:35,240 --> 00:59:39,240
Cool. So Azure or hybrid?

536
00:59:39,240 --> 00:59:47,720
bicep or Terraform? bicep. GitHub or Azure DevOps?

537
00:59:47,720 --> 00:59:53,560
That's difficult one. I have to choose.

538
00:59:55,080 --> 00:59:59,320
Yeah, that's okay. You can't take both. I have to love both.

539
00:59:59,320 --> 01:00:05,720
This is purely experienced bias from myself, is Azure DevOps.

540
01:00:05,720 --> 01:00:08,680
Okay. See your portal.

541
01:00:08,680 --> 01:00:11,080
It's still like.

542
01:00:11,080 --> 01:00:13,640
I'm going to show them all obvious code.

543
01:00:13,640 --> 01:00:14,920
We use code.

544
01:00:14,920 --> 01:00:17,080
Gemolo Jason.

545
01:00:17,080 --> 01:00:21,720
I was in digs and all the way. People are going to hate me for this.

546
01:00:24,280 --> 01:00:25,240
HeinecgoerGroge.

547
01:00:25,240 --> 01:00:27,640
HeinecgoerGroals?

548
01:00:27,640 --> 01:00:28,280
Groals.

549
01:00:28,280 --> 01:00:31,480
Your favorite Azure service?

550
01:00:31,480 --> 01:00:34,760
My favorite Azure service, API management.

551
01:00:34,760 --> 01:00:37,800
The most underrated Azure future.

552
01:00:37,800 --> 01:00:40,600
Underrated.

553
01:00:40,600 --> 01:00:45,480
Deny assignments.

554
01:00:45,480 --> 01:00:48,120
I hope people know what it is.

555
01:00:48,120 --> 01:00:51,880
Yeah, awesome. Thank you.

556
01:00:51,880 --> 01:00:57,640
So, yeah, if listeners remember only one message from today's session, what should it be?

557
01:00:57,640 --> 01:01:01,400
I'll take the boring.

558
01:01:01,400 --> 01:01:10,840
Okay. And finally, who will you nominate as feature guest on the ANSI65 podcast?

559
01:01:10,840 --> 01:01:13,160
And what is the one question I should ask then?

560
01:01:13,160 --> 01:01:16,120
Who I would nominate?

561
01:01:16,120 --> 01:01:20,280
Yeah. It's like.

562
01:01:20,920 --> 01:01:25,240
Oh, that's a tough one.

563
01:01:25,240 --> 01:01:29,960
Can I nominate like anybody?

564
01:01:29,960 --> 01:01:31,240
Yeah.

565
01:01:31,240 --> 01:01:35,240
I have a colleague that I work with.

566
01:01:35,240 --> 01:01:40,120
Am I okay with saving names and everything?

567
01:01:40,120 --> 01:01:41,400
Yeah.

568
01:01:41,400 --> 01:01:41,880
Yeah.

569
01:01:41,880 --> 01:01:43,480
And I can link them.

570
01:01:43,480 --> 01:01:49,880
Okay. You can ask Mike Berman.

571
01:01:50,840 --> 01:01:51,240
Okay.

572
01:01:51,240 --> 01:01:56,280
And I would say the tough question is,

573
01:01:56,280 --> 01:02:03,800
how do we do sovereignty within the Microsoft domain?

574
01:02:03,800 --> 01:02:08,040
I try if I get them.

575
01:02:08,040 --> 01:02:13,160
Yeah. So, yeah, Jeff, thank you for joining me today on the ANSI65 podcast.

576
01:02:13,160 --> 01:02:18,680
Yeah, we explored Azure platform engineering, the lending zones, the Microsoft cloud and

577
01:02:18,680 --> 01:02:24,120
the option framework, yeah, infrastructure as code governance, automation,

578
01:02:24,120 --> 01:02:27,400
the developer platforms, and the future of enterprise cloud architecture.

579
01:02:27,400 --> 01:02:30,040
So, yeah, thank you for being here.

580
01:02:30,040 --> 01:02:33,240
This was a really deep dive episode.

581
01:02:33,240 --> 01:02:35,880
I thank you so much for staying here with me.

582
01:02:35,880 --> 01:02:36,680
Oh, well, now we're.

583
01:02:36,680 --> 01:02:37,720
So, thank you so much.

584
01:02:37,720 --> 01:02:41,160
My account was in my pleasure.

585
01:02:41,160 --> 01:02:42,040
Thank you very much.

586
01:02:42,040 --> 01:02:43,400
I enjoyed it back and full wide.

587
01:02:43,400 --> 01:02:45,960
I didn't even realize I thought we were like halfway through still.

588
01:02:47,080 --> 01:02:48,600
Great questions. Thank you so much.

589
01:02:48,600 --> 01:02:51,000
Thank you. Bye.

590
01:02:51,000 --> 01:03:15,120
[signature sounds]