Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP]

What happens when your cloud strategy cannot live entirely in the public cloud? Organizations are modernizing infrastructure with Azure, platform services, Infrastructure as Code, automated deployment pipelines, and Azure Landing Zones. At the same time, some workloads still need to remain close to factories, offices, regulated environments, existing infrastructure, or latency-sensitive systems. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Klarskov Jakobsen about how Azure Local can become part of a broader Azure architecture rather than another isolated on-premises platform. They explore Azure Local, Azure Landing Zones, Azure Arc, governance, Infrastructure as Code, Bicep, Azure DevOps, modernization, and the realities of building hybrid cloud environments.

WHAT IS AZURE LOCAL?
Azure Local combines familiar infrastructure technologies with Azure-based management, governance, and security capabilities. At its core, organizations can run workloads such as virtual machines locally while connecting the environment back to Azure. Christoffer explains that the major difference compared with a traditional Windows Server environment is the Azure experience surrounding the infrastructure. Organizations can keep workloads and data locally while using Azure capabilities to manage and govern the environment.

IS AZURE LOCAL JUST AZURE IN YOUR DATA CENTER?
Not exactly. Azure provides a significantly larger catalog of cloud services, but Azure Local can bring selected Azure experiences closer to local infrastructure. Christoffer discusses running virtual machines and Kubernetes on Azure Local as well as scenarios involving SQL Managed Instance and Azure Virtual Desktop. The result isn't a complete copy of Azure running inside your building. It's a hybrid platform combining local compute requirements with selected Azure services and management capabilities.

WHEN DOES AZURE LOCAL MAKE SENSE?
Several scenarios stand out. Organizations may have regulatory requirements requiring data to remain locally. Others need extremely low latency between applications, machines, factories, or other infrastructure. Some organizations simply have workloads that cannot yet move completely into the public cloud. Christoffer also sees increasing potential around local AI workloads, including scenarios where organizations need AI capabilities while maintaining local control over their data.

AZURE LOCAL IS A LOCAL CLOUD
One of the important architectural lessons from the conversation is that Azure Local shouldn't be treated as simply another pair of servers. The environment includes multiple infrastructure and Azure-connected layers. Organizations therefore need people who understand the underlying hardware and operating technologies as well as Azure management. Christoffer describes Azure Local as effectively operating a local cloud rather than simply installing another traditional virtualization cluster.

WHY AZURE LANDING ZONES MATTER
Moving workloads into Azure doesn't automatically create a well-designed cloud environment. Organizations need structure, security boundaries, governance, permissions, networking, logging, and clear separation between workloads. Azure Landing Zones provide an architectural approach for establishing those foundations. Instead of placing unrelated applications, development environments, production systems, networking components, and shared services inside the same subscription, organizations establish clearer boundaries around workloads and responsibilities.

THINK DIFFERENTLY ABOUT AZURE SUBSCRIPTIONS
A subscription shouldn't simply become a container for everything an organization deploys. Christoffer recommends thinking about subscriptions as boundaries for specific environments and workloads. A development environment can have its own subscription. Testing can have another. Production can have another.

Welcome everybody back to the M665 podcast.

Today we are tackling a question that becomes

incredible, important as organization,

when they are modernized, when you modernize your infrastructure.

What happens when your cloud strategy can't live internally

in the public cloud?

Azure has evolved, far beyond virtual machines,

running in Microsoft data centers.

Organizations are adopting cloud from services,

infrastructure, the code automated, deployment, pipelines,

Azure landing zones, while at the same time some workloads

still need to remain physical, close to factories,

offers regulated environments, or existing infrastructure.

That's where Azure Local become particular interesting.

My guest today is Christoher Clarkson, Yard Copson,

Microsoft MVP Azure Specialist at Fellow Mind in Denmark,

Christoher designs and implements Azure Solutions work,

especially with Azure Local, Azure landing zones,

Azure DevOps, PowerShell and Biceps,

and has a strong focus on modern,

rising security, automated, and infrastructure as a code.

Today we are deep dive into how Azure Local fits

into the Azure landing zone strategy,

how organization can merge cloud and local infrastructure

constantly, and while Christoher believes many companies

are missing some of the possible Azure Local providers.

Christoher, welcome to the MC65 podcast.

Thank you.

Thank you so much.

Yeah. Before we get deep into Azure Local,

how did your own journey into Microsoft technology began?

Yeah, so I have been working with Microsoft Technology Stack

for many years, I think, 15 years or so,

started all the way back when I was a student,

and I got to my first company working there,

so part-time in school and part-time at this company,

that's how that education worked.

And that was all Microsoft, so back in the day,

that was a lot of Windows Server was working on that.

And then I've been working a lot of years,

and then they used hosting provider,

did that for around eight years,

that was also based on Microsoft Windows servers.

And then for, yeah, I think four years now,

when we're going to implement, that is a company

