Cloud services have come a long way in the last 5 to 10 years. Cloud was and still is one of the biggest trends in Information Technology (IT), with new topics still to be discovered.

In the early 2000s, cloud computing wasn't a widely used phrase, but the concept, as well as data centers with massive computing power, already existed. Later in that decade, the word cloud became a buzzword for nearly anything that was not tangible or online. But the real rise of cloud computing with all its different service models happened before, when big IT companies started their cloud offerings. That was Amazon, Google, and Microsoft in particular. As these cloud offerings developed, they enabled companies from start ups to Fortune 500s to use cloud services, from web services to virtual machines, with billing exact to the minute.

In this chapter, we'll explore the following topics:

• Cloud service models
• Cloud deployment models
• Cloud characteristics
• Multi-cloud characteristics and models
• An overview of Azure services 

To start with Microsoft Azure and cloud services, you need an active Azure subscription and an Azure tenant, which will be obtained with the subscription. There are different ways to order such an subscription. The following list provides a few options: 

• Microsoft MSDN subscription
• Microsoft Azure free trial 
• Microsoft Azure pass 
• Microsoft Enterprise Agreement (EA) with Azure commitment 
• Microsoft Azure cloud solution provider 
• Microsoft Azure in open licensing 
• Microsoft BizSpark program 

Cloud computing is a new trend model for enabling workloads that use resources from a normally huge resource pool that is operated by a cloud service provider. These resources include servers, storage, network resources, applications, services, or even functions. These can be rapidly deployed, operated, and automated with little effort and the prices are calculated on a per-minute basis. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

Cloud offerings are mainly categorized into the following service models:

• Infrastructure as a Service (IaaS): This describes a model where the cloud provider enables the consumer to create and configure resources from the computing layer upwards, without any need to care or know about the hardware layer. That includes virtual machines, networks, appliances, and lots of other infrastructure-related resources and services. The most popular IaaS resources in Azure contain virtual machines, virtual networks (internal and external), container services, and storage.
• Platform as a Service (PaaS): This gives the consumer an environment from the operating system upwards. So, the consumer is not responsible for the underlying IaaS infrastructure. Examples are operating systems, databases, or development frameworks. Microsoft Azure contains many PaaS resources such as SQL databases, Azure app services, or cloud services.
• Software as a Service (SaaS): This is the model with the lowest level of control and required management. A SaaS application is reachable from multiple clients and consumers, and the owning consumer doesn't have any control over the backend, except for some application-related management tasks. Examples of SaaS applications are Office 365, Visual Studio Online, the Outlook website, OneDrive, and even the Amazon website itself is a SaaS application with Amazon as its own consumer.

A comparison of service model responsibilities is shown in the following diagram:

There are also a number of deployment models for cloud computing that need to be discussed. These deployment models cover nearly all common cloud computing provider scenarios. They describe the group of consumers that are able to use the services of the cloud service, rather than the institution or the underlying infrastructure:

• Public cloud: A public cloud describes a cloud computing offer that can be accessed by the public. This includes individuals as well as companies. Examples of a public cloud are Microsoft Azure and Amazon AWS.
• Community cloud: A community cloud is only accessible by a specified group. These are, for example, connected by location, an organization membership, or by reasons of compliance. Examples of a community cloud are Microsoft Azure Germany (location) or Microsoft Azure Government (organization and compliance) for US government authorities.
• Private cloud: A private cloud describes an environment/infrastructure built and operated by a single organization for internal use. These offers are specifically designed for the different units in the organization. Examples are Microsoft Windows Azure Pack (WAP) or Microsoft Azure Stack, as well as OpenStack, if they are used for internal deployments.
• Hybrid cloud: The hybrid cloud combines the private and public clouds. It is defined as a private cloud environment at the consumer's premises, as well as the public cloud infrastructure that the consumer uses. These structures are generally connected by site-to-site VPNs or Multiprotocol Label Switching (MPLS). A hybrid cloud could also exist as a combination of any other models, such as community and public clouds. Examples are Azure VMs connected to an on-premises infrastructure through Microsoft Azure ExpressRoute or site-to-site VPN.

The following diagram depicts a comparison between Azure (public cloud) and Azure Pack (private cloud):

