Book Image

Microsoft Azure Fundamentals Certification and Beyond

By : Steve Miles
Book Image

Microsoft Azure Fundamentals Certification and Beyond

By: Steve Miles

Overview of this book

This is the digital and cloud era, and Microsoft Azure is one of the top cloud computing platforms. It’s now more important than ever to understand how the cloud functions and the different services that can be leveraged across the cloud. This book will give you a solid understanding of cloud concepts and Microsoft Azure, starting by taking you through cloud concepts in depth, then focusing on the core Azure architectural components, solutions, and management tools. Next, you will understand security concepts, defense-in-depth, and key security services such as Network Security Groups and Azure Firewall, as well as security operations tooling such as Azure Security Center and Azure Sentinel. As you progress, you will understand how identity, governance, privacy, and compliance are managed in Azure. Finally, you will get to grips with cost management, service-level agreements, and service life cycles. Throughout, the book features a number of hands-on exercises to support the concepts, services, and solutions discussed. This provides you with a glimpse of real-world scenarios, before finally concluding with practice questions for AZ-900 exam preparation. By the end of this Azure book, you will have a thorough understanding of cloud concepts and Azure fundamentals, enabling you to pass the AZ-900 certification exam easily.
Table of Contents (21 chapters)
1
Section 1: Cloud Concepts
4
Section 2: Core Azure Services
7
Section 3: Core Solutions and Management Tools
10
Section 4: Security
12
Section 5: Identity, Governance, Privacy, and Compliance
16
Section 6: Cost Management and Service-Level Agreements

What are the cloud computing service models?

Cloud computing has four service models; these could also be referred to as categories. These service models are as follows:

  • IaaS
  • PaaS
  • Serverless/FaaS
  • SaaS

The following illustration shows the relationship between these service models. Every cloud computing resource will fit into one of these three categories; a solution will comprise one or more resources from each of these categories, and you would select the resources from each category based on each solution's needs, a mix and match approach to tailoring a set of technology resources to map to business needs:

Figure 1.6 – Cloud computing service models

Figure 1.6 – Cloud computing service models

In this next section, we will cover quite a lot of ground as there are many concepts and aspects on which to present information, not only for the exam but also for knowledge beyond. We will take a closer look at each of the service models, comparing and contrasting each of their characteristics in more detail and introducing the concept of serverless computing.

A closer look at the cloud computing service models

Cloud computing is all about abstraction. This abstraction model approach means removing layer(s) that you no longer need to care about; the layer still exists, but it is being handled by somebody else and frees up resources to concentrate on other layers that are of more value.

The service models or categories of cloud computing define what layer of access and control the cloud services platform provider is responsible for and what the consumer of the cloud resources is responsible for.

We also change the unit of scale from hardware in the traditional computing model to applications or business logic (functions) at the other end when we look at serverless in the next section:

Figure 1.7 – Cloud computing service models – layer providers

Figure 1.7 – Cloud computing service models – layer providers

In the following illustration, we liken this to consuming pizza:

Figure 1.8 – Cloud computing service models – layer analogy

Figure 1.8 – Cloud computing service models – layer analogy

The comparison in this illustration to the cloud computing service model is to what level of input and control you want to fulfill that requirement to eat some pizza.

Do you want the quickest time to be enjoying eating pizza and let somebody else take care of making it, selecting the toppings, and cooking it? The trade-off is that you don't get a say in what ingredients they use to make the pizza base, what size it is, what toppings, or how well it is cooked; but in this scenario, you accept that you don't need to know or care and this may be the perfect scenario to meet this particular need at this time. This is an example of SaaS, a ready-cooked and prepared meal ready to consume, that is, takeaway as a service.

However, to contrast the example, you may need to eat pizza the same as before, but you have some requirements you wish to specify or mandate. You want a particular type of flour or ingredient to be used in the pizza base; maybe this is imperative as you have a specific intolerance or medical condition, so you must have control over the ingredients. You can't guarantee this with the takeaway example we just looked at; we know we get that choice and control when we take the cook at house in our illustration, so the option with the most control is the kitchen as a service or IaaS model.