that focused entirely on the cloud,

so that's naturally we are going to be focused on Azure,

since we're going to implement this Microsoft partner.

So yeah, I've been working with Microsoft for a lot of years,

actually,

maybe on Windows servers.

But then recently, just more about the cloud also,

and hybrid cloud, as you can call it.

Yeah, I look a little bit when you do add photo,

mind, you are involved in both an Azure solution

and actually also implemented them.

How important is this for architect to remain hands-on?

I think if you ask some of my colleagues,

maybe not that much thought, but for me,

personally, I always want to be hands-on,

because I feel like I cannot design solutions

and write the whole design dark

and write the implementation phases

if I do not know how to implement it,

because I think if anyone that has been implementing stuff

knows that, you know, Sunday night at 2 a.m,

shit stops working and what we need to do

to fix it, that is where you get the hands-on experience

that cannot be all written in the design phases,

because sometimes you just, some,

yeah, problem emerges that you did not,

was aware of.

So I feel like hands-on is very important for me,

just to stay current with how do we actually deploy

and migrate and modernize our customers'

application and their workloads in general.

Yeah, you have described modernization

from the traditional VM-based infrastructure

to about past and zas,

as a particular interest.

Why are so many organizations still heavily

depend on virtual machines?

Yeah, I think we see it in both in our Danish customers,

but also in, we have a lot of international customers as well,

and I think that there are two main reasons,

at least from my perspective, one of the reasons

that many of the customers are running some applications

that is very old, so we can call them legacy applications,

you know, 20, 20 years old applications that

must run on a virtual machine, cannot run,

and modern pass-based SQL Server.

The other part is actually the IT department

that those companies, if they feel confident in Windows Server,

they feel confident that they can install applications

on a Windows Server, sometimes they are actually also hesitant

to get into the past area,

and that is also, I don't know if you can call this,

stalling, but it's dragging the modernization to pass also

because we almost always find an application

that could run on a pass,

but that just didn't because this ECF for the IT department

to install it on a Windows Server.

Awesome, interesting, but let's establish the foundation.

What does it look?

Yeah, what is actually looking?

I think some would say it's just Hyper-V

and some are stores best-direct, it's just old technology,

but for me, really there is a lot more to it, so of course,

down at the core, we have some functionalities from Windows Server,

we have the Hyper-V, we have the storage-based direct

for when we're doing hyper-convicts stores,

we can, as of recently, we can also use external storage,

same-based storage, so that doesn't call components

in oscillators that are very similar to a normal Windows Server

technology you can deploy in one virtual machine.

But then they also have that whole,

Microsoft has this component in it called Microsoft Online Cloud,

and on that one's something called an Azure Local in Bridge,

and so that is some key components that is running locally,

this Azure Local Environment, but has the connection to Azure,

so we can use the management plan in Azure,

we can use security and governance features from Azure,

and it comes directly down to the cluster.

So for me, the main difference between Azure Local and a normal

Windows Server environment is that we get so much of the Azure experience

out of the box, we do not have to do a whole lot of manual configuration

if we deploy our Azure Local MSIS on our servers,

connect it to Azure and configure the cluster.

We are actually good to go, and we can run a lot of resources

on our local environment, keeping our data locally,

complying with whatever regulations need it,

and have that sovereignty that some customers are asking for.

Is it correct to think of Azure Local as simply Azure

in your data center or is that too simple?

In some ways, yes, of course, if you look at how many different

products or services you can run in Azure Cloud,

that number is huge compared to what you can actually run on Azure Local,

because you can run virtual machines on Azure Local,

you can run Kubernetes cluster on Azure Local,

and especially on top of the Kubernetes, of course,

there you can run all sorts of different services,

one services that is actually able to deploy

from your support on Azure Local is a SQL Managed Instance.

You have to deploy the Kubernetes cluster,

you have to deploy something called an Arc Data Controller,

but once you have those components on your cluster,

on Azure Local cluster, you can actually deploy in a SQL Managed Instance,

and you get the same look and feel as if you are deploying that service in Azure.

And I do believe that more of these past services

will also come in the future.

One other area that's also very nice and have been there for quite some time now is the

possibility to use Azure Virtual Desktop on Azure Local.

And I have built some of those solutions on Azure Local,

and we use a lot of the components in Azure,

so we actually built our images in Azure.

We have the whole orchestration in Azure,

but we just deploy the session host to the Azure Local cluster instead of the Azure Cloud,

but everything else is actually the same.

So I think that's a huge reinforcement.

I know that as a AVD or Azure Azure Desktop can now be deployed

on the ARGA enabled environments,

so we don't have to use Azure Local.

But the first quite some time that was the case,

you could only want AVD on Azure for Azure Local.

And what are the main workflows or scenarios where Azure Local makes sense?

And if we see a lot of ask for companies wanting to keep that data locally,

and then we have recently got Azure Public Cloud data centers in one part of Denmark.

