Welcome back to another edition of the M365 podcast.
Today's episode is all about building Azure the right way.
Many organizations have migrated to Azure,
but creating a cloud platform that is secure,
scalable, automated, and the developer friendly is
a completely different challenge.
Jeff is a cloud architect specializing in
Azure platform engineering,
Azure landing zones, infrastructure as a code,
platform engineering, Azure DevOps,
and Michael of Cloud on that two framework is also an
active community contributor through blogging,
YouTube, and speaking.
Today we will discuss how enterprise
should build Azure platforms that
develop us equally love to use while keeping
governance and security under control.
Welcome to the M65.
Jeff.
Thank you very much.
Thanks for having me.
Yeah.
For listeners meeting you the first time.
Who is the F Strhoy outside of Microsoft technology?
Outside of Microsoft technology,
that's an interesting question.
Well, both inside and outside of Microsoft technology,
I would say I'm the guy that likes to pick things apart.
I've done so as a kid when my parents gave me a toy or something,
like a remote control car.
I remember the first thing I did instead of driving it,
I found the screwdrivers from my dad,
and this is a remote holding,
curious on how it works.
And I still do that.
It's a bit easier to do that in Azure,
where you can delete stuff that you've broken.
Obviously the toy in this case got broken and I ended up
crying because it didn't work anymore.
So I tried to learn from these things also outside of
the Microsoft area.
So what I usually love to do is to work with my hands.
I'm a big fan of creating furniture and anything would relate it actually.
And how did you find into the Microsoft ecosystem?
Well, that's I guess by luck or by fate,
whatever you want to call it.
Originally, I'm actually a GIS specialist.
I'm pretty sure most of the listeners are not familiar with this term.
It's called geospatial information systems,
which is basically the mapping, the anything map related.
So I started out as a geospatial information systems consultant.
And I ran into on a certain project into a guy who was working
with Microsoft technology.
So we were doing the backend to all mapping.
And this guy built the websites, the portals and everything.
And when I worked with him together, I saw what he was doing.
I was like, oh my god, this is cool.
I want to do this as well.
So I figure out in which company he worked.
And I just called them out is like, I don't know what needs to be done,
but I want to be do it to do whatever this guy does.
So that's how I started with Microsoft technology.
Basically, they got me into a spot as a dot net developer.
So that's how my journey started.
Yeah, I think as well has also a map skills,
yeah, the services, right?
Yeah.
And I like this is this is the the the main thing about Azure.
It's huge.
I would love to meet the person that knows all the services.
And he goes for me, I know quite a number of them, but not all of them.
And maps is always eluded me.
I've never had in the last almost 15 plus years.
I never had a project where I was able to do anything with the map service.
So maybe maybe it's my curse.
When you look back, what project thought you the biggest lesson in your career?
The biggest lesson, that's the ones where we make the biggest mistakes
and the most painful ones, I would say.
For me, if we talk like just the career perspective,
not Azure specific or within Microsoft domain,
I think my biggest lesson was that I am a very mediocre.net developer.
What meant that I, I, I, so I like to be competitive.
I like to be as good as I can get.
And in dot net that's never happened.
So that ended up with a bit frustration, but like with any kind of frustration,
you can get something cool and beautiful out of it.
So when I had that frustration, I noticed that's,
there's at the company at, I was at that point,
it was like a huge gap, like two big islands, the classic infrastructure people,
because this was like pre-cloud error, like close to cloud getting started and
everything, but just pre-cloud error and application,
dot net developers, any kind of other.
And I, I thought about this like, well, if I, if I'm a mediocre developer,
maybe I'm gonna be a better infrastructure guy.
So I switched to infrastructure, obviously not overnight.
And I took all the, all the lessons that I learned in being a developer with me.
And I would say that was my biggest learning moment,
at least is I realized that infrastructure engineers had no clue on
the standards and best practices and they were not benefiting from them.
And so I evolved into that direction and I believe we call this DevOps these days.
Yeah, you have to say, the other services, but yeah,
the good thing is Microsoft rename it a regular, so it makes more simpler for people.
And yeah, the other good thing is the cloud technology change,
incredible fast.
How do you stay ahead with our burning out?
Oh yeah, that's, that's a challenge.
I would say if you want to be what I like to call ahead of the curve,
it needs to be a lifestyle.
It cannot be a just a job.
So what drives me is that curiosity, like opening up the,
looking how the car, the remote control car work,
I still have the same thing with Azure.
So whenever something new comes up, I would like to see if I can find the screws
and unscrew it and look how it runs, what the inside are.
So that's my main motivator to not burn up from a practical perspective.
My day starts after I wake up, I start looking through some new feeds,
articles that I have on my phone.
Okay, while we were sleepy and the US was awake, what new stuff did they release?
And then I make a selection on which topics are closer to my heart,
or maybe topics that I'm working on one of my clients and go deep into those.
Because I would say the, now talking about it, I'm realizing that
the second factor of not like burning out or going in same is it needs a purpose.
So in my case, if a client has a problem, a challenge,
I get super hyper focused and excited to see if I can solve that as as effective as possible.
Okay, that's interesting.
So you have this knife style.
So you do it so, so, so long.
How do you keep exciting to work so many years with Azure?
How it's, I don't know, actually, they come up, Microsoft comes up with interesting services.
Quite often and services that are available are being reiterated as well.
Sure, there are some things that I consider boring, but for me,
that landscape is so fast that it still keeps me entertained.
And if I get bored with something, I like to see if we can,
or I can set up the same automation, but in different areas.
So for example, a colleague of mine was working on M365.
And at a certain point, I was like, yeah, I need something else to do.
It's slightly different focus and he asked me like, well, how would you set up M365?
And then I figured out that there's a whole open source project, which is called M365DC,
desire state configuration.
So which is basically infrastructure code, but for M365.
So I dove into that, figured out how it worked, looked at the concepts and everything,
and helped him set it up, which was kind of like a holiday or a break for me to not work on Azure.
When so when I returned back to working on Azure, it felt fresh and new again as well.
Awesome. Yeah, I don't have a platform engineering.
I think that's one of the, yeah, actually hardest topic in cloud computing.
How will you explain platform engineering to someone who's only family or
with traditional infrastructure teams?
Yeah, that's a good one.
Platform engineering is, I would say your building standardized, sell service tools.
I would like sum it up into that.
It's understood.
So there are two aspects to it.
One is you build you standardized everything as much as possible.
So any kind of repeat you want to automate and
standardize it into something that can be reusable.
A second point, which is completely different to traditional infrastructure self-service.
So you build something that another team can use without relying on your availability expertise, etc,
which helps you also to scale obviously.
And the final one I would say is a common is a bit of having understanding and knowledge
of what a platform needs to do.
And often our platforms are built for developers.
I consider as a platform specialist that's my main consumer is the developer.
So I try to keep a track of what developers do the way their practices are.
So I would say if I would have to explain it, that's a combination of those three things,
those practices.
Like DevOps is also a practice.
I would say platform engineering is to a certain extent also.
A practice of those three.
So then we have, I think we have to stop only moving workloads to Azure, right?
Can you elaborate on that a bit?
Yeah, I think a lot of companies say, okay, we are on prem.
And now we move all to Azure.
What's wrong on the thinking?
Ah, yeah, like that.
Yes, yes, and well, the fundamental mistake that happens here is thinking that Azure or any other
cloud platform, but I know most about Azure, so I'll stick with that is a data center.
It's not a data center and you should not treat it as well.
I think that's the most fundamental, the biggest mistake or anti-pattern that exists
when we're talking about moving workloads, applications, anything to Azure.
If you consider it a data center, you can build Azure into a data center,
but then you're not really reinventing yourself, getting the max, the most of what a cloud platform is,
and you're making it extremely expensive because building things in the way a data center is hyper
optimized for on-premise infrastructure. A cloud is not optimized for that. It never will be.
It is much, much more than that, so you technically can do it, but it will not bring you the benefits
of why you usually go to Azure.
And what separates a good cloud platform from a great one from your perspective?
A good one from a great one.
Yeah.
I think a good one is automated, and well, follows basically like Microsoft's cloud adoption
framework standards, etc. A great one understands the business need that the developers,
that are or the workload or the application teams, whether you want to call them,
that are using a platform. So it's tailor fit to that specific business case.
Because taking a generic enterprise landing zone and deploying it,
that can be done relatively fast, especially with everything that is now available in
Lysap in Terraform, for even in their DRSD case for Python and Pulumni.
So that's a good one. That one fits all the criteria, but taking that one and tailor fitting it
to your organization's specific needs, that makes it a great one.
Did you see some, what's the biggest architectural mistakes you see organization do when they
are starbaths as a reduction?
Thinking that, well, it's not, if it's okay, I'll broaden the question a little bit, it's not
just architecture. I think the biggest mistake is thinking it's a technology exercise.
It's not. It's an adoption exercise, actually, which means that it's people process technology.
And in those three technologies, often the easiest one. You can hire great engineers, consultants,
etc, especially if your budget allows for it and they will build the technology. But if the rest
of your organization isn't ready for the modern ways of working, that go hand in hand
with a modern way of doing clouds, so not the traditional data center one, you will never be successful.
Because your organization will rub against the processes that are needed to run your cloud.
So a very simple example in a cloud, you want to be proactive instead of reactive, often
traditional systems, IK-SEM kind of systems, they work with incidents. Ideally in a cloud,
if you set this, it's things up into a great platform, you're working majority of the times
proactive, you prevent things by having certain environments like, for example, a canary environment,
which stem from the canary in the coal mine that miners like in the 1800s used to take victim to make
sure that their options general levels are still okay. If something happened to the birds, they could
safely get out. If you don't adapt these kind of principles, which is primarily a people and processes
adoption, then you'll run into even more trouble than you have in your traditional
and param systems with traditional processes. Yeah, let's a little bit talk about the
Azure Landings on topic, or let's not run you to the concept, what exactly is the Azure Landings on?
That's a good question. In layman's terms, so actually have our awesome blog post,
if I say so, how did myself? Let me see if I can paraphrase it in less than two minutes instead of
15 minutes. In layman's terms and application, let's roll back. Microsoft calls everything a lending
zone. This is where you mentioned Microsoft rename certain things. The naming can always be improved
on because if everything is a lending zone, how do you know what is what? If you let's take it from
the outside and peel it layer by layer. At first, you have the Azure Landings on. This is your whole
Azure environment. Traditionally, we used to call this a tenant, but the tenant practically doesn't exist.
That contains everything. It contains the core services that are needed for your applications
to be able to run for your lending zones, application lending zones, wants to function, etc. So those
core services, they are called the platform lending zone. That's usually security, management,
networking, and identity. So the service is that everybody rely on this regard. They are called
the platform lending zone. They are built conceptually the same way. That's why it's called a
lending zone every time. This is one of the, if I can add on your previous question, things that you
can do fundamentally wrong. If you don't build it that way, that they're fundamentally the same,
or conceptually the same, this is going to give you a bit more challenges. Speaking of the platform
lending zones, the platform lending zone is clear. Next, the bread and butter, why you do all of this
setup are something called the application lending zones. And those are depending on how many
applications you have. And an application lending zone is basically a set of Azure subscriptions,
depending on how your environments are and the current standard is having at least one subscription
Azure subscription for environment. Those subscriptions are pre-prapped by your platform team to provide
you with utilities. And those utilities is your own virtual network, maybe a key vault storage
account, some logging, log analytics workspace, depending on your constraints. And because those
subscriptions live in a, have a certain purpose, you usually have some Azure policies depending on
let's say GDPR or any other compliance security compliance regulations applied on top of them.
That combined is what we call technically a application lending zone. So if we would translate that
into layman's terms, look at it this way, you are your application lending zone is a house.
And your water electricity, et cetera, those are also utilities. So the utilities that I just
mentioned, like virtual network, maybe a key vault, depending on the configuration storage account,
a place to do your security and other kind of logging are also your utilities.
So you get a house, the house is maybe multiple floors or multiple rooms,
those floors you could see as subscriptions, the rooms could be seen as resource groups, one layer,
one-depth layer lower, and that house is part of a neighborhood. And that neighborhood is then
service by the platform lending zone, which contains security, contains management. So somebody
takes care of the sidewalk, somebody takes care of the road. So the lanterns that you can walk
here when it's dark. And so conceptually, it's a house that's placed inside a neighborhood. And
finally, you have a team that operates that house, your workload team, your application team,
and those are your people that live inside that house.
Yeah, also, that's a good example. A lot of companies are, I think, a few I work with,
there are, yeah, there are, how should I say nice? Well, I make that, I ask other than the question,
how much should organization customize Microsoft's reference architecture from your perspective?
Sorry, KKK, you repeat the last part? I lost you, I apologize.
How much should organization customize Microsoft's reference architectures?
How much they should customize it? Yeah. Well, that depends a bit on their case,
but I would say in an enterprise organization, if you take the Microsoft enterprise lending zone,
it's a very good starting point. It is very generic. And I think if you're part of an enterprise
organization, you should always customize it to your needs because it is not designed as a
tailor fit. It is designed to, if you're not sure how to start, where to start, that you are at
least starting from a good solid foundation, which provides reasonable levels of security
in compliance for you. But I would say anything, any organization that is an enterprise organization
should take that base and should build on top of that and create their own version of that.
It's like with ice cream, everybody loves vanilla, right? But I'm pretty sure most of us have
their own tailored taste that we like. So I would do the same comparison here as well. It's good to
start with vanilla if you're unsure, but as soon as you grow into your next maturity level,
which regards to cloud, that would be definitely the first thing to do is start thinking, okay,
how can I customize it? And it's for two reasons, I would say. One is to make sure that security
compliance that your organization needs to abide to because of regulatory, etc, is
very often custom tailored to your specific business. And the second part is the one that I already
mentioned, to get the most out of your cloud, you need to understand what the business drivers
are for your cloud. So listen to your product teams, your workload teams on what they need and focus
on that. That would be my feedback on that. And how has Microsoft guidance involved over the past?
few years you've worked in with Azure Islandings on? When I started, it was very poor. I'm
going to be honest. It was very poor. So figuring things out was quite difficult. And I'm talking about
more than 10 years ago. So for example, Microsoft was at that point, I think also very
in a discovery phase, okay, what do we want with it? What's it's a great set of services that we have,
but in which direction are we going to bring them? A good example, way, way back. There was a movement
where Microsoft said, we don't want you to use subscriptions. Please do as much as possible in
resource groups. And there's still a use case to do this. So don't get me wrong. It's not a
fundamentally wrong thing if you do it consciously. But these days, the trend is to use subscriptions
to separate like environments because they contain natural boundaries, which you cannot pack,
you cannot make a mistake with configuration, etc. So these kind of guidance, way, way back,
was the opposite of what the people that were actually using Azure were doing. However,
this has been streamed right, especially in the last three years. The cloud adoption framework is
super mature. The examples that are there are the enterprise lending zone is really a good starting
point. And I think my most favorite one that I think shows like the mature, the biggest growth in
maturity from Microsoft stack is the very Azure Verified modules. So these are modules either in
by supporting Terraform that Microsoft provides official support about if you have a Microsoft
support for your environment and you're using the Verified modules, date to my knowledge,
provide the same support, SLA, etc. for those modules as well, where you can literally take
infrastructure code modules that are maintained by Microsoft in combination the community
and deploy them and use them to deploy your own workloads, which is I think like the amazing step.
Yeah, I have started the last week with the Microsoft Cloud Adopture Framework course on learning.
Yeah, the Cloud Adopture Framework is comprehensive, but also intimidating.
It's a bit of a bible, all right.
Do you introduce the cloud adapter framework to organization without overrunning them?
With care. Well, Cloud Adopture Framework is broken up into different, different parts.
So they have one for Greenfield, they have quite a lot for Brownfield and then it's broken up into
getting the business case, it has an area for setting up the team structures,
management, organization, etc. And finally, they like for me the bread and butter,
what I really like about it is the design areas.
And so what I try to do is not to introduce them, hey, this is the Cloud Adopture Framework.
Here, please read this 500 plus pages, which is way too much, even if you use like an MCP server AI,
whatever to go through it, it's still too much. So architects I introduced to them, for example,
design areas and we start with some core design areas because the number is quite,
is still quite complex and security for those I introduced to the security design area.
And operations, folks usually to the management or the DevOps design area or combination of both
a bit. So I give them their own little piece of the puzzle and when they are
I have consumed it and get used to it, then we zoom out a little bit and zoom out a little bit.
That would be my suggestion and if you're talking about an organization setup, how would I do this?
The first step is to form something called a CCOE and manage this knowledge distribution from
there, which is the Clouds I always forget where the, basically your Cloud enablement.
We think about either the CFOE or so ask, where did you see the framework or which areas
in the framework deliver the quickest business value?
Which areas of the framework deliver the quickest business value? Well, it depends a bit on your
business case, why you're going to Azure. If your business case is to
empty your data center because otherwise you'll need to let's say within a year, everything is out
of support or something like that. So you need to quickly move out of the data center.
Then the area with regards to how would I lift and shift, basically as much as possible or if
where we have traditional work through machines would gain the biggest business value.
If you're going to Azure for innovation, then obviously the easiest answer to that is AI,
but I would say in combination with data and platform as a service services.
So it depends on the business case from which area you the company goes. For startups,
platform as a service services are the best ones because with Azure functions, you can create certain
logic, Azure function logic apps combinations, you can create certain solutions which will
give you tremendous value and have an operational cost of less than 10 euros a month.
They have also, I have here a book, and I will read it, the error well-identified to the framework.
Is this the same or is it something other?
There well architected framework is exist side by side with the Cloud Adoption Framework.
So the Adoption Framework introduces you into Azure like, okay, how would I adopt?
And this is in line with some previous questions that you asked with regards to, okay,
how would you adopt Azure properly? Adoption framework doesn't just speak about technology part.
It speaks about people and processes. What processes do I need to adapt? How do they need to be
adapted? How do I do operations? How do I, what kind of profiles do I need from people to upskill them?
How does the work over traditional subchanges now?
He or she needs to do things through code. So it's much more comprehensive than just the technology.
The well architected framework actually focuses primarily on the technology and how to design it
architecturally sound, not just the platform, but also there's a super great focus on workload
design reference architectures. There are some advise advisory recommendation
assessments that you can do for yourself. So it is more technology focused and it zooms in,
okay, when you are ready with your adoption and you want to build your first technology part,
how can you build them properly without building that data center that we talked about?
I think or can we understand the framework as an operation model or it's more a documentation,
I don't know. There is a explanation in the adoption framework on the target operating
models that can be that are viable in Azure. You can have a centralized team etc. Again,
that depends a bit on your business case why you can move to Azure. So I wouldn't say that the
well architected framework is the operating model. It is more, so it is more on how to do things
right. For example, it contains six pillars, reliability, so it reliability, let's say you want a certain
service and you want to provide a high level SLA with great reliability. How do I do that? What do I
need? Just deploying let's say a VM doesn't make it reliable, maybe SQL set is good or maybe I need a
failover in a different region, just a couple of use cases. So reliability pillar explains based on
the specific resources that you use. How can I ensure that the workload meets the uptime and
recovery targets? There is a security area that talks about protecting that workload from
attacks from a certain level of attacks. Let's say I'm a government organization with Azure
and I'm a very high state target for foreign attackers. They need to probably take care of focus on
different security aspects than a startup, right? And then you have cost optimization, operational
excellence and performance efficiency. And cost optimization, everybody would love to reduce their
Azure bill. So that's a great way to start. An operational excellence basically tells you how to
build observability monitoring in an automated system. And finally perform performance efficiency,
latency stuff like that, gentle testing, scaling, chaos, engineering stuff like that that comes into
mind with. So it really explains to you how to build those infrastructure resources and not
so much on how to operate the whole thing. Yeah, I think yeah, say a governance security is also
good words we can talk about. Sorry. That's something as a policy. What role do you play in
every environment? Asher policy. So basically those are your guardrails. Those are your guardrails
with regards to doing certain things, disallowing certain things, monitoring certain things,
and final one, fixing certain things. And personally, the most fundamental one is when we deploy
something in Azure, let's say for Europe right now, it's a very important topic that we don't
deploy certain things outside the European economic region, right? So Azure policy plays here as a
a guardrail and enjoying if you configure an Azure policy does is you only allow to deploy in
let's say Sweden, Germany and West Europe, which is Netherlands,
practically speaking. So when you try to deploy something, you get an error, second,
hey, you're not allowed to deploy in those regions. So that's the most fundamental one. But in my opinion,
the Azure policies are so much more so you have something called a remediation policy or the
policy state called deploy if not exist. And I think this is where policy not just plays a guardrail,
but an active helper to your application teams workload engineers. If you configure these kind
of policies, correct? You can do things, for example, let's say I have a web app and my policy
make sure that when a web app is the pool point, it is deployed over SSL. So it's CTS and not
not an on secure connection. We everybody would like that, right? But we don't want to focus on every team
taking care of that themselves. So we can create a remediation policy or deploy over that exists
policy that when a team deploys runs a deployment, which deploys a web app, it will automatically check if
the check check box for SSL is enabled. And if it's not enabled, it will enable that for the developer.
So the developer in this case or the engineer is not bothered. And this is a very simple thing.
They should be bothered with, but there are more complex options, complex scenarios. They're not
bothered with the compliance things. They know their platform takes care of them, not just by saying,
policing them around saying you're not allowed to do this, but actually helping them to do the right
team. And what misconceptions have companies often, when they come to GAWA and secure Azure?
What misconceptions they have? The biggest misconception in my opinion, and this depends a bit on the
maturity of the organization, but let's say they're relatively new to Azure. So in traditional data
center thinking is still there. And traditional data center thinking is we will want everything needs
to be network integrated. And second, we will use network as a primary security program.
If we, Azure is built on zero trust concepts and there are many variations, definitions of zero trust,
but the easiest way if you want to know what Microsoft think about is there's a whole white paper for
Microsoft on zero trust in Azure. So I suggest Google that one and read it. But what it says is
identity is the primary security perimeter. So with regards to security compliance, this is the
first and the biggest misconception. If you focus just on networking, it will not be enough because
you're no longer protected by a physical data center with all kinds of break person, even physically
a access control system with a security guard who sits there, etc. You are running your services
in your own landing zones, but it is still public cloud. So because it's public cloud,
identity is a much more important security perimeter than networking is. So just
putting everything network integrated and saying now I am secure is just going to make
your Azure very expensive and you're moving. This is one of those steps of building a data center
in Azure. Sure, there are areas that need additional security layers. Those you network integrate
when you actually have reason to do so. When you don't, please don't focus on the identity part
because any resource in Azure when you enable network integration for those, especially the
past resources, you automatically need more expensive or in some cases the most expensive SKU for that,
which is going to cost you a lot of money, you will feel secure, but you are not really, you're not
you're not as secure as you would think you are if you would compare it to a traditional data center.
And what role do you do is infrastructure code as code apply in the governance risk and compliance
topic? Well, infrastructure code helps in a way that well first it is traceable. So if you,
especially if you do with bicep the deployments, you're deploying through the Azure resource engine,
the air engine, which tracks all the deployments that you have done. There's a lot of logging available
on activity log, who did deployment or which managed identity or even traditional
app registration that the deployments or it helps you to trace on who did the deployment and what
got deployed because you can check out which kind of bicep files, for example,
used to do the deployment or which configurations were changed. That's the first one, but because it is
code, it enables us to adapt security much earlier than when the resource is already deployed in Azure.
Let's say we don't have that Azure policy that enforces SSL on our web app.
When we find out that it's not there, we're already too late. So this is the mindset part. We will
be reacting and we would theoretically maybe have a leak or we would need a security department to
verify that there was maybe an exfiltration that took place because SSL was not enabled.
So what we can do is because it is already defined as code, we can verify certain things
through the code, we can do static code analysis, we can do the whole well-architected practice checks
while the resource, let's say this web app is still defining code, which reduces the risk of
misconfiguration being applied to the actual resource. We will find and test and fix our misconfiguration
before we deploy things in Azure, which is the shift-left approach. That's the biggest plus for
infrastructure code when it comes to security and blind to my opinion.
Another topic is, I don't know, but I heard a lot of companies say we want self-service cloud platforms.
What would that actually look like? How does a self-service look like? Again, here it depends on the
type of company that you are. If you are a company that has 900 developers where you have a lot of
self-built code that you maintain, which is or business value to you, then a self-service looks
more from a developer portal where you help the developer to deploy the code in the right way.
You can have, for example, triage where a developer deploy has developed a piece of code and you run
it in a container. Let's use that as an example. You can help the developer to a self-service where they
can select what's the best run time for the code is. It can be a full-blown AKS as you can
be in a service, but that's a platform on each home. But you can also run that code as a container
in an app service or container instances and there are a couple of more of these choices that you
can make. So if your organization's developer-heavy, helping developers making this choice and helping them with
which Azure Verified Module already helps us with a lot, helping them with already building
blocks to get started, that's where the self-service comes in. However, if your organization is more
static, they run off the shelf, commercial off the shelf applications, then you'll much more
the organization will be more helpful from a self-service perspective on how to operate, how to
use disaster recovery for these kind of commercial off the shelf applications because often those
applications run in virtual machines. So in the focus, self-service comes more in, okay, how can we help
these teams to use the right SKU to maybe shut down the virtual machines to disaster recovery,
help them how to do in-place restores and stuff like that. And the focus is more on the
auto-making traditional operational procedures and not so much on helping them with infrastructure
code. So it depends a bit and these are two like extremes, there are a lot of scenarios in between.
If you have, for example, very mature teams, developer teams, say in first example,
then what they want is they want to be left alone as much as possible, just give them a
definition on guardrails and give them as much self-service on the platform part. So a very mature
team usually loves to have a self-service with regards to firewall rules. They can configure that
and not be dependent on a central platform teams. So these are like P3E examples that I would
I don't know if you want more. This is so, that's okay, thank you. What did you think,
how do Azure DevOps or the end get fit into platform engineering?
Into platform engineering, well, the first part I think in platform engineering is practice for
you preach, in your own dog, food, etc. So whatever you build, you need to consume and run it yourself.
So here Azure DevOps or GitHub is a good addition because whatever you build as code,
you can figure and deploy and run it yourself. Which regards to Azure DevOps, I think
well, the focus is on GitHub as DevOps is definitely at least to my current knowledge while we're
recording. I don't know how it will be in the future. It's not a good platform, it's just a second
if they will get their features slightly later, slightly delayed, but they're pros and cons to
both platforms. So what often happens, which regards to Azure DevOps is the platform that we talked
about, gets extended. So you don't get just those four subscriptions that we talked when purely Azure
as your application learning zone, you also get an Azure DevOps project, for example.
And the Azure DevOps project enables the platform engineers to provide the application teams
with ready service connections and ready pipelines already configured with the right permissions,
right scopes to deploy from day one, deploy their code. They enable platform engineers to
provide demo setups or pre-built, let's say pre-approved in some organizations, do that,
pre-approved building blocks. I would still based them on the verified modules, but I've seen
combinations where organization provide them with pre-approved building blocks of things that
they cannot do. So it's more of an extension of Azure where you run your pipelines,
a piece of compute, you can abuse those pipelines to create a piece of compute.
And I think they're like a storage vault for all the blueprints of everything that you do in Azure.
And what does your meaning show platform team think like of developers as customers?
Yes, I think so. In an organization where developers, where the organization has a lot of
developers that deploy their service, yes, then developers are their customers. Because
in my opinion, if my platform doesn't satisfy my developers, obviously with guardrails,
then it's either a failed platform or a hobby. Because if we unpack on the hobby part a little bit,
a hobby doesn't have, doesn't generate business value. That's my definition of hobby. It's a
fun thing. I can build a fun cool project that completely doesn't make any sense to anybody else,
just for me. And it creates a lot of joy for me, but it doesn't generate business value. And
obviously there are successful hobbies that generated a lot of business value to people,
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
on Microsoft article. And that article says Azure is our combination of services that provides certain
things. And the final part of that sentence, I think the sentence is still there. I haven't checked
it for a while, but I would assume it's still there. It's the sentence ends with which you can use
to build your solution workloads with the tools of your choice. And that last part is I think is
something that platform engineers should shoot like take as their guiding line as their core reference.
We need to support the developers to do what they need with their tool choice. And that doesn't
mean that everybody can use any kind of tool on an Azure platform. You can still like put guardrails
around it, pre select certain tools, but in the basis, when that happens, let's say, we have three
main developer languages. Let's say we support Python, Java and all that. Then we need as a platform
engineers to ensure that developers that use those tools, those languages are comfortable that they
would love to use the platform that we built otherwise for who are we building that platform.
Also, I think a topic when we talk platforms, what do you think about the IDPs in the
initial developer platforms? Is this the future? Sorry, what do you mean with IDPs? I'm always
careful with the internal developer platforms. It's I have the all the time one on YouTube and
LinkedIn. Oh, yeah. Well, there is an anti pattern in the cloud adoption framework defined.
And it's, well, it's not an anti pattern. It's defined as a conscious choice that you need to make
and something to be aware of. So I kind of see this as an anti pattern. So if internal development
platform provides additional value on top of what Azure portal provides great, but there's very
how to say this slippery slope that's a lot of IDPs are not doing right. So they're basically
slipping. They want to compete with portal.azure.call. And you will always fail because Microsoft has
the biggest number of developers, engineers and focus. And they are also the ones in control of
the portal. So whatever tooling you build, you need to think of how can it have on top as an
additional value, which is specific to your organization, to your developers, and not try to just
copy the Azure portal and combine certain things in automation because you will always lose.
Microsoft will change things, will modify things and you'll be competing with something that your
organization already bought and paid for, which is portal.azure.call. So I don't think they're the
future. I think they are a good addition for certain specific use cases, but does every organization
need them? No, definitely not. If you have the commercial of the shelf applications, I don't think
a full-blown internal developer, developer, or will be of added value to you as an organization.
You'll probably have more than enough with a GitHub Azure DevOps combination with your Azure portal.
Where you do your discovery in the Azure portal, where you do certain visual things in your Azure
portal, dashboard, etc. And you do everything as code in your GitHub or Azure DevOps.
Yeah, oh, we are. Oh, it's really now. Okay. Then, yeah, how the impact of AI, I think, Microsoft,
of every AI, how big is the impact from AI on your side as Cloud Engineer?
So for me, because I have been growing up as a Cloud Engineer, Architect, etc. For me,
I love AI is especially GitHub co-pilot and my huge fan of that because I can do, let's say,
my work eight times faster, at least, at least. So it enables me to do so much more work.
That would be my biggest one for junior engineers.
It's a blessing in a curse, in my opinion, because we all know AI lies. Even GitHub co-pilot
sometimes hallucinates and says certain weird things like, you know, bicep, having a certain function
that simply doesn't exist, but it saw it in Terraform. So it made the assumption that it probably
exists there or it read some blog posts from somebody who's still reviewing things, etc. So
I can relatively easy see, hey, now it's lying to me, this is not possible. I can correct it and say,
hey, you're doing things that shouldn't be done. For a junior, they have a much tougher time
in figuring out that they were sent into the wrong direction. Awesome. Yeah, so I have an
every session and rapid fire round. I give a short sentence and you give a full answer.
Cool. So Azure or hybrid?
bicep or Terraform? bicep. GitHub or Azure DevOps?
That's difficult one. I have to choose.
Yeah, that's okay. You can't take both. I have to love both.
This is purely experienced bias from myself, is Azure DevOps.
Okay. See your portal.
It's still like.
I'm going to show them all obvious code.
We use code.
Gemolo Jason.
I was in digs and all the way. People are going to hate me for this.
HeinecgoerGroge.
HeinecgoerGroals?
Groals.
Your favorite Azure service?
My favorite Azure service, API management.
The most underrated Azure future.
Underrated.
Deny assignments.
I hope people know what it is.
Yeah, awesome. Thank you.
So, yeah, if listeners remember only one message from today's session, what should it be?
I'll take the boring.
Okay. And finally, who will you nominate as feature guest on the ANSI65 podcast?
And what is the one question I should ask then?
Who I would nominate?
Yeah. It's like.
Oh, that's a tough one.
Can I nominate like anybody?
Yeah.
I have a colleague that I work with.
Am I okay with saving names and everything?
Yeah.
And I can link them.
Okay. You can ask Mike Berman.
Okay.
And I would say the tough question is,
how do we do sovereignty within the Microsoft domain?
I try if I get them.
Yeah. So, yeah, Jeff, thank you for joining me today on the ANSI65 podcast.
Yeah, we explored Azure platform engineering, the lending zones, the Microsoft cloud and
the option framework, yeah, infrastructure as code governance, automation,
the developer platforms, and the future of enterprise cloud architecture.
So, yeah, thank you for being here.
This was a really deep dive episode.
I thank you so much for staying here with me.
Oh, well, now we're.
So, thank you so much.
My account was in my pleasure.
Thank you very much.
I enjoyed it back and full wide.
I didn't even realize I thought we were like halfway through still.
Great questions. Thank you so much.
Thank you. Bye.
[signature sounds]