abccccc.pdf

Types of cloud service and we use this term the cloud. So really when we think about a cloud. What are we really talking about? So understand what are the key principles and features we expect from a cloud. We expect to see agility. So agility in terms of there's lots of different requirements we ha...

Types of cloud service and we use this term the cloud. So really when we think about a cloud. What are we really talking about? So understand what are the key principles and features we expect from a cloud. We expect to see agility. So agility in terms of there's lots of different requirements we have, there's lots of different types of service. So I want to be able to use the right service that meets my exact goal. My needs might evolve, so I want to be able to change what I'm doing as my needs change. I don't want to be stuck with a certain technology, but also my usage amount is going to fluctuate over time. So agility is all about types of service and amount of service and that really leads into this idea of kind of consumption based. I want to pay for what I'm actually using at any given second because again, that agility, there's seasonality. The amount of work may vary by hour, or day or week or year, month, maybe multiple years. So I want to be able to handle that by only paying for a need at any moment in time. We think about high availability, ha. I want to make sure that yes, the basic infrastructure that my service is running on is resilient to certain types of failure, but it's also mechanisms in place to help me architect my services to have high availability. Maybe distributing them over different racks, maybe distributing them over different datacenters in a small area, maybe spread over data centers with hundreds of miles between them. We also think about. Faster recovery, which builds into that high availability. But this time we definitely want that big distance. I want big distances, hundreds of miles. So there was some natural disaster. It's not going to impact all of our deployments. And that agility I talked about scalability. I don't want to worry about running out. I don't want these little islands of resource that of this island could run out. When we think about the cloud, we think about pooling resources together. So this massive amount available to me. So there's always enough resource to meet my needs. Now, when I think about a cloud, so this is just thinking, OK, these are the definitions of a cloud. There's different types of cloud. We often think about. Hey, yeah, the public cloud. But that's not the only type now, obviously. There is public cloud. So I have the idea of a public cloud. E.g. Azure. Azure is an example of a public cloud. When I think about a public cloud, this is typically externally hosted. Buy some provider. It's going to be multi tenant. It's not typically infrastructure dedicated to me. I might access it over the Internet now. It doesn't have to be exclusively over the Internet. There were certain ways I can get private connectivity. Could be a VPN, could be a private connection, but typically and by default it's going to be Internet facing. These are very much going to have the idea of being consumption based. I expect to pay for what I'm using that's going to be a key tenant of that and I think about many locations. I'm going to be able to pick, well, hey, yes, it's the cloud, but we still have to understand geography. So I can be maybe close to certain customers because that latency thing, the time things take can be a big impact and want to distribute things around. When I think about Azure, for example, well, there's this huge number of regions. So this is kind of an infrastructure map that we actually have available on the Azure website, if I skip the intro. And just explore the globe. What we can see is there's just a huge number of regions available. Actually make it 2D to make it quicker. All of these little blue dots, these are regions, these are all distinct sets of infrastructure where capacity is available. All over the world. So I can go and create resources there, so there's just a massive amount of these available to me. So that's the public cloud, but realize I can also have. Private cloud. Now really, what is a cloud? Take everything else away. Really what we're talking about is capacity. There's some capacity that exposes a certain set of resources that I can consume, and there's going to be certain APIs and interfaces to actually use that well. Likewise, I can have capacity on premises, it could explode certain resources like VMS or containers, and I have certain management infrastructure. Who maybe facilitate the idea of a cloud pulling things, user self-service, showback, chargeback, all of those types of things. So here I could have a private cloud that's basically running on my infrastructure so it's on premises. I might be able to do quotas and policies to help control. But I'm using my on premises infrastructure. So that's private cloud and then we have the idea of hybrid cloud. As you would expect with hybrid cloud is essentially both of them. Maybe I'm using private cloud on premises to host some work, maybe I'm using public cloud for other types of work. Maybe I run it on premises but in busy times that variable load. I burst out and start using the cloud. All of those things are available to me. So I have these different types of cloud. But absolutely Azure is an example of a public cloud. Now with that, there's things like operational expenditure, capital expenditure, and so those are all about how we pay for things. So I can often think about anything on premises CapEx, OpEx and consumption-based that's typically going to be capx capital expenditure, IE I have to kind of pay for it up front. I buy my server, I buy my license, I buy my data center and then depreciate it over a certain period of time. So I have these assets that has a certain lifespan and the challenge with that is we have to do all that investment up front. So that could be fairly painful. I can compare that to the public cloud, what is going to be OpEx? Operational expenditure, I pay for it as I use it, which this OpEx really plays into that consumption based nature of the public cloud. I pay for what I use. There isn't this big upfront cost. I pay for it as I use it and that's really powerful because we've CapEx again I get certain assets and I have to use I have to use them for a certain period of time to get my value for money and I lack a certain amount of flexibility. Whereas when it's OpEx and I pay for what I use, I can change my mind. I can start using a certain type of resource and then say actually that's not the right one for me anymore, delete it, create a new type. I don't lose any money. I change for what I'm doing. If I'm using less, I payless, if I'm using more, I pay more. So if I think of any type of workload where there's some variable load. Typically the public clouds could be very uniquely suited for this to work. For example, you think about scenarios where maybe it's the idea that it's on and off. Maybe I'm a tax company and I only run for a few months a year. Maybe I'm a startup company and I'm growing really fast. Well, do I want to go and pay for all that hard work up front when I may fail? No. Maybe I just have these idea of variable loads and I just want to pay for what I'm using. So there's all these different scenarios where this consumption based nature really is key for this to be successful. So let's focus on this idea of the public cloud. Shared responsibility and types of service Now one of the big focuses we have around the public cloud is this idea of shared responsibilities that both the customer I, me using Azure and the provider Microsoft. They have certain responsibilities for different aspects of the service. Now that responsibility will change depending on which service I'm using. We often think about there's different layers to a complete solution. I can think sure there's things like storage. There's network. There's the service, the compute itself, there's some type of hypervisor that basically creates VMS I can use. Then inside that VM there's an operating system, there's a run time like .net or J2E. Then I get my app. And then my data and realized that as a business, the things we really care about is the app and the data. That's what sets us apart from other companies. So that's where we really want to be out of focus. So when I think about those layers, that are what we care about. If we think on premises, well, we're responsible. For all of that. So here the customer. Is responsible for all of the layers. You may have different teams, but ultimately it's all you as the customer. When you start to move to the cloud, you typically start with IaaS infrastructure as a service. With infrastructure as a service, I can really think about this line. There. So now the hypervisor, all of the fabric, the server, the network, storage well. With IaaS, the responsibility is let's just say Azure. Microsoft as the provider are responsible for all of those things. You get a service offered to you, you don't manage any of that. What you get as the customer is for what is inside. That virtual machine. So that includes things like, hey, I can pick the operating system, is that windows? Is that Linux, but there's all the responsibilities for that. OK, responsibilities for that means I'm worrying about things like. OK, patching it. The backup. Config. Antivirus, firewall, the list kind of goes on. There's all these responsibilities that I have, but I have full access to the operating system, so I have all of that flexibility. So in this world we've IaaS, we're really talking about kind of virtual machines. And kind of virtual machine scale sets which we're going to come back to more detail of what those services are. But for those, hey I full access to the operating system. So the most flexibility, but I have all the responsibility as well. Then we get to platform as a service PaaS. So here the line of responsibility. Shift all the way to there, so now Azure is responsible. For basically everything, there's still an operating system, there's still runtimes, all those things happening. I'm not responsible for that. I may not even see it, depending on the type of service what I'm responsible for. Is my app and my data. So obviously if I'm creating a custom service, I'd rather use this as my company what differentiates me as my app and my data. I don't really want to be in the business of managing VMs and worrying about backup and patching and all of that stuff. So if I can, we like this idea of PaaS and you'll hear services like all Azure container instances, Azure Kubernetes services, app services. You'll hear about things like functions. And logic apps, serverless offerings. And again, we're going to come back to all of these, but these are Paas offerings. And then finally I'm going to do it in a different color. You have software as a service. The whole point of PaaS is it's providing these blocks. I can just focus on my app and my data and it's this is what provides the business function. The PaaS service on its own does not provide a business function. With SaaS, it's providing that business function. For example, this could be Microsoft 365, it's providing me SharePoint, it's providing me collaboration, it's providing me mail, whatever that might be. It's all provided I don't have any responsibility for the platform itself. I might do little things like administer users to enable them for a feature, but I'm not patching exchange or patching SharePoint. There's dynamics 365, there's all different types of SaaS, there's third party SaaS solutions, but I am not managing over those. And again, just the key point here. Is I kind of want to get as far that way as I can. Because I don't want responsibility if I can get away from it. Regions, environments and Availability Zones OK, so let's dive into really what we think about when we think about Azure. A big focus is on kind of IaaS and Paas and there's a kind of a joke. There's no such thing as the cloud. It's just someone elses PC. And there's an element of truth to that. If we think about that idea of capacity, well, I need capacity, I need compute, so servers, I need network switches to connect things together, I need some storage. So that has to live in some physical space. I talked about regions already, that flexibility to have many locations and so a region is really one of the key building blocks when we think about Azure. So let's explore regions. So I can really think about the idea of Azure has many many regions. I showed them already and I can think about a specific region. Is east US or West US? And it's made-up of multiple physical locations, so I could think about, OK, well I have a region here. And within that region, there's multiple physical buildings. Now, what really defines the region is those buildings are all fairly close together. We talk about the idea of this two millisecond latency envelope. Don't worry about that too much. It's basically the longest amount of time saying can take from the region to the edge of the region to talk either very close together. So I might have a region like E. US. And then there's lots and lots of other regions. This could be a completely different region that would have its own buildings that might be W US, for example. So we have all of these different regions. And then the reason we have different regions is, well, there might be certain data sovereignty requirements. I might be in a certain country that requires me to have my data remember my app. In the same country, so there's requirements to host the data. So by having lots and lots of different regions, hey, I can stand up my services in a region in my country to meet data sovereignty requirements. Also, I want multiple regions so I can have DR. I want maybe hundreds of miles. Between them so that if there was some natural disaster it's not going to impact my other service. Also yes a latency is the boundary of a region, but might have customers all throughout the world. From the customer to the region takes time. So I want to be able to put my services all throughout the world, maybe says an instance close to my customers, so they get a really nice experience when using the service. Now. I'm talking about Azure and regions in Azure. The reality is there's actually more than one Azure environment. There are several. What we typically think about is kind of the commercial, like the regular Azure commercial that we all have access to. That's kind of how we think about it typically. But there's actually multiple regions. It's not just that commercial region and we can see this. So if I jump over for a second and we go and look at a command prompt, so if I just jump over to this makes a bit bigger for you, I can actually do a get. Easy. Environment. And notice what we see. We actually see there's Azure cloud kind of that regular commercial cloud. Then there's also a China cloud. And an Azure U.S. government cloud, now there is also an Azure German cloud, but that's actually getting a lot less investment now because of changes to regulations, changes to just regular regions. We're not going to typically see that used as much. But certainly we can think about, well, there's this China cloud and this US Gov cloud. So why are there these separate regions? And it's really about compliance and certain regulatory requirements that I need to meet. So yes, we have commercial which has a set of regions. But then there's also China. Now China has requirements that it has to be operated by a Chinese company. So the China environment is actually operated by 21 vianet and they're basically licensed the Azure technology. So it has its own sets of regions. And then obviously we have kind of the US Gov. Which has its own sets of regions, so they each have their different sets of regions. US Gov for example, has a whole bunch of other regulatory standards that it meets, for example CGS, ITAR. There's a whole bunch of these available for it. But the idea is if I'm a company, maybe a government entity, hey, I have certain additional requirements that are not met. By the commercial environment, well, I would use the US Gov. If I'm a Chinese company and I want my services hosted in China, I would use the China environment, which again has its own regions, has its own Azure AD, as does US Gov so these are all essentially completely separated. They're different physical facilities, they're different logically, they're different networks and different identity providers. They are really isolated. Environments to meet whatever regulatory requirements that I may have for my particular workloads. And even when we look at the regions, you'll notice, well, some of them are particular environments. So we have this idea. We have multiple regions for those different reasons. I want Dr capabilities to have a big distance between them. Regulatory, hey, I need the region in the same country. I am just, hey, I want it close to my customers. So these are all super important and that idea of for disaster recovery is actually a key concept. So there are pairings in Azure. Said. Certain regions appeared and we can actually go and look at these pairings. And what we can see is this is showing us all of the pairings that exist. Now what you're going to see here? Is that the pairings are in the same geopolitical boundary. For example, Asia replicates to Asia, Australia to Australia, Canada to Canada. The only exception is Brazil S currently goes to South Central US. This is because Brazil only had one region, so it had to replicate outside of Brazil, but South Central US does not replicate to Brazil if you go and look. You'll kind of see South Central actually replicates. To North Central US kind of see those there. So nothing ever replicates outside of the US from that capacity. You also see got like the US government regions here, US Gov. Arizona, Iowa. And you can also see those China regions as well. So we actually see these different environments as well, which all have. So not Canada, they all have their own regions. So those pairings are used by certain services. So there were certain services in Azure like storage and key Vault that use those pairings just behind the scenes. So that's how it does that resiliency. Additionally, those pairings are useful if I was deploying my own services, when Azure rolls out updates, it will not roll them out to paired regions at the same time they introduced a problem with a software update or you don't want to take down the primary and the Dr region. The same update. So it's going to stagger those updates as well. So I can think about a region as a really big blast zone. If there was a problem, it shouldn't impact other regions. However, even within a region, as we saw, there's multiple physical buildings. And what happens in many regions is those physical buildings, will they have independent power? Cooling. And networking I communications. So they're independent. So these are then exposed as availability zones. Now there's more than three buildings that can think about. There's lots of other buildings sitting in that region, for example. And I can now think that, OK, great, I could now put my services distributed over multiple buildings. So now I have resiliency if an entire building has a problem by distributing my services over multiple buildings. The way this is exposed. Is we're going to have something called a subscription. And for each region, if it supports availability zones, you'll actually see 3 availability zones. You'll see an A1, an AZ two and an A Z3. Now that may map like that for that subscription. If I had a second subscription for the same region, it will also see 3 availability zones. But they might map to completely different buildings. Mayas one could be that building my AZ 2 could be that building, my AZ3 could be that one. So there's no consistency between different subscriptions. The whole point of this is isolation within my subscription. Yes, as one will always be the same building AZ two will always be the same one, but there's no consistency between different subscriptions. When I think about services, services use these in different ways. For example, some services you will see are zone. Redundant. If it's zone redundant, it spans the availability zones just as part of the service, so it's automatically just redundant. There's nothing I have to do. Office services will be zonal. If it's zonal, it gets created in a specific availability zone, so I tell it the availability zone and it will go to that availability zone. But to get resiliency I need to create another instance in a different AZ because the whole point is I want to be distributed over multiple buildings. So some services it's just native. I can say hey I want to be zone redundant and it will make it resilient. Others have to get pinned to a particular zone and then I need to create multiple instances. To get that protection, if something happened to a building like a VM, a VM cannot span availability zones. A VM can't exist in multiple buildings. So we'd have to create zonal VMS. Now create maybe 3-1 in as one, one in a Z21 in a Z3. They're all provide the same service. We can see this. So if we jump over, if I actually go and look at a certain type of resource for example. If I was to look at a public IP address when we create a public IP, we actually get the choice. So I can say down here at the bottom availability zone and it's letting me pick the default is zone redundant. But also I could say actually I want to make it zonal, put it in a Z2. So for some services you'll get the choice, other services you won't. Of a services have no ability to span multiple availability zones like a virtual machine. It understands availability zones. So I can say here, use an AZ, but there's no option to be zone redundant. All I can say is pick which AZ I actually want to create it in because of the type of resource. So it's really important to understand kind of those concepts. And the key point here really is that. I'll pick the one. That makes the sense for what I'm trying to achieve. So if I think about how do I use these, if you see a question and it's hey, I need to deploy a service and I want to make sure my service can survive the failure of a data center. Ping availability zone, that's the answer if you don't have that option. Remember I'd have the same protection if I use multiple regions because obviously they're different data centers as well, but that's typically a very different architecture. That would tend to be more Dr purposes because of how we can synchronize data. So if it's hey and hey within a region, I need protection from a data center failing, do I use a availability set? Availability. zone Or resource group or any of those things. Hey availability zone is a distinct physical building. We've isolated power calling, networking. It helps me by deploying my services over AZs from any particular failure. So that's kind of a key point. So the regions and the availability zones, they're physical constructs. Then we get these logical components of resources we want to use. Identity, authentication, authorization and Azure AD So the first kind of building block we're actually going to see is identity. So we'll often hear about Azure AD. So I'm going to draw Azure Active Directory. And you might just hear it called AAD. So Azure AD is a cloud. IDP an identity provider. It's used by Azure and many many other types of service. Within there I have things like users, I have groups. I can have devices, I can have applications defined. I've all these various things in my Azure AD and it speaks cloud. What do I mean by that? Different types of protocols conducts authentication, authorization. So it speaks things like hey, Openid connect. SAML WS Fed Oauth 2. They're all things we typically think about for the cloud in how things can work together. Now I talked about authentication, authorization. So what am I really talking about? So authentication and I can really break some of these down South, we typically think about these around authentication. Authentication is all about proving. Who I am, that's what authentication is about. You may see it written as all. N so who am I? I want to prove I am. Who I say I am, or an app or service principal is. Typically we prove that by a number of ways. Something I know I know is typically like a password or a pin. It might be something I have. It could be a token, some sort of device that I can put in, or maybe it's a time based that shows a code. It could be my PC, it could be my phone. Well, it's something I am, IE a biometric. Fingerprint 3D face scans, smiling at the thing. So I want to prove who I am by one of those kind of things. And what we like in authentication today is the idea of MFA multi factor authentication IE. Two plus of these and I want just one of them. I want at least two of them. Hey maybe it's something I have my PC and then a pin for that PC that will be multi factor authentication. Maybe it's going to be a code from my phone while the code from my phone I have the phone. And then it's maybe unlocked with my biometric. So I want multifactor authentication to get that really strong authentication, give me more confidence. I really am who I say I am. You'll hear about things like hello for business that uses your PC and a trusted platform module chip inside the PC and then you unlock it with maybe a biometric or PIN and it's something I have the PC. So with that unlock, it's MFA now MFA is available to all users. The Azure AD, if I turn on security defaults, I don't get to configure very granularly how that's going to work, but I can get it for everyone for certain actions. If I have Azure AD premium, then I can control the multifactor authentication through things like conditional access, which we're going to talk about. Global administrators always get the full kind of MFA set of capabilities, and Office 365 users get a subset of MFA for the Office 365 apps. So authentication is who I am. Then we talk about well. Authorization. So authorization is really about. What? Ohh trying write too fast. What I can do? So I've proved who I am. With authentication now, once I'm authenticated, it knows who I am. Authorization says what I can do, and often we'll hear about things like role based access control as a whole part of controlling well, what exactly can I do? Now I talked about with Azure AD, we like this idea of conditional access which can really feed in to do I require MFA if I have that premium P1 or premium P2 license and it's a big part of hey driving some of that authorization. So I can think about conditional access. Conditional access and SSO Kind of seeing as that Gateway anytime I ask Azure AD for a token which is how we actually go and communicate to other things. So what I can do with conditional access is based on certain conditions. I can have requirements, so I specify conditions and then I add requirements. For example, hey you need to MFA, you have to be on a trusted device, you have to be hybrid Azure AD joined and if we super quickly just jump over. If we go and look at Azure Active Directory. And we look at security. And on the security, we look at conditional access. We can create policies and we can see, hey look, we have assignments, we can assign it to certain users and groups or certain roles. I can target certain cloud applications. So any application that trusts Azure AD. Could be targeted with its own policy. I can add lots of different conditions. And the users risk the sign in, risk the platform they use in what location they're coming from device state. And then I can have different controls. Hey look, I require multifactor authentication or I require it to be marked as compliant or it has to be Azure Hybrid joined and I can pick. Well do I require all of those things? Or do I just require one of them to be true so I have a lot of control around that. So conditional access is all about, as the name suggests, giving me growing granular control about when a certain application should be available and then what needs to be met to make it available. And that's kind of a key point. We have this Azure AD, this cloud identity provider and the whole point of this is we have all these different cloud applications. That will trust Azure AD for that authentication authorization. Obviously Azure is an obvious one, so it's going to trust a particular Azure AD tenant. I have an instance of Azure ID, it's a tenant for my company, but also so does things like Microsoft 365. So do thousands and thousands of other third party cloud applications can all use Azure AD. And So what that's going to give me is this ability to give a great experience for the end users. Because instead of having a different identity every single cloud application, which could be hundreds, which would be a disaster, I can have one identity. Now most of the time what will happen is a company already probably has an Active Directory. This is an. On premises directory system, Active Directory domain services and they already have users in here and groups in here and maybe other things. So what will happen for most companies is you're actually going to synchronize. Using something called Azure AD Connect. So this is going to take the users and the groups and synchronize them up into Azure ID. So my user here will also has an account up here and it does a number of different things. Once I have that synchronization what I can then turn on is SSO. Seamless sign on. What that means is if I'm authenticated already, if I go and access one of these cloud applications, I'm not going to get prompted to authenticate again. I already have the required authentication in place so we can go and check hey conditional access for the authorization. There's certain requirements I have to meet, but not going to get prompted to re enter my password or maybe MFA again. If I've already got a strong authentication, I'll just seamlessly be able to access those. So I'll syndicate maybe once at the start of the day. And then I'm good. It's not going to keep prompting me over and over again. So this is all of the idea that, hey, Azure AD becomes this central identity provider, not just for Azure, but for thousands and thousands of other applications out there. Governance (RBAC, policy, budget) Now. This is great. This idea the central Azure AD we have identity in place. But there might be other requirements we have when we start creating resources, hey, what regions we're allowed to create in, what types of service we're allowed to create, what types of replication we want. And if I think about year old days, I think about this the on premises days if I was a user. And I wanted something what would we do? Well, there was probably kind of an IT operations person it OPS and they had access to the servers where you could actually create stuff. So what would happen is I would put in a request, hey, I want this thing please. I wanna VM or 10 VMS or a database and the IT operations, well what they would essentially be doing. Would be the checks. OK. You put in this request, does it meet our requirements in terms of governance, in terms of regulatory, in terms of all these other things? And only if this passes would they then go and actually create? So their IT operations person wasn't just the person that created things, they were the ones making sure our requirements for compliance and everything else were being met. So that was great. Well, it doesn't exist in a self-service world if we take this same scenario. But now I think about the cloud. I think about Azure for example. Well. It's self-service. There is no IT operations person in the middle of that interaction, but I had the same requirements that IT operations person would check, hey, we're creating right things. It would then maybe give me the right sets of permissions. It would maybe enforce certain budgets how you're spending too much money. I'm not going to let you create these things. So those controls that used to be in place, those checks I need to do another way. I still need those checks. But now I need Azure to do them. So let's think about, well, exactly what those checks could be. So we talked about, well, maybe they gave certain permissions. So a big one here would be role based. Access control. The idea, remember. So if I think about all these things, this is what I can do. So role based access control in Azure is all about the idea that we have various roles. And a role is just a set of actions. There's all these different resources in Azure that depending on the type of resources, different actions you can perform. So we have roles. So then a role, maybe it's easier to just go and see one of these quick. So if we were to jump over and I just went and looked at, for example, a virtual machine and I'll just pick one. And we can look at access control. And I can look at the roles that exist. That was I can. There's always different roles now. Key ones are kind of owner that zoomed in a long way. Here's owner, contributor, reader. These are generic and available for pretty much everything. As the name suggests, owner is the owner of the resource. They can do anything, including change permissions. A reader can read anything, but can't change anything. A contributor can do pretty much any action except change permissions. So they're like the owner, but they can't change permissions. But there's many other roles that are a subset. For example, here I could have a virtual machine contributor. And I can go and look at. Well, here are all of the actions they can perform. So we can see a list. So all of these different things based on a different types of resource they can perform all these different actions and so role based access control is all about the idea that I have a certain role. That I want to give to a certain identity. That could be a user, it could be a group, it could be a service principle which represents an application. At a certain scope. I'm going to talk about what those scopes are, but management group, subscription, resource group, resources themselves and those things together are a role. Assignment. We can think about role based access control is about giving a certain entity a user or group, a service principle, a certain set of permissions. At a certain scope. So that's hey, this is what you can do. So next thing I care about is policy. So if RBAC is kind of about OK, what I can do and who can do those things, policy is going to control maybe the where and the how I can do these things. So this is all about guardrails. If you think about that IT operations person may be controlled, you could create things in these locations of this type. That's exactly what a policy can do. So actually I might change this. I might make this simpler for you to think about. Maybe this is more about who can perform the action and this is what they can perform. But realize the role also controls kind of what you can do. So if we go and look at a policy for a second. If I look up policy. There's a whole bunch of definitions and you'll see a huge number of these, so many on all different categories of types of service. But we could unselect and only look, for example at storage. And you'll see there's all these different definitions. And I could say, hey, storage accounts should use private links, storage accounts should use customer managed keys. So it's accounts should be limited to allowed SKUs IE control which types of storage accounts I can create. So I'm basically putting in all of these different controls and what this can do is I can use these not only to stop or allow someone doing this, I might put it in an audit mode so they can do it, but it kind of tracks and I can use that for compliance. I might. Even used them to correct something if it was deployed incorrectly. There's different ways I can use policies. And rather than having to deploy each of these one at a time, I can actually create initiatives. O initiatives. I just groups of policies and there are many built in. There are additional ones available for certain compliance requirements, like here you can see hey look NIST SP 800 Rev 4 that's 989 separate policies. And so then I can just assign this initiative at a certain scope. Does that word scope again? But what's really nice is again, I can use it to control. But can you also use it for compliance? I can quickly see for each policy or initiative how am I actually doing in terms of that assignment and how my meeting that in terms of my compliance. So I think about policy is about those guardrails. So yes, it can control. I can stop you, I can correct you, but I can also use it for audit purposes. I can see well what is my compliance. So there's different ways I can assign that, but it's those guardrails to help control and again I apply this at a certain scope. And then I think about budget. And maybe that's how much. I want to control how much of something you can create again at a certain scope. And maybe that's, hey, I want to control how much you're going to spend based on what you've spent so far. Or maybe I'm going to look at trends and say, hey look, if you carry on as you are, you're going to spend this amount. So I want to kind of stop you now or alert you now so we can kind of change track. For all of these different things, they're actually going to get inherited because we're going to be able to apply them at this scope word. So all of these apply Scopes - Management groups, subscriptions and resource groups at a certain scope. So what are those scopes? So we talked about, we had Azure, that's the cloud and we talked about, well, what actually happens is. That Azure cloud we have trusts a particular Azure AD tenant. So my Azure subscription is going to trust a certain instance of Azure AD. Under my Azure AD we have something called a root management group. So we're now talking about is this idea of management. Groups. And I can create a hierarchy of these so I can create this whole hierarchy of management groups. To fit my needs. This could be based on maybe dev, test and production. Different countries, different business units. They're there for my benefit to. Apply these things to so management groups, RBAC policy and budget at any of these levels can have these applied and I could apply it to all of them. We tend to be more loose and general at the top and get more specific as we get closer and closer to actual resources. But I can have up to 6 levels of management groups, not including the root, but they're designed around. Hey, I want to apply. RBAC policy. And budget and for everything we're going to see here, they are going to get inherited. All the way down to everything we're going to do. So if I assigned a policy, this management group, it will get inherited by this management group and this management group and then everything underneath as well. Same for rbac. Budgets would roll up to wherever I set it. So management groups are there to help me assign RBAC policy and budget and for loose organizations. So if the management group is there to help me kind of structure and control those governance type features when we actually create stuff. So the next construct we have. Is the idea well under a certain management group? I create. A subscription. And I can have lots of subscriptions I might create different subscriptions for, again, for different account teams, different business units, different purposes. Subscriptions do have limits now, they're pretty big, but we can go and look and Azure subscriptions and service limits page goes through all of the different limits that apply. See, some of these numbers are pretty big. So maybe I have to have certain different subscriptions just because? I've maxed it out. I have so many things. I need to have a different subscription just because of that. That's not super common. What's more likely is I have different subscriptions for some kind of structural benefit for how I'm organizing. Or I want certain isolation because the subscription is a base unit of Azure interaction. It's part of the agreement between the customer and Microsoft. It uses a certain billing model, like pay as you go. Maybe it's part of an. Surprise agreement. It's kind of a billing boundary. It's what it's really useful for. Well, all of those things are back policy and budget I could apply into management groups. Yep, I can apply them here as well. So I can apply RBAC policy and budget here as well. Which will also get the ones that were applied to management groups above it. So I have these different subscriptions. Now once we have that and I want to create something. Well, when we create resources, resources get created in a resource group. A resource group exists in a specific subscription. I can have lots and lots of resource groups in a single subscription. I cannot nest them. And what can I do? A resource group? Hey I can apply role based access control policy. And budget. You get the idea. And again these all inherit down South, the resource group would inherit the ones from the subscription and the management groups all the way down. So it just gets more and more granular. So behavior, certain resource group has a certain app that needs a different policy. Saying more specific hey I can do that or a different set of role based access control I can do that there as well. Resource groups are not a boundary of use though. What I mean by that is, for example, I might have in this resource group of virtual machine. That's connected to a network interface card. Maybe this resource group over here has a virtual network. Well, I can still connect the nick to that virtual network. So resource groups are not a boundary of any kind of connectivity. They're there partly for these role based access control policy budget. But I really think about resource groups as things that have a common. Life cycle. What I mean by that is that things are going to get created together, they're going to run together, ultimately they're going to get deleted together. So I put them in a resource group as that boundary really that coupling together. So it makes it very easy for me to understand because most likely all of the components in the same service, well, I probably want to have common role based access control, maybe common budgets. When I deploy and provision things, I'll push it into a resource group. So having that ability to have. These common life cycle, that's really a key reason we would use resource groups. Think about, hey, I finished with a certain project, rather than trying to scour around 50 different places that project was in that resource group, I can just delete that resource group and that's really the key point around there. Now. OK, so we have these key logical constructs. Management groups, subscriptions, resource groups. I can apply those key governance constructs while based access control policy and budget. So understand what those do. Well based access control? Well, who can do? Certain actions policy. What can I do? I can put guard rails and control that stuff. Budget or how much of that can I do? And all of those things can be applied at these scopes to help. Hey, I don't want to have to deploy the same policy in RBAC to 100 different subscriptions. They can all roll up under certain hierarchy management groups and apply it at the management group. So it makes my life easier. ARM and management interaction Now when I think about this, these are all inherited down. Great. But how do I actually interact with this thing? See if I think about. Well, there's Azure. There's actually. Thank God the Azure. Resource. Manager. Arm. This is how I talk to Azure. So no matter what I'm doing, I'm actually going to talk to the Azure resource manager. Now, Azure itself is actually made-up of. I talked about creating resources of VM and network interface card, all of those things. So Azure is actually made-up of resources. That are defined in resource providers. So that tells me all of the different types of resource I can actually create if we jump over and look. So if I clear this out for a second. If I do a get a. Resource provider. There's a lot of different resource providers in the system. And what we can see. For any of these particular ones, you can start to see hey, look. There's resource types listed. But if we dive into one of them. We have particular provider namespace. Microsoft dot compute. And that means to capitalize that and we can format it as a table and just look at resource types. We'll see. There's just a whole list of different resource types existing in here. This is just compute. Now you see obvious things you'd expect. Virtual machines. That's a particular resource. Virtual machine. Scale sets. Locations. Remember all those different regions? Um, But then we'll see other things. We'll see things like disks. Disks are part of compute. Says all these different types of resources that actually exist within Azure. So the Azure resource manager is really what understands and facilitates that. And everything in Azure is a resource, even a VM. So we talk about a VM as that. It's really simple thing. Well, the reality is even a VM that's simple simple little virtual machine we might have when I go and look at a virtual machine. What I can do is, well, hey, here's a VM. I deployed it to his own resource group, so it's in a certain resource group. If we look at this resource group that contains one VM. It actually contains 5 different resources. O what does it have? Well, it has the VM itself. But the VM connects to a network interface. The VM connects to a disk for its operating system. The network interface connects to a public IP address, and the Nic can use a network security group to control the flow of traffic. And there could be other resources as well. So everything is a distinct resource, but that's good. Because I didn't draw it on the picture, but I can also do RBAC at the resource level. I can go and see all the policies that apply at the resource level because they've all inherited down. And all of those things are available to me here. So the Azure resource Manager provides that management for Azure. So when you hear arm, you can think that the key point of all of this is management. Kind of interactions. And everything is going to use that. So if I think about me as a user. And I'm setting up my machine. I have different ways of talking to Azure. The most common one we are typically going to start with is the portal. Well, the portal. Is talking to Azure and I've kind of shown the portal already. Now the portal is very pleasant, it's very intuitive. The portal is great to quickly look around. I can say, OK, let's look at my resources. I can see my virtual machines. I could go and investigate this virtual machine. Maybe I want to see some basic monitoring information about what's happening. It's great to quickly go and look around. It's good to do little investigations. It is not good to create things to provision. Think about just creating a virtual machine. I have pages and pages of things that I would have to configure so understand the pain point of that. Think about that for a second. If I was going to use the portal to provision resources, I'd have to make sure I did it in a consistent manner. So that's this super detailed document and humans do kind of click the wrong things and important might change, so as I'm screenshot all the buttons slightly different. Try and create 100 of them. I'd be crying so it doesn't scale. It's hard to document, it's hard to compare to a desired end state. There's just so many options, so the portal's great to come and look at things. I would never ever want to go and create things from the portal, but it's good to just kind of look around. Now, there's also something called the cloud shell, which lets me get to things like PowerShell and Bash. If you looked at the portal for a second up here in the corner, you'll see this little icon. So that opens up the cloud shell. So the cloud shell lets me run. So I'm about to show you PowerShell on the Azure CLI. It lets me run both of those so I can pick, but it gives me access without me having to install anything locally on my machine, a bash environment for the Azure CLI, and a PowerShell to run the PowerShell. So that's just natively part of the portal. That can be super convenient. There's also. The mobile. App so this is available for kind of iOS and Android, sadly not Windows Phone. Once again, this talks to the Azure resource manager. The mobile app is great for hey, I'm on the go. I want to quickly look at the state of my resources, maybe look and see if there's certain alerts I could start and stop things. I can access the cloud shell from there as well. So another useful thing. But once again, I'm not going to try and really do any big management from my mobile device. I'm not going to try and provision resources from that. So we get to things. PowerShell Azure module. Now PowerShell is open source. PowerShell is multi platform, Windows, Linux, Mac OS. Which means the AZ module is Windows, Linux, Mac OS. And this is phenomenal for automation. I just want to interact from a command line over here. For example, I've been using this already. You've seen me run certain commands. Hey, I want to go and see what VMS I have super quickly. Ohh get a VM and you can see I've got those commands. And obviously I can use that interactively, but that's also really powerful for automation scripts. I want to automate a set of management actions. These are phenomenal for automation. And likewise, if that's sort of PowerShell based, then there's the AZ CLI that's more kind of from a bash kind of history. I can run it on Windows as well, CMD. And that. Has exactly the same capabilities. So I'm going to jump over to just a regular command prompt now instead. And what we can see here is if I clear this quickly, make this a bit bigger for you, I could do an Azure VM list output table and I see the same information. It's a different syntax because I'm now it's more in the bash world, but I can do the same exact type of things, it's just the syntax is different. So these are super, super powerful for a command line interface scripting. I still don't want to create things with these, although it's easier to create things with this. It's still not the right solution. But again, they go through the Azure resource manager. So so far I've shown you the portal, there's a mobile app, there's PowerShell, there's the acli. We're not creating anything, so keep saying don't create things with this. How we want to create things. There's arm JSON templates. Everything in Azure, the metadata that describes it is stored as JSON JavaScript object notation. And So what I can now do is I can apply a template. To that Azure resource manager and this this is the way we want to do provisioning. And there's a reason for this. This is declarative. And what that means is if I was to create something through PowerShell or Az cli, I have to tell it how to do something. New VM, add disk, what's the script failed halfway through when the change config. I can't just run the script again and change the value, have to use completely different commands. I'm telling it how to do it, it's imperative. This is what I want you to do. With declarative I simply say what is my desired end state. I could say, hey, I wanna storage account. Called A1 and I want it to be a locally redundant storage account. Go and make it so and it will go and look. Does this exist already? Is it LRS? If not, I'll create it. But it's idempotent. I can run this as many times as I want, it has already created it. And it matches, it just won't do anything. Whereas if I run a script to create a storage account an existed it would error. But I could also change my mind. I'll say actually, I now want this to be gears. Make it so and it would ee. The storage account is there, but it's LRS. I'll change it to GRS to match that desired state. So this is kind of where does is so powerful. This is why we want to provision a things with JSON templates. It's declarative. I say what I want, I don't say how to do it. So I can easily go and modify those things and we can actually see so behind the scenes. If we wish to just come and look at really any type of resource, we look at my VM again. And it's going to look honestly, kind of. There's a lot to it. It's not super friendly to actually understand, but you do an export template. And it's actually going to show me. The JSON so here I can see. OK yeah it's a type Microsoft dot compute resource provider of type virtual machine. OK, then there's a name which is a parameter. It's in a certain location, and there's a whole bunch of other. Configurations and properties for that. I can see the VM type. There's a whole bunch of stuff here. But it's declarative. I could run this as many times as I want and it would just make it so. So this is the preferred way to provision things. An arm JSON template, it has massive parallelism. It could create 100 resources, it would create them all in parallel. It wouldn't wait for resource one, then resource two, then resource three. So it's super powerful from that perspective. And what's really useful is it's a file, so I can compare it to what's actually there. But if we think about things like DevOps, I could. Absolutely have some kind of GitHub repo or Azure DevOps repos or whatever. It is something probably git based. I can store that in there. Well, then I get things like version control. I get great collaboration features, so the fact that this is declarative file makes it really good to actually then work with other things. I can have parameter files so I can have different values for different environments, but I can now use this file across many many different types of things. And I can define anything in there well based access control policy. All those can be defined as that Azure JSON template. Now, what you may also hear about is a technology called bicep. So bicep is something new. And it actually transpiles, which means it converts into an armed JSON template. But this is just more human friendly. So I think in the future you're going to see more and more bicep as a friendlier way for us as a human. I want to create this declarative template. Instead of having to try and write JSON, which is really kind of ugly, I could write this really nice bicep file. I've got an example here of a bicep file. So this is create a storage account. And what you can basically just see is how I've got a few parameters. I'm saying I want to create a resource of type storage account and it has a name, location, kind and skew and that's it. So that's me as a human typing that out, which is actually really, really nice compared to the pretty hideous world of trying to actually create an ARM template. So you may hear the term bicep, but it's just going to go and create an arm JSON template. Behind the scenes there were third party solutions like Terraform, Terraforms. Great. Maybe I'm using more than just Azure. I think I've got AWS and Google Cloud. I've got maybe VMware and Kubernetes. I want one declarative technology for all of those. Well, Terraform will let me do that. So total about governance things. There are some other types of governance constructs so I think about this for a second. Rbac is great. Rbac controls what I can do. But maybe sometimes I want an extra check. I want Resource locks, tags and blueprints to say look you can't change this or you can't delete it or at least you have to go and perform an extra steps. You don't accidentally do something. So what we can actually do is we can create these things called resource. Locks. And I can then apply that at different levels. So again, I could think about, hey look, I could apply at the subscription, it will get inherited down. I might apply at a certain resource group, I might apply at a certain resource. And what I can do with the resource lock is I can do one of two things. Can not delete, so I can change it. But I can't delete it or I can say I don't even want you to change it. I can say read only so you cannot change or delete it so I can go and create the resource lock. And then what it would do is if I accidentally went and tried to change or delete it depending on which lock I set, it wouldn't let me. It would say, hey you can't do this, I would have to then go and remove the lock. So it has to be the owner basically to be able to do that. And then once I've removed the lock, then I could go and modify, delete or just delete depending on which one I set and it does get inherited. So if I set a resource lock at the subscription level. Whatever that effect was would apply it to everything within there as well. So that's something I can go and do. Another really useful thing is we talked about JSON was kind of the metadata. So we have these arm JSON templates that are fundamentally talking JSON. Well, there's optional metadata we can set because I might want to be able to identify who's the owner, what's the business unit, what's the purpose, what's the criticality? So if I want metadata, one of the things we can add is something called tags. And again, this is basically metadata. It is a key. And the value. And just like pretty much everything else, I can set this kind of subscription. I could set it up the resource group, I could set it at the individual resource. Now. Important thing. Most things we've talked about get inherited. Rbac policy budget rolls up resource locks get, inherited tags do. Not inherit. If I create A tag at the resource group, the resources within it will not have that tag. So just keep that in mind. If I wanted the resources to copy the tag from the resource group, I could do that with policy. I could create a policy that says, hey look if you're missing this tag, go and copy the value from the resource log. But by default. You do not inherit tags, and again, they're just metadata. I'll use them for different things. If I go and look at for example my virtual machine here. I configured a couple of tags. And I had for example over here where I did one for the cost center. I did one for environment, I did one for the operating system, one for the owner. You might see other ones for the type of resource, you might see an exact billing ID. It could be security, like public or confidential. It could have different regulatory tags. It's whatever you want. This is not a fixed schema. I can go ahead and add any value I want, show me ones that I've done already, but I can go and create a completely new one. I could go and create any value I wanted. If I wanted to control, what do you think I would do? I could use policy. So I could use policy to restrict what I could actually do here and these tags are really useful. I can search and find things with a certain tag value when I do billing. Billing I could actually say hey show me the bill and I want to filter it by tags that have this certain value. So tagging that metadata is super super useful for that. Another key construct we have is, well, I've talked about a bunch of different things so far. I talked about our back and resource group and policy and templates. What about if I've got kind of a new subscription and I want to be able to apply maybe a base configuration? I want to be able to stamp down a certain configuration. Well, we can do that. We have a construct called a blueprint. And a blueprint basically enables me to contain a number of different types of artifacts so I can define resource groups. Then within that resource group I can alley an ARM template which again remember creates resources, I can apply role based access control, I can apply policy and I could create a resource group to