So some customers may not need that anymore,

but we do have some customers that want the days that locally at their site.

We also have customers that need that one millisecond latency on their network.

They want our need to have that application wanting locally,

but still want all the governance and security features from Azure.

I think on the other hand, we are starting to see customers asking for Azure Local to run AI models.

So you can actually at this point now you can run Azure Foundry or

Foundry Local as it called.

You can run that on Azure Local.

Nothing, that is something we are going to be seeing a lot more asked for in the future

that customers with strict regulations that must keep their data and the AI

solutions locally.

They are going to be spending money on Azure Local hardware because it is actually very easy,

that way to get access to the models and integrate with those on that solution.

And how does it work?

Is it, I don't know, I buy Azure Local like I don't know Windows CD and install it.

How is pricing working?

Yeah, good ask.

Of course you have to buy the hardware unless you can find the local provider that will

list the hardware or in other ways do some posting of the hardware for you, but yeah, of course,

we find the hardware, the Azure Local software is installed on all the nodes and you connect that

because you are deploying the Azure Local cluster into a subscription and Azure, that enables the

billing and is built for physical core and there are some buildings for the virtual machines running

on top depending how you do it.

But you can also use your own, so if you have Windows Server Data Sender licenses with software,

Azure and Zanabel, you can use those and use the hybrid benefit feature in Azure to keep the

cost where we go. There is something about, I've seen some talk about if you're going to be

using the external send for storage. There are some billing requirements there that customers need

to look into because that will cost some additional money to use that. But yeah, that's the

billing. It is mainly built by subscription in Azure.

So, when we think a little bit about, I say we are living in the every thing is moving to the cloud

times. Where does Azure Local sit between traditional on-prem infrastructure and Azure Public Cloud?

Yeah, I think it is mainly around the customers that can see the business case in running

at local or have the straight calculations that they need to keep at local. But I know and acknowledge

that a few years back when hardware didn't cost as much as now, you could purchase the hardware

and you could run Azure Local. If you kept that hardware for extended amount of time, let's say

five or eight years, there could be a business case in that instead of running the virtual machines

or what workload you had to run in Azure. In Azure, you can do a lot of things with reservations

and cost, saving, and that's kind of stuff. But anyway, I feel like at the moment,

hardware is very expensive and I see some customers are hesitating to buy the hardware.

I do expect that at some point the hardware will get cheaper again and I think we will see

that the business case may be in the favor of local hardware again.

Do you see Azure Local primarily as data center technology or increasingly as an edge technology?

Yes, so there is this new feature I haven't got really the chance to dive into in there.

There is new possibility to run, let's call it Azure Local on the edge. So there is a thin image that

you deploy and it's based on Linux distribution. But for most of the customers that is going to be

running that, it sounds like it's more focused around running AI workloads locally.

The normal Azure Local environment that is connected, I really both in the talk to my colleagues

and also if I talk to customers, I do use some time to tell them that it's not just,

they buy true servers, it's not just true servers, you have to pass and keep maintain.

You need to see this as a local dataset, as a local cloud because that whole ecosystem

around the Azure Local is actually quite complex and you need to understand what you're working with

also if something goes wrong, if the patch goes wrong or if the services go down,

you need to know what you're doing and have some experience around it. So I think like

both in-house technician or external consultants from our company and also all companies,

they need to know what they're dealing with. You cannot just put in guys that have never touched

hardware, never touched Windows Server technology and expect them to understand what is going on

because there are so many layers in this way. It is basically a local cloud you are running when

you're using Azure Local. Not let us introduce to a second major part of all this

casual Azure Landings zones for someone who is new to the concept, what problem do

and Azure Landings are involved.

Yeah, I think that is a question I've been asked a lot and of course,

since I work in a team in Phillumon that delivers this Azure Landings zone concept based on

Microsoft's clouded-up and framework concept, it's I think it's for many people that is used to

ask it but not used to that concept, it can be a bit tricky to understand at first. But the

concept is that when you're working with Azure, you need to build structure, you need to build

hardware, you need to ensure that an application owner cannot access your firewall, you need to make

sure that the support consultants cannot go in and modify your logging solution.

So, the whole point of landing zone is that you have the platform landing zones

or the platform subscriptions. That is something like connectivity, so firewalls and routing

that stuff. You can have identity that could be if you're still running the main controllers

that could be that or it could be any identities that kind of stuff. And then you have the landing

zones for the applications and each landing zone should represent a application or solution.

So, if a customer has an application, it could be their ERP system, their final system.

That should live in a landing zone and typically a landing zone exists of multiple environments.

So, in terms of an environment that could be a development environment, a testing environment,

a production environment, it could be a pre-produced environment. Yeah, different kinds of environments

in that landing zone. And the purpose of that is that it is very divided. So, if we go by for that

ERP system, they want to develop and have a development area. That would go into one environment

