Today, cloud computing is one of the most promising upcoming technologies and enterprise—no matter how big or small, almost every companies and organization has adopted it as a part of their IT strategy. It is difficult these days to have any meaningful conversation about an IT strategy without including cloud computing in the overall solution discussions.

Cloud computing, or simply the cloud in layman terms, refers to the availability of resources on the internet. These resources are made available to users on the internet as services. For example, storage is available on demand through the internet to users for them to store their files, documents, and so on. Here, storage is a service provided by a cloud provider.

A cloud provider is an enterprise or consortium of companies that provide cloud services to other enterprises and consumers. They host and manage the services on behalf of the user. They are responsible for enabling and maintaining the health of services. Typically, there are large data centers across the globe opened by cloud providers to cater to IT demands from users.

Cloud resources consist of hosting services on on-demand infrastructure, such as compute, network, and storage facilities. This flavor of the cloud is known as Infrastructure as a Service.

Cloud adoption is at an all-time high and is further growing because of the advantages it provides. Some of these advantages are mentioned here:

• Pay-as-you-go: Customers do not need to purchase hardware and software for cloud resources. There is no capital expenditure for using cloud resource. Customers just pay for the resource for the time they are used.
• Global access: Cloud resources are available globally via the internet. Customers can access their resources on demand from any where.
• Unlimited resources: The scale of the cloud is unlimited. Customers can provision as many resources as they want, without any constraints. This is also known as unlimited scalability.
• Managed Services: The cloud provides numerous services that are managed by the cloud provider for customers. This takes away the technical and financial burdens from customers.

There are three different deployment patterns available on Azure. They are

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

The difference between these three deployment patterns is the level of control exercised by customer viz-a-viz Azure. The next image shows different levels of control within each of these deployment patterns.

It is clear from the previous image that customers have more control using IaaS deployments and it keeps reducing from PaaS to SaaS deployments.

IaaS is a deployment types in which customer provision their own infrastructure on Azure. Azure provides infrastructure resources and customers can provision them on demand. Customer are responsible for maintaining and governing their infrastructure. Azure will ensure to maintain the physical infrastructure on which these virtual infrastructure resources are hosted. Under this approach, customers needs active management and operations on the Azure environment.

PaaS takes away infrastructure deployments and control from customer. This is a higher level abstraction compared to infrastructure as service. In this approach, customers bring their application, code and data and deploy them on Azure provided platform. These platform are managed and governed by Azure and customer are responsible solely for their application. Customers perform activities related to their applications deployment only. This model provides faster and easier options for deployment of applications compared to infrastructure as a service.

SaaS is a level higher abstraction compared to PaaS. In this approach, software and its services are available for end user consumption. Customer bring only their data into these services. Customers do not have any control over these services.

Azure provides all the benefits of the cloud, while being open and flexible. Azure supports a variety of operating systems, languages, tools, platforms, utilities, and frameworks. It supports both Linux and Windows, SQL Server, MySQL, PostgreSQL and more, as well as C#, Python, Java, Node.js, Bash, and other languages; MongoDB and DocumentDB NoSQL databases, and Jenkins to VSTS as continuous integration tools. The whole idea behind this ecosystem is to enable users to have their choice and freedom of language, their choice of platform and operating system, their choice of database, their choice of storage, and their choice of tools and utilities. Users should not be constrained from the technology perspective; instead, they should be able to build and focus on their business solution, and Azure provides them with a world-class technology stack. Azure is compatible with the user's choice of technology stack.

For example, Azure supports all popular (open source or commercial) database environments. Azure provides Azure SQL, MySQL, and Postgres PaaS services. It provides a Hadoop ecosystem and offers HDInsight, a 100% Apache Hadoop-based PaaS. It also provides a Hadoop on Linux virtual machine implementation for customers who prefer the IaaS approach. Azure also provides a Redis cache service and supports other popular database environments, such as MongoDB, Couchbase, Oracle, and many others as an IaaS implementation.