But maybe the pizza base is not of concern; you don't want the trouble of making your pizza, as that's time, effort, and skill required even to know how to make a pizza base. So, you will let somebody else provide that for you, which will probably be better, faster, and cheaper than you could do, so you can focus on just choosing your toppings as this is where the value and fun bit is. Pizza bases are boring, but selecting the toppings is where it gets exciting, and you want to focus on the ingredients. This is where the ingredients as a service or PaaS model now has the most appeal.

The summary of all this is that each model will have its place that best meets your needs.

In the following section, we will introduce the concept of serverless computing to understand its positioning with the three service models of IaaS, PaaS, and SaaS that we looked at in this section.

What is serverless computing?

As this book's context is that of the knowledge and skills required to pass a Microsoft certification exam successfully, we should start with understanding Microsoft's definition of serverless:

"Serverless computing enables developers to build applications faster by eliminating the need for them to manage infrastructure. With serverless applications, the cloud service provider automatically provisions, scales, and manages the infrastructure required to run the code."

The term serverless itself is a bit of a misnomer, as in reality, there are servers involved, much like wireless does have wires involved at a certain point in the solution; it's more the fact that the servers do exist, but you don't need to know or care that they exist for you to have your desired outcome met. We come back to the topic of abstraction again; the same layers still exist, and there are still servers that execute the code passed down from the runtime layer – it's just that this layer is now further abstracted from you than it was in the IaaS and PaaS models.

The benefit of this further abstraction is that there are even fewer components to create and manage and allow development teams to focus on writing their core code without considering what's running their code; the provider takes care of automatically provisioning these resources to run the code. This all means faster, more productive development teams, less operational overheads for DevOps teams, more significant innovation, and quicker time to value and return on investment in development resources:

Figure 1.9 – Cloud computing service models – compare and contrast

Figure 1.9 – Cloud computing service models – compare and contrast

In the following illustration, we again liken this to consuming pizza:

Figure 1.10 – Cloud computing service models – layer providers

Figure 1.10 – Cloud computing service models – layer providers

In the preceding illustration, we have included the pizza analogy once again, this time to expand to include the serverless model. Again, the comparison here in this illustration to the cloud computing service model is to what level of input and control you want to fulfill that requirement to eat some pizza.

Some of the caveats of serverless are as follows:

  • Event-based workloads are the best use case.
  • Long-running tasks are not well suited.
  • The execution environment cannot be customized.
  • The cloud provider supports specific languages and runtimes.

Comparing the cloud computing service models

Each service model has its characteristics. The most appropriate model is defined by how much you want (or need/mandate) to control, secure, and manage your resources, for example, your apps, code, data, networks, security, and so on. From the last section, we can now define what the service models are; this section looks at the characteristics of each model in more detail to help you understand when you may choose one service model over the other.

Characteristics of IaaS

In a nutshell, IaaS is a model where you can host your virtual machines and infrastructure services on hardware provided for you and shared with other tenants.

The cloud provider is responsible for providing all layers up to and including the hardware; you are responsible for providing all layers preceding (refer to Figure 1.10).

The following are the characteristics of IaaS:

  • You create the virtual machine (install an OS and software), storage, and computing resources as you would in a traditional on-premises computing model; this can be likened to a virtual data center. There is the ability to provide fault tolerance, redundancy through availability solutions in case of failure within an Azure data center, zone, or region.
  • You have control to increase resources such as the processor, memory, and storage of a virtual machine by using self-service without requiring to redeploy or create a new virtual machine of the required spec.
  • Based on the OpEx model, meaning you only pay for resources you consume on a pay-as-you-go basis; you only pay for a virtual machine while it's running, therefore your month-to-month running charges may be different across virtual machines if you run them for a different number of hours in the month. You will not be charged while it is in the stopped deallocated state; storage costs will still be charged if you wish to persist the data on disks.
  • It provides the greatest control and flexibility to deploy, configure, manage, and support resources as you require and requires the most management and administrative and operations overhead.
  • You have direct access and complete control of the virtual machine, the operating system, and any roles/services such as the web server, application server, or SQL server that may be required to be installed/running on the virtual machines, as well as complete control over decisions on networking, security, and protection.