in the landing zone and one environment is equal a subscription. So, if you say this landing zone

has a demo test and a product, that is actually free subscriptions and the resources would

typically be deployed three times in that demo test and production and subscription.

But it is to keep a very tight and very secure guard well around our applications because

customers that do not use landing zone, they tend to use one subscription, put many applications in,

put a mix of their tests and production systems. They totally lose the overview. They have no idea

is that application running in that database, is that production or is a test or maybe it is a

database that is running both and it is very hard for them to manage, it is hard for them to secure

and it is hard for them to decommission if the application needs to go at some point.

So, that is one of the main things about landing zone is keeping it tight. And when we dig into what

we are using in landing zones, we are using things like asset policy to make governance,

use the attacking solution and asset to check all resources within the subscriptions in the landing

zone. So, again, that is some of the mechanisms we can use to have that governance for those landing

zones. Okay, there was a good architect, overview of the VM, there are a lot of topics. Let us start

with management groups, what do they fit into the design?

Yes, so management group, that is the illusical separation that is used when you are building

the landing zone concept. So, at the top, we have a, let's call it a parent or a main management group,

and below that, you typically have the platform management group and below that, that is where all the

the platform landing zones live. Then again, you can have a below the main management group,

you can have a management group for the corporate landing zones and the online landing zones,

and also actually for the local landing zone, because quite recently, Microsoft added this local

management group to the management groups overview to have that same feature for a local.

But that is what we use management group. For the management groups have the functionality of we can

assign the policies to them, we can deploy to them, we can use the RBACs, so we can set permissions

on the management group group. So, that's an extra and actually create a layer to

suspend the structure that we use often. And I think when we talk about landing zone, the other

most spoke word is subscriptions. How should organization think about subscriptions?

Yes, so from my point of view, we really should stop things as subscription as a container of

everything we need to see subscription as just environments. If you think of it, like I'm talking

about in the landing zone design, a subscription should only contain a subset of resources. It should

not be a mix of all everything. One subscription should not contain both firewall resources and

logging resources and a scroll databases. That is too many resources for one subscription to live in.

I acknowledge that if you are a very small customer, maybe if you resources, it may be a bit overwhelming

and maybe a more careless, you can say, to use this concept. But for most customers in Azure, they

really need to use this concept. And what role does the Azure policy play?

Azure policy can do several things. So there's the audit mode. We have a lot of

regulations for customers need to apply to. It can be in Europe, we have the GDPR, they can be

software, can be a nist, I think it's called. Most of those policy initiatives I actually build in

from Microsoft and ready to use, we just assigned them. They are mostly auditing. And I know we have

Microsoft Cloud Security Benz, my initiative that it can also do some denying effects.

But if we were just reading the audit mode, a lot of Azure policies can be used to audit

your environment. So say that you have to deploy the storage account and you have used less secure

settings that would trigger one of the policies and then initiative to go in a non-compliant state.

And you can see that in the Azure policy overview and you can see that resource needs to be fixed

to be compliant. That's for the audit part. But we also have the deploy if not exist part. So you

can deploy extensions to machines and you can deploy resources actually. And then you have the

blogging of the deny effect. So the Azure policy is also able to deny things. It could be that

you are only allowing users to deploy in certain regions in Azure. And that could be one of the

policies to use or you could deny that they are deploying storage account with the public access

available. It will use for many things and we use that a lot. We have used both of

a lot of buildings from Microsoft and from third parties and also some custom written policies.

Azure policy is great. It's time consuming and you need to use some time to understand it. But

once you get a grip on it, it can do so many things in Azure. And also, and also local.

And we have to say before about how important are identity and

Arabak and in the learning zone architecture from your perspective. Yes, it's very important.

I think one of the main reasons to use the NISON is to have that strict security,

let's call it the SEA trust configuration setup. And you use the principle of LEADS privilege.

At every scope within the learning zone on the management groups or in every subscription in the

learning zone, you have in 3D groups that you apply to users so they have just the right amount

of permissions but not more than that. And also, since we are working a lot with infrastructure code

and automated deployments, we are going to be using service principles that they need to have

access as well. And again, you can control that in the same way. So I think, yeah, that's a very good

area also to understand when working with Linux. So I said, don't go ahead and put yourself

on everyone else's owner on the top management group. That is very tricky. So you use the features

and the possibilities in the Linux and concept to have that zero trust configuration done.

My Microsoft has these reverence architecture. How deep should organize, follow it and

when make sense, yeah, doing modifications. Yeah, good question. I think in our company,

we actually want customers to follow the best practices as much as possible. And we do have some

discussions sometime with customers that want to do it their own way and maybe there is not a

strictly secure as we want them to, but I feel like for the most part, we get the discussion in

and we get them convinced to do it the proper way. We also, all the time, us to go in and assess

solutions in Azure, built by us or built by us. And again, we also, we always want them to be