Microsoft Azure is one of the biggest cloud service providers worldwide, offering a wide range of services from IaaS to PaaS to SaaS. It fulfills all of the characteristics that the National Institute of Standards and Technology (NIST) describes for cloud computing. These are as follows:

• On-demand self-service: This means an automated deployment of resources that a consumer orders through an interface such as a consumer portal.
• Broad network access: Providing availability of cloud services through a standardized network interface that is, at best, accessible by several endpoint devices.
• Resource pooling: This means that the automated assignment and reassignment of diverse resources from various resource pools for individual customers is possible.
• Rapid elasticity: It is also known as rapid scaling and describes the ability to scale resources in a massive way. The automatic and fast assignment and reassignment of resources, and rapid up and down scaling of single instances, are keywords when talking about rapid elasticity. The adjustment of web server resources depending on the demand is an example of rapid elasticity.
• Measured service: All data usage for consumer resources is monitored and reported, to be available for consumers and the cloud provider. This is one of the requirements for minute-based billing.

When defining multi-cloud, you need first to be aware of what a cloud service is. At this stage of this book, you already had some insight into cloud computing and cloud models and characteristics. Now, you should be able to identify the cloud services you already use in your company and that you might use in the future. 

Multi-cloud means you or your company are using not only the services of one cloud provider, but different solutions from different cloud providers. That could be an example of using Microsoft Office 365 for business collaboration, Salesforce for CRM, and AWS Area 52 for GeoDNS and GeoIP, or even OpenStack or Azure Stack as your private cloud solution within your data center or co-location.

The following diagram shows a schematic definition of a person or company between multiple cloud providers:  

Why use multiple cloud providers and not only one that fits all? There are different reasons why someone chooses a multi-cloud solution. Let me explain the most common reasons in the field:

• Redundancy: You don't want to build up your environment on only one cloud provider because one can fail, as happened with AWS in the past. So, you want to keep the business running with the services of another cloud provider. That's mostly a reason when using IaaS or PaaS. Redundancy is mostly not possible with SaaS if the cloud provider does not support hybrid environments. 
• The solution does not fit my needs: Mostly when choosing a cloud solution, you see whether it fits your need. You mostly look to features such as data center location or performance. Sometimes, a cloud solution from my preferred provider does not fit those needs, so I need to choose another cloud provider with its solution. Often, you see that in Microsoft Dynamics CRM Online versus Salesforce, or your preferred provider does not offer a data center in South Africa. So, you may switch from AWS to Microsoft Azure for that reason. 
• The cloud provider does not offer the service I need: Often, cloud providers are strong in one field and less so in others. This means they don't offer the services you may want; for example, you use Salesforce and want to have a unified single sign-on solution with Facebook, Twitter, or Instagram for your marketing teams. That's a service Salesforce does not offer at the moment, which means you may want to include Microsoft Azure Active Directory (AD) in your environment to achieve your goal.
• Your departments use a cloud service as shadow IT: I have seen shadow IT in nearly every company in the last 12 years of my work experience. It means a department uses a solution outside of the IT controlled area or solution field, managing the application itself without IT knowing of it. Often, it happens that those solutions become business critical and C-level management forces IT to take over the solution and support it. In times of easily accessible cloud solutions, this issue increased dramatically. Their are mostly two reasons for shadow IT:  
  • IT departments aren't fast enough to deploy an appropriate on-premises solution
  • The user thinks, Okay I only need a credit card? Let's try.

The key elements to building and performing a successful multi-cloud solution is to build a uniform solution between all of the cloud providers. Those solutions are based on a uniform Identity and Access Management (IAM), network, and application infrastructure.

Within this field, you might see two flavors of multi-cloud.

With cloud brokering, you migrate your workload depending on the price and needs from one cloud provider to another. That can be on a day-to-day or more frequent basis. This brokering was the first intention of businesses to save money with the cloud, but in practice, brokering only works with very simple IaaS or very standardized PaaS solutions. Most of the more complex workloads, such as Microsoft Exchange, SAP, and Oracle depend on drivers and you always have different hypervisor solutions between your cloud providers. In addition to that, IaaS workloads are very costly compared with solutions built on PaaS. So, looking down and ahead the timeline, the second multi-cloud model has become more common—best of breed. 

 Best of breed means you choose your cloud provider and a solution that fits for your needs and business requirements, or that is the market leader in a special area, for example, artificial intelligence, Network as a Service (NaaS), collaboration software, or data center distribution. Mostly, that means you will always end up with three or more cloud providers integrated with each other. 

