As we are going to use Microsoft Azure, it's important that we understand the key concepts of cloud computing and especially the concept of the public cloud, as Azure is exactly that: a public cloud.

In the past, we have seen many trends in the IT industry; some of them were short-term and some of them stayed for quite some time. Many consider cloud computing to be a trend that will not be here for a long time, but they don't really understand the concept of the cloud and where it all begins.

Cloud computing didn't just starting with public cloud offerings, but it began in the 1990s. Obviously, the cloud didn't have a form like it does today but started more as something that companies implemented internally, offering their employees the option to create virtual machines on demand. At this stage, the cloud included a virtualization platform that allowed employees to create development/test environments composed of virtual machines based on preprepared images when needed. Two components are part of the foundation of cloud computing: virtualization and on-demand resources. None of this would be possible without server virtualization, an option that allows us to create many virtual machines on a single physical server. Cloud takes virtualization to another level beyond just simple server virtualization, but we'll get to that a bit later.

The ability to get resources on demand, when we need them, is the foundation of what cloud computing is about. As mentioned before, it all started with virtualization platforms and companies creating platforms that would enable their employees to create virtual machines on demand. Today, we call this the private cloud.

There are different types of cloud computing and different opinions on how they should be categorized. Personally, I find four types most logical:

• Private: Everything hosted internally, in our own data center.
• Hosted: Something between a private and public cloud; the service provider creates a separate environment in their data center and offers us an isolated cloud for our use only.
• Public: The service provider offers a service available to everyone—publicly available. There is still tenant isolation but we'll talk about this later.
• Hybrid: A combination of private and public cloud. Some services are used in the public cloud but some stay in our local data center with direct connection between two or more environments. From my experience, this is the most common form of cloud computing. Again, we'll explain more about this later.

In the private cloud, all resources are located on-premises, in our local data center, and no internet access is needed to access resources. The internet and resources are accessed separately as shown in the following diagram. Building your own private cloud previously required large-scale investment, both materially and in terms of knowledge. First, you needed space and needed to consider other elements like cooling and power. Then, you needed to invest in hardware like firewalls, routers, network switches, servers, and storage.

You needed licenses for a virtualization layer, operating system licenses for virtual machines, and then licenses for different kinds of software. In the end, all material investment was in vain if you didn't have the right people to set everything up and maintain it in the years to come. Once everything was in place and you had your private cloud running, it required new investment every few years as you needed new versions of software (virtualization, operating systems, and other software) and hardware needed to be replaced as well:

The hosted cloud came as the first step in the transition from the private cloud to the public. As creating and maintaining your own private cloud demanded large-scale investment, some companies took advantage and started offering services where you could rent part of their data center and use it as your own private cloud. They specialized in this kind of offer; it was cheaper for them to buy hardware and software as vendors offered discounts on mass purchases. So, creating an environment in the hosted cloud was cheaper then creating an identical environment in the private cloud.

There is also the question of upfront investment; using the private cloud requires that all hardware and most software licenses be paid for upfront, so many companies have decided to use the hosted cloud as they don't have to make an upfront investment but monthly or yearly subscriptions instead. Also, it's easier for data centers to provide experts to maintain systems as a single expert can take care of multiple customer environments. For the private cloud, you need a network engineer, a storage specialist, a virtualization specialist, and so on, and this is for a single data center.

In the case of a hosted cloud, all personnel are still required but a single specialist can set up and maintain environments for multiple customers and the price of maintenance is lower than for a private cloud. Note that to access the hosted cloud, usually some sort of Virtual Private Network (VPN), either site-to-site or point-to-site, is required. We access resources located outside our own network and located in another hosted network as shown in the following diagram:

In the next step of cloud evolution, the public cloud emerged. Large service providers offered large amounts of resources for on-demand use. Similar to the hosted cloud, resources you used were still outside your local infrastructure and hosted by service providers who specialized in this kind of offer.

There are two key differences. The first difference is that in a hosted data center the amount of resources available I usually predetermined and to get more resources you need to wait for new resources to be configured, if this becomes available at all. In the public cloud, providers have a large amount of resources available for on-demand requests and you can get them whenever you need them. You can create any kind and any amount of resources when needed. All you need is to create a subscription and access to the internet to start deploying. This also means you have highly scalable environments and you are not limited by the initial size of the resources created. For example, if you create a virtual machine with four CPUs and 16 GB of RAM and find out over time that the virtual machine can't handle the workload you have, you don't need to create a new virtual machine; you can use a scale-up option to change size. Scaling up is explained later in more detail. This works other way around: If you find out that the size of the virtual machine initially created is too large for your workload, you don't need to keep that size and pay for something you don't need. Simply scaling down will do the trick. In this case, we access resources over the internet as shown in the following diagram:

The other difference between a hosted cloud and a private cloud is pricing. In a hosted cloud, you would get an agreed amount of resources and pay a monthly or yearly subscription no matter in what capacity these resources are used, whether 10% or 100%. In the public cloud, pricing is based on usage and the model of payment is such that you pay for only things that are used. So, in the public cloud, if you create a virtual machine, you will be paying for that virtual machine for the time you actually use it. If you stop or delete this virtual machine, you will not be paying for it. The payment model is different for different cloud providers and can vary by per-day, per-hour, or per-minute usage. As we'll talk about Microsoft Azure, it's important to mention that Azure is using a per-minute billing system. So, for example, if you create a virtual machine in Microsoft Azure and delete it after 12 days, 11 hours and 13 minutes, the amount you pay will be calculated for that exact amount of time. In a per-hour billing system, you would pay for 12 days and 12 hours. In a per-day billing system, you would pay for 13 days.