The number of services is increasing by the day, and the following diagram displays the rich set of services provided by Azure. Not all services are shown here, and the list keeps on growing. The most updated list of services can be found at https://azure.microsoft.com/en-in/services/.

Azure also provides a unique cloud computing paradigm—the hybrid cloud. The hybrid cloud refers to a deployment strategy in which a subset of services are deployed on a public cloud, while other services are deployed in an on-premise private cloud or data center. There is a Virtual Private Network (VPN) connection between both the public and private cloud. Azure provides users the flexibility to divide and deploy their workload on both the public cloud and an on-premise data center.

Azure has data centers across the globe. Azure combines these data centers into regions. Each region has multiple data centers to ensure that recovery from disasters is quick and efficient. At the time of writing, there are 38 regions across the globe. This provides users the flexibility to deploy their services at their choice of location and region. They can also combine these regions to deploy a solution that is disaster-resistant and deployed near their customer base.

Azure provides infrastructure and services to ingest millions and billions of transactions with hyper-scale processing. It provides multi-petabytes of storage for data. It provides a host of inter-connected services that can pass data between themselves. With such capabilities in place, data can be processed to generate meaningful knowledge and insights. There are multiple types of insights that can be generated through data analysis, which are as follows:

• Descriptive: This kind of analysis provides details about what is happening or has happened in the past.
• Predictive: This kind of analysis provides details about what is going to happen in the near-future or the future.

• Prescriptive: This kind of analysis provides details about what should be done to either enhance or prevent the current or future events happening.
• Cognitive: This actually executes the actions determined by prescriptive analytics in an automated manner.

While deriving insights from data is good, it is equally important to act on them. Azure provides a rich platform to ingest large volume of data, process and transform it, eventually store and generate insights from them, and display them on real-time dashboards. It is also possible to take action on the insights automatically. These services are available to every user of Azure and provide a rich ecosystem on which to create solutions. Enterprises are creating applications and services that are completely disrupting industries because of the easy availability of these intelligent services from Azure that are easily combined to create meaningful value to end customers. Azure ensures that services that are commercially unviable to implement by small and medium companies can now be readily consumed and deployed in a few minutes.

Azure Resource Manager (ARM) is the technology platform and orchestration service from Microsoft that ties up all components discussed earlier. It brings Azure resource providers, resources, and resource groups together to form a cohesive cloud platform. It helps in the registration of resource providers to subscriptions and regions; it makes the resource types available to resource groups; it makes the resource and resource APIs accessible to the portal and other clients; and it authenticates access to resources. It also enables features such as tagging, authentication, Role-Based Access Control (RBAC), resource locking, and policy enforcement for subscriptions and its resource groups. It provides the same deployment and management experience, whether through a portal or client-based tools such as PowerShell or a command-line interface.

The architecture of ARM and its components are as shown in the following diagram. As we can see in the following figure, Azure Subscription comprises multiple resource groups. Each resource group contains resource instances that are created from resource types available in the resource provider:

ASM has inherent constraints, and some of the major ones are discussed here: ASM deployments are slow and blocking. Operations are blocked if an earlier operation is already in progress. Some of the limitations to ASM are mentioned here:

• Parallelism: Parallelism is a challenge in ASM. It is not possible to execute multiple transactions successfully in parallel. The operations in ASM are linear and executed one after another. Either there are parallel operation errors or they will get blocked.
• Resources: Resources in ASM are provisioned and managed in isolation from each other; there is no relation between ASM resources. Grouping services and resources or configuring them together is not possible.
• Cloud services: Cloud services are the unit of deployment in ASM. They are reliant on affinity groups and not scalable due to their design and architecture.

Granular and discreet roles and permissions cannot be assigned to resources in ASM. Users are either service administrators or co-administrators in the subscription. They either get full control over resources or do not have access to them at all. ASM provides no deployment support. Deployments are either manual or you will need to resort to writing procedural scripts in PowerShell or .NET. ASM APIs are not consistent between resources.