When Windows Azure came online for the general public in February 2010, there were only database services, websites, and virtual machine hosting available. Over time, Microsoft constantly added features and new services to Azure, and, as there were more and more offerings for Linux and other non-Windows services, Microsoft decided in April 2014 to rename Windows Azure to Microsoft Azure. This supported Microsoft's commitment to transform itself into a services company, which means that, in order to be successful, you have to offer as many services as possible to as many clients as possible. Since then, Microsoft has constantly improved and released new services. Additionally, it constantly builds and expands data centers all over the world.

Azure offers many services in its cloud computing platform. These services include the following:

The service categories, differentiated between platform services and infrastructure services.

The platform services are as follows: 

• Management: These services include the management portal, the marketplace with the services gallery, and the components to automate things in Azure.
• Compute services: Compute services are Azure cloud services that are basically PaaS offerings for developers to quickly build and deploy highly scalable applications. The service fabric and Azure RemoteApp are also in this category.
• Security: This contains all of the services that provide identity in Azure, such as Azure AD, multi-factor authentication, and the key vault, which is a safe place for your certificates.
• Integration: The integration services include interface services such as BizTalk and Azure Service Bus, but also message helpers such as storage queues.
• Media and CDN: These are basically two services. One is the CDN, which makes it possible to build your own content delivery network based on Azure. The other is media services that make it very easy to use and process different media with the help of Azure.
• Web and mobile: These include all of the services that assist in creating apps or backend services for the web and mobiles, for example, web apps and API apps.
• Developer services: These are cloud-based development tools for version control, collaboration, and other development-related tasks. The Azure SDK is a part of the developer services.
• Data: The data services contain all of the different database types that you can deploy in Azure (SQL, DocumentDB, MongoDB, Table storage, and so on) and diverse tools to configure them.
• Analytics and IoT: As the name suggests, analytics services are tools to analyze and process data. This offers a broad range of possibilities, from machine learning to stream analytics. These can, but don't have to, build on certain data services. The Internet of Things (IoT) services include the fundamental tools needed to work with devices used for the IoT, such as the Raspberry Pi 2.
• Hybrid operations: This category sums up all of the remaining services that could not clearly be categorized. These include backup, monitoring, and disaster recovery, as well as many others.

 The infrastructure services are as follows:

• Operating system and server compute: This category consists of compute containers. It includes virtual machine containers and, additionally, container services, which are quite new to the product range.
• Storage: Storage services are the two main storage types—BLOB and file storage. They have different pricing tiers depending on the speed and latency of the storage ordered. Storage is looked at in detail in Chapter 6, Implementing Azure Storage.
• Networking: This category consists of basic networking resources. Examples are load balancer, ExpressRoute, and VPN gateways.

The important thing is to remember that we are talking about a rapidly changing and very agile cloud computing platform. After this chapter, if you have not already done so, you should start using Azure by experimenting, exploring, and implementing your solutions while reading the correlating chapters.

