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

Azure Core Services

Virtual Machines (Compute)

The first and the most fundamental of the core Azure components is the virtual machines, or in other words, the compute in Azure environment.

Virtual machines are the fundamental building blocks for pretty much all the rest of the managed services on Azure, whether we are managing those virtual machines or whether Microsoft is.

What exactly is a Virtual Machine

Let's briefly talk about what exactly is a virtual machine.

A virtual machine is nothing more than a virtual computer that acts just like every other computer you have access to.

• If we think about a physical computer, a physical computer has a few core components that are the same regardless of which individual computer we're talking about.
• Every physical computer has a certain number of CPUs.
• It has a specific amount of RAM or memory.
• It has to have hard drive storage.
• It has to have a network card, so it can communicate with other computers outside of itself.
• It should also have network controls in place via a firewall to ban or allow different types of network traffic.
• And of course, you have to have an operating system installed on that computer. In this case, we're going to be talking about Windows or Linux.

When it comes down to Azure virtual machines, it is literally the exact same thing,except it is not a physical computer where you're managing. An Azure virtual machine is simply a virtual computer as opposed to a physical computer; however, it still uses the exact same components of CPU, RAM, hard drive and storage, a network card, firewall rules -- or as Azure refers to it, as network security groups -- and of course it also needs a Windows or Linux operating system as well.

Scope of Responsibility

Now let's talk about where virtual machines fall into this spectrum of different managed services.

Specifically, virtual machines are known as Infrastructure as a Service.

So when it comes to Infrastructure as a Service, as a type of multiple managed services, the scope of responsibility is as follows.

Azure's responsibility :

• Responsible for all the physical components, such as the networking and also the physical server rack itself for that virtual machine.
• Provide a base version of an operating system, such as Windows or Linux, that you can then take over responsibility from there.
• Handle the virtualization component of taking a physical server and creating virtual machines on top of it.

Your responsibility:

• Updating and patching your Windows or Linux operating system to make sure it is secure and up-to-date.
• Managing who has access to your operating system and who does not.
• Responsible for any software or additional software that you install on your Windows or Linux operating system as well.

So, with that scope of responsibility in mind, it then leads to the question of why would you want to use a virtual machine instead of one of a number of managed services, when there is less stuff that you're responsible with those managed services, as opposed to a virtual machine, in which case you are responsible for so much more.

Why Use VMs vs. Managed Services ?

It all comes down to flexibility.

You can do almost anything imaginable with a virtual machine compared to a managed service.

If it runs on a server, which is to say pretty much any application you can think of, you can do it with a virtual machine because it is again, simply just a virtualized computer.

It all comes down to a trade-off of whether or not you want the additional flexibility, or do you want less management or less administrative overhead that Azure will take care of for you at the expense of a little bit less flexibility.

There is no right or wrong answer for this question.

It all comes down to your own specific needs.

Cloud Computing Advantages with VMs on Azure

There are two unique cloud advantages that you get with virtual machines on Azure that are typically not available with your own physical computers that you have to manage.

The first cloud advantage is a function within Azure known as an availability set.

An availability set on Azure is essentially a replication or an automatic copy of one virtual machine to another one in a different Availability Zone.

If you enable an availability set within Azure with your virtual machines, you will be managing one virtual machine in one zone; however, it will always be consistently replicating or copying itself over to another zone.

The cloud advantage is that if you are automatically replicating your virtual machine across zones, if one of those zones go down, you automatically have another virtual machine, which is again, an exact copy of your previous one to let you pick up where you left off.

This is going back to our previous cloud advantages of fault tolerance.

The second cloud advantage is known as a scale set.

A scale set is often paired with a load balancer in which you can have multiple copies of virtual machines, which enables you to scale up or down your application based on user demand.

With a VM scale set paired with a load balancer, when user load on your application increases, a scale set will automatically create additional copies of your application to direct users to; and when user load to your application drops, the scale set will then reduce the number of copies of your virtual machine as well.

This goes back to our cloud advantages of scaling and elasticity.

Networking

Let's discuss now about networking, or in other words, how our virtual machines and other resources communicate with the outside world.

Returning to our overview of Azure services, we are now going to be concentrating on the bottom right component of networking, which include virtual networks, load balancers, DNS, and other networking services.

However, in this case, we are going to focus on the primary building block of all those services, which is the virtual network, also referred to as a VNet for short.

Azure Virtual Network (VNet)

A VNet is one of those fundamental building blocks for all Azure communications in that it is used for both private and public network communications for communicating within Azure and also with the outside world.

Many of the concepts of working with a VNet in Azure are the exact same as working with the traditional physical network, in which you are working with subnets, firewalls, routes, and other fundamental networking concepts; however, these are all in virtualized format.

