 Hello everybody and welcome to today's live stream. My name is Sarah Lean and I'm a senior cloud advocate here at Microsoft and I'm joined with my colleague, Thomas. Thomas, welcome. Hi, Sarah. Good to see you. Happy to be on air today with you, so yeah, thank you for having me. That's okay. Today's session is all about Azure Landing Zones, and hopefully you've all seen the blog series that Thomas and I have been writing in conjunction with the Azure team around the Cloud Adoption Framework and Azure Landing Zones. We're going to be taking your questions, so please feel free to drop your questions in the comments. We have our colleague, Antony backstage trying to furiously type away to your answers, so definitely make sure you drop us a question and we'll answer that as well. Thomas, do you want to kick us off today and explain the Cloud Adoption Framework, Azure Landing Zones, all that kind of good stuff? Yeah, I will. Obviously, you and I both, before we joined that role in Cloud Adoption, we were both consultants and we worked actually with customers around the globe, basically, on their Cloud Adoption journey. One of the main things we have is when a customer decides to go with Azure or basically any other Cloud provider, the big questions come up like, how do I do the architecture right? How do I do security right? How do I do the role-based access control right? Obviously, there's a lot of things you need to learn, especially when it comes just from an on-prem world. That is where, for example, the Cloud Adoption Framework can come in, which basically gives you that proven guidance. Again, there are many, many different options. Like how you can actually build your Azure environment, and it's not just about building the Azure environment per se and then in itself. It's also about thinking about the processes behind it and the people behind it, and then what you actually can do and deliver. I think that is also important that you then think of like, how can I align with my business strategy, like what does the business want, and all these questions, and that is exactly where the CAF or as we call the Cloud Adoption Framework can come help you. Yeah. I talked to customers a lot about migrations, Thomas, and I think lots of people get caught up in the technology because that's obviously a massive part of a migration project, but there's also the people that are involved in all of that, whether that be the people in your IT department or the end users and how these changes actually affect them. I've got this slide up here about the Cloud Adoption Framework and how it's part process, part technology, and part people, and that helps to drive that modernization for you to your end goals, whatever that may be. That's one of the reasons why I really love the Cloud Adoption Framework, and I always highlight the people part to people. It is a very important one, and it also is important to understand it, because that is then how you actually can keep the control of your Cloud environment, but still have the speed and agility the Cloud promise to you. You're probably talking about simple, can be simple things. We don't want to have every developer or IT Pro going out and deploying in every region Azure offers, or for example, deploying our large MB2 series machines with hundreds of course, and I think 20 terabytes of memory and stuff like that, and they drain your credit card in three seconds, so you want to keep that control, and that is where the Cloud Adoption Framework can come in. In a nutshell, what is the Cloud Adoption Framework, and where does it come from, and what does it actually focus on? Really what I like is the sentence above, it's really like proven guidance for your Cloud Adoption journey, if you will, and what we're seeing is obviously where we did that is we worked with different customers, we worked with our partners in the field, with consultants, architects, and we try to create that guidance in the Cloud Adoption Framework, and as you can see, it covers a lot of different topics, not just like do the basic architecture, but also then like what comes further, right? Yeah, and I think this slide is actually a great representation of the kind of journey that you go through. We often talk about the Cloud Adoption journey, and this kind of shows you those decision points that you kind of have to go through. So defining your strategy, defining why you're actually doing this, what your success looks like, then planning about it. So starting to think about what you're going to do, and then the ready phase, whereas you are just getting ready for that migration, whether that be your new workloads we're putting into the Cloud, or whether it be existing ones you're migrating, and that's actually where the landing zones sit in. They sit in that ready section. So if you're looking for the Cloud Adoption Framework and you're looking for all the documentation, that's the ready section that has the meat around the landing zones, which is what we want to talk about today as well. And then obviously, there's the other stages, but we're kind of stopping that ready kind of today to talk about the landing zones. So yeah, I think, yeah, that's the way I look at the Cloud Adoption Framework. I don't know if that's also how you look at it, Thomas. Absolutely. I mean, again, we just want to point out, this is not necessarily just about the Cloud Adoption Framework, but we have a lot of people. We're not familiar with the Cloud Adoption Framework, so we want to really point that out. Definitely, if you're part of a Cloud journey, or even if you already have implemented stuff in the Cloud, please check out the Cloud Adoption Framework. It also offers you a couple of tools. We have the Cloud Journey Tracker, which you go through an assessment, basically you answer a couple of questions. And this Cloud Journey Tracker will, for example, find the gaps for you to actually then see, okay, hey, where do I need to pay a little bit more attention? Could be on governance, could be on security stuff. You name it, like basically everything in the Cloud Adoption Framework. Yeah. I just want to address one quick question, because we've got a viewer asking about landing zones and the top three components. You should definitely be deployed. We'll be talking about that in a wee minute, Matthew. So we will answer your question once we get on to talking about the landing zones. Yep, Axie, and that's actually a perfect, perfect time. I think let's talk about landing zones, because we already have a couple of questions also in the chat about the landing zones. But first, let's set the groundwork here on what actually the landing zones cover and what they are. Yeah. So I think when you're looking at what you need to prepare your environment in the days gone by when we're doing physical data centers, you'd be thinking about electricity and air conditioning and badges for your staff to get into. Those are kind of the decision points you have to think about when you're also moving to the Cloud. Obviously, there's different points within that. And as you can see on the screen of the slide that Thomas is talking about here, you've got those decision points you have to go through. And it's key to go through those decision points before you do the landing zones, Thomas. I know I've probably seen a few customers and you've probably seen a few who have went out and deployed a landing zone and then thought about their design. And that's probably the wrong way to do it, I think, if it's fair to say that. I mean, it's definitely helpful with the earlier you start, right? I mean, it's like building, and we bring that example, for example, building a house, building like stadiums, building like projects, like building houses in general, right? It's always good to have a plan and build an architecture and like answer these questions before you actually start building it. However, obviously, as I said before, even if you're started, that doesn't like, without that, you can still circle back and go and have a look at it. I still highly recommend because I know a lot of viewers right now probably already started and you're not like completely wrong, right? But the earlier you look at this, the more helpful it is to that. And I love how you pointed out like what actually is in the landing zone and that is also very interesting to me. I mean, I know that you wrote one of the big, or took the big part of like what is actually an Azure landing zone. Can you tell me a little bit more? Yeah, so the landing zone is those key components and you'll probably hear us say in the documentation, the minimum viable product that you need to house a resource in Azure. So if you think about like a server, a server needs core components, it will need like network connectivity, it will need authentication methods. We're not even cooling an electricity because we already have that in the cloud, but that's the kind of things you need to think about, you know, the governance, the role-based access control, who has access, who doesn't have access. Those are the kind of parts that make up a landing zone. Those are the bits that you have to design and you have to put in place before you can actually put a server there or a web app or even just a storage account. So your landing zone is really just that minimum viable product that you need to be able to support a resource. So hopefully that actually makes sense. Does that make sense, Thomas? I think it works perfectly sense. And I think what also a lot of people need to know because I see already a couple of questions and no worries, keep them coming. We will go through them as much as we can. It's not like just a fixed thing, right? It's not just like, because every customer is a little bit different and every project is a little bit different and the different landing zones can also be different depending on you have customers. So there's not the one right way of doing it. But again, the cloud adoption framework provides you with the proof and guidance on this. Now, what we are talking about, one of these landing zone types, if you will, or the architectures are the new, basically new, I put it in quote, because they're exists right now for a while, are the enterprise scale landing zones. And so we wanna quickly see, talk about what that actually is. And I like the slide you put here together, which shares like basically covers it pretty well in a very short sentences. Yeah, the enterprise scale is just building on that minimum viable product and making it for the companies that have, tens of thousands of workloads or 100 thousands or you don't, to be honest, you don't actually need all that kind of workload, but it's just the kind of next bit up from that minimum viable product that you need. And I think that's how I simplify in my head between a landing zone and an enterprise scale landing zone. Hopefully, I'm hopefully doing that right and doing that justice, Thomas, and summarizing that correctly. Yep, absolutely. I mean, for me, what I usually tell people what like enterprise landing is always like two things, right? We have this architectures itself, really providing you with like, this is how an architecture of different landing zone types can look like, but basically the guidance again for these landing zones, but then also we have certain reference architectures which we probably will have a look at before in just a bit, which we actually have also again, two things. We have the architecture of it, like we provide you and say how it can look like, but we also provide you with the automation around it. So you can actually take that code and the team created things like automated, like ARM templates and other automation parts based on, for example, Azure policy to make it easy to integrate into your environment. And that is also something we will definitely gonna have a look at a little bit later on. Yeah, absolutely. We can actually dive into that now if you want, Thomas, if we want me to jump over to some of the landing zone or do you wanna do the design principles first, very, very quickly. Just cover like before we go a little bit because again, I know that there are people in the chat which are probably not that familiar with the different design principles because this is an important part. What did actually Azure, like the enterprise scale landing zones, like taking care of, right? And it focuses as you can see here in blue and a couple of things. For example, like this is the democratization of subscriptions or you use subscriptions to separate your different environments. It's policy-driven governance. So it can take like policies and native management service within Azure which takes like place so you can run that. It provides a single control plane and a management plane. So you can actually go out and use basically enterprise scale to manage your different environments and landing zones. And I think what is also very important is this application centric and architecture neutral part where we don't just think about like, hey, okay, we just take over and we do a lift and shift of your applications if you have any existence. We also think about how you can actually optimize them for a cloud and in a cloud native way. And then I think most importantly, overall is that it actually looks at the Azure roadmap, right? Because what we see in the lot is like, obviously when you implement something we will bring out new features and new functionality. And so it actually aligns with that roadmap. So whenever you start, you can still work with that in the future and it's designed to be like upgradable. But yeah, you're right. Let's dive in and have a look at this stuff we want to show. Cool. So what we have is a documentation which lives on GitHub which is all the enterprise scale, landing zone templates and some documentation about how you can actually deploy them. So it's the place that I want to show you where they are. So yeah, this has all the information about the different architectures that we have, the different enterprise scale landing zones that we have. And there is some documentation about how you can deploy them. There's some documentation around how you deploy them in a CI CD pipeline via GitHub Actions if you want to do that. There's also some information about how you can try it out in a one-stop subscription. And yeah, basically just lots of information about this. So definitely somewhere for you to head over to on GitHub. What I want to show you is some of the reference architecture that we've got in terms of the landing zone. So we've got these fictional companies as we do here at Microsoft. We've got Contoso, we've got Adventureworks, we've got Wingtips, and we've got the Tree Research ones. And they all do the similar thing but on different scales and have different components when you look at them. So if we dive into just the Contoso one for an example, what we'll see in this GitHub repo is a big deploy to Azure button. So it takes the template and deploys it into Azure which we'll be showing you in a minute. But it also tells you a little bit about the customer profile that this is intended for and also some of the prerequisites that you have to do, what will be deployed, and then you've got the architecture diagram. So it kind of explains what this template is actually going to deploy for you so as you're not just deploying the template and not understanding what's behind it. Got a nice kind of visual diagram there showing you all the different components of it. And as you can see from the landing zones, what we try and do with these landing zones is split things up into different subscriptions. So we have subscriptions around your management and your governance, your connectivity, if you're looking to do hybrid connectivity back to your on-premises environments. Got identity and we've got the landing zone subscription which is actually where you put all your resources. It may look complex and I think probably first glance, Thomas, I'm sure you've looked at these and you think, oh, that's a lot of resources or a lot of things for us to manage. But when you actually look at it, it makes a lot of sense or at least it does to me now that I've been studying them for quite a few weeks. Absolutely. I mean, usually you need to look at this like all by yourself, right? If you would not take the enterprise scale landing zones, if you would just take something else, you probably, those are still the things you need to look at. You still need to look about network connectivity, security, still need a bit of a role-based access. So this is actually a good thing to like making you also aware of it. By the way, we also, this is great when you show that screen because we just see one question, I think from Matthew, I just came in. He asked about like, so would you have like multiple landing zones for example in a hub and spoke environment? And yes, kind of that's absolutely what it is. So if you look at, for example, this screenshot here, you can see that we have obviously different subscriptions for like the management part and centralized subscriptions, if you will. But then you have, for example, different landing zones on, for example, which can suffer like different applications, different teams, different departments or different environments, if you will. And I think that you can see here, it's like covered with a little end there that you have like one landing zone is literally like the base. But then obviously you can have multiples next to each other to separate different environments. Yes. And I think also someone's asking about the start small and expand landing zone. I believe that's the tree reference. So tree research, if you look at that one, don't necessarily quote me on that one, but they're different ones and they have different scales. So if you have a look quickly at the tree one, yes. So this one's for the smaller ones. So we might call it start small and expand but when you actually look at our cloud adoption framework, it does reference these company names, these fictional names, so you can put the pieces together. But again, you will have, if you scroll down, it's a slightly smaller architectural diagram for the smaller landing zone as well. And our documentation does go into why we've picked all these components and that's part of the design process. So those design principles that we talked about earlier and Thomas showed that kind of slide point. Those design points are driven by what you end up here. So if you say that you have to be mega secure because of some compliance need within your industry, if you've maybe got PCI, DSS, we've got payment protection you need to do, then it will help you design the different components that you need within this environment versus if it's just a demo environment and you don't need it secure and you're quite happy to have port 3389 open to the internet and stuff like that. Those design principles will ultimately help you design your landing zone and kind of define the points. So the documentation, the cloud adoption framework really walks you through why we've kind of gone with these reference architectures as well. So yeah, hopefully that kind of answers some of the questions. I know we've got a lot coming in here guys. We will definitely take the questions we can't really answer right now on the stream. We will definitely try to answer them in the follow up blogs or posts we have. I also wanna quickly go with Pixel Robots question here. One of, hi Richard by the way. Thank you very much for joining today. So he asked basically, are they also giving like these documentation to these different architects but they're also giving kind of like business reasons for it. And as you can see where Scarra is scrolling through, there is a customer profile. For example, it says, okay, for whom, for which type of enterprise or customers or which scenario is this made? I don't know if this is enough for depending on your scenario, but it should give you a pretty good idea how you can use it. Yeah, so yeah, there's lots there. I think somebody was asking about Azure Lighthouse and how it's integrated into the landing zones. I actually don't know if we have anything at the moment that integrates that environment, that cool technology that you have with Azure Lighthouse. But what we'll do is we'll definitely take that back to the team and check where it is on the roadmap if it's something that they do have. In this GitHub repo, there is a roadmap file. So yeah, we'll definitely take that question back to the team and see where they're going. The reference architecture that I wanted to actually show you and show you how to deploy it is actually the AdventureWorks one. And this would deploy everything that you see on screen here, which again, looks like a lot. But when we show you how you can deploy it, it's actually quite a simple deployment in terms of it. So again, when you're in this GitHub repo, you can click on this deploy to Azure button. And what it'll do is it'll start to open up the Azure portal for you and start to walk you through a nice interface that the team have put together to help you deploy this reference architecture in this landing zone. And I won't go through all the questions because it is one you can actually go through without actually deploying. Thomas and I have worked through it a few times before this live question. But it asks you simple questions, like what region do you want to deploy into? So I'm based in the UK. So I'd say UK for that. And then I start to walk through the wizard and I ask you various different questions. Like what prefix do you want all your management groups to have? You can have like your company short name or you could have tests or you could have production. Whatever it makes sense for your organization. And again, if you've went through the design process, these questions should not actually be unfamiliar to you. You should have all these answers written down on a bit of paper. If you've had those design meetings and you aren't just deploying this like me ad hoc without any planning at all. You've all get asked lots of questions around things like log analytics. Do you want to deploy that? Do you not want to deploy it? How long do you want all of this kind of data stored? Again, if you went through the design decisions then you will have the answer to all of this. And this could be key again, like I was saying to customers who have lots of compliance needs. They might need to store their data for 180 days to be compliant with whatever the compliance is within their industry. So yeah, there's lots of questions through this. Thomas, would you put any? That is actually pretty cool because you showed the architecture but it does not just give you exactly the default. Still you'll be able to actually easily modify different solutions. So if you, for example, let's say you don't want to use change tracking in your solutions for whatever reason. Again, obviously you have this documentation to explain what it is. You could actually just go out and say, okay, I don't want to deploy that. And so this is pretty awesome. I really like how the team has done it. Looks fairly simple to me to go through. I mean, I wish we had this way earlier years ago, but now we have it and it should be very beneficial for a lot of enterprises out there. Yeah, and obviously all the answers are tech. Yes, at the moment, Bill, like you said, if you don't want to use something right now, you don't have to have it enabled when you walk through this wizard. You get through to the networking piece again. You can deploy things if you want them. You can deploy things if you don't. Obviously I wouldn't want to do an express route gateway on my sub because I would suddenly burn my credits on my subscription right now. But obviously that's something again, if you're planning for, if you want that hybrid connectivity back to your own prem environment that you can start to actually plan through as well. One thing I am actually working through this in the portal obviously through the ARM template that was on GitHub, but we also have it in terraform form as well. So if that's something that you preferred, I know a lot of organizations are having debates about, do we use ARM templates? Do we do bicep? Do we do terraform? The options there in terraform, if that's something that you want. And then you could look at doing the pipeline things through Azure DevOps or GitHub Actions to deploy this as well. So there's multiple options there. You don't have to use this GUI interface, but obviously the GUI interface is actually quite a nice way of doing it. I think this is awesome because this is just, you answered just one of the questions which was coming in. Is it also like, can we also use automation and infrastructure as code? Absolutely, right? The great thing about that is then you can later on even go and obviously like from the concept of infrastructure as code doing changes within the code to actually like edit your deployed environment. One thing I also want to highlight. So for example, I know that a lot of you probably say, well right now we don't have an express route, but later we will. Or for right now we don't have, we don't need the hyper connectivity. We just want to start an Azure environment and we obviously have reference architectures for that as well. Can I like go from like starting smaller with another architecture and then still add things later if I want to? Yes, absolutely the options there for you to do that. And again, this is where a lot of the design comes back into play, Thomas, because you'll start to think about these questions. You'll have done all your discovery. You'll have figured out what your success measures are and actually forecasted where you want to be as a company, you know, in three years or five years or whatever that metric might be. So right now you might be saying, well, we're only going to deploy this brand new workload into Azure, but in six months time we want to start a data center migration. So we have to think forward that we might need an express route, that we might need governance, we might need something bigger. So again, I'm going to hammer the hot point again, just that that design decisions really help you pick the right one. You can pick the wrong one. That is something that some customers have unfortunately done, but again, if you walk through the documentation and walk through the design decisions, hopefully you will lead down the right path. But again, it's no disaster if you haven't because a lot of the landing zone architecture can be scaled and can be refactored. We do have a documentation as well in the cloud adoption framework that talks about refactoring your landing zones. So because I think as you said, landing zones didn't really exist when we were doing consultancy. So a lot of organizations already are using Azure, but they now want to maybe look at using the cloud adoption framework and landing zones going forward. So you can definitely refactor. You just have to again, sit down and plan it properly, if that all makes sense. Yep, absolutely. And I think one of the questions as well is about, there's some of the landing zones don't have a lot of policies in them. There are some policies, the basic ones that a lot of organizations meet, but if you need more as an organization, you can build on that basic landing zone that we have. So if there's more policies you want to add in, then absolutely add them in. Again, we can't necessarily cover all the scenarios for every business and every industry and every vertical that there potentially is out there, a nuance that everybody needs. But hopefully these landing zones give you a great starting point, a great point for jumping off into your cloud adoption journey. And I think that's one of the key things that we have to mention as well. Absolutely, absolutely. I actually think we're running out of time. We're hitting that 30 minute mark, which has went super quick. So thank you everybody. Thank you Thomas as well for being here with me and answering all these questions. Yep, that was a great pleasure. Again, we have the link here. You can see you can find more. We will add more resources. Please also let your questions come in there. We will definitely try to answer as many as possible and let's keep the conversation going. And if you want to hear more of us, obviously leave a comment and we will be happy to do more. Yes, thank you everybody and have a great day.