Fundamentals of Microsoft Azure Cloud

In this session, you will learn more about the basic building blocks of Microsoft Azure. Tenants, subscriptions and resource groups. Think of these as the core elements needed to build a strong foundation in Microsoft Azure. It's the first step in understanding how to build your cloud practice. We'll take you through examples of each, using the Microsoft Azure portal and Nerdio for Azure and by the end of this session, you will feel prepared to take the first step towards spinning up your first customer in Microsoft Azure. So, Azure as we all know, is a Microsoft cloud platform. It has both Infrastructure-as-a-Service and Platform-as-a-Service components. It has many hundreds of different types of products in there. We're gonna be focusing primarily on Infrastructure-as-a-Service. So VMs, disks, networks, virtual network cards, things like that. Those are what is referred to as Infrastructure-as-a-Service components as opposed to things that are referred to as Platform-as-a-Service components. Those are packaged services that get to be consumed in a server-less way. What do I mean by server-less way? For instance, Azure has a past services called Azure Files, and Azure Files allows a user to create a SMD share and map to it from their desktop or server just like that share was running on top of a file sever, but you can do that all without using a file server. You kind of accomplish the things that were normally run as rolls of servers which are IaaS, or Infrastructur-as-a-Service, but using PaaS services within Azure. And there are lots of examples. There's things like Azure SQL, which is the alternative to running an SQL server on top of a VM. There is VPN gateway which is the alternative of running a VM with VPM software on it, et cetera. So we're gonna focus primarily on Infrastructure-as-a-Service but we are gonna talk about some specific Platform-as-a-Service components. So the first thing to understand is how Azure and just, you know, the Microsoft Cloud is structured. So at the very top level, you have something that is referred to as a tenant, also known as a directory. So a tenant or a directory normally has the format of, you know, what's called the tenant ID, so in this case, you can see it's @nerdio1013.onmicrosoft.com. Then this sort of an identifier, a human-readable identifier of a particular directory or tenant. So the reason it's called a directory is because each directory has an Azure AD service associated with it. Every Microsoft Service is always integrated with Azure AD, even if you're not using Azure itself and you're using only Office 365. There is an Azure AD deployment associated with that particular Office 365 service. So get top level tenant or directory, kind of the same thing. A lot of times it's also referred to as the account, kind of the all-encompassing thing. This ID that sits in front of the onmicrosoft.com is global unique, which means that, you know, Nerdio 1013, if somebody wants to create Nerdio 1013 as a new tenant, they will be told it's already in use and they won't be able to use it because it's a global unique thing. And once you have an account, I'm sorry, an account, directory or a tenant, then in order to leverage Azure, you need to create something that's called a subscription. So, let's take a look at what subscriptions are. So first of all, let me just point out a couple things here. You can see I have a little navigation menu on the left. This is a very useful little menu of shortcuts that are commonly used. If you wanna get to all of the Azure services, you simply click on All services and you can click and you can search here and you can see this is a list of all the various services that are available within Azure and if you click the little star, that adds it to your list. So I'm specifically gonna look at subscriptions. And what you'll see here right now is I'm logged in as, you know, my email address. I am in a particular directory. So I'm in the ngeterdio.net directory, and this directory is this one right here. It's the nerdio1013, which is what I'm a part of right now and within that directory or tenant, I have a subscription called Nerdio Template VMs and there are different types of subscriptions. So let's click on the Subscription and see what type of subscription it is. So we click on the subscription, it comes up to a view that's gonna be very common throughout Azure and you can see this is a CSP subscription and as a result of it being a CSP subscription, you don't see any cost information. A CSP subscription means that I'm being provided the subscription by a reseller, service provider, cloud service provider, and I, as the end customer in this particular case, even though I have access to the subscription, I don't see my cost information. This is one type of a subscription that you can use. Let's jump back out. If I had no subscription listed in this particular view, then any time I go to deploy a resource, let's say a VM, a disk, you know, Azure SQL, what have you, the very first thing it asks me to do is what subscription it gets put into and if there's no subscription available, it obviously cannot deploy it. So it will ask me to create the subscription. So let's see what it looks like if I wanna create a new subscription as the customer or the end user of this platform. So I'm gonna click Add over here and it's gonna open up an Add Subscription box and you will see here the various types of subscriptions that are available. So, there's what's called the free trial subscription which gives you, I think, $200 to spend, to try Azure out. There's something called the Pay As You Go subscription which is a, as the name implies, it's a pay as you go, you add a credit card as a payment method, and then as you consume resources, your credit card gets billed. Then there are other types of subscriptions which are ultimately pay as you go, but they have support associated with them. So for example, this is developer support, this is professional support, this is standard support. You pay a surcharge in addition to any consumption within the subscription that you have for the support that you are getting. Now what you don't see here is a CSP subscription. So a CSP subscription is something that the reseller who owns this particular tenant gets to add into the subscription. I'm sorry, into that account. Most of our MSP partners are gonna be CSPs. They may not be direct CSPs, which means they don't transact with Microsoft directly. They go through a distributor like Tech Data or you know SherWeb or an InGram or something like that, but they basically will be able to go in and add the subscription from a different portal and make it appear in this particular screen. Then once you have a subscription, let's click on it, within the subscription, you have something called the resource groups. And it's important to keep in mind that the subscription is mostly a billing construct. Everything must live inside of the subscription because it has to be built, but the way you segregate things for organizational and technical purposes, kind of isolate things from each other within, inside of Azure, within a single billing subscription is by creating resource groups that are sort of functionally focused. So if you can have, imagine you have a subscription that's a direct pay subscription. You know, you're the company and you have multiple applications that are kind of independent of each other. So what you'll do is you'll create multiple resource groups, one for each application, and then within each resource group, you would create your various resources which are the services that you can see here on the left that you get billed for by Microsoft. So let me just make a visual representation here. So within subscriptions, you have resource groups, and within resource groups, you have resources. Okay. So this is where you get billed. You get billed at this level and the subscription could be, you know, we talked about it. It could be CSP subscription, it could be a pay as you go, it could be what's called EA, which is an enterprise agreement that large companies use. It could be, you know, what's called MPN. The Microsoft Partner Network where Microsoft sponsors a subscription for you to use for testing purposes and demo purposes. There are many different types, but the thing that makes them all different is how they're built, who's responsible for the billing, how it gets transacted. EA, for example, is something you negotiate and pay for up front. CSP is something you pay for on a monthly basis. Pay as you go, obviously, you pay as you go. FDN is normally pre-paid and sponsored. There's free. All sorts of different versions of the billing arrangement. Okay, now, when you are talking about granting access and getting access to things within Azure, so accounts, users, let's not call them accounts because that's not really accurate. Let's call them users. Users live at this level. So users live at the Azure AD tenant/directory level. So you can have a user, for instance, in this case, it could be [email protected]. And then you can decide what this user has access to within a particular subscription and the way you do that is by assigning that user what's called a role. So for NFA to work as an example, in order for you to use an Azure subscription, you need to provide a user that is an owner on a particular subscription. An owner obviously means it can do everything within that subscription and create resources, delete resources, assign other users, create other users, et cetera. So this is a prerequisite for NFA provisioning is that this user is an owner on a particular subscription. Let me show you what it looks like inside of a resource group. So if you go into a particular resource group, let's look at the templates resource group we have that we use and you can see there's a bunch of different resources. We can see what they are. So you know there is a DNS zone, there is a virtual machine, there is a virtual network interface, there is a public IP address, automation account, all kinds of stuff that make a lot of sense to some of you and probably make no sense to others, but all of these are resources and these resources interact in a certain way and these resources are completely isolated from anything living in another resource group, other than the fact that they all get billed together on one invoice because they're part of the same subscription. All right. Then one other thing that I wanted to bring up now that we understand subscriptions is is this topic that comes up fairly frequently with partners, where if they have a deployment model, they may be using today or that some other vendors and competitors like CloudJumper, for example, uses and advocates, and you know, it's sort of loosely termed hoteling and the concept of the hoteling RDS deployment is when you have a shared active directory force and you have dedicated segregations within that force that could be separate subdomains, that could be a single domain with different OUs for different organizations, but you guys get the concept where you have a common forest, which means you have a common network, which means things are running within the same subscription and the same resource group in Azure specifically and then you have the ability to leverage and we'll talk about the pros and cons in just a second, you have the ability to leverage resources either in a shared way or you can use software and access list to restrict permission. So you know, oftentimes we have to go though the pros and cons of doing the hoteling versus what we call single stack. Single stack is what we are all very familiar with. This is what we've done in legacy and in DC and NFA, this is where you deploy each and every customer completely, independently of any other customer, and you have segregation at the very minimum at the network level. So there isn't any sharing an active directory, there isn't any sharing of resources, it's all segregated. So now that we understand subscriptions and resource groups, let's go through this exercise very quickly. So the common objections to doing a single stack deployment, probably the only and the biggest ones, is the fact that you have additional infrastructure roles that cost you money. For example, if you have a hoteling environment, you can have a set of domain controllers that are commonly shared by multiple customers. So you basically take the cost of that Infrastructure as a Service resource like a VM and you spread it across multiple customers, whereas if you're doing a single stack deployment, then each and every customer has at the minimum to have one domain controller, one file server, one ADFS proxy, one RD gateway, connection broker for using RDS connection. So basically, all the infrastructure roles get deployed separately and cannot be leveraged in a shared scenario. Now the effect of that, if you look at the minimum sizing with all the applicable discounts of those roles, it's fairly minimal, right. So people think okay, well I need all these extra machines. They're gonna cost me hundreds of dollars a month, but really, if you use discounts and reserved instances which is something we'll get into in detail a little bit later, you can really bring the cost of these VMs down to a $20 per month range. So, we're talking about 100, 150, $200, for all of these additional rolls. Still additional cost, but not as much as people usually think and we'll see what the advantages are of doing single stack and those outweigh those additional costs. The other advantage or disadvantage of using single stack, especially for someone who's used to doing a hoteling environment, is now they have to kind relearn a different way of managing the environment. You know, they may be used to working out of a single active directory users and computers screen where they can manage all their customers in one place. Now they have to figure out how to jump from one customer to the other. You get the idea. Once you're used to a certain way of managing it, you have to learn a new way if you go into single stack. Okay, what are some of the pros of single stack and cons of hoteling? So obviously by having a single stack deployment you eliminate a significant amount of complexity and risk by keeping each customer completely independent. I think this requires no further explanation. You have complete isolation between customers, but you still have multi-tenant management without having to log in and out of different accounts. So everything is at your fingertips with the NAP. So you have the NAP, which lets you very easily exit one account and log into another account and kind of do that very rapidly. There isn't much lag between going from one to the other. So, you know, still complete isolation and easy management. When you have a hoteling environment, any time you make a change that is at the shared component level, so imagine you're chasing the database schema because you're deploying exchange or you're installing something under the main controller. You have to conduct what's called impact analysis on the entire environment because every time you make a change, you have to know, well, how is that gonna interact with what Customer A has differently than what Customer B has? And in a environment when you have a small number of customers, that may not be a big deal but you can imagine that that doesn't scale very well because when you make changes to shared components, those could have unpredictable impacts on different customers that you couldn't foresee. So there's lots of impact analysis which becomes very difficult and expensive to conduct and ultimately, still, can result in high risk of issues. You have the ability to eliminate these global issues that arise when certain shared infrastructure components fail. So imagine you have active directory issues that affect the entire environment. All your customers are affected. Or you have a shared RD gateway deployment and there is an issue there that's affecting everybody at the same time. So you eliminate these global issues. You can also eliminate the noisy neighbor problem right when you have people on a shared network environment maybe hammering away at a particular resource, maybe hammering it away at AD or gateway or whatever the case may be, you can limit that as much as possible by having single stack because you have, different customers are split up. You still have that noisy neighbor at an employee-to-employee basis but not customer-to-customer basis. This is where some of the concepts we learned earlier comes into play. If you're doing a hoteling deployment, that, by definition, means you're deploying everything within a single resource group, which means you're in a single subscription, which means you're getting billed on the same invoice without an easy way of attributing your spends and tracking the spend on a per-customer basis. The way NFA deploys the product is by doing it in a single stack, which allows you to put it in single, independent subscriptions and then track the spend very accurately on a per-customer basis. If you have single stack deployment, you can delegate the administration without the concern that somebody is gonna screw something up that's gonna have a global impact. So imagine, again, hoteling environment. You don't wanna give someone global admin rights or domain admin rights because they'll be able to make changes that can affect all of your customers. In our case, that's not a problem. So they can do things, reset passwords, clear home sessions, you know, group memberships, et cetera. You can give full admin access or just selective access, et cetera, okay, continue. You can, okay we talked about it. Give user domain admin rights without concern if they have anything outside of their own environment. It's easier to show compliance with regulatory audits because you can claim, you know, you can say that each environment is fully isolated because it is, at the resource group level. You then have a lot more flexibility with networking and VPN connectivity, so you're flexible on how you design your network, how you set up your AD schema, you could do hybrid AD, which we then will talk about later on for those of you who are not familiar with that, but you could do hybrid AD for some customers and brand new greenfield deployments for others. You can have multiple Office 365 accounts linked to different customers. So a lot more flexibility in the architecture and you have more pricing model flexibility. So think of this as a service provider that's trying to package this and go to market and sell this to a customer. When there is hoteling, again, because it's so difficult to separate the usage of one customer versus another, you then have as much flexibility around how you price it. So you have to kind of blend things together and use averages, whereas with single stack and different subscriptions, you do have a lot more flexibility on how to do it.