Another difference is multitenancy. Even the public cloud is available to everyone; creating your own subscription creates your own tenant. By using special fabric, this tenant separates your resources from other tenants, and resources created in that tenant are available only to people with access to that specific tenant.

To sum up, the key concepts of the public cloud are:

• Access over the internet
• Multitenancy
• Resource pooling
• On-demand consumption
• Highly scalable

The term cloud or public cloud wasn't forged with modern IT but the term started in the 1960s with the concept of resources being time shared. The concept did evolve in the 1990s with the private cloud. However, the cloud did evolve and shift further to a modern form in the 2000s.

It all started with Amazon Web Services, a subsidiary of Amazon, when they released their Elastic Cloud Compute (EC2) in 2006. Google followed with Google App Engine in 2008. Microsoft announced their version of the cloud in October 2008 and it was publicly available in February 2010. Other service providers followed and many companies such as IBM or Oracle have their own public cloud offering. Looking at market shares and the pace at which they evolve, we can put only two cloud providers at the top of this list: Amazon Web Services and Microsoft.

We already said that Microsoft announced their version of the public cloud in 2008 and public release was in 2010. At this time, the official name for Microsoft's public cloud platform was Windows Azure. The name was changed in April 2014 to Microsoft Azure. The reason for the change was never publicly announced but there were many guesses. One of the theories was that Microsoft needed to change its name due to embracing open source software. As Microsoft added a Linux virtual machine to their offering, the name convention became too confusing. A virtual machine running Linux on a Microsoft public cloud would initially be Windows Azure Linux virtual machine, and having Windows and Linux in same name was confusing indeed. Changing it to Microsoft Azure Linux virtual machine made more sense. Now, this is only one of the theories that you can find and not an official reason for the name change.

Not only the name changed over the years. The first version of Azure, Windows Azure, had completely different specifications and a different type of portal. The first Azure portal was accessed at the address https://manage.windowsazure.net and was based on Silverlight. This portal was later referred to as a classic portal and the model of management for resources created in the classic portal was referred to as Azure Standard Management (ASM). The classic portal layout is shown in the following screenshot:

At this time, Microsoft realized there were issues with their cloud model and started working on completely new fabric. In 2014, a new Azure portal was announced. Along with a new portal, we got a new model of management called Azure Resource Manager (ARM). ARM brought new features like role-based access control (RBAC) and resource groups.

These features changed how we managed resources in the cloud. In ASM, the only way to allow someone to administrate Azure resources was to add this person as a co-administrator to the Azure subscription. This person would have total access and control over the subscription in question. With RABC, we got the option to give different permission levels to users such as reader or contributor, without giving them full access to the subscription.

Resource groups went even further. Resource groups in Azure represent logical containers where you can place resources depending on the convention of your choosing. For example, you can place all resources that are used by a single application in a single resource group. This would allow you to give user access to a single resource group with the option to manage or access only that specific resource group. When that user logs in to the tenant, he will be able to see only the resource group that was assigned to him even if you have other resource groups under the same subscription or tenant. You could go further with RABC and assign only users to a specific resource but that is too granular and hard to manage. Assignment based on resource groups is considered best practice and the best way to manage Azure resources.

The new Azure portal was considered a preview version until December 2015. At that time, it became an official portal and could be accessed at the address https://portal.azure.com. This portal became available in April 2014, when it was announced, but it was a preview version. The new portal layout is shown in the following screenshot:

The classic portal was announced to be retired and this eventually happened in January 2018. Along with RBAC and resource groups, ARM brought us another amazing feature—ARM templates. ARM templates are JSON files that hold information about Azure resources and can be used to deploy new resources or edit existing resources.

With the ARM model and ARM templates, Microsoft stepped up and really changed cloud business. In the cloud and in DevOps, the Infrastructure as code (IaC) concept is very important and that was exactly what ARM templates were. You are able to create an ARM template and reuse it multiple times to create similar environments. By doing so, you automated your infrastructure deployment steps and removed possible mistakes in the deployment and configuration process.

Speaking of IaC, we have lot of terms something as something in cloud world. The main types of services in Microsoft Azure (and cloud in general) are:

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

Each type represents a different kind of service level and our control over that resource. To explain each one and how they relate, it's best to compare them to services in our local data center. A service layer for all models is shown in the following diagram and we'll use this to explain the relationship between cloud models:

In a private data center, we are responsible to set up and maintain everything. We need to set up a networking stack, prepare and configure storage, buy and prepare hardware, install software, and configure the virtualization host. Then we need to configure images and servers, and deploy and manage databases. Security is also our concern in all aspects—physical security, network security, host and OS security, and finally application security for all application software running on our servers.