The following are examples of Microsoft IaaS resources:

  • Azure Virtual Machines
  • Azure Storage
  • Azure Networking

Characteristics of PaaS

In a nutshell, PaaS is a model where you host your application, code, data, and business logic on compute, and storage resources are provided for you and shared with other tenants, but secured and isolated from other tenants.

The cloud provider is responsible for providing all layers up to and including the compute; you are responsible for providing all layers above (refer to Figure 1.10).

The following are the characteristics of PaaS:

  • It provides a ready-to-use environment and platform for faster deployment of hosting web applications, code, business logic, data, and so on. Using pre-deployed resources, development frameworks, languages, and runtimes provided as a service, there is a quicker time to value and consumption of the service.
  • It provides on-demand autoscaling of the platform used by a hosted application and services.
  • You have control to increase resources by changing the pricing tier of the service by using self-service; you must still select underlying compute resources sizing to host your app, code, and so on.
  • You would have no direct access or control of the virtual machine or any applications, services, or roles that may be installed; you do not get to specify or control which versions are available.
  • Because the service provider is responsible for the compute and storage resources layer, it gives you the least control and least flexibility. Still, it requires the least amount of management, administrative, and operations overhead.

The following are examples of Microsoft PaaS services:

  • Azure App Service
  • Azure SQL Database
  • Cosmos DB
  • Azure Files
  • Azure Active Directory Domain Services (AADDS)

Characteristics of FaaS (serverless)

In a nutshell, FaaS is a model where you provide your code and business logic and the cloud provider hosts it in their language, runtime, and compute environment shared with other tenants.

The cloud provider is responsible for providing all layers up to and including the language, runtime, and compute. You are responsible for providing all layers above, that is, the business logic layer (refer to Figure 1.10).

The following are the characteristics of FaaS:

  • Azure Functions is a serverless code engine. It has the use case of events that trigger code; that is, Functions code being executed is a response or action based on an event trigger.
  • Azure Logic Apps is a serverless workflow engine. It has the use case of events that trigger workflows; that is, a Logic Apps workflow is a response or action based on an event trigger.
  • You only have control over your application, code, and business logic layer; all other layers are provided as a service that you have no access or control over. Essentially, you take the layers supplied to you and use that to execute (run/launch) your code/workflow. Using the pizza analogy covered earlier, this is much like what could be described as a take and bake approach; ultimately, you are still responsible for cooking, but they have provided all the layers below, so it's ready to cook, as it were, much like a microwave meal, or taking the packaging off a pizza and putting it straight in the oven.
  • It provides the least control and flexibility but abstracts all the layers below, providing the least amount of deployment, configuration, and maintenance, so you can focus on the application, code, and business logic layers, where the value is, without needing to concern yourself with the layers below.

The following are examples of Microsoft Serverless resources:

  • Azure Functions
  • Azure Logic Apps

Characteristics of SaaS

In a nutshell, SaaS is a model where you consume an application provided for you and shared with other tenants.

The cloud provider is responsible for providing all the layers up to and including the applications; you are not responsible for any layers above other than the configuration and consumption of the app (refer to Figure 1.10).

The following are the characteristics of SaaS:

  • The cloud provider installs the application/solution and is responsible for its updates, scalability, availability, and security.
  • It provides the greatest time to value as there is no development time or resources required to create an application; it can be directly configured as needed and used instantly.
  • In our pizza analogy, all the layers are taken care of for us, so all we need to do is just eat; this is the classic takeaway approach.
  • It provides the minimum amount of control and input on the lower layers.

The following are examples of Microsoft SaaS solutions:

  • Microsoft Teams
  • Microsoft Exchange Online
  • Microsoft SharePoint Online
  • Microsoft OneDrive
  • Microsoft Dynamics 365

The following are examples of other vendors' SaaS solutions:

  • Zoom
  • Salesforce
  • Dropbox
  • Google Mail/Google Docs

In this section, we covered the service models of IaaS, PaaS, and SaaS and introduced the concept of serverless computing as an extension of PaaS. We compared and contrasted each service model and outlined the characteristics unique to a particular model and those common across the models.