as secure as possible and to follow the best practices as much as possible because in the end,

I believe that the best practices that Microsoft has written is a great way to build your environments.

How do the Azure local, the Azure cloud, and Azure landing fits together?

Yeah, so in the past, when we were deploying Azure local, we did not have the possibility to use

multiple subscriptions or multiple research groups. So at first, it was really limited. You

deployed Azure local into one subscription into one research group and everything was just set

there, but there was some time ago, it was, it was changed a lot. So as of right now, we can use

multiple subscriptions and we can use multiple research groups. And that actually enables us to use

the landing zone design when we are deploying Azure local. And I think that's a huge

reason and a great feature at this in that Microsoft did some time ago because when we can deploy the

Azure local cluster itself into one subscription, let's call it a control plane or a management plane

or somewhere like that. And then you can use additional subscriptions to have your workloads in.

That could be if you are traditional customers running at domain controllers, you want them to be

TSO and you want them to be in a separate subscription. That is actually now possible with Azure local.

And again, for for members, which we can have these new tier to your one subscriptions. And if you're

running Azure desktop, I believe they should be considered tier two because they host the end user

activity. So we have now the possibility to use the the tearing model also because we can use

multiple subscription. Everything was that would then sit inside a landing zone. So if you think

of the management group layer, we will have that local management group below that. We will have

another management group that is named after this landing zone. We are going to deploy for this

Azure local cluster. And below that, we will have a minimum of four subscriptions, so the control

plane subscription then then tier zero one and two subscriptions for for the workloads.

And also if you're one and co-genators, you can do addition subscriptions for that as well.

So that's I think that's a great way to design. I know all those other Microsoft MEPs has written a

lot about how to use Azure Arc when you are using Azure Arc on your on-premise servers. And again,

for domain controllers, they should be treated as tier zero. How to keep them secure. That was I

feel like that was a headache before. But now I think Microsoft has solved that and we can we can

deploy a tier zero into their own subscription. And we can really make tight security around that

subscription. So no one without the need can access the servers via Azure because every server,

every virtual machine that you deploy in Azure local will also basically be

ARC enabled. You can manage the server's re-SR. Yeah. Interesting, interesting. And I think in

another topic, it's hard to ignore. Yeah, we can't really discuss Azure local without talking about

Azure Arc. What role does Azure Arc play? Yeah, so I think I think Azure Arc is like the

also would connect that between our on-prem and our cloud Azure Arc and one on almost everything.

I think nowadays it can run on Windows servers and it can run and select Linux distributions.

It can run outside of Azure local. So if you have something running on VMware or Hyper-V or

if you have it running in another data center, it could be a ABS or another hosting provider.

You can you can enable those machines. And by an our enabling UI enabling the features that is

within Azure Cloud. So say things like you can use Microsoft Defender for cloud. You can use

Azure Policy. You can use Azure Update Manager. So I think some of those features are really great.

And there's the whole matrix of what features you can do when you are in the machines. But

the Azure Arc is the connect that is connecting our on-prem to our Azure Cloud.

Okay. So would it be fair to say the Azure Arc is one of the technology make the

boundary between cloud and on-prem is increased the relevant?

Yeah. Yeah. So I do believe that as the Azure Arc is the is the boundary it is what enabled us to

connect almost everything outside of Azure Cloud into Azure Cloud for management governance

security really enabled us to have our daily maintenance task within one day one management

pain. So administrators can go into the Azure Cloud and they can monitor all their workloads

regardless of whether they are running in a physically speeding.

Okay.

How do those other Arc changed the way administrators manage the local infrastructure?

I guess for some people I know I have myself in the past in other companies I worked it.

So you use a lot of different third party solutions to have that monitoring and the management

and the passing and installing security. So I think for most servers and for most companies they are

using a whole lot of different products, third party products to manage the servers. And I do believe

that Microsoft solved that issue by having Azure Arc so you can use one product really to enable

all of those functionalities, the both the monitoring the past and installing security,

keeping it up to date, governed them, use machine configuration to keep them at a correct

configuration level. All those things is enabled by Azure. And also of course I work in a company that

we are deeply connected to Microsoft and we want to provide Microsoft product to our customers.

But for that being said I really truly honestly believe that this product as a

arc and the as a cloud is so good that many customers, if they are not always switching from

some other products to this product, they should be looking very seriously into it because I think

the feature matrix is quite comprehensive. We can do a lot of things with as a arc.

I think another topic, especially when we think about all people speak about infrastructure as a code,

how important is this topic for Azure Local?

Yeah, good question. You can deploy the whole stack and you can deploy workloads,

you can deploy everything actually with infrastructure code. And I have done it before and I have

done it also with customers. I would guess that I was suspect that some customers that is going to

be deploying Azure Local themselves will not use the infrastructure code method to deploy it.

That's totally fair. But I think if you're going to be doing a thing more than once, you should