With IaaS, it gets easier. We don't have to prepare anything anymore; all we need to do is sign up for a subscription and create a virtual machine when needed and start using it. The part where we must buy, prepare, configure, and maintain is no longer our concern and the cloud service provider takes care of that, in our case Microsoft with Azure. Preparing images and deployments is also no longer our responsibility. Security is getting easier and physical, network, and host security are handled by Microsoft. We still have a responsibility in the security corner in order to keep our operating system up to date, patched, and secure. Application security is also our responsibility and we need to keep applying the best security practices in order to stay safe and secure. Many people forget that when migrating to the cloud we need to step up security. As the cloud service provider takes care of a big part of security, many get comfortable and relaxed and they neglect the part of security they need to take care of. When moving to the cloud, we need to remember that our resources and applications are publicly exposed and will experience significantly more "attacks" compared to when using on-premises infrastructure. Attacking resources on-premises usually means getting behind a firewall, then breaching the server and getting some data out. Now, many services are accessible over the internet and you need to take care of security better than ever before. The best examples of IaaS, when talking about Microsoft Azure, are Azure virtual machines. Both Windows Server and Linux virtual machines are available in Microsoft Azure. An interesting fact is that, according to information Microsoft released in October 2017, more than 40% of virtual machines in Azure are running Linux.

PaaS is getting even easier to use than IaaS. Everything that we said the cloud service provider is taking care of applies, plus some more. In this type of service, Microsoft is taking care of the operating system, additional software needed, and an additional layer of security. We still need to maintain everything we place there (depending on the PaaS service) and the part of security that remains our problem. Again, people forget that security part very quickly as even more responsibility is on Microsoft. However, IaaS is often used with VPN connections (either point-to-site or site-to-site) and endpoints are not publicly exposed in this case. This is not the case with PaaS, which is more often accessed over the internet. Because of this, we need to take security very seriously unless we want to lose our data or access to our services. The best examples of PaaS in Azure are Azure app service or Azure SQL databases.

Finally, we have SaaS. In SaaS, the cloud service provider is taking care of almost everything, from end to end. In this case, we have a complete solution prepared and all we have to do is create a subscription and assign users different kinds of access. Usually, SaaS has to have modules, an administrator, and a user. The administrator module is used to manage users and access levels; the user module is used to actually use the software feature we subscribed to. Security is also our responsibility, only on the user level, and we need to make sure users are aware that they need to keep their credentials safe and their password strong enough to prevent accounts being brute-forced into. The best example of SaaS in Microsoft Cloud is Office 365.

This diagram explaining Pizza as a Service is very often used to describe how cloud services relate to real-life situations and to better understand what cloud computing offers:

In this case, we can compare pizza to all four types we have in the previous diagram that explains IaaS, PaaS, and SaaS as well as on-premises computing.

When compared to on-premises computing, pizza would be the homemade option. We need to buy all ingredients, mix everything, bake it, buy sodas, and serve. Comparing pizza to IaaS, we would buy frozen pizzas and bake them, set up the table, and serve. Pizza, compared to PaaS, would be home delivery—we just order our pizza and need to buy sodas and serve. Lastly, the SaaS version of pizza would be dining in a restaurant: we go out and order and everything is done for us. We get our pizza, get our sodas, and everything is served.

We already discussed some of the features and benefits that each cloud service model brings to us. IaaS needs more enrolment and more maintenance than PaaS. SaaS needs even less of a human touch than PaaS and almost no maintenance except for user administration.

But there is an other side of that as well. SaaS asks for minimum maintenance and administration, but gives you a minimum amount of customization too. If you need something changed in SaaS, you'll probably need to contact your cloud service provider who can make the changes.

In PaaS, you have more freedom in terms of administration, maintenance, and customization. However, these changes are usually a preconfigured set of options you can choose from, but there are still more options than in SaaS.

IaaS requires the most administration and maintenance but gives you the best customization options as well. As you are controlling everything from the operating system upwards (you can select different preconfigured images or even bring in your own OS image), you have the best control as well. You can select what features you are going to configure, what server roles you are going to have on that server, and even install any type of software on that virtual machine.

The bottom line is you need to decide what kind of feature is best suited for you in a given situation. In some cases, the simplest solution would be SaaS, as that product offers everything you need. If you need the latest settings and features, you'll probably use the PaaS model. If you have some legacy dependencies, IaaS would be the way to go. This way, you would be able to configure and install everything related to that dependency.

The first benefit of cloud computing is obvious from all things previously written: it's easier to maintain and manage.

With the cloud there are many areas of expertise you don't need to provide yourself; the cloud service provider manages these thing for you. But this can be kind of a trap—cloud resources are not self-managed and you still need IT professionals who will manage and maintain your resources and keep them in good health. These are different kinds of IT professionals than in a local data center, but we still need people who understand core IT. If you are using IaaS, you still need a Windows Server Administrator (or Linux Server Administrator, depending on your preferences). If you are using databases, you are still going to need a database administrator. IT professionals need to adjust their skills and roles to cloud computing and leave on-premises behind them, but we still need them very much.

The financial benefit is also one of the obvious pros. In an on-premises environment you needed to buy and pay for all resources upfront, before you started using them. There are many different hardware components that we need to prepare for a local data center such as a firewall, network switches, storage, servers, a power supply that cannot be interrupted, and so on. We need to prepare infrastructure that can handle this kind of hardware, such as a proper server room. Cooling that will keep our hardware at the optimum temperature or provide enough electrical power that we can keep this running without overloading our electrical grid. And when we have everything in place, we need to have proper licenses for the virtualization host, operating system licenses for each virtual machine you want to run, and licenses for any additional software you plan to use such as SQL Server, endpoint protection, or any other software needed. In a local data center, you need to buy and prepare everything in advance. This can be a significant financial hit for any organization.

And after this initial cost, we have to pay upkeep. We are paying for electricity, for a cooling system, the required spare parts, and someone to maintain all of this.

After a few years, our hardware and software becomes obsolete and we need to repeat everything again. It can be hard to keep up and stay relevant in these conditions.

