These are my personal notes taken from the course Azure DevOps from aCloudGuru, all the credit goes to them

What is Microsoft Azure

Microsoft Azure is Microsoft's public cloud computing platform

The "public" here is a key term, in which there are other types of clouds referred to as private clouds, which are usually maintained by a single organization for use only with a single organization. That's not what we're talking about here. Microsoft Azure, AWS, Google Cloud, and others are public cloud platforms, which are available to -- as its name applies -- the general public, not just a single organization.

Using Microsoft Azure, you can build, run, and manage applications on Microsoft's global infrastructure.

For that, Microsoft Azure has over 200 individual products and services which provide a wide number of management and solutions for any business use case you can possibly think of.

These different product and services have different levels of management assigned to it :

• Infrastructure-as-a-Service (IaaS),
• Platform-as-a-Service (PaaS),
• Software-as-a-Service (SaaS)

Platform-as-a-Service and Software-as-a-Service are commonly referred to as managed services. Technically all three are actually managed services, but the Platform and Software as a Service have an extra layer of management applied to it.

Pay-as-you-go Pricing The main advantage or the main difference with cloud computing -- and again, this is a foundational concept -- is cloud computing operates on what is known as pay-as-you-go pricing.

What this means is that, compared to on-premises models or our examples in which you have to buy computers or servers in advance and set them up, you only pay for what you need or consume at that given moment.

What that means in our example is that if we need a virtual server for just a few hours, we don't have to go buy that physical server, set it up -- we're stuck with it, whether we actually get full use out of it or not. By comparison, we can simply temporarily pay for that server when we use it, and then when we're done it and we get rid of it, we don't have to pay for it anymore. To be more specific, for many of Azure services, you're only billed by the second for those services as you're using them.

From a terminology perspective, this entire concept of pay-as-you-go pricing -- in which you pay for resources as you need them and then, when you're done using them, you're done paying for them -- is commonly referred to as an operational expense (OPEX). By comparison, the expense model in which you purchase the server upfront -- which is the traditional IT model and then hope that you get the return on investment of that server over the long term -- is often referred to as a capital expense (CAPEX).

So cloud computing operates on an operational expense model, whereas on-premises computing often uses a capital expense model.

Azure Global Infrastructure

##Highlights :

• Azure's global datacenter infrastructure
• Breakdown between regions and availability zones

Azure Global Datacenter Infrastructure

Azure's data centers are located in multiple regions all around the world.

The primary takeaway from this map is that Azure is not just one cloud in one location. Rather. It is a set of geographically distributed, multiple sets of data centers positioned all around the world to give them a global footprint. Next, let's talk about the relationships between regions and availability zones, in which -- once again if we look at the left side on the United States region -- if we look at that Central US region, we can see that it is a blue dot with a white diamond inside of it. Again, going back to our map key, that represents a region with availability zones inside of that region.

This relationship between regions and availability zones is another fundamental cloud topic, especially when working with Azure, that we need to keep in mind.

Breakdown between Region ans Availability Zones

A region is defined as a collection of individual data centers deployed within a single geographic region. Once again, going back to our map example,we have regions such as Central US, South India, various locations in Europe, Asia, and other places all around the world. In some of these regions, there is another division construct referred to as an availability zone. An availability zone is one of multiple physical locations within each individual Azure region.

These zones are made up of one or more individual data center buildings, and each one of these individual data centers have its own self-contained construct of independent power, cooling, and networking capabilities.

The primary purpose of these multiple availability zones inside of a single region is to provide an additional layer of fault tolerance or -- as Azure refers to it as, resiliency -- by offering the ability to replicate your application or whatever business solution that you're using across multiple availability zones inside of the same region.

This means that, in the unlikely event that one of the availability zones in a region went down, if you're replicating your resources across multiple zones inside of that region, your application or other business solution will still be up and running despite a partial data center failure.