automate it, you should write code for it and you should use infrastructure code.

Think of an example about Azure Virtual Desktop. Sorry if you're running Azure Virtual Desktop

on Azure Local, there are going to be some maintenance tasks that is going to be recurrent.

They can be automatically handled with infrastructure code and perform very well. So

that is actually a use case where I would recommend customers not to build it from scratch,

everything with infrastructure code because that will, I know it's maybe the time-consuminal for us,

but all the long, all the next few years it will save the IT department. I was that for sure.

Yeah. I have seen in your profile, I used to say, on the byset side of

infrastructure at the code, why byset and why not terraform?

Yeah, I think that's a good question. And I haven't really made that much thought decision about it.

It came quite naturally for me that we were a few years back when I really started working on

infrastructure code. We started on Azure Derops and we started with byset.

I think for some of the guys like myself, I have been writing new housescript for many years.

And I think the transition from using only power cell to using power cell to get

a bit byset. And also nowadays maybe not power cell, that multiple can be where it can work as a,

as an executioner, but we use a lot of risk call also in redeploy. But I think the uses of

power cell together with byset, I would suspect that for many, including myself, it's quite easy to

get started and get used to it. The byset language is easy to understand that if you are writing byset

and we use code for them and have the extensions installed, it's quite helpful and it's going to

tell you all that you cannot just send text or this is wrong again. So it's, I feel it's quite easy

to use and to get working. But I have not spent time with telephones or act actually I cannot say,

it's just because that is much better natural for me and what I've been doing for the past years.

Yeah, I think what also interesting is,

also in actually GitHub GitHub, but yeah, as I love really, I think the Azure DevOps makes, makes sense.

What role does Azure Devop play in your infrastructure deployments?

Listen, actually we use Azure Devos for many things. We use it for our repositories in our

Devos projects, but also we use the service connections to deploy into Azure and into the

deploy into Azure local. It's super easy and Azure DevOps to set up a service connection that hooks

into Azure and if it's connected to Azure, it can connect to Azure local also because

provided by Microsoft and super easy to set up. There are other features than there also,

the board feature and the development tracking if we are learning a project. We also use in that.

Also, I also use GitHub and do that, but in terms of Azure and deploying to Azure Azure,

it's local. For me, it's just very easy to use DevOps because it's so, so fast to set up and

everything is configured by Microsoft. You just have to go a few resources and you have permissions

on the setup. You can even go in and set up a Azure DevOps managed agent pool. If you need to run

your custom scripts and you use your DevOps agents, it's very easy to set up a good start of it.

You run this local. I don't know. I think a little bit. Yeah, but

as a dev ops team, can you a little bit walk us through a typical pipeline from

the developer changing infrastructure code to that infrastructure pre-earing in Azure?

Yeah, let me see if I can answer that question in a good way. It can be just as simple as

writing the bicep template to deploy a certain amount of resources and use a simple pipeline

to the broader insescia. It can also be more extensive where you use

integration tests. If you have maybe a pair of meter files, or some pair of meter things, then

you want to test that they are correctly

containing the correct data. You're going to have certain kind of tests and you can use

different kind of linders also to test. If you want to use pipelines also or to check

if you're secure, so some of the pylons steps could be to check if your code is secure.

That maybe is not common to use for infrastructure code, but I know it is for application code.

And then you deploy your code. Something that can be useful is also to

if you write up what you're expecting to be deployed, you can use that as a pre-deployment check

and have a post deployment check. So, you're writing your recipe. What do you expect to deploy into

asher? When you do the actual deployment in another stage in the pipeline, and then after that,

you do another stage where you check and actually check the resource in asher. Were they correctly

deployed? Were there some errors? Were there some differences? Where are my recipes? Does not

align up with my deployment? That can be can be super useful for if you're wanting a bit more complex

pipeline deployment. I think you prefer you also working on the fellow-mind management platform.

What is the management development management platform? What problem do we try to solve?

Yeah, that's a very good question. I know that fellow-mind will be happy that I spend time telling you

about the fellow-mind management platform. We call it the FMP. So, in the essence, FMP is a turnkey

solution to asher cloud. We are also looking into adding features for as a local as well. But

if you do not want to spend a huge amount of time developing your own landing zone

system and subscription, vending, resource cleanup, deployment of new landing zones, how to manage

your connectivity, how to do logging, everything within that concept is provided by this platform

as a turnkey solution. The customer just signs up. They hand us a permission to go into the tenant and

redeploy everything in this managed method. So, if someone wants to look into it more, there is a

public site called fmp.filomind.com. There is the architectural design and there is the matrix of what

we do versus what the asher landing zone concept does. We have a lot of different features that is

not within the baseline form for the asher landing zone. So, there is a real customers. I know we

have AI nowadays. We could set down and develop them themselves. Agree and acknowledge that.