In the cloud, we don't have to pay upfront for anything; we are using services in a pay-as-you-go model where you pay for resources you are using on a per-minute basis. We don't have to invest heavily in anything—you create resources when you need them, for the amount of time you need them for, and delete them once you're done.

If we need a new server, we can have that in a matter of minutes in the cloud. There is no need to contact different resellers, no filling in orders and waiting for deliveries. In Azure, you just spin up a virtual machine (or any other resource) whenever you need it. Once you don't need it anymore, you can delete it and from that moment on you don't need to pay for it anymore. This is also one of the differences between the cloud and on-premises: you are not stuck with what you buy. In a local data center, you need to buy resources in order to use them. Once you don't need them, they don't magically disappear from your server room. And even if it did somehow disappear, you still invested money.

Assessment in terms of how many resources we need for a specific service can also be a big issue. Let's say we are creating a new web application that we are going to offer to end users. The application is completed and we need to host it somewhere in order for users to start signing up and using that application. The application is probably going to need servers, a web server and a database server. We need to buy new hardware and licenses for these servers. The problem here is that we need to buy hardware that is going to be able to handle our workload. The workload needs to be estimated for an initial number of users and growth over time but this can be very hard to estimate. If we guess the initial workload, it's very easy to make mistakes with growth numbers. If we overestimate, we are stuck with something we don't actually need but have paid for. If we underestimate, we need to upgrade very quickly. Upgrading can bring us to two problems: time and money.

It can take some time to order upgrades and resolve issues with workload. And in this time, while we're waiting on upgrade components, users experiencing bad performance caused by high workload may leave. Losing users due to the bad performance of our application is something we definitely want to avoid but may be out of our hands because it takes time to get permission (especially in large companies) to order upgrade components, to have them delivered, and to upgrade our servers. Upgrading servers will also cause some downtime because we need to shut down servers in order to add new components. Again, we have something that we want to avoid.

The second thing about upgrades is that they cost money. It can take a significant amount of money in order to increase server workload. In some cases, if we need to upgrade memory, we are not able to do that unless we upgrade the CPU. Sometimes, upgrading a CPU requires the upgrading of the motherboard first in order to continue. But that is if servers can be upgraded, because sometimes we are limited with what we get and are not able to upgrade at all. In such cases, we need to buy brand-new hardware and we have an old server that we don't need but already paid for.

The cloud keeps these issues much more simple and easier to resolve. We will create either two servers (in case we decide to use IaaS) or two other services (in case we decide on PaaS; we have multiple options there). Managing workloads and the amount of resources is simple, fast, and easy.

If time shows that we overestimated ourselves, we can simply scale down resources and the issue is resolved. We are not stuck with something we don't need and we are not paying for it. We simply scale down the server/resources and from that moment forward, we are paying for a smaller server that we actually do need.

In case we underestimated ourselves, we can scale up and increase the amount of resources just as easily and quickly. We don't have to wait for parts and don't need to lose time until upgrade components are finally delivered. We just increase the amount of resources and the issue is resolved.

Another benefit of the cloud is also tied to resource amounts. In some cases, we have spikes in our applications. Spikes are sudden increases in workload and can be predictable or unpredictable. For example, if we are hosting a web shop application, we can predict spikes in workload if we have offer discounts on popular items or increased workloads during holidays. If we have some kind of news portal, we can experience unpredicted spikes in workload caused by some breaking news or something similar.

In both cases—unpredicted or predicted spikes—we need to account for them when setting up resources we are going to use. Even if our resources are sitting idle and underused most of the time, we need to buy hardware that is going to handle these kinds of workloads. So, if we are having 10,000 users on a normal day and 1,000,000 during spikes, we need to buy resources that can handle a workload for 1,000,000. Otherwise, during spikes, users are going to experience high workload and an unresponsive application. As a result, we will lose users once again. But, buying a server that will be underused 90% of the time is something we would like to avoid as it is expensive. We have a choice: either pay or lose customers.

The cloud lets us handle this issue very quickly as well. We can scale up and down very easily, simply, and quickly. Two approaches can be taken, depending on if we have unpredicted or predicted spikes.

In case of predictable spikes, we can increase and decrease the amount of resources on demand. By doing so, we are no longer paying for a large amount of resources outside of the period we actually need them. In a normal period, we are paying only for a normal workload and in the case of increases we are paying for a high workload but only for the period we have a higher workload before we scale down back to normal.

In the case of unpredictable spikes, we can set performance counters and alerts that will trigger a scale-up (or scale-down) as needed. For example, we can set up a trigger that will monitor the CPU. Once the CPU hits 90%, we can schedule automatic scaling out and increase the amount of resources assigned to that service. This way, users don't experience any issues caused by high workload and increased usage of our application. We need to be careful of automatic scaling out as this will create an increase in pricing and unless we scale back down, we will pay the increased price. Scaling down can be done manually but it can be done automatically as well. We can create another trigger that will perform scaling down in case the CPU drops below 50%. This way, we can always use only the resources that we actually need and use.

Most of the cloud service providers have similar subscription models but have some unique features. We are going to concentrate on Microsoft Azure as this is the cloud service we are going to cover in this book. From now on, all features we are going to discuss are going to be Azure-specific.

For Microsoft Azure subscription, the highest level of administration is that of a tenant. Azure is a public cloud with data centers all over the world that are available to everyone. There are a few exceptions such as the US government's data center that is available only to US government institutions, the Chinese government's data center for Chinese official institutions, or the German data center only available to companies registered in Germany.

