Microsoft Azure is a collection of online services that organisations can use to build, host, and deliver applications. You don’t need to have your own data center because Azure runs in Microsoft’s data centers around the world. Not only does this approach save you the trouble of having to build and maintain your own on-premises IT infrastructure, but it can also save you money, because you only have to pay for what you use, and you can scale your Azure resources up and down as needed.
In this course, you will not only get an overview of the Azure services available in various categories, such as compute, storage, and networking, but you will also follow hands-on examples showing you how to create virtual machines and web apps using the Azure Portal and Azure command-line interface.
- Describe some of the Azure services available in various categories
- Use the Azure Portal
- Use the Azure command line
- Anyone who would like to learn more about Azure
- General technical knowledge
- A Microsoft Azure account is recommended (sign up for a free trial at https://azure.microsoft.com/free if you don’t have an account)
The GitHub repository for this course is at https://github.com/cloudacademy/azure-overview
So what is Microsoft Azure? To put it simply, it's a collection of online services that organizations can use to build, host, and deliver applications. The best part is that you don't need to have your own data center or even any servers because Azure runs in Microsoft's data centers around the world, which your users can access over the internet.
Not only does this approach save you the trouble of having to build and maintain your own on-premises IT infrastructure, but it can also save you money because you only have to pay for what you use, and you can scale your Azure resources up and down as needed.
For most applications, you need three core elements: compute, storage, and networking. Let's start with compute. In Azure's early days, Microsoft offered only one type of compute service: virtual machines, or VMs for short. These are machines that run either Windows or Linux. If you currently have an application running on a Windows or Linux server, then the most straightforward way to migrate it to Azure is to do what's called a "lift and shift" migration. That is, you simply lift the application from your on-premises server and shift it to a virtual server in the cloud. Azure VMs are known as Infrastructure-as-a-Service because they're traditional IT infrastructure components that are offered as a service.
Later, Microsoft came out with what's known as a Platform-as-a-Service offering called Azure App Service. This platform lets you host web and mobile applications without having to worry about the underlying infrastructure. After doing a minor amount of configuration, you can just upload your code to an App Service instance and let Azure take care of the details. In most cases, this is a better solution than using virtual machines, but there are times when it makes more sense to use VMs. For example, if you have an application that's not a web or mobile app, then you can't use App Service, so you'll have to use a VM.
These days, the hottest compute technology is containers. These are self-contained software environments. For example, a container might include a complete application plus all of the third-party packages it needs. Containers are somewhat like virtual machines except they don't include the operating system. This makes it easy to deploy them because they're very lightweight compared to virtual machines. In fact, containers run on virtual machines.
Microsoft provides a variety of ways to run containers. The simplest way is to use Azure Container Instances. This service lets you run a container using a single command. If you have a more complex application that involves multiple containers, then you'll probably want to use Azure Kubernetes Service, which is what's known as a container orchestrator. It makes it easy to deploy and manage multi-container applications.
Before we move on, I should mention one more compute service. It's called Azure Functions, and it's Microsoft's main "serverless" offering. Azure Functions is kind of like Azure App Service except that it executes individual functions rather than entire applications, and you only pay for it when it gets used. When you provision an App Service instance, it runs until you shut it down, and you pay for it the whole time it's running. Although it's possible to configure Azure Functions in the same way, it's usually better to use the Consumption plan, which means that it only uses resources when a function is running, so you only pay when a function is running.
Okay, that was a lot of compute options. Now let's move on to storage. Believe it or not, there are even more options for storage than for compute. That's because I'm also including databases and other data stores in the storage category.
The simplest form of storage is called Blob storage. It's referred to as object storage, but really it's just a collection of files. It's not like a normal file system, though, because it doesn't have a hierarchical folder structure. It has a flat structure. It's typically used for unstructured data, such as images, videos, and log files.
One of the great things about it is that it has multiple access tiers: hot, cool, and archive. The hot tier is for frequently accessed files. The cool tier is for files you expect to access only about once a month or less. The advantage is that it costs less than the hot tier as long as you don't access it frequently. The archive tier is for files that are rarely accessed, such as backup files. It has the lowest storage costs but the highest retrieval costs. It also takes several hours to retrieve files from the archive tier.
If you need hierarchical file storage, there are a couple of options. The one that will probably seem more familiar is Azure File Storage, which is like a typical SMB file server. It serves up file shares that you can mount on Windows servers. The less familiar option is Azure Data Lake Storage Gen2. This is Hadoop-compatible storage for use with data analytics applications.
Okay, now how about relational databases? In an on-premises Microsoft environment, SQL Server is the most commonly used database. The cloud equivalent is Azure SQL Database. It's very similar to SQL Server, although it's not 100% compatible. If you need to run an open source database, then Microsoft still has you covered. It offers Azure Database for MySQL, MariaDB, and PostgreSQL.
All of these databases, including both SQL Database and the open source options, are suitable for online transaction processing. On the other hand, if you need to build a data warehouse, then Azure Synapse Analytics is the best choice.
If you release an application that attracts a very large number of users, you may find that a traditional relational database can't scale to meet the demand. One common solution is to use a so-called NoSQL database. These databases are designed to handle far more data than relational databases. However, in order to achieve that massive scalability, they have to sacrifice something, so they don't support all of the features of relational databases. Nonetheless, they have become a cornerstone of many cloud-based applications.
Microsoft's main NoSQL offering is called Cosmos DB. It's an amazing database service that can scale globally. Another NoSQL service is Azure Cache for Redis, which is typically used to speed up applications by caching frequently requested data.
That's a lot of storage options, and I still didn't cover them all, but you don't need to know every single option at this point, so let's move on to network services.
When you create a virtual machine on Azure, you have to put it in a virtual network, or VNet. A virtual network is very similar to an on-premises network. Each virtual machine in a VNet gets an IP address, and it can communicate with other VMs in the same VNet. You can also divide a VNet into subnets and define routes to specify how traffic should flow between them.
By default, all outbound traffic from a VM to the internet is allowed. If you also want to allow inbound traffic, then you need to assign a public IP address to the VM.
If you want VMs in one VNet to be able to communicate with VMs in another VNet, then you can connect the VNets together using VNet peering. By the way, so far, I've only been talking about virtual machines, but other resources, such as Kubernetes clusters, can be in VNets, too.
If you want to create a secure connection between a VNet and an on-premises network, then you can use either a VPN, which stands for Virtual Private Network, or Azure ExpressRoute. A VPN sends encrypted traffic over the public internet, whereas ExpressRoute communicates over a private, dedicated connection between your site and Microsoft's Azure network. ExpressRoute is much more expensive than a VPN, but it provides higher speed and reliability since it's a dedicated connection.
There are plenty of other network services available as well, but the ones I've covered are enough to give you a good high-level understanding of Azure networking.
Azure also provides a wide variety of other services outside of the core compute, storage, and networking categories, such as in hot areas like artificial intelligence and DevOps. I'll go over some of those later.
The easiest way to understand how Azure works is to actually use it, so in the next lesson, we'll create a virtual machine. If you're ready, then go to the next video.
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).