But still, they would need substantial knowledge about how to design solutions in asher.

Just think of connectivity. We have multiple designs. So, customers want to use the vvn or

they want to use another network to sign, mostly just deploy a firewall and a repaint gateway,

or if they do not need network connectivity at all, all the routing, the private DNS handling

from zones and if they have unpremly need to have an DNS resolver as well deployed,

all of those different components they need to understand and be aware of. So, of course, in the FMP,

we have the deployment of all resources, but we also have quite a substantial amount of documentation.

Available so customers can really dig into and understand what should they do in certain situations.

And besides that, we also give them a portal with a lot of data about the platform. Give it to

them and also for stakeholders that need to do decisions about cost and governance for the asher.

They may not be in the asher portal that much, but we are giving you a lot of data from that portal as well.

I think that for the last part, it's also access to consultants that know a lot about asher

and the different components, the resources that they can deploy, how to design it. So, again,

also if a customer has the FMP, they also have access to consultants that they can have their

discussions with on how to design solutions within asher and also within the FMP once they are

one-border to that. Awesome. But let's jump back to the start of the

lecture to modernization, imagining that the company I say that has five of our traditional

virtual machines. Where do you begin?

The one is to get some access, some really good access because we can use tools like

asher migrate actually to do assessment. That tool has been available for many years by a

manufacturer. Then if you deploy an instance of that in the environment and you have proper permissions,

that asher migrate solution can actually assess all the workloads within that environment.

They can assess things like each version machine or committed or under committed, is it using all

the allocated resources? You can also see things like, does it have as grill show installed? Does it have

web hosting like in the information stores installed? And I think also all the other

application services as well. Then that gives us a good start-up point to know what should we dig into

further because of course as a migrate alone as an assessment tool is great but it's not complete

and it will not tell the customer exactly how to work from there. So the next level is to

assess all the application zeros. So we look at what kind of file zeros that we have. Could we

put some data in SharePoint or put some data in storage account? Could we put some data in

some kind of solution that has to run locally and we can use that as a storage sync service?

That kind of stuff. So just for that, just for the files we need to look into what of those many

new solutions can we use for that? And again, that's the same for the applications and for the

databases if the use remote desktop today can we use AVD instead? All those sorts of things.

It can be quite time consuming to do but yeah, we use things like as a migrate to do some of the

initial assessment and from there we talk with the customer and we advise them on what to do.

We build the faces because if let's say have five hundred zeros, you're typically not migrating

everything to asset once and I know that some companies want to just tell the customers to just migrate

all five hundred zeros and go from there but to be honest, I think everyone working with migration

should be honest about it once the customers in Azure. The customer thinks, okay, I'm an

asset. Good to go. But yeah, you just migrated five hundred zeros from one data center to another.

You have not modernized them yet. So my perspective is always to, if you have hardware locally

and you can keep running there, let's start with looking at the modernization possibilities.

So I do not want to move five hundred zeros to as it is for the front of it. I want to migrate

them to platform solutions wherever possible. I want to decommission zeros. I want to minimize the

number of zeros that customer has. That is always my in-code. Yeah, you're not the biggest lift

in shift vendor. I know, hate lift in shift. And I've done it so much. It's not like I've not done it.

I've done it for plenty of times but it's just, it's not fulfilling to do lift in shift. It's so much

more fun to do the modernization to see that the customer can move from, say, five hundred zeros to

two hundred zeros and the other three hundred workloads were modernized to lose solutions.

And also we always find something that should just be straight up decommissioned because it's

not running anymore. Customers do not know what they have running.

What was, what was, did you think, what's the biggest opportunity organization,

this when they migrate a latency infrastructure? I think it is a combined of many things.

So if they're moving to Azure, of course, use the features for cost savings,

reservations and savings plan and that kind of stuff. You should use that wisely because

that can save a lot of money. And they can also save a lot of if they have windows showers,

they can save one of the licenses as well. I see that a lot that customers just don't make the

decisions and then they end up spending a lot of money on purchasing machine that is going to be

running in Azure for years. That's one thing. And I also see a lot of customers moving their

workloads into Azure, but just keeping the same level of integration that they did before.

Let's say they were on prem or they were at another hosting provider, somebody else.

And they just moved the servers into Azure, but they do not take the time to set up Azure policies

to actually govern and secure them. And they do not use Azure update management to keep

them updated. They still do many of them updating or use some third party software that also paid to.

And yeah, so I think that's some of the things that they do not actually use the features

handed to them once they migrate into Azure because again, as I said before, once they have moved

into Azure, they feel like I'm done now. I'm in Azure, everything is good. But even things like

doing so many, don't see or doing during the day in Azure, you have to set that up, you have to

configure it. It's not just enabled by default by Microsoft. And that's also a thing that I think

a lot of customers is not aware of. And we do, we really try a lot to tell customers about those things.

You need to maybe need to rebuild your servers, maybe you need to configure them in different