ARM provides distinct advantages and benefits over ASM, which are as follows:

• Grouping: ARM allows grouping of resources together in a logical container. These resources can be managed together and go through a common life cycle as a group. This makes it easier to identify related and dependent resources.
• Common life cycle: Resources in a group have the same life cycle. These resources can evolve and be managed together as a unit.
• Role-Based Access Control: Granular roles and permissions can be assigned to resources providing discreet access to users. Users can also have only those rights that are assigned to them.
• Deployment support: ARM provides deployment support in terms of templates enabling DevOps and Infrastructure as Code (IAC). The deployments are faster, consistent, and predictable.

• Superior technology: Cost and billing of resources can be managed as a unit. Each resource group can provide their usage and cost information.
• Manageability: ARM provides advanced features, such as security, monitoring, auditing, and tagging, for better manageability of resources. Resources can be queried based on tags. Tags also provide cost and billing information for resources tagged similarly.
• Migration: Easier migration and updating of resources within and across resource groups.

With ARM, everything in Azure is a resource. Examples of resources are virtual machines, network interfaces, public IP addresses, storage accounts, and virtual networks. ARM is based on concepts related to resource providers and resource consumers. Azure provides resources and services through multiple resource providers that are consumed and deployed in groups.

These are services that are responsible for providing resource types through ARM. The top-level concept in ARM is resource providers. These providers are containers for resource types. Resource types are grouped into resource providers. They are responsible for deploying and managing the resources. For example, a virtual machine resource type is provided by a resource provider called Microsoft.Compute Namespace. The REST API operations are versioned to distinguish between them. The version naming is based on the dates on which they are released by Microsoft. It is necessary that a related resource provider is available to a subscription to deploy a resource. Not all resource providers are available to a subscription out of the box. If a resource is not available in the subscription, you need to check whether the required resource provider is available in each region. If it is available, the user can explicitly register in the subscription.

These are an actual resource specification defining their public API interface and implementation. They implement the working and operations supported by the resource. Similar to resource providers, resource types also evolve over time with regard to their internal implementation and have multiple versions of their schema and public API interface. The version names are based on the dates that they are released by Microsoft as a preview or General Availability (GA). The resource types become available to a subscription after a resource provider is registered to it. Also, not every resource type is available in every Azure region. The availability of a resource is dependent on the availability and registration of a resource provider in an Azure region and must support the API version needed for provisioning it.

Resource groups are a unit of deployment in ARM. They are containers grouping multiple resource instances in a security and management boundary. A resource group is uniquely named in a subscription. Resources can be provisioned on different Azure regions and yet belong to the same resource group. Resource groups provide additional services to all the resources within it. Resource groups provide metadata services, such as tagging, which enables the categorization of resources, policy-based management of resources, RBAC, protection of resources from accidental deletion or updates, and more. As mentioned before, they have a security boundary, and users that don't have access to a resource group cannot access resources contained within it. Every resource instance needs to be part of a resource group or else it cannot be deployed.

Resources are created from resource types and should be unique within a resource group. The uniqueness is defined by the name of the resource and its type together. In OOP parlance, resource instances can be referred to as objects, while resource types can be referred to as a class. The services are consumed through the operations supported and implemented by resource instances. They define properties that should be configured before usage. Some are mandatory properties, while others are optional. They inherit the security and access configuration from its parent resource group. These inherited permissions and role assignments can be overridden for each resource. A resource can be locked in such a way that some of its operations can be blocked and not made available to roles, users, and groups even though they have access to it. They can be tagged for easy discoverability and manageability.

The following are some of the major features provided by ARM:

• Role-Based Access Control: Azure Active Directory (AAD) authenticates users to provide access to subscriptions, resource groups, and resources. ARM implements OAuth and RBAC within the platform, enabling authorization and access control for resources, resource groups, and subscriptions based on roles assigned to a user or group. A permission defines access to operations on a resource. These permissions could allow or deny access to the resource. A role definition is a collection of these permissions. Roles map AAD users and groups to the permissions. Roles are subsequently assigned to a scope, which can be an individual, collection of resources, resource group, or subscription. The AAD identities (users, groups, and service principles) added to a role gain access to the resource according to permissions defined in the role. ARM provides multiple out-of-the-box roles. It provides system roles, such as owner, contributor, and reader. It also provides resource-based roles, such as SQL DB contributor and virtual machine contributor. ARM allows the creation of custom roles.
• Tags: Tags are name-value pairs that add additional information and metadata to resources. Both resources and resource groups can be tagged with multiple tags. Tags help in the categorization of resources for better discoverability and manageability. Resources can be quickly searched and identified easily. Billing and cost information can be fetched for resources that have the same tags. While this feature is provided by ARM, an IT administrator defines its usage and taxonomy with regard to resources and resource groups. Taxonomy and tags, for example, can relate to departments, resource usage, location, projects, or any other criteria deemed fit from a cost, usage, billing, or search perspective. These tags can then be applied to resources. Tags defined at the resource group level are not inherited by its resources.

• Policies: Another security feature provided by ARM is policies. Custom policies can be created to control access to resources. Policies are defined conventions and rules and must be adhered to while interacting with resources and resource groups. The policy definition contains an explicit denial of actions on resources or access to resources. By default, every access is allowed if it is not mentioned in the policy definition. These policy definitions are assigned to resource, resource group, and subscriptions scope. It is important to note that these policies are not replacements or substitutes for RBAC. In fact, they complement and work together with RBAC. Policies are evaluated after a user is authenticated by AAD and authorized by the RBAC service. ARM provides a JSON-based policy definition language for defining policies. Some examples of policy definition are that it must tag every provisioned resource, and resources can only be provisioned to specific Azure regions.
• Locks: Subscriptions, resource groups, and resources can be locked to prevent accidental deletion and updates by an authenticated user. Locks applied at higher-levels flow downstream of child resources. Locks applied at the subscription level lock every resource group and the resources within it.
• Multi-region: Azure provides multiple regions for provisioning and hosting resources. ARM allows resources to be provisioned at different locations and yet reside within the same resource group. A resource group can contain resources from different regions.
• Idempotent: This feature ensures predictability, standardization, and consistency in resource deployment by ensuring that every deployment will result in the same state of resources and configuration, no matter the number of times it is executed.
• Extensible: ARM architecture provides an extensible architecture to allow the creating and plugging of new resource providers and resource types into the platform.

Virtualization was a breakthrough innovation that completely changed the way physical servers were looked at. It refers to the abstraction of a physical object into a logical object.

The virtualization of physical servers led to virtual servers known as virtual machines. These virtual machines consume and share the same physical CPU, memory, storage, and other hardware with the physical server on which they are hosted. This enabled faster and easier provisioning of application environments on demand, providing high availability and scalability with reduced cost. One physical server was enough to host multiple virtual machines, each virtual machine containing its own operating system and hosting services on it.

There was no longer any need to buy additional physical servers for deploying new applications and services. The existing physical servers were sufficient to host more virtual machines. Furthermore, as part of rationalization, many physical servers were consolidated into a few with the help of virtualization.

Each virtual machine contains the entire operating system, and each virtual machine is completely isolated from other virtual machines, including the physical hosts. Although a virtual machine uses the hardware provided by the host physical server, it has full control over its assigned resources and its environment. These virtual machines can be hosted on a network such as a physical server with its own identity.

Azure can create Linux and Windows virtual machines in a few minutes. Microsoft provides its own images, along with images from partners and the community. Users can provide their own images. Virtual machines are created using these images.

Containers are also a virtualization technology; however, they do not virtualize a physical server. Instead, a container is an operating system-level virtualization. What this means is that containers share the operating system kernel, provided by the host, among themselves along with the host. Multiple containers running on a host (physical or virtual) share the host operating system kernel. Containers ensure that they reuse the host kernel instead of each having a dedicated kernel to themselves.