As a public cloud provider, Microsoft has to keep data separate for each user. Azure fabric is used to separate resources in the data center and tie them to a specific customer. So, even if you are sharing physical resources such as network, servers, and storage, your services can be accessed and managed only by you.

As the highest level of Azure, a tenant is created by default when you create your first Azure subscription. Many people don't realize that they already have an Azure tenant if they use Office 365. Office 365 requires Azure Active Directory and creates your first Azure tenant. I have seen many people making the mistake of creating a new Azure tenant even when they had Office 365 in use. The issue is that the tenant is tied to Azure Active Directory and creating a new tenant creates a new copy of Azure Active Directory. This makes Azure Active Directory hard to manage as you have two copies and differences appearing over time.

Creating your first Azure subscription creates a new Azure tenant and a new Azure Active Directory. There are multiple options for managing Azure Active Directory but we'll discuss that in Chapter 8, Azure Active Directory – Identity in the Cloud. Creating an additional Azure Active Directory creates a new Azure tenant as well.

The next level under tenant is Azure subscription. You can have multiple Azure subscriptions under a single tenant. Creating a new tenant will result in an empty tenant with only an Azure Active Directory without subscriptions. As Azure Active Directory has multiple tiers, you will not be able to change Azure Active Directory from Basic (that is free) to another tier without a valid subscription. A subscription is needed in order to collect usage information, generate a billing report, and finally issue an invoice for service usage.

An Azure subscription can be used to separate Azure environments by financial and administration logic. This can be done in many ways and you can design it to fit your needs. One example would be to have a single tenant at the company level and an Azure subscription for each department. This way you can assign a different administrator to each subscription/department and keep track of how much each department is spending. Another example for subscription separation would be to have different stage environments. I've seen many companies dividing their subscriptions into development, testing, and production environments and having different Azure subscriptions for each of these environments. This approach gives you the ability to administer and manage each environment separately but provides insight into how much you are spending on each environment as well.

The third part of separating resources would be using resource groups. Resource groups were introduced with the ARM model and bring many benefits. As with subscriptions, you can use resource groups to separate resources in terms of logical or billing level. An example would be to have a different resource group for each department or development/test/production environment. You can then assign different administrators to each resource group and track billing for each resource group. Note that for billing, you will still receive a single invoice at the end of the month and need to manage and track spending manually. Billing separation is much easier on a subscription level. If you need to separate invoices per department/environment, you should go with subscription separation.

Every resource in Azure can be tracked using hierarchy. Resource belongs to a resource group, resource group belongs to subscription, and subscription belongs to tenant. Logging in to the Azure portal will connect you to the default tenant. You can manage which tenant is going to be the default one as a single account can be in multiple tenants. For example, my corporate account is by default in my corporate tenant but I'm a guest user in multiple client tenants. By default, I connect to my company tenant but can select client tenants from a drop-down list. I can change my default tenant as well and select in which tenant I want to be logged in by default when I sign in to my Microsoft Azure account.

To look at this from a Microsoft Azure perspective, when you log in to Microsoft Azure with your account, Azure fabric determines to which tenant you have access, signs you in to your default tenant, and you have access to subscriptions that are in that tenant. From there you can manage all subscriptions, resource groups, and resources that belong to that tenant. By switching tenants, you have access to different subscriptions, resource groups, and resources that belong in that tenant. All this is handled by Azure fabric in order to separate client environments.

This approach is much better since the ARM model was introduced as things were much different in ASM. In ASM, after login you would have access to all subscriptions that were under that single account. Azure Active Directory wasn't tied to a specific tenant and you could have multiple Azure Active Directories in a single tenant. It was difficult to keep track of resources as there were no resource groups and the only thing separating them was the subscription level.

A similar hierarchy can be applied to resources administration too. You can assign a user to have certain access to your resources as well. The access level can have different kinds of permissions such as owner, contributor, reader, and so on. You can build custom permissions to achieve your own rules and policies. User roles can be assigned on the level of tenant, subscription, resource group, or single resource. Managing user access at the resource level can be hard and time-consuming and I wouldn't recommend this approach.

On the other hand, access to the tenant level is something you will often want to avoid because in most cases you don't want users to have same access to all resources. A few administrators can be exceptions, but this approach is something you want to avoid in general. The best and most common option is to assign users access at the subscription or resource group level. Subscription-level access can be used if you have different departments or environments for each subscription and you can assign an administrator for that department or environment as a subscription administrator. Access to the resource group level can be applied if you have a single application or environment in the resource group and assign an application/environment administrator for corresponding resource groups. These aren't the only options or models you can use but you can adjust and create whatever option best fits your needs. For example, I have seen where organizations have placed similar resources in a single resource group and assigned an administrator based on their on-premises role. All network resources would be in a single resource group and network engineers assigned to a network resource group. All databases would be placed in another resource group and a database administrator assigned as administrator for that resource group and so on.

To create your first Azure subscription, you need a few things. The first thing is to provide an email address that needs to be either a Microsoft Live account or an Office 365 account. You need to provide a phone number. Finally, you need to provide credit or debit card information along with a billing address. Credit card information is needed even for free subscriptions because Microsoft uses it to verify your identity.

When talking about Azure subscriptions, we can divide them into three different types:

• Sponsored subscriptions
• Pay as you go
• Enterprise subscriptions