way, maybe you need to redesign the applications to use the features available in Azure to keep the

resiliency at the at the spest because we have so many features in Azure around that.

One thing all companies see if all states are getting expensive, they're more expensive.

Did you see also we can, we have the option when we model, we are getting more down infrastructure,

we can also save cost. Yeah, I think, yeah, usually we can. Of course, if you take a thing like a very

small windowsill running in a squirrel database on top and you want to use a squirrel many things,

of course, that will be more expensive, but for the most part, we can save money by removing the

windows servers, removing the windows licenses, using a platform service instead, that is also

provisioned correctly and has the right amount of resources. And typically we can save money by

doing that. And also a thing that customers do not account in when they do the calculation is,

for every server you have, you have a administrative burden, so you have to keep it a patch,

you have to monitor it, you have to fix when the patch grows wrong. And every time you move from an

infrastructure service to a platform service, your amount of remains in this work is getting smaller

because Microsoft will take care of more things than before. And of course, that is not a nice

to customers that are selling managed services because, yeah, of suddenly we have to do less,

but then again, we can do a bit less of the growing part about maintenance and things we can do more

about continuously improving the customers environment, keeping the up-to-date, tuning the environment,

configured it, because that's always the thing you can figure different to keep it more secure.

I don't think we are not doing time in that sense, but the customer can save money, I believe,

if it's designed correctly. Yeah, awesome, I think we're a little bit running out of time,

so I have every session, like, a quick fire round, so five, six questions, you give a fast answer.

So, PowerShell or Azure CLI? Hmm, PowerShell.

Portal or infrastructure is code? Ah, infrastructure is code.

Like, we can outspoken or to work. To work.

Pass or containers? For my bad pass, because I don't know much about containers, but if I do know

containers, I will say containers. So, it's not the end of the day yet to come to you and say,

you get all the money resources to make Azure Local better or develop a feature. What feature will it be?

So, a thing running on top of Azure or Local or a feature that is developed by Azure Local team,

I just need to understand the question. Yeah, you can do, you get all the money resources and

you say, this is what I need to make the best product of the world. Yeah, okay. I know,

I know one answer that me and my colleagues want, so we have this thing called Hydration.

If you backup in restore, if you have to move version machines from one Azure Local cluster to another,

they lose the arc enabled from another team, have to do a lot of car bar tricks to get that running.

So, that Hydration feature will be so good and I know, Microsoft will do it at some point.

I think it's a hard feature to develop, but we really want to have that possibility to move,

workloads between clusters and keep them arc enabled. That is my number one feature,

what really want to have really soon. So, okay, then my final question is Christopher,

imagine I'm responsible for the traditional infrastructure at the mid size enterprise.

I have the amber or hyperview, hundreds of VMs, active directory, I grow an Azure environment,

pleasure from management to modernize. I don't want another isolated infrastructure platform.

How will you approach design and several learnings on strategy G, where Azure Local and Azure Public

Cloud becomes part of one architecture and what should it do first on one day money?

I think number one is I would look into the hardware head already because maybe that hardware could

be upgraded with some other network cards or maybe some other storage adapters and that could actually

use Azure Local. Then next, I would look into what resources could be modernized into Azure to

platform services to keep the amount of virtual servers as low as possible. When ones have done that,

I would look into what servers could be moved into Azure and what servers need to be locally,

either because of latency, regulations or another third option. That would be my set of starting

points to get started with, looking at the signing of it.

I love that network. Who should I invite next at what questions should I ask?

That is a good question.

Of course, since I work with the things that I work with, I find infrastructures code and I find

Azure Local exciting. I think there's a lot of things going on with BICEP at the moment. There's a new

features going to DA. That can't stop. I feel like for myself personally that some of the things I'm

looking very much into right now is what is going on with BICEP because there are new features coming out

and really BICEP is moving forward and adding functionalities within the BICEP deployment.

For me, I cannot pinpoint an exact person right now, but for me personally, I think BICEP is

very nice to look into at the moment for what is going on with that.

Awesome then. Yeah, Kirstoff, thank you for for joining me today. I think one of the important ideas

from this collaboration is that hybrid cloud tool means running to completely separate worlds.

And a local becomes particular interesting when organizations stop thinking about it's purely

as local infrastructure and start considering how it fits in the broader Azure architecture.

So yeah, we have heard a lot. Azure learning zones, Azure art, infrastructure as a code, BICEP,

PowerShell, and so on. Yeah, I think this was really cool overview. I'm very thankful for what a

time you have spent with me and yeah, for the listeners, all the info for Kirstoff, you find on the MC65

podcast page in the show loads. And yeah, you see the work of Kirstoff, you can connect with them

and all the other information. So yeah, thank you very much for staying here with me.

Thank you. Glad to let that you would have me on this podcast. Yeah, so thank you.

[BLANK_AUDIO]