In this session, you will learn more about the basic building blocks of Microsoft Azure. Tenants, subscriptions and resource groups. Think of these as the core elements needed to build a strong foundation in Microsoft Azure. It's the first step in understanding how to build your cloud practice. We'll take you through examples of each, using the Microsoft Azure portal and Nerdio for Azure and by the end of this session, you will feel prepared to take the first step towards spinning up your first customer in Microsoft Azure. So, Azure as we all know, is a Microsoft cloud platform. It has both Infrastructure-as-a-Service and Platform-as-a-Service components. It has many hundreds of different types of products in there. We're gonna be focusing primarily on Infrastructure-as-a-Service. So VMs, disks, networks, virtual network cards, things like that. Those are what is referred to as Infrastructure-as-a-Service components as opposed to things that are referred to as Platform-as-a-Service components. Those are packaged services that get to be consumed in a server-less way. What do I mean by server-less way? For instance, Azure has a past services called Azure Files, and Azure Files allows a user to create a SMD share and map to it from their desktop or server just like that share was running on top of a file sever, but you can do that all without using a file server. You kind of accomplish the things that were normally run as rolls of servers which are IaaS, or Infrastructur-as-a-Service, but using PaaS services within Azure. And there are lots of examples. There's things like Azure SQL, which is the alternative to running an SQL server on top of a VM. There is VPN gateway which is the alternative of running a VM with VPM software on it, et cetera. So we're gonna focus primarily on Infrastructure-as-a-Service but we are gonna talk about some specific Platform-as-a-Service components. So the first thing to understand is how Azure and just, you know, the Microsoft Cloud is structured. So at the very top level, you have something that is referred to as a tenant, also known as a directory. So a tenant or a directory normally has the format of, you know, what's called the tenant ID, so in this case, you can see it's @nerdio1013.onmicrosoft.com. Then this sort of an identifier, a human-readable identifier of a particular directory or tenant. So the reason it's called a directory is because each directory has an Azure AD service associated with it. Every Microsoft Service is always integrated with Azure AD, even if you're not using Azure itself and you're using only Office 365. There is an Azure AD deployment associated with that particular Office 365 service. So get top level tenant or directory, kind of the same thing. A lot of times it's also referred to as the account, kind of the all-encompassing thing. This ID that sits in front of the onmicrosoft.com is global unique, which means that, you know, Nerdio 1013, if somebody wants to create Nerdio 1013 as a new tenant, they will be told it's already in use and they won't be able to use it because it's a global unique thing. And once you have an account, I'm sorry, an account, directory or a tenant, then in order to leverage Azure, you need to create something that's called a subscription. So, let's take a look at what subscriptions are. So first of all, let me just point out a couple things here. You can see I have a little navigation menu on the left. This is a very useful little menu of shortcuts that are commonly used. If you wanna get to all of the Azure services, you simply click on All services and you can click and you can search here and you can see this is a list of all the various services that are available within Azure and if you click the little star, that adds it to your list. So I'm specifically gonna look at subscriptions. And what you'll see here right now is I'm logged in as, you know, my email address. I am in a particular directory. So I'm in the ngeterdio.net directory, and this directory is this one right here. It's the nerdio1013, which is what I'm a part of right now and within that directory or tenant, I have a subscription called Nerdio Template VMs and there are different types of subscriptions. So let's click on the Subscription and see what type of subscription it is. So we click on the subscription, it comes up to a view that's gonna be very common throughout Azure and you can see this is a CSP subscription and as a result of it being a CSP subscription, you don't see any cost information. A CSP subscription means that I'm being provided the subscription by a reseller, service provider, cloud service provider, and I, as the end customer in this particular case, even though I have access to the subscription, I don't see my cost information. This is one type of a subscription that you can use. Let's jump back out. If I had no subscription listed in this particular view, then any time I go to deploy a resource, let's say a VM, a disk, you know, Azure SQL, what have you, the very first thing it asks me to do is what subscription it gets put into and if there's no subscription available, it obviously cannot deploy it. So it will ask me to create the subscription. So let's see what it looks like if I wanna create a new subscription as the customer or the end user of this platform. So I'm gonna click Add over here and it's gonna open up an Add Subscription box and you will see here the various types of subscriptions that are available. So, there's what's called the free trial subscription which gives you, I think, $200 to spend, to try Azure out. There's something called the Pay As You Go subscription which is a, as the name implies, it's a pay as you go, you add a credit card as a payment method, and then as you consume resources, your credit card gets billed. Then there are other types of subscriptions which are ultimately pay as you go, but they have support associated with them. So for example, this is developer support, this is professional support, this is standard support. You pay a surcharge in addition to any consumption within the subscription that you have for the support that you are getting. Now what you don't see here is a CSP subscription. So a CSP subscription is something that the reseller who owns this particular tenant gets to add into the subscription. I'm sorry, into that account. Most of our MSP partners are gonna be CSPs. They may not be direct CSPs, which means they don't transact with Microsoft directly. They go through a distributor like Tech Data or you know SherWeb or an InGram or something like that, but they basically will be able to go in and add the subscription from a different portal and make it appear in this particular screen. Then once you have a subscription, let's click on it, within the subscription, you have something called the resource groups. And it's important to keep in mind that the subscription is mostly a billing construct. Everything must live inside of the subscription because it has to be built, but the way you segregate things for organizational and technical purposes, kind of isolate things from each other within, inside of Azure, within a single billing subscription is by creating resource groups that are sort of functionally focused. So if you can have, imagine you have a subscription that's a direct pay subscription. You know, you're the company and you have multiple applications that are kind of independent of each other. So what you'll do is you'll create multiple resource groups, one for each application, and then within each resource group, you would create your various resources which are the services that you can see here on the left that you get billed for by Microsoft. So let me just make a visual representation here. So within subscriptions, you have resource groups, and within resource groups, you have resources. Okay. So this is where you get billed. You get billed at this level and the subscription could be, you know, we talked about it. It could be CSP subscription, it could be a pay as you go, it could be what's called EA, which is an enterprise agreement that large companies use. It could be, you know, what's called MPN. The Microsoft Partner Network where Microsoft sponsors a subscription for you to use for testing purposes and demo purposes. There are many different types, but the thing that makes them all different is how they're built, who's responsible for the billing, how it gets transacted. EA, for example, is something you negotiate and pay for up front. CSP is something you pay for on a monthly basis. Pay as you go, obviously, you pay as you go. FDN is normally pre-paid and sponsored. There's free. All sorts of different versions of the billing arrangement. Okay, now, when you are talking about granting access and getting access to things within Azure, so accounts, users, let's not call them accounts because that's not really accurate. Let's call them users. Users live at this level. So users live at the Azure AD tenant/directory level. So you can have a user, for instance, in this case, it could be admin@tenant.onmicrosoft.com. And then you can decide what this user has access to within a particular subscription and the way you do that is by assigning that user what's called a role. So for NFA to work as an example, in order for you to use an Azure subscription, you need to provide a user that is an owner on a particular subscription. An owner obviously means it can do everything within that subscription and create resources, delete resources, assign other users, create other users, et cetera. So this is a prerequisite for NFA provisioning is that this user is an owner on a particular subscription. Let me show you what it looks like inside of a resource group. So if you go into a particular resource group, let's look at the templates resource group we have that we use and you can see there's a bunch of different resources. We can see what they are. So you know there is a DNS zone, there is a virtual machine, there is a virtual network interface, there is a public IP address, automation account, all kinds of stuff that make a lot of sense to some of you and probably make no sense to others, but all of these are resources and these resources interact in a certain way and these resources are completely isolated from anything living in another resource group, other than the fact that they all get billed together on one invoice because they're part of the same subscription. All right. Then one other thing that I wanted to bring up now that we understand subscriptions is is this topic that comes up fairly frequently with partners, where if they have a deployment model, they may be using today or that some other vendors and competitors like CloudJumper, for example, uses and advocates, and you know, it's sort of loosely termed hoteling and the concept of the hoteling RDS deployment is when you have a shared active directory force and you have dedicated segregations within that force that could be separate subdomains, that could be a single domain with different OUs for different organizations, but you guys get the concept where you have a common forest, which means you have a common network, which means things are running within the same subscription and the same resource group in Azure specifically and then you have the ability to leverage and we'll talk about the pros and cons in just a second, you have the ability to leverage resources either in a shared way or you can use software and access list to restrict permission. So you know, oftentimes we have to go though the pros and cons of doing the hoteling versus what we call single stack. Single stack is what we are all very familiar with. This is what we've done in legacy and in DC and NFA, this is where you deploy each and every customer completely, independently of any other customer, and you have segregation at the very minimum at the network level. So there isn't any sharing an active directory, there isn't any sharing of resources, it's all segregated. So now that we understand subscriptions and resource groups, let's go through this exercise very quickly. So the common objections to doing a single stack deployment, probably the only and the biggest ones, is the fact that you have additional infrastructure roles that cost you money. For example, if you have a hoteling environment, you can have a set of domain controllers that are commonly shared by multiple customers. So you basically take the cost of that Infrastructure as a Service resource like a VM and you spread it across multiple customers, whereas if you're doing a single stack deployment, then each and every customer has at the minimum to have one domain controller, one file server, one ADFS proxy, one RD gateway, connection broker for using RDS connection. So basically, all the infrastructure roles get deployed separately and cannot be leveraged in a shared scenario. Now the effect of that, if you look at the minimum sizing with all the applicable discounts of those roles, it's fairly minimal, right. So people think okay, well I need all these extra machines. They're gonna cost me hundreds of dollars a month, but really, if you use discounts and reserved instances which is something we'll get into in detail a little bit later, you can really bring the cost of these VMs down to a $20 per month range. So, we're talking about 100, 150, $200, for all of these additional rolls. Still additional cost, but not as much as people usually think and we'll see what the advantages are of doing single stack and those outweigh those additional costs. The other advantage or disadvantage of using single stack, especially for someone who's used to doing a hoteling environment, is now they have to kind relearn a different way of managing the environment. You know, they may be used to working out of a single active directory users and computers screen where they can manage all their customers in one place. Now they have to figure out how to jump from one customer to the other. You get the idea. Once you're used to a certain way of managing it, you have to learn a new way if you go into single stack. Okay, what are some of the pros of single stack and cons of hoteling? So obviously by having a single stack deployment you eliminate a significant amount of complexity and risk by keeping each customer completely independent. I think this requires no further explanation. You have complete isolation between customers, but you still have multi-tenant management without having to log in and out of different accounts. So everything is at your fingertips with the NAP. So you have the NAP, which lets you very easily exit one account and log into another account and kind of do that very rapidly. There isn't much lag between going from one to the other. So, you know, still complete isolation and easy management. When you have a hoteling environment, any time you make a change that is at the shared component level, so imagine you're chasing the database schema because you're deploying exchange or you're installing something under the main controller. You have to conduct what's called impact analysis on the entire environment because every time you make a change, you have to know, well, how is that gonna interact with what Customer A has differently than what Customer B has? And in a environment when you have a small number of customers, that may not be a big deal but you can imagine that that doesn't scale very well because when you make changes to shared components, those could have unpredictable impacts on different customers that you couldn't foresee. So there's lots of impact analysis which becomes very difficult and expensive to conduct and ultimately, still, can result in high risk of issues. You have the ability to eliminate these global issues that arise when certain shared infrastructure components fail. So imagine you have active directory issues that affect the entire environment. All your customers are affected. Or you have a shared RD gateway deployment and there is an issue there that's affecting everybody at the same time. So you eliminate these global issues. You can also eliminate the noisy neighbor problem right when you have people on a shared network environment maybe hammering away at a particular resource, maybe hammering it away at AD or gateway or whatever the case may be, you can limit that as much as possible by having single stack because you have, different customers are split up. You still have that noisy neighbor at an employee-to-employee basis but not customer-to-customer basis. This is where some of the concepts we learned earlier comes into play. If you're doing a hoteling deployment, that, by definition, means you're deploying everything within a single resource group, which means you're in a single subscription, which means you're getting billed on the same invoice without an easy way of attributing your spends and tracking the spend on a per-customer basis. The way NFA deploys the product is by doing it in a single stack, which allows you to put it in single, independent subscriptions and then track the spend very accurately on a per-customer basis. If you have single stack deployment, you can delegate the administration without the concern that somebody is gonna screw something up that's gonna have a global impact. So imagine, again, hoteling environment. You don't wanna give someone global admin rights or domain admin rights because they'll be able to make changes that can affect all of your customers. In our case, that's not a problem. So they can do things, reset passwords, clear home sessions, you know, group memberships, et cetera. You can give full admin access or just selective access, et cetera, okay, continue. You can, okay we talked about it. Give user domain admin rights without concern if they have anything outside of their own environment. It's easier to show compliance with regulatory audits because you can claim, you know, you can say that each environment is fully isolated because it is, at the resource group level. You then have a lot more flexibility with networking and VPN connectivity, so you're flexible on how you design your network, how you set up your AD schema, you could do hybrid AD, which we then will talk about later on for those of you who are not familiar with that, but you could do hybrid AD for some customers and brand new greenfield deployments for others. You can have multiple Office 365 accounts linked to different customers. So a lot more flexibility in the architecture and you have more pricing model flexibility. So think of this as a service provider that's trying to package this and go to market and sell this to a customer. When there is hoteling, again, because it's so difficult to separate the usage of one customer versus another, you then have as much flexibility around how you price it. So you have to kind of blend things together and use averages, whereas with single stack and different subscriptions, you do have a lot more flexibility on how to do it.

Transcript for:Fundamentals of Microsoft Azure Cloud

Transcript for:
Fundamentals of Microsoft Azure Cloud