From a terminology perspective, this virtual format of networking concepts is often referred to as Software Defined Networking, or SDN for short.

And using this Software Defined Networking, you can enable a combination of different types of public access or choose to keep different types of communication private and internal only.

What does this look like

In this diagram, we have a number of components up and running. On the right side, we have an example single Azure virtual network, in this case using an example of a virtual network in the Central US region.

On Microsoft Azure, a virtual network can only exist in a single region at a time.

In our example single virtual network, we have a number of subnets. In this case, we have two individual subnets and each of those subnets has a single virtual machine inside of it.

These two virtual machines are able to communicate with each other over a private network communication, which is not exposed to the public internet, of which this communication between different resources inside of the single virtual net is enabled by default.

At the same time, our user in the outside world is able to access our virtual machine on the left side over a public internet connection as well. So, in this case, we have a virtual network which has resources that support both private network communication and public connections at the same time.

Private Network Examples - Home Networks

To explain what a private network is, as opposed to a public network, let's go ahead and start with a personal example that many of you have experienced, and that is working with a home network, whether it is a home WiFi connection or corded connections as well.

When you have a home network typically using a home WiFi router, you may have a number of devices on that home network like mobile phones, laptops, tablets, printers, so on and so forth.

These resources are able to communicate and see each other over an internal only connection within your home WiFi network.

In this example, we have a white box, which is designating the private network. And the communications among those devices on that private network are not visible to the outside world, which is being managed by your home router, which manages those private networking connections.

At the same time, your home router and in addition, your other devices on your home network, are able to communicate with the outside world over a public internet connection, which goes through that home WiFi router for your public-to-private communications and vice versa.

From a terminology perspective, private networks use what is known as private or internal IP addresses to communicate with each other and only with each other on those private networks.

The internal IP addresses are not visible to the outside world and the outside world is not able to see those specific communications.

What does this look like on Azure

So how does this relate to Microsoft Azure using the personal network example?

You can think of a VNet or a virtual network as a type of home network on Azure, which is able to use both internal or private IP addresses and also optionally external or public IP addresses as well.

A virtual machine on Azure can have both an internal address and an external address, or maybe even only an internal address and no external address, depending on the level of public access that you want to give to that machine.

Network Management Features

If you are familiar with working with networking in general, you should know that traditional network tools are in use to manage access.

We have subnets on a virtual network, in which you can segment multiple resources for easier organization.

You have the ability to connect a virtual network on Azure to other Azure virtual networks or to even other clouds or on-premises locations over a private connection via either network peering, VPN connections, or ExpressRoute, which is essentially a leased line to a large organization.

Then, it is a really good idea too to enable some sort of network control via a combination of network security groups and firewall services on Azure as well, which is able to control who has access and who does not have network access to your resources based on protocol, port, or where that traffic is coming from.

Storage

Let's explore the storage component; specifically, focusing on storage accounts.

What are Storage Accounts ?

Storage accounts aren't just a single thing or a single type of storage.

A storage account itself is Azure's all-purpose storage solution for multiple different types of data storage solutions or services. Regardless of which individual service type we're working with, it is massively scalable.

It is a type of managed infrastructure, in which you do not have to worry about the underlying virtual machines powering those storage accounts.

And depending on the sub-service that you're using, there is a multitude of ways to access that storage, such as file shares natively built into a Windows system or disks on a virtual machine.

Storage accounts is in itself five different types of sub-services, all within the storage accounts umbrella. We have :

• Blob storage (often referred to as object storage),
• Files,
• Disks,
• Queues,
• and Tables.

Storage Account Infrastructure

Taking a look at the overall infrastructure and organization of how a storage account works, within your Azure organization you would of course create a resource group for any service. Inside of that service, you will create a storage account. And then inside of that storage account, you would then create each one of your sub-service types, such as Blob storage, Disk, so on and so forth.

Within a storage account, you can have more than one instance of the different sub-service types. You can have multiple disks in a storage account, multiple Blob containers, and multiple instances of any other sub-service types as well.

You're not limited to one of each in each storage account.

Storage Account Services at a glance

Blob storage

Blob storage is short for Binary Large Object storage.

Object storage is often referred to as unstructured data.

What is unstructured data, you may ask? It is literally any loose type of file that you can think of: images, videos, scripts, application files -- if it is a file that exists, it is technically an object that can be stored in the Blob storage type.

Files

Next we have Files, which is similar to Blob, except the main difference is it essentially acts as a remote file server that is available on a cloud vendor.

But you don't want to set up a whole new Windows or Linux server to host that file server? The Azure storage Files type can be your file share for you, without having to mess around with all these server setup parts.

Disks

Next we have Disks and, as its name implies, disks host your virtual hard drives for virtual machines like we talked about earlier.