If you want to take a look at the visual breakdown of that previous definition, we are returning once again to our global map, except this time we went ahead and zoomed in on the United States region and decided to go ahead and blow up an example region and availability zone pairing of the Central US region. In this example,we have a single region listed as Central US. However, inside of that single region, we have multiple availability zones and each one of these availability zones is in itself one or more individual data center buildings.

What this means is that a single region is often composed of multiple buildings in multiple locations in that region, and not just a single data center in a single location. Rather, it is multiple data centers in a single geographical location. And once again, as we talked about in the previous slide, each individual availability zones -- which is again, comprised of one or more individual data center buildings -- has its own self-contained power, cooling, and networking capabilities.

So if one availability zone goes down -- or in other words, if an entire data center went down -- there are still multiple other data centers in that same region that go ahead and pick up the load.

Let's revisit our fundamentals of cloud computing lesson by associating some of our key cloud technology terms to the differences between regions and availability zones.

In this case, a region serves to provide both high availability and fault tolerance, whereas an availability zone is used mostly only for fault tolerance.

With regions, especially with applications that are deployed to multiple regions all around the world, it fulfills the need of high availability by allowing you to deploy your application or your solution to be closer to your end users, regardless of where in the world that you're at. And, deploying an application or a solution across multiple regions also provides a level of fault tolerance, in which case, in the unlikely event an entire region goes down, if your solution is deployed to multiple regions, at least one of those regions is still working and you can still have some uptime, even if it is not at 100% capacity.

By comparison, deploying a solution across multiple availability zones in a single region doesn't really give you that much in the way of high availability, because all your solutions are replicated in the same geographical region.

Instead, it is used mostly for fault tolerance in which, if you deploy resources across multiple zones in a single region and one of your availability zones go down, another zone can step in and keep your application running because your replicated deployment helps guard against a single point of failure.

Azure Services

Highlights :

• Breakdown of Azure services
• Overview of managed services types Iaas, Paas, Saas
• Overview of Azure Resource Manager (ARM)

A solution for every need

IaaS, PaaS and Saas

Infrastructure as a Service (IaaS)

• Virtual servers
• You are responsible for maintaining OS (Windows or Linux patches or security updates)

Plateform as a Service (PaaS)

• Cloud vendor maintains infrastructure for you
• You focus on application code and data

Software as a Service (SaaS)

• Vendor provides full software stack

Resource Hierarchy and Organization

Azure Organization Considerations

Azure Resource Hierarchy

• The resource hierarchy allows us to better organize our large variety of different Azure resources and services.

• It also provides a mechanism of tracking and segmenting who in an organization is paying for different sets of resources.

• And finally, Azure's resource hierarchy gives us a mechanism to limit who in our organization has access to different sorts of resources, and by that manner, doesn't have access to other sets of resources.

Starting from the very top, all resources in an Azure organization start with a single Azure tenant.

Going on down the chain, an Azure tenant can have one or more management groups.

Inside of those management groups can exist one or more subscriptions.

A subscription can have one or more resource groups, and those resource groups can themselves have one or more resources inside of it.

Of these different layers of the resource hierarchy, management groups are technically an optional component.

Azure Resource Hierarchy Fundamentals

All organizations in Azure's resource hierarchy are arranged in a parent-child relationship. And when we're talking about parent-child relationship, the higher levels of the hierarchy are the parent levels and the lower levels are the child resources in relation to the layer right above it. Now, this is a very important fundamental concept to keep in mind when we're talking about managing access or applying policies to different parts of our Azure organization.

Specifically, whenever we apply some sort of a security policy to a higher level of our resource hierarchy -- whether it is a resource group, subscription, or anything else -- those same policies are automatically inherited or passed down to the lower child levels.

Going with the theme of parent-child relationship, another key advantage of the resource hierarchy is that it provides a method of centralized management, in which different management principles and policies applied to a parent level is automatically applied to those child levels as well.

Another thing we saw on the previous slide is that a parent level -- again, whether it is a subscription, management group, etc. -- can have multiple children objects underneath it; however, a child can only have one parent.

File System Relationships