Containers are also completely isolated from the host and other containers, such as a virtual machine. Containers use Windows storage filter drivers and session isolation to isolate operating system services such as the filesystem, registry, processes, and networks. Each container gets its own copy of operating system resources.

The container has the perception that it has a completely new and untouched operating system and resources. This arrangement provides lots of benefits, as follows:

• Containers are fast to provision. They do not need to provide the operating system and its kernel services. They are available from the host operating system.
• Containers are lightweight and require fewer computing resources than virtual machines. The operating system resource overhead is no longer required in containers.
• Containers are much smaller than virtual machines.
• Containers help solve problems related to managing multiple application dependencies in an intuitive, automated, and simple manner.
• Containers provide infrastructure to define all application dependencies in a single place.

Containers are an inherent part and feature of Windows Server 2016 and Windows 10; however, they are managed and accessed using a Docker client and a Docker daemon. Containers can be created on Azure with Windows Server 2016 SKU as an image. Each container has a single main process that must be running for the container to exist. A container will stop when this process ends. Also, a container can either run in interactive mode or in a detached mode like a service.

The preceding diagram shows all the technical layers that enable containers. The bottom-most layer provides the core infrastructure in terms of network, storage, load balancers, and network cards. At the top of the infrastructure is the compute layer, consisting of either a physical server, or both physical and virtual servers on top of a physical server. This layer contains the operating system with the ability to host containers. The operating system provides the execution driver that the layers above use to call kernel code and objects to execute containers. Microsoft has created Host Container System Shim (HCSShim) for managing and creating containers and uses Windows storage filter drivers for image and file management.

The container environment isolation ability is provided to the Windows session. Windows Server 2016 and Nano Server provide the operating system, enable the container features, and execute the user-level Docker client and Docker engine. The Docker engine uses the services of HCSShim, storage filter drivers, and sessions to spawn multiple containers on the server, each containing a service, application, or database.

Docker provides management features to Windows containers. It comprises of the following two executables:

• The Docker daemon
• The Docker client

The Docker daemon is the workhorse for managing containers. It is a Windows service responsible for managing all activities on the host related to containers. The Docker client interacts with the Docker daemon and is responsible for capturing inputs and sending them across to the Docker daemon. The Docker daemon provides the runtime, libraries, graph drivers, and engine to create, manage, and monitor containers and images on the host server. It also has the ability to create custom images that are used for building and shipping applications to multiple environments.

Azure provides multiple ways to connect, automate, and interact with the intelligent cloud. All methods require users to be authenticated with valid credentials before they can be used. The different ways to connect to Azure are the following:

• Azure Portal
• PowerShell
• Azure Command-Line Interface (CLI)
• Azure REST API

Azure Portal is a great place to get started. With Azure Portal, users can log in and start creating and managing Azure resources manually. The Portal provides an intuitive and user-friendly user interface through the browser. The Azure Portal provides an easy way to navigate to resources using blades. The blades display all the properties of a resource, logs, cost, its relationship with other resources, tags, security options, and more. The entire cloud deployment can be managed through the Portal.

PowerShell is an object-based command-line shell and scripting language used for the administration, configuration, and management of infrastructure and environments. It is built on top of the .NET framework and provides automation capabilities. PowerShell has truly become a first-class citizen among IT administrators and automation developers for managing and controlling the Windows environment. Today, almost every Windows and many Linux environments can be managed by PowerShell. In fact, almost every aspect of Azure can also be managed by PowerShell. Azure provides rich support for PowerShell. It provides a PowerShell module for each resource provider containing hundreds of cmdlets. Users can use these cmdlets in their scripts to automate interaction with Azure. The Azure PowerShell module is available through the web platform installer on as well as through the PowerShell Gallery. Windows Server 2016 and Windows 10 provide package management and PowerShellGet modules for quick and easy downloading, and installation of PowerShell modules from the PowerShell gallery. The PowerShellGet module provides the Install-Module cmdlet for downloading and installing modules on the system.