When we create a virtual machine on Azure, the disk that that virtual machine uses for either your Windows or Linux operating system is actually hosted and powered by a separate storage account.

Now, the default option is to use a managed storage account, which is largely invisible to you because Azure is managing it on your behalf, but the main takeaway is that the disks for your virtual machines are being used by separate storage accounts to actually host and run those disks.

Queues

Next, we have a sub-service called Queues.

And Queues is referred to as asynchronous messaging between apps and services.

As you start learning more about Azure and other cloud services, you will eventually start diving into topics such as how do we get these services to communicate with each other asynchronously -- that is not in real time.

Queues is a method of delivering asynchronous or non real-time messages from one service over to another service, or to even accept messages coming in from the outside world.

Tables

And then our final storage account sub-service is Tables.

Tables provides NoSQL database storage inside of a service account. Microsoft announced that they are in the process of gradually transitioning the Tables sub-service type inside of storage accounts and added storage accounts into the separate managed Cosmos DB database service.

As of right now, it is currently available in storage accounts, but at some point in the future, that may change.

Why Storage accounts ?

Let's cover a simplified scenario, in which how we would use a storage account for a larger solution. In this case, we're going to take an example music streaming service in which we are going to host and stream audio files to our end customers.

In this example, we have a virtual machine, which is currently hosting our music streaming application, which is what our end users interact with when they are streaming music.

This music streaming service is going to host and stream its music files from a storage account, specifically a Blob storage container.

Why are we using a separate storage account to host our music files, as opposed to hosting those music files on the music application virtual machine itself? If we have everything all in one place, that's one less service that we have to manage, right? Well, there's some very good reasons when it comes down to cloud advantages, why we are separating the storage from the computer that our application is hosted on.

Databases and Analytics

We are now going to be focusing on the database or the Data section of our example diagram here in the top right, in which we can see that there are a number of different database types available on Azure.

Before we jump on into it, I wanted to make a quick note about the little bit of a change in approach for the next two parts specifically focusing on databases and web apps, in that these are both going to refer to both core services and managed services at the same time.

The reason databases and web apps are considered to be core services, is that they are often core, primary components for a wide variety of Azure solutions.

At the same time, they are also referred to as managed services, which -- as we discussed before -- these are services in which Azure will manage a lot of the infrastructure management on your behalf.

So are these core services or are they managed services? The answer is: they are both at the same time.

What is a Database ?

So once again, starting off with the high-level basics, what exactly is a database and how is that different from the storage solutions we talked about previously ?

Simply put, database is a type of structured data.

Compare this to our Blob storage example in the previous lesson, which is referred to as unstructured data. In fact, if you've worked with an Excel document or spreadsheets in the past that is a very simplified version of a database, in which we have structured data arranged in tables and rows.

That is a very simplified database.

Structured data has a wide variety of use cases, such as acting as a user directory, or usernames and passwords, transactional records for financial and hospital institutions. And it can also act as a product catalog, providing a structured directory to be able to query what kind of products you have sitting where.

Databases on Azure

Moving on, let's talk about how databases -- especially managed databases -- on Azure are organized.

We're talking specifically about the multiple managed database services on Azure or the Platform as a Service managed solutions. The reason I mention that is that you also have the option of just taking a simple virtual machine that is Infrastructure as a Service, installing a database on your virtual machine, and just using that as a database as well.

Managed databases come in a variety of solutions, such as Azure SQL, Cosmos DB, Managed MySQL and PostgreSQL for open source solutions, and a variety of other ones as well.

What is important to note with these wide variety of options is that you have multiple managed database options available, each with their own different use case and levels of management as well.

You have a SQL versus a NoSQL database.

You have fully managed versus provisioned infrastructure, of which the main difference is that:

• with a provisioned infrastructure, you set how much compute and memory and storage space that you need, even though Azure handles a lot of it for you;
• versus dynamically adding and removing as much compute and memory as you need, without you having to interact with that aspect.

Again, different levels of management, depending on the specific managed service.

And you also have some differences such as single region versus multiple regions. For example, Cosmos DB can be replicated to multiple regions at the same time, whereas some other managed database options exist in only a single region.

And of course you have open source solutions versus proprietary. For example, Microsoft SQL is a closed source or a proprietary solution, whereas MySQL and PostgreSQL are examples of open source database options.

The main takeaway from this (again, we have a large variety of options available) is that, regardless of your managed database needs -- SQL versus NoSQL, open source versus proprietary, so on and so forth -- Azure has some sort of a managed database solution to cover whatever type of data storage scenario that you can come up with.

Databases and Analytics

Lat's talk about a very related topic in analytics, as it relates to databases.

Analytics are technically a separate solution, apart from databases; however, they are often paired together.

