Azure Platform Engineering, Azure Landing Zones, Cloud Adoption Framework & Building Enterprise Cloud Platforms Jev Suchoi [MVP]

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]