There are a few different sponsored subscriptions in Azure: trial, Azure pass, MSDN subscription, Azure sponsorship, and so on. What all of them have in common is that they have a certain amount of resources available to you free of charge. Another thing they have in common is that not all services are available in all regions. For example, you may be able to create an A2 standard virtual machine only when selecting the North Europe region, but you will not be able to create this virtual machine in any other region.

The Azure trial offers you $200 of service for 30 days. Subscription will expire whatever comes first: either you spend $200 or it expires at the end of the month. You need to provide credit/debit card information for this type of subscription. You can convert subscription from a trial to a pay-as-you-go model at any time using that card or by providing details of a new one. Credit card information must be provided—it's used only for identity verification, and you will not be charged any amount of money unless you specify that you want to remove the spending limit and start billing after the trial is over. What Microsoft is trying to achieve is to prevent you using Azure for anything illegal. Without credit card information, anyone could set up a trial subscription and use it to host illegal things for 30 days. At the end of a trial, a person would need to set up a new trial and continue to use Azure services for illegal content. In this case, Microsoft wouldn't be able to provide information on who was conducting illegal activities using Azure and they would be held accountable by the respective authorities.

Azure pass is offered as another type of trial subscription and offers a limited amount of credit for 30 days. This type of subscription is tied to Microsoft's official courseware and the amount of credit is determined by the course, each type having a different amount of credit. This type of subscription doesn't require a credit card as you need to register for a course and information from that registration can be used to verify your identity if needed. As with a trial, you are limited in the type of resources you can create, the amount of resources available, and the region resources can be created in.

MSDN Azure subscription is tied to a user's MSDN subscription and has a different credit amount based on the MSDN subscription level (a different amount per MSDN level, such as professional and enterprise). The amount of credit given is on a per-month basis and you get a certain amount at the beginning of each billing period (the billing period depends on the date of activation, the date of activation will be the beginning of your billing period, and the end of the billing period will be in 30 days).

The Azure subscription will be active as long as the MSDN subscription is active as well. Credit card information isn't needed as another way of identifying verification can be used (MSDN payment information). If you reach your spending limit in a single month, your resources will be deactivated and stopped until the end of the billing period.

To use these services again, you need to wait for the beginning of a new billing period or provide credit card information that will be used to charge any use over the sponsored amount. Removing the limit can be specified to apply to single months or for subscriptions. Single-month removal will remove the spending limit only for that month while subscription removal will the remove spending limit permanently and start billing every time the spending limit is reached. In the case of a single-month limit removal, the limit will be removed only for a specified month and if the issue happens again in the following month, it will disable your service. If the limit is removed from the subscription, once you reach the spending limit, it will automatically start to charge your usage.

Note that in every case, first the sponsored amount will be spent and only then will the credit card be activated. An Azure subscription for MSDN is limited for development and testing; it should never be used for commercial or production purposes. You also have a limit on the amount of resources and regions available. MSDN subscription also applies different pricing for resources. You are not charged for software licensing as this is a dev/test environment and prices of resources are much cheaper as a result.

Azure sponsorship is very similar to an MSDN subscription. It should not be used for commercial or production purposes. Azure sponsorship also has spending limits but in this case, it is not per-month but per-year. The billing period is one out of two differences between Azure sponsorship and Azure MSDN subscription, where sponsorship is billed per-year and MSDN per-month. The limit can be removed; there is a limit for resources and regions. The second difference is in that normal prices apply and you will be charged for software licenses.

Pay as you go is the most simple and most common type of Azure subscription. You sign up for an Azure subscription, provide credit card information, and this credit card is used for billing at the end of each month. The name tells you almost everything in this case: there are no limitations and you are billed for only what you use. If you don't have a single resource in your subscription, Microsoft will not charge you for only having a subscription. If you have resources in your subscription, you will be charged only for those resources. If you add some resources, you will be charged additionally. If you delete some of them, you will be charged only for those still active. There is no minimum or maximum limit on your subscription; you can spend nothing or millions per month.

Enterprise subscription requires a contract that determines a minimum amount you will spend on Azure resources. You receive a certain discount for resource prices as you commit that you will be spending a certain amount of money at a yearly level. You are charged on a monthly basis, based on the amount in the contract. Any amount that is over the minimum amount determined in the contract is billed separately at end of the year. With an enterprise subscription, there is also an option to bring your own licenses to Azure, enabling you to reuse existing licenses you have for on-premises resources.

Additionally, there is a reserved instances discount. It can be applied to both pay-as-you-go and enterprise subscriptions. You determine the number and type of virtual machines that you are going to use in the next period. The period can be 1 or 2 years. One year gives you a discount on these virtual machines and 2 years gives you an additional discount (for a longer time, and a bigger discount as you are obliged to use the service for longer). You can edit the reserved instances agreement at any time by adding or removing virtual machines. An increase in number can provide an additional discount and a decrease will result in penalties.

Once a subscription is in place, you can start creating resources in order to use them and deploy your application. Choosing what to use and when can be overwhelming in terms of the broad choice Microsoft Azure has to offer. There are different approaches and different architectures we need to consider before even starting.

We have already talked about IaaS, PaaS, and SaaS. An example of Microsoft SaaS is Office 365 and, as a cloud software, it is available under a subscription model. Office 365 even runs in Azure data centers (it was the initial purpose of these data centers along with identity management—we now call this Azure Active Directory), but we will not discuss this product further as it isn't directly connected to Azure subscriptions. Our goal will be to distinguish Microsoft Azure's offerings when it comes to IaaS and PaaS.