Now, if you're familiar with a typical operating system file structure, such as windows or Linux, it is very much the same concept. I typically use an operating system file structure like we'll see here in a second as a good example of what we're working with.

So as a visual example of how a parent-child relationship works on a cloud vendor like Microsoft Azure, the file system of an operating system like Windows or Linux has the exact same format and fundamentals.

The main takeaway from this example is that Azure's resource hierarchy has the exact same relationships as your typical operating system file structure.

Azure Resource Hierarchy Components

Next, let's further unpack the relationships between those five different layers of our resource hierarchy by going through a quick breakdown on how each of those work.

Starting from the very top layer, we have the tenant of our Azure organization. An Azure organization will only have a single tenant. You can think of a tenant as a company, such as Microsoft or whatever your company name is. The tenant is where your user directory or identity directory exists that acts as a single bucket to manage all the users who have access to various parts of your Azure organization.

Underneath our tenant, we have a technically optional grouping component referred to as a management group. The primary purpose of a management group is, as its name implies, to provide a centralized management component for multiple subscriptions that you want to manage all in one place. Now, again, as I said, a management group is technically optional. If you only have a couple subscriptions in your Azure organization and they do not need the exact same policies applied to them, you are technically not required to use a management group. However, in situations in which you have multiple subscriptions that you want to apply the same security access policies to, a management group allows you to bundle multiple subscriptions inside of that management group, therefore applying a single policy to a management group is automatically inherited by all subscriptions inside of it. Again, that nested parent-child relationship.

Moving on down, we have our next layer, which is that of subscriptions. The primary purpose of a subscription is to act as the primary billing and access isolation boundary within Azure. When you're running resources on Azure, you need some sort of a method to be able to pay for them. A subscription is the organizational component within Azure in which you attach a billing account, attached to some form of payment (whether it is an invoice or a credit card), and it acts as your billing agreement with Microsoft in which you have a single payment method for all resources created inside of that subscription.

Underneath subscriptions, we have one or more resource groups. Resource groups is where you create your actual resources like virtual machines, storage accounts, etc. Now, the reason that we have resource groups under these subscriptions, which are required to run resources, is that, per Microsoft's best practices, a good practice to get into is that when you are creating different types of projects or a certain lifecycle of different resources all working together, you want to create those multiple resources inside of a single resource group. Let's say, for example, that you're going to create a virtual network, a virtual machine, and a storage account, which are being all used together for the same business purpose, which is also going to have the same lifecycle. When setting them up, you'd want to create all these resources in the same resource group; in which case, all security access policies applied to that resource group are automatically inherited by the individual resources. And when you no longer need the resources in that resource group, you can simply delete the resource group, which will also automatically delete all the resources inside of that resource group as well.

And then finishing up, the final layer of our resource hierarchy is the individual resources themselves, whether it's a virtual machine, storage account, virtual network, AI solution, or anything else available on Azure.

So, once again, nested format or parent-child relationship all the way down.

• When you're working with a company or an organization, it will have a single tenant, which is where the identities live at.
• A tenant can have one or more management groups.
• A management group can have one or more subscriptions, which is where your billing account is attached to.
• A subscription can have one or more resource group, which contain multiple individual resources that have the same lifecycle.
• And then at the very bottom, we have the individual resources like virtual machines and so on and so forth.

Putting It All Together

So once again, quite a bit of information. Let's go ahead and summarize that by combining our diagram and our brief descriptions, all in one place.

Once again, as a brief review:

• At the very top of our organization, we have a single Azure tenant, which contains all of our Azure Active Directory users -- or in other words, the identities we give access to different parts of our Azure resources.
• Next, we have one or more management groups, which is a grouping of multiple subscriptions with a single policy that is automatically inherited by all subscriptions.
• Subscriptions themselves provide yet another isolation boundary and is also the construct used for our billing agreement or our payment methods with Microsoft.
• Inside of our subscriptions, we have resource groups in which we create and group individual resources together. And at the very bottom, we have resources, which is the individual services that we create such as virtual machines, virtual networks, data analytics, so on and so forth.