Installing a module is a simple act of copying the module files at well-defined module locations that can be done as follows:

Import-module PowerShellGet
Install-Module -Name AzureRM -verbose  

Azure also provides Azure CLI 2.0, which can be deployed on Linux, Windows, and Mac operating systems. Azure CLI 2.0 is Azure's new command-line utility for managing Azure resources. Azure CLI 2.0 is optimized for managing and administering Azure resources from the command line, and for building automation scripts that work against the ARM. The CLI can be used to execute commands using Bash Shell or Windows command line. Azure CLI is a very famous among non-Windows users as it allows us to talk to Azure on Linux and Mac. Steps for installing Azure CLI 2 are available at https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest.

All Azure resources are exposed to users through REST endpoints. Representational State Transfer (REST) APIs are service endpoints that implement HTTP operations (methods), providing create, retrieve, update, or delete (CRUD) access to the service's resources. Users can consume these APIs to create and manage resources. In fact, the CLI and PowerShell mechanism uses these REST APIs internally to interact with resources on Azure.

In an earlier section, we witnessed deployment features, such as multi-service, multi-region, extensible, and idempotent, provided by ARM. ARM templates are the primary means of provisioning resources in ARM. ARM templates provide implementation support for ARM deployment features.

ARM templates provide a declarative model through which resources, their configuration, scripts, and extensions are specified. ARM templates are based on JavaScript Object Notation (JSON) format. They use the JSON syntax and conventions to declare and configure resources. JSON files are text-based, human-friendly, and easily readable files.

They can be stored in a source code repository and have version control. They are also a means to represent IAC that can be used to provision resources in an Azure resource group again and again, predictably, consistently, and uniformly. A template needs a resource group for deployment. It can only be deployed to a resource group and the resource group should exist before executing a template deployment. A template is not capable of creating a resource group.

Templates provide the flexibility to be generic and modular in their design and implementation. Templates provide the ability to accept parameters from users, declare internal variables, define dependencies between resources, link resources within same or different resource groups, and execute other templates. They also provide scripting language type expressions and functions that make them dynamic and customizable at runtime.

PowerShell allows the following two modes of deployment of templates:

• Incremental: Incremental deployment adds resources declared in the template that don't exist in a resource group, leaves resources unchanged in a resource group that is not part of a template definition, and leaves resources unchanged in a resource group that exists in both the template and resource group with the same configuration state.
• Complete: Complete deployment, on the other hand, adds resources declared in a template to the resource group, deletes resources that do not exist in the template from the resource group, and leaves resources unchanged that exist in both the resource group and template with the same configuration state.

The cloud is not more than 10 years old. It is a new paradigm and still in its nascent stage. There will be a lot of innovation and capabilities added over time. Azure is one of the top cloud providers today and it provides rich capabilities through IaaS, PaaS, SaaS, and hybrid deployments. In fact, the Azure stack, which is an implementation of the private cloud from Microsoft, will be released soon. This will have the same features available on a private cloud as on the public cloud. They both will, in fact, connect and work seamlessly and transparently together.

It is very easy to get started with Azure, but developers and architects can also fall into a trap if they do not design and architect their solutions appropriately. This book is an attempt to provide guidance and directions toward architecting solutions the right way, using appropriate services and resources. Every service on Azure is a resource. It is important to understand how these resources are organized and managed in Azure. This chapter provided context around ARM and groups—the core framework that provides building blocks for resources. It provides a set of services to resources that help provide uniformity, standardization, and consistency in managing them. The services, such as RBAC, tags, policies, and locks, are available to every resource provider and resource. Azure also provides rich automation features to automate and interact with resources. Tools such as PowerShell, ARM templates, and Azure CLI can be incorporated as part of release pipelines and continuous deployment and delivery. Users can connect to Azure from heterogeneous environments using these automation tools.

The next chapter will discuss some of the important architectural concerns that help solve common cloud-based deployment problems and ensure the application is secure, available, scalable, and maintainable in the long run.