IaaS is the first step in migration to the cloud. It's natural for traditional IT professionals to accept this as a first step in the cloud journey. Creating an Azure virtual machine is simple and from a VM level there isn't much difference between a local VM and a cloud VM. You don't have access to hardware or host components, which makes maintenance easier and cheaper. But administering and managing VM in Azure isn't much different form on-premises versions, no matter what host we used locally—Hyper-V, VMWare or something else (Microsoft Azure uses a modified version of Hyper-V hosts that are different than the version used on-premises).

You select an image for the operating system, select the size of the VM, and some other parameters. From there forward, you connect to your VM and install features and software as you see fit. You can control access, frameworks, and data for all software installed on your VM; you'll need to pay for it as part of a subscription or provide a valid license of you own. If your create a VM with Windows Server 2016 and SQL Server 2016, you will be charged extra for both licenses.

Creating a PaaS resource is even simpler than IaaS. It's easier to administer and manage as well. But, on the other hand, control is no longer completely in your hands. You can edit some key features that are predefined to have different values or to be turned on and off. But, some things are default and you are no longer able to edit them. All licenses are included in the price of resources by default.

Let's consider a simple scenario where you have a web application running on IIS in the frontend and a database on SQL Server in the backend.

For IaaS, you'll need to create two virtual machines, a web server, and a database server. In order to host your application, you'll need to set up IIS on a web server that will be running Windows Server 2016. A database server can be a VM with SQL Server 2016 running on Windows Server 2016. By now, added to our computing prices, we have two licenses for Windows Server and one license for SQL Server (price also varies in the version of SQL Server if we choose web, standard, or enterprise edition). Once we have installed and configured IIS, we need to create firewall and network security group rules that will allow us to access our application over the internet. We need to set up communication between the web server and database server and create similar rules in order to allow communication between our application and database. We already have our hands full enabling a simple scenario with IaaS.

For IaaS, we will set up the app service plan in order to host our web application and Azure SQL database for the backend. All licenses are already configured and we don't have to do anything else in terms of configuration. The process is much simpler and easier.

But on the other hand, PaaS doesn't always allow us to have everything we need to run our applications. If we need to use an older version of some framework, PaaS will not work. PaaS already has a preconfigured set of frameworks that you can use but you can't install anything additionally. In the case that you have some features for the database that are not supported in Azure SQL or compatibility issues, you need to use SQL Server in VM.

Overall, PaaS is usually cheaper and needs less attention than IaaS, but IaaS gives better control and better legacy support.

Service offerings are growing by the day and every few weeks we have new services and new features in Microsoft Azure. A couple of services that we mentioned are only examples for a simple scenario. IaaS does give us control as to what is going to be on our VM and offers better combinations compared to a single resource, but the PaaS list doesn't stop there. For Azure PaaS, we can create an app service, content delivery network, Azure SQL database, traffic manager, service bus, Azure functions, Azure CosmosDB, Azure storage, and Redis cache just to name a few.

Azure data platform has over 50 different services that are PaaS. The same goes for other platforms such as web, media, compute, and so on. Choosing the right service can be beneficial both when we look at the solution from a financial perspective and a performance perspective. We need to consider if some service has some limitation that will make us use another service just to cover that limit. And there could be another service that will cover both aspects and there will be no need to use an additional service. Limitations can cause performance issues if we don't look at all aspects and try to anticipate all possible scenarios. Luckily, with Azure, we are not stuck with a single solution, even if we see that we have made a mistake and the service we chose doesn't really cover our needs—we can always scale out or switch to another service completely.

There are few things you need to consider regarding pricing in Microsoft Azure. There are resources that have fixed pricing and resources that have consumption pricing. Also, fixed-price resources sometimes have service level limits included in the basic price. Once you reach that limit, you will be charged extra based on consumption. This potentially turns fixed-priced resources into consumption-priced ones. There are also exceptions that have different uses applied.

Resources that have fixed pricing will be added to your bill as soon as you create them. Fixed-pricing resources are billed on a monthly basis, have a fixed price, and are added to your bill as soon as you create them. Examples of these services would be OMS or Azure Active Directory on higher tiers. A reserved public IP address is also one of the fixed-cost resources. After you delete this type of resource, it will be added to your bill for the current billing period.

Azure storage is based on consumption and you pay for the amount of data you have in your storage account. But the amount of data varies every month and there could be less data at the beginning or end of the month, but more data in the middle of the month. In this case, average consumption is calculated and you are billed on the average consumption of Azure Storage.

An example of a service that has performance-level restrictions would be bandwidth. Inbound data transfer is free of charge and you don't pay anything as long as data is going towards an Azure data center. Outbound data is free for the first 5 GB per month and you are charged extra for everything over those 5 GB. Another example of a service limit would be Azure container registry, where you have 100 minutes of CPU included but pay extra when exceeding that limit. Azure function is also an example of this type of resource where you get the first 1,000,000 executions for free and you are charged for additional executions.

Resources based on computing are calculated on a per-minute basis. If you have a virtual machine or app service running, billing will stop as soon as you delete these resources. This also applies to resources being stopped in some cases. Azure SQL database can't be stopped but pricing will be calculated on a per-minute basis. If you delete Azure SQL database, you stop paying for it the same minute it's deleted. For virtual machines and app services, you can stop these resources and you will not pay for compute hours any longer. Note that there are a few pricing details related to a virtual machine. Virtual machine price information, that you can find in Azure portal when creating virtual machine or shown in Azure calculator, is only for compute hours. A virtual machine also uses Azure storage that you pay for, separately from computing, and you will pay for storage no matter if the virtual machine is running or stopped. Some network components can create additional charges for virtual machines. For example, you can reserve a public IP address that is charged separately.