Identity and Access Management

Identity and Access Management (IAM)

It should be quite obvious that we need to limit who in the world has access to our different Azure resources in our company.

The solution to managing access to different parts of our cloud environment is known as Identity and Access Management.

Identity and Access Management is simply the process of determining who can do what on which resources.

Azure IAM Components or Three-part-equation-Who-can-do-what-on-which-resources equation

Azure Active Directory (Azure AD)

The first part of our equation is the "who," and the "who" is managed by Azure Active Directory, which exists in the tenant, or in other words, the very top level of an Azure organization.

Azure Active Directory contains the identities that we use to authenticate and prove who we are is who we say we are, that we will then use to assign various roles and permissions.

Azure Active Directory is the "who" and we have a single instance of Azure Active Directory per tenant, or in other words, one per company.

It provides the identity in which you authenticate who you are is who you say you are. When you sign into a Microsoft service or an Azure-based service, you are signing in and authenticating yourself against Azure Active Directory.

An identity on Microsoft Azure has the technical definition or a technical name of a security principal. So a security principal is what is actually your identity on Azure Active Directory.

Now that could be a little bit confusing if you're thinking about end users being our identities: why are end users referred to as security principals?

The reason it is named as such is that, with Azure Active Directory, we can authenticate end users -- in other words, human beings -- however, applications not assigned or attached to an end user or human being can also be their own separate identities in Azure Active Directory as well.

End users can be identities, applications can be identities, programmatic methods of access to our Azure environment can also be their own separate identities as well -- which is why they are all underneath the general term of security principal.

When talking about Active Directory for end users (or in other words, human beings), they often come in the format of an email address.

So in other words, when you authenticate with Microsoft Azure, you are typically authenticating in your email format like frederick@mycompany.com, or whatever your business email address that is associated with your Active Directory account is.

Azure Role-Based Access Control (Azure RBAC)

The next part of our process is "can do what," and the "can do what" component is managed by what's known as Azure Role-Based Access Control, or Azure RBAC for short.

With Azure Role-Based Access Control, we are able to provide different types or different levels of access to different resources in our Azure environment.

When controlling access, access is controlled with what is known as a role.

The role that you assign to an identity essentially tells that user: " this is what you are allowed to do within the scope that we're going to give you access to. And for that matter, this is what you are not allowed to do, or what access you are not granted, as well."

We assign roles to a security principal, or in other words, an identity. Or to put it in more realistic terms, we can assign a role to our end user of frederick@mycompany.com.

Roles themselves are simply a collection of specific permissions, and permissions on Azure are very specific singular assignments of what you can do on different resources, such as creating a virtual machine, deleting a virtual machine, editing a virtual machine, even something as simple as viewing the specifics of a virtual machine. Each one of those very concise actions is one of its own individual permissions. And those individual, very narrowly defined permissions are bundled up into roles, which are essentially groups of permissions assigned to an end user.

Be aware that roles can come in both wide-ranging and fairly narrowly defined types regarding the scope or the amount of access you have to specific resources.

For example, the Owner role is a very broad role, which gives a user full access, or in other words, full administrative permissions to all resources inside of a given scope. By comparison, if we assign a Virtual Machine Contributor role to the same person (as opposed to an Owner role) even within that same scope, that end user only has access to manage virtual machines, but not any other Azure resource, within that same scope. So again, roles can be very wide in scope or very wide in the level of permissions granted, and very narrowly defined as well.

... on which resources

And then rounding things out, the third component of our Azure IAM trilogy is the scope, and the scope determines "on which resources" our identities have different levels of access to.

And you'll see that the scope directly relates to our previous discussion on the Azure resource hierarchy.

The scope is defined as the set of resources that one is allowed to access, or in other words, "on which resources." When we are assigning a role to an end user, we also define what level of our Azure resource hierarchy that user has different permissions to. Also from our previous discussion, lower levels in that Azure resource hierarchy inherit those assigned roles from higher levels as well.

If we assign a role to an end user to one of our subscriptions, those same roles are inherited by all the resource groups inside of that subscription as well.