So what exactly are we referring to when we are talking about analytics? When we use analytics, we are not just storing data, but we are analyzing that data or trying to get some sort of information or Business Intelligence from that data for various types of insights. Now, keep in mind, when we are often working with analytics, we are talking about working with absolutely massive amounts of data that we're acquiring -- talking about in the terabytes or even multiple petabytes range.

Analytics help us answer business-specific questions, like what are the most popular features of our website or our application that our users like. It also helps answer very important questions, like how happy are our customers and how can we make them even happier so they continue to do business with us.

Referring once again to our services overview, when we are talking about analytics, we are referring to the bottom right of our Platform Services field, which again have a number of separate services depending on your particular use case.

In a typical analytics scenario, we would be using two separate services.

Azure Synapse is a service used for querying and visualizing massive amounts of data, and Azure Data Lake is a separate service used essentially as a large dumping ground for absolutely massive amounts of data that we're going to be able to query. In this scenario, a Business Intelligence employee will be using the Azure Synapse service to query and visualize customer metrics, which are currently being stored in our Azure Data Lake.

App Service and Serverless Compute

I wanted to revisit our example music streaming app scenario that we've talked about over the past couple of lessons. For this, I wanted to refocus on that top left section of our diagram, where it says Music Application. And in this example, that music application that our users are accessing and interacting with is currently hosted on a virtual machine or again, Infrastructure as a Service. Now, while this does work just fine, there are a number of challenges to be aware of and a number of solutions for those challenges when we're hosting applications on virtual machines -- again, Infrastructure as a Service versus more managed services.

Challenges of hosting applications on VMs

As we mentioned before, virtual machines come with the full amount of flexibility possible; however, that comes with the cost of you being responsible for much more of the management process. When working with virtual machines (or Infrastructure as a Service), you manage operating system updates and patching. You need to determine how much CPU and RAM -- or in other words, compute -- that your solution needs. And you're also responsible for managing how much storage your virtual machine uses as well. And if you want to scale out your application, you're responsible for setting up and configuring the scale sets that your virtual machine will use to automatically create copies of itself for scalability and elasticity purposes.

The end result is a lot more flexibility; however, there's a lot more overhead to management -- or in other words, a lot more stuff that you are responsible for. So with that in mind, what if we choose that we just want to focus on coding our application -- or in other words, focusing on our application code -- and let Azure handle all that administrative overhead on our behalf? Well, fortunately, we can do just that.

And the solution for that is to use Azure App Service.

Returning once again to our Azure services at a glance, we are going to be focusing on the top center section of Platform Services, specifically underneath Application Platform. Now, we are going to be focusing specifically on Web Apps, which is the top left item in that box. However, the other services in that box are related to App Service, in that they are known as a type of service known as serverless compute.

App Service = "Serverless" Compute

So what exactly is serverless compute?

Serverless compute does obviously use a server or some sort of a virtual machine to power it. The main difference, though, is that you have very little interaction that you are responsible for it for those virtual machines, and instead you can simply focus on the type of data or code that you want to go into your application and Azure will simply handle the rest.

Manage Code instead of Servers

Or another concise way of putting it is that you can focus on your code and not on the actual virtual machine management.

App Service Handles Infrastructure for You

So what does this look like, going back to our example, music streaming scenario? In our example, we have the exact same diagram as before, except this time we have subbed out our virtual machine and put in an App Service service in its place.

With App Service set up, all we have to do is code our application and the Azure App Service will take our code and deploy it to an application hosted on virtual machines that Azure is 100% in control of.

We don't even have to choose how much CPU and RAM we need, or how much storage we need -- Azure will handle that. All we deal with is focusing on updating and pushing out our code, and Azure will handle the rest of it for us.

The main benefit is that we have the ability to focus only on our code and Azure will handle 100% of the virtual machine management on our behalf.

App Service Considerations

Now, of course, this is not the perfect solution for every single possible use case scenario. As we talked about in a previous lesson, when you are using more managed services, you are trading flexibility for convenience.

App Service is overall a less flexible solution, but it is a more convenient solution, depending on your particular use case. With that, App Service desk support most of the major programming languages and also containers, if you're familiar with those; however, it is still not quite as flexible as a virtual machine.

If you have a really customized application that you can't code in one of the supported formats of App Service, a virtual machine is still often your best bet.

One very important point to keep in mind when considering whether or not to use App Service is that App Service is very much a developer or a coding focused tool.

It is the perfect tool for developers who aren't very familiar or don't want to deal with the infrastructure management aspects of Windows or Linux.

However, if you're not a developer, you're not going to get much use out of it, because it is 100% coding focused. If you are a developer and a coder, it is a fantastic tool, but not so much if you do not come from a development or a programming background.