It is very important to keep track of your resources in Azure and to know what you are using, if resources are utilized, and what the limits are for current resources. If you are not using something correctly or not using it at all, you are still paying for it. This is different from a traditional IT environment where you have resources prepaid and it doesn't really matter if a single virtual machine is being used or not as long as you don't reach the resource limit at the host level. In Azure, you are paying for everything you created (or have running in some cases) so you need to keep track of active resources and what you actually need. Otherwise, the cloud can become a very expensive solution and bills will start to pile up. Financial benefits can be great but if you are not careful, it can go the other way as well. I've seen many companies using a development and test environment without control and many resources where no one knows who created them and why, let alone if there is someone actually using them. This is not as often a problem with production environments, but can happen in some cases.

Be smart and Azure will help you, but if you don't keep track of usage and billing, it can go the other way. It's your choice: you can get either promoted or fired!

In April 2014, Microsoft announced a new approach to Azure with a new portal and ARM model. We already discussed how ARM and RBAC changed the administration of Azure resources and made life in the cloud much easier.

But another option ARM brought to the table was ARM templates. ARM templates are files in JSON format that contain information on all resources in a single resource group. We can use ARM templates to deploy new resources, update resources, or remove resources from a resource group. Every resource group in Azure portal has an automation blade that allows us to save an ARM template for that resource group, redeploy resources, or download a template locally. This allows us to replicate resources from a resource group quickly and simply.

This is why placing resources for a single application is common practice in Azure. If we have a complicated environment that takes some time to deploy, it can be very useful. For example, let's say that we have a SharePoint farm with Windows Server running a domain controller role, two servers for SharePoint farm, and two additional servers running SQL Server. This requires us to create a virtual network, create five servers, and add them to the virtual network. Doing this manually in the Azure portal requires some time to create. But with ARM templates we can do this in a matter of seconds.

Deploying infrastructure with ARM templates is only one option for infrastructure as a code. We can achieve similar things with PowerShell and Azure CLI as well. Using infrastructure as a code allows us to deploy infrastructure needed to run our application in a fast and reliable way. It's a more consistent option as well because we are excluding manual tasks from deployment, creating an automated process, and eliminating human error in deployment.

Another great thing about ARM templates is that they can be added to our application project and stored in a repository, and we can keep track of versions of our environment. Different versions of an application may require changes in environment and with ARM templates and code repositories we can keep track of these changes and make sure that the correct environment is deployed for the version of the application we are deploying.

To sum everything up, ARM templates are a fast, reliable, and consistent way to deploy Azure resources that allow us to keep track of environment versioning and automate deployment processes. This is especially interesting and useful if we are trying to implement DevOps in our software delivery. In combination with configuration as a code (we'll talk about this in later chapters), we can build or replicate any environment with all resources required and apply the configuration needed for everything to run correctly.

A sample of an empty ARM template is shown here:

{
 "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 },
 "variables": {
 },
 "resources": [
 ],
 "outputs": {
 }
}

An ARM template contains information on parameters, variables, resources, and outputs. Using this information we define what resources need to be deployed, using which parameters, and which of these parameters can be variables that can be changed. Finally, we define the output as a replay, but this part is optional.

In this chapter, we explained cloud computing types and the evolution of cloud computing over time with a focus on the public cloud and Microsoft Azure. The next step was to explain the public cloud service model and how IaaS, PaaS, and SaaS work and the basic concepts of these public cloud types. You should also understand how Azure subscription works, how prices of resource are calculated, and basic administration concepts in relation to Azure subscriptions and the ARM model. We provided more information on ARM in general, and how it's connected to RBAC and ARM templates.

Understanding Azure subscriptions and ARM templates along with IaaS and PaaS in Azure is very important, as we'll use this knowledge in chapters to come.

The next step will be IaaS, as the first step toward cloud computing. The foundation for IaaS (and all other Azure services) is the Azure networking stack, and we'll start with this.

1. Which type of cloud requires an internet connection and allows anyone to sign up for service?
   1. Private cloud
   2. Hosted cloud
   3. Public cloud
2. Which cloud service model allows us most control over resources?
   1. IaaS
   2. PaaS
   3. SaaS
3. Which cloud service model requires the least management and administration?
   1. IaaS
   2. PaaS
   3. SaaS
4. Which cloud service model always gives us the latest features and updates?
   1. IaaS
   2. PaaS
   3. SaaS
5. What is responsible for separating the client environment from other clients in Azure?
   1. Azure fabric
   2. Azure tenant
   3. Azure subscription
6. What is the first access layer in Microsoft Azure?
   1. Azure fabric
   2. Azure tenant
   3. Azure subscription

7. What is the lowest granularity at which you can assign access to Azure resources?
   1. Azure resource
   2. Azure resource group
   3. Azure subscription
8. What is the recommended access level that should be assigned for Azure resources?
   1. Azure resource
   2. Azure resource group
   3. Azure subscription
9. How is pricing calculated for Microsoft Azure?
   1. Per year
   2. Per month
   3. Per minute
10. ARM templates are part of what?
    1. Infrastructure as a code
    2. IaaS
    3. Configuration as a code