Which provides us a method of centralized management: assign a role to the proper level of the Azure resource hierarchy and all the lower levels will automatically inherit those same roles as well. So you do not have to manually assign roles to lower levels in addition to that higher level, at the same time.

Three parts of the IAM equation and action.

In our example, we have a subscription -- shown by the blue circle and line coming out of it -- that we want to assign proper access to.

In this case, we will take the identity of matthew@mycompany.com that is going to be the identity or the "who" that we give access to. We are then going to give the Owner role to our identity of matthew@mycompany.com. And that Owner role is going to determine what Matthew is able to do inside of that subscription. In this case, the Owner role gives Matthew full admin rights to the subscription and everything inside of it. And then finally, our subscription scope is the subscription itself, or in other words, the level of the Azure resource hierarchy that we are assigning our ownership role to Matthew, the security principal. In this case, since we are assigning the role to a subscription and since the lower levels of our hierarchy inherit roles from the higher level, all of the lower resource groups also inherit that Owner role as well.

If we assign our security principal or our identity, matthew@mycompany.com, the Owner role to the subscription that you see circled there, our user, Matthew, has full admin rights to the entirety of the subscription, which includes all resource groups and by that manner, all resources inside of that subscription, as well.

Monitoring your Azure Environment

This section will discuss about how to keep track of what is happening in your Azure environment. If there are errors in your applications, this is something that you definitely need to be aware of. And if you're working with a team who has access to your same Azure environment, you need to keep track of who is making changes to your environment, especially if somebody is making changes that they are not supposed to be making.

Azure Monitor

To answer questions such as these, Azure Monitor is a service within Azure that gives you that necessary cloud visibility.

To be more precise, Azure Monitor collects both logs and metrics from all of Azure services and some other non-Azure sources as well.

Together, logs and metrics within Azure Monitor simply answer the question, "What is happening in my Azure environment?"

Logs and Metrics

So we mentioned that we have two separate components in our Azure Monitor. We have logs and metrics, which are two very different things. Let's talk about each one of those in a little bit more detail.

Logs can be thought of as a text-based record of some sort of event taking place. In other words, something happens and there is a text record of what happened. These can include items like activity logs, such as who created a resource and when. For example, if I were to create a new virtual machine in a database in my Azure environment, there's going to be a text-based log record or an activity record of that action taking place. Another example is an operating system log such as Windows Analytics System Activity logs; or, in other words, if your Windows virtual machine is generating an error in Windows Event Viewer, that will generate a log and we can view that log and take action on it within our logs within Azure Monitor.

By comparison, metrics are not text-based records, but rather it is telemetry-based performance data. In other words, it is a measure of performance of our different resources. This can include items such as CPU utilization in a virtual machine, or if we're running a website, we can measure the latency or the performance of visitors to that website.

How it works

Next, we have a big picture diagram of how the entire process works from beginning to end.

Within Azure Monitor, all of our various Azure resources that you see on the left side -- whether it is a web-based application, an operating system, or anything else -- all of the records, including both logs and metrics, are all funneled through a centralized location known as Azure Monitor. Again, it's that "centralize it" management theme in action.

These logs or metrics are collected in what is known as stores.

And then finally, based on those metrics and logs, there are a variety of actions we can take place that you see on the right side, including various application insights, data visualizations, analysis, responses (in other words, alerts being automatically generated) and we can also integrate those metrics and logs for various automation steps.

In summary, Azure Monitor acts as our cloud visibility function or our cloud visibility mechanism to simply answer the question, "What is happening in our Azure environment?" which includes, but is not limited to, exploring performance metrics in dashboards such as CPU utilization, network utilization, application latency, so on and so forth.

It gives us the ability to troubleshoot and be alerted to various Windows and Linux operating system errors. It can automatically create alerts, which will automatically notify somebody if something breaks that definitely should not be broken.

And it can be used to set up a variety of automated responses, such as automatically scaling an application or to create an automated chain of events based on certain logs or metrics coming in.