For testing purposes, you should use the Azure Free Trial (https://azure.microsoft.com/en-in/offers/ms-azr-0044p/‎), Visual Studio Dev Essentials (https://www.visualstudio.com/dev-essentials/), or the included Azure amount from an MSDN subscription.

In the following section, we will take a look at the basic Microsoft Azure key concepts. This should provide an overview and an idea of how to use Azure.

In the previous major version of Azure, a deployment backend model called Azure Service Manager (ASM) was used. With higher demand on scaling, and being more flexible and standardized, a new model called ARM was introduced and is now the standard way of using Azure.

This includes a new portal, a new way of looking at things as resources, and a standardized API that every tool, including the Azure portal, that interacts with Azure uses.

With this API and architectural changes, it's possible to use such things as ARM templates for any size of deployment. ARM templates are written in JavaScript Object Notation (JSON) and are a convenient way to define one or more resources and their relationship to another programmatically. This structure is then deployed to a resource group. With this deployment model, it's possible to define dependencies between resources, as well as being able to deploy the exact same architecture again and again. The next section will dive a little deeper into resources.

Azure resources are the key to every service offering in Azure. Resources are the smallest building blocks and represent a single technical entity, such as a VM, a network interface card, a storage account, a database, or a website. When deploying a web app, a resource called app service will be deployed along with a service plan for billing.

When deploying a virtual machine from an Azure Marketplace template, a VM resource will be created as well as a storage account resource holding the virtual hard disks, a public IP Address resource for initial access to the VM, a network interface card, and a virtual network resource.

Every resource has to be deployed to one specific resource group. A resource group can hold multiple resources, while a single resource can only exist in one resource group. Resource groups also can't contain another resource group, which leads to a single layer of containers regarding resources.

One resource group can contain all resources of a deployment or multiple resources of different deployments. There are no strong recommendations on structuring resource groups, but it's recommended to organize either the resources of one project/enrollment/deployment in separate resource groups or distribute resources based on their purpose (networking, storage, and so on) to resource groups.

Azure as a global cloud platform provides multiple regions to deploy resources to. One region consists of at least one highly available data center or data center complex. At the time of writing, 54 regions are distributed all over the world and include community clouds, so-called sovereign regions.

Microsoft also divides its regions into geopolitical zones, which can be found at the following URL: https://azure.microsoft.com/en-us/global-infrastructure/regions/.

These sovereign clouds where built by Microsoft to fit customer or governmental needs, such as for special compliance and/or data privacy laws. At the moment, the following sovereign clouds are available: 

• Microsoft Azure US Department of Defense (DoD) 
• Microsoft Azure US Government 
• Microsoft Azure China 
• Microsoft Cloud Germany

Microsoft Cloud Germany is also special among the sovereign clouds. Because of customer demands, Microsoft built up Microsoft Cloud Germany differently. Microsoft does not operate the cloud in Germany itself; they use a data trustee to operate the cloud for them. Microsoft Azure staff and all Microsoft employees are not allowed to enter the data centers or lay hands on the servers or framework. Everything is operated by the trustee, starting with hardware maintenance up to updates of the framework. 

Regions can also have an impact on the performance and availability of some resources. Some services may not be, or are only partially, available in a specific region.

The costs of offered services also vary by region. For reduced latency, it's recommended to choose a region next to the physical location of the consumer. It might also be important to see which legal requirements must be met. This could, for example, result in a deployment only in EU regions, or even regions in specific countries:

• Available Azure regions: https://azure.microsoft.com/en-us/regions/
• Lists all the services available in specific regions: https://azure.microsoft.com/en-us/regions/services/

Microsoft operates two types of following data centers:

• The first type is the production data center, where Microsoft calculates all workloads of its customers and stores all the data.
• The second type is the edge or delivery site. Those sites connect all Microsoft Cloud services to the internet and Microsoft's customers. Edge sites come in two stages of expansion. The smallest one allows Microsoft public direct peering through the internet. With the second stage of expansion, Microsoft allows customers and providers to establish a private connection to the Microsoft backbone using the Microsoft Azure ExpressRoute service. 

The following diagram shows a schematic of the Microsoft data center structure:

Edge and production sites are connected through the Microsoft backbone. Currently Microsoft owns and operates the second largest and fastest full meshed provider backbone of the world.. Microsoft also owns and operates own see cables such as the MAREA cable from Bilbao (Spain) to Virginia (US). 

This map shows the current Microsoft Azure backbone with the new MAREA cable:

While building its backbone, Microsoft acts differently to the other cloud providers. Microsoft builds its own dark fibre cables or leases dark fibre cables and operates the whole backbone itself. Microsoft runs a fully software-defined network and infrastructure for its backbone, using firewall appliances built for network function virtualization.

If you ever have the chance to see a server rack that connects the Microsoft backbone or represents a Microsoft Edge site, it will probably look like this:

If you want to know more about Microsoft regarding data center equipment and software defined, I highly recommend you consult open source and open compute projects. Microsoft is investing highly in these and is very open in the following projects:

• Microsoft cloud servers:
  • Open cloud server platform: https://www.opencompute.org/projects/server
  • ARM-based cloud server project olympus: https://www.opencompute.org/wiki/Server/ProjectOlympus
• Microsoft network cards for backbone and cloud services: 
  • Smart NIC: https://www.opencompute.org/wiki/Server/Mezz
• Microsoft networking and switch software:
  • Project SONiC: https://azure.microsoft.com/de-de/blog/sonic-the-networking-switch-software-that-powers-the-microsoft-global-cloud/

The Azure portal is a web application and the most straightforward way to view and manage most Azure resources. The Azure portal can also be used for identity management, to view billing information, and to create custom dashboards for often used resources to get a quick overview of some deployments.

Although it's easy to start with using and deploying services and resources, it's highly recommended to use some Azure automation technologies for larger and production environments. The Azure portal is located at https://portal.azure.com.

Azure automation is a service and a resource, as well as an Azure concept in the context of cloud computing.

It's very important to see automation as an essential concept when it comes to cloud computing. Automation is one of the key technologies to reduce operational costs and will also provide a consistent and replicable state. It also lays the foundation of any rapid deployment plans.

As Azure uses a lot of automation internally, Microsoft decided to make some of that technology available as a resource called automation account.

Azure provides several ways of interacting and automating things. The two main ways to interact with Azure besides the portal are Azure PowerShell and the Azure Command-Line Interface (CLI).

Both are basically just wrappers around the Azure API to enable everyone not familiar with RESTful APIs, but familiar with their specific scripting language, to use and automate Azure. The Azure PowerShell module provides cmdlet for managing Azure services and resources through the Azure API. Azure PowerShell cmdlet are used to handle account management and environment management, including creating, updating, and deleting resources. These cmdlet work completely the same on Azure, Azure Pack, and the Azure Stack, Microsoft's private cloud offerings.

Azure PowerShell is open source and maintained by Microsoft. The project is available on GitHub at the following link: https://github.com/Azure/azure-powershell. The Azure CLI is a tool that you can use to create, manage, and remove Azure resources from the command-line. The Azure CLI was created for administrators and operators that are not that experienced with Microsoft technologies, but with other server technologies, such as Unix or Linux. The Azure CLI is an open source project as well, and is available for Linux, macOS, and Windows here: https://github.com/Azure/azure-cli.

All Azure services, including the Azure Management Portal, provide their own REST APIs for their functionality. They can, therefore, be accessed by any application that RESTful services can process.

In order for software developers to write applications in the programming language of their choice, Microsoft offers wrapper classes for the REST APIs.

These are available as an Azure SDK for numerous programming languages (for example, .NET, Java, and Node.js) here at https://github.com/Azure.

In this chapter, we learned about cloud models and what cloud in general means. We now know how Microsoft fits into that ecosystem with its cloud services and their strategy. We also gained some very important insights into Azure and Microsoft regarding their data centers and backbone. 

In the next chapter, we will take a look at Azure Resource Manager and the Azure Resource Manager tools.

Please answer the following questions:

1. What are the three basic cloud service models? 
2. What are four basic cloud deployment models? 
3. How is a multi-cloud solution described? 
4. What is the difference between a Microsoft Azure Global Region and a Sovereign Region? 
5. What is the difference between a Microsoft Edge and production data center? 
6. What is the URL of the Azure portal? 
7. What is the name of the Microsoft private cloud solution based on ARM? 

In the following books, you can find more information about what we learned in this chapter:

• Building Hybrid Clouds with Azure Stack: https://www.packtpub.com/virtualization-and-cloud/building-hybrid-clouds-azure-stack
• Beginning Serverless Architectures with Microsoft Azure: https://www.packtpub.com/virtualization-and-cloud/beginning-serverless-architectures-microsoft-azure
• Architecting Microsoft Azure Solutions – Exam Guide 70-535: https://www.packtpub.com/virtualization-and-cloud/architecting-microsoft-azure-solutions-exam-guide-70-535
• Implementing Azure Cloud Design Patterns: https://www.packtpub.com/virtualization-and-cloud/implementing-azure-cloud-design-patterns