Cloud computing is the next phase in the evolution of the computing platform and the next significant shift of the IT industry; it is another model for delivering computing resources to an organization.

We have evolved from physical hardware to virtualization that is run from our facilities or somebody else's to another computing model shift of virtual machines to containers and now the leap to serverless, where the business logic layer is the new scale unit in the journey to the cloud:

Figure 1.1 – Evolution of cloud computing

The goal of hybrid computing is to provide computing resources anywhere, anytime, and give a business the power of choice as to the most suitable technology platform for any given workload, business initiative, or scenario that needs to be supported.

Cloud computing is not only a technical evolution but also a financial evolution; the expenditure model shifts from that of capital expenditure (CapEx) of hardware (buying upfront before you can use resources) to operating expense (OpEx) and paying as you use resources.

It should be noted, though, that the private cloud model can contain an element of CapEx and OpEx; typically (and for the exam objectives), the primary cost expenditure model is CapEx. However, leased hardware and software are financially also considered OpEx, but would mainly mean building an on-premises infrastructure.

As the computing platform environments have changed over time, so have the architectures; this next section will look at the evolution of the cloud computing architectures.

Evolution of cloud computing architectures

Serverless comes about from another architectural shift in the compute layer and is an extension and evolution of PaaS.

When you use PaaS resources to host a website or application or execute code, you are still using servers; you specify a set of underlying compute resources and pay for those. This would be the server farm in traditional hosting.

Whereas in serverless, it's exactly as it says in the name, you are not responsible for creating any compute resources; there are servers involved, but this compute layer is provided by the platform provider – it's abstracted from your control or responsibility. In essence, you provide your business logic layer, and they run it for you on their compute layer.

The term cloud-native also gets introduced here; this means moving from the monolith stacks of virtual machines to microservices such as containers or serverless architecture solutions as functions (Azure Functions) or workflows (Azure Logic Apps). This is a fundamental shift from compute stack-centric to business logic-centric, where we are only focusing on the outcomes and not the inputs; that is, we no longer care or have to concern ourselves with the lower layers such as the languages, runtimes, compute, and so on, as these are now provided as a service for us to consume by the provider. You give the code, and the provider will decide how they will handle the execution of it.

As I mentioned earlier, serverless is about abstracting the language runtime, PaaS is about abstracting the compute, and IaaS is about abstracting the hardware. When we say abstract, what we mean is to remove, that is, remove the requirement to provide that layer; we make that layer the cloud provider's responsibility to provide, scale, keep available, maintain, and so on. It is a layer that we no longer need to know or care about:

Figure 1.2 – Cloud computing architectures

This section looked at the evolution of both the computing platform environments and the cloud computing architectures. The illustration outlines where the architectures differ in their characteristics and outlines decision criteria to consider so that each architecture can be positioned to make the most appropriate choice for any given scenario.

In the next section, we look at the Shared Responsibility Model, one of the most misunderstood cloud computing concepts but one of the most critical to understand. It underpins many decisions and their consequences of security and degrees of control measures.

In the Comparing the cloud computing service models section, we continue to look at the degrees of control offered by each model.

The Shared Responsibility model is a security model and is critically important to understand when operating resources within a public or hybrid cloud environment.

You should understand when it is your responsibility to provide the appropriate level of security and where it's not your responsibility but that of the cloud services provider.

This responsibility level may dictate what cloud computing services models you decide to deploy, such as IaaS, PaaS, or SaaS, to determine how much control and responsibility you must provide or hand off to the cloud services provider.

There are three levels of responsibility to be considered:

• Responsibilities that the consumer of the cloud services always retains
• Responsibilities that can vary by the resource type
• Responsibilities that will transfer to the cloud services provider:

Figure 1.3 – Shared Responsibility model

This security model illustration aims to visually set out the division or separation of responsibilities between the consumer of the cloud resources and the cloud services provider itself.

The most critical to be aware of is the responsibilities that the consumer of cloud services always retains and your responsibilities to secure and protect.

Cloud computing generally has three deployment models: public cloud, private cloud, and hybrid cloud:

• Public cloud, in a nutshell, is a shared entity (multi-tenant) computing model. Hardware and resources such as compute, storage, and networking are owned by the cloud provider and shared with other tenants on the platform, known as multi-tenant or multi-tenancy. Think of this as an apartment block, where you are a tenant that shares the building with other tenants; you pay rent to a landlord for your apartment. In cloud computing, this is the service provider.
• Private cloud, in a nutshell, is a dedicated entity (single-tenant) computing model. Hardware and resources such as compute, storage, and networking are dedicated to your organization use only; this is single-tenant. Think of this as a house as opposed to an apartment block; you are the single tenant, and you do not share the building with any other tenants. You either own the building or you rent the property and pay a landlord; that is, a private cloud can be hardware that you own in your facility or a third-party hosting provider, colocation data center facilities provider. Alternatively, this could be their hardware that they dedicate to you, which is traditional dedicated server hosting.
• Hybrid cloud, in a nutshell, is a combination of a shared entity (multi-tenant) computing model and a dedicated entity (single-tenant) computing model. Some computing resources you choose to have running in your private cloud environment and some resources you choose to have running in a public cloud environment based on your needs. This model offers the most agility and flexibility to changes in demand and business requirements:

Figure 1.4 – Cloud computing delivery models

This illustration aims to outline some key aspects of the three delivery models of public, private, and hybrid cloud.

In the following section, we will compare each of these delivery models and look at the characteristics of each model in more detail.

Comparing the cloud computing delivery models

From the last section, we can now define what the delivery models are. This section looks at the characteristics of each model in more detail to help you understand when you may choose one over the other.

Each delivery model has several characteristics. The most appropriate model is defined by how much you want (or need/have mandated) to control, secure, and manage your resources, for example, your apps, code, data, networks, security, and so on.

The deployment model defines what control you have over your cloud computing resources, for example, your apps, data, networks, security, and so on. It describes what resources you share or have dedicated for your organization's use.

We use the terms multi-tenant and single-tenant to differentiate between models that share resources or have dedicated resources.

We could analogize this to a house versus a hotel; with a house, you have your private and dedicated front door, stairs, kitchen, TV/movie subscription service, and more, whereas with a hotel, you have a private room dedicated to you for your sole use, but you share a front door, stairs, kitchen/restaurant, TV/movie subscription service, and so on:

Figure 1.5 – Comparing cloud computing delivery models

Now that we have a basic understanding of the delivery models, this next section will cover the characteristics of each delivery model in more depth.

Characteristics of public cloud computing resources

To recap, a public cloud is a shared entity (multi-tenant) computing model.

The following are the characteristics of public cloud computing resources:

• Metered pricing and consumption-based billing and pay-as-you-go monthly usage costs; you only pay for the resources you use, which can allow cost control and cost management.
• Almost unlimited resources are available.
• Performance, scalability, and elasticity. Rapid, on-demand, and automated provisioning and de-provisioning computing resources are required.
• Availability, reliability, fault tolerance, and redundancy.
• Computing resources access is available anywhere, typically via the internet and a private managed network such as Microsoft's ExpressRoute service.
• Self-service management, typically through a web browser or a command-line interface.
• Least control over security, protection, and compliance; you do not have complete control over security and compliance with the public cloud model.
• Access to computing resources can be provided by Azure Active Directory as the identity and authentication layer and traditional Windows Server Active Directory when you synchronize the directories.
• Physical hardware is not/cannot be deployed to public cloud computing platforms; virtual servers are provided. However, some cloud providers allow physical hardware to be dedicated to an organization's use.
• May allow on-premises facilities hosting computing resources to be decommissioned.
• Expenditure model; move from a CapEx model to an OpEx model. No CapEx on hardware.

The following giants are use case examples of public cloud platforms: Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).

Characteristics of private cloud computing resources

To recap, a private cloud is a dedicated entity (single-tenant) computing model.

The following are the characteristics of private cloud computing resources:

• Computing resources created on-premises at the organization's facility or could be provided at a third party's hosting facility; resources only available within the capacity provisioned.
• It requires a CapEx expenditure model for computing resources.
• Computing hardware (physical servers/virtualization platforms and so on) is implemented for the organization's sole use. The hardware/physical resources must be supported; failed hardware must be replaced.
• Required to provide systems and data availability, fault tolerance, scalability, security, protection, update management, maintenance, and support.
• May allow on-premises facilities hosting computing resources to be decommissioned.
• Computing resources access is available via a local/private network and typically will have an internet connection. The private cloud resources, however, may be disconnected from the internet or have intermittent access in scenarios such as cruise ships, construction sites, and Formula One teams on the trackside; while some other scenarios, such as regulated or high-security facilities such as medical, research, scientific, defense, and manufacturing, may not permit internet access and so are disconnected from the internet. Being connected or disconnected from the internet is not a defining characteristic of private clouds.
• The same self-service management functionality and creation of resources is provided as with the public cloud computing model, but you remain in complete control of the security and governance; and you are also entirely responsible for the purchase, implementation, maintenance, and support of the hardware and computing resources you provide from the private cloud platform.
• You do have complete control over hardware, physical resources, security, and compliance with the private cloud model.
• Traditional Windows Server Active Directory can provide access to computing resources as the primary identity and authentication layer; Azure Active Directory can also be utilized when connecting to public cloud computing resources through a hybrid model by using directory synchronization as the link between the two identity providers for a consistent, common, or same-sign-on experience.
• Physical servers can be deployed with the private cloud model.

The following are examples of private cloud platforms: Azure Stack or VMware VCloud.

Characteristics of hybrid cloud computing resources

To recap, a hybrid cloud is a combination of a shared entity (multi-tenant) computing model and a dedicated entity (single-tenant) computing model.

The following are the characteristics of hybrid cloud computing resources:

• The greatest flexibility in choosing the most appropriate location of computing resources and computing model.
• The hybrid cloud model provides a choice of creating some computing resources created in the service providers' public cloud computing platforms; some resources are created in your on-premises private cloud platform; both these resources are connected via the internet or a private managed network such as Microsoft's ExpressRoute service.
• It allows bursting or extend computing resource capacity to a public cloud.
• Computing hardware (physical servers/virtualization platforms and so on) is implemented for the organization's sole use as part of the private cloud resources. These hardware/physical resources must be supported; failed hardware must be replaced. For public cloud resources, the hardware and physical resources are provided and supported by the service provider of the public cloud resources.
• It provides the greatest flexibility of access to computing resources via the internet or private networks.
• Private clouds are not necessarily disconnected from public cloud resources; access may be provided by a private managed network such as ExpressRoute to allow a hybrid cloud approach, a computing model where an organization uses some public cloud resources connected to some private cloud resources.
• It provides the greatest flexibility of control of security, protection, and compliance.
• Traditional Windows Server Active Directory can provide access to computing resources as the primary identity and authentication layer; Azure Active Directory can also be utilized when connecting to public cloud computing resources through a hybrid model by using directory synchronization as the link between the two identity providers for a consistent, common, or single-sign-on experience.
• Physical servers can be deployed within the private cloud and public cloud, but you cannot own these servers in the public cloud; they can only be rented.
• It provides the greatest flexibility of expenditure model, that is, the ability to choose CapEx or OpEx, whichever is most appropriate for the computing resources.

The following is an example of a hybrid cloud platform: Azure Stack connected to Azure – this scenario could have on-premises virtual machines backing up to Azure or an Azure web app connecting to an on-premises SQL Server, for example.

In this section, we saw the different cloud computing delivery models, how they compare, and the characteristics of each. Now we will take the same approach to look at 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

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

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

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

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

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.

This chapter included complete coverage of the AZ-900 Azure Fundamentals exam skills area Describe Cloud Concepts.

We described what cloud computing is, where the platform environments and architectures have evolved from, and their direction of travel. We then looked at the Shared Responsibility model, which is critical to understand the security model when adopting cloud computing. We concluded by outlining the delivery and service models for cloud computing, comparing each, outlining the characteristics, and including some simple examples; this helps us to understand the use case for each model and which model may be most appropriate in any given scenario.

Further knowledge beyond the required exam content was provided to prepare for a real-world, day-to-day Azure-focused role.

In the next chapter, we will look at the benefits and value of cloud computing and its positioning as a digital transformation enabler.

This section provides links to additional exam information and study references:

• Exam AZ-900: Microsoft Azure Fundamentals: https://docs.microsoft.com/en-us/learn/certifications/exams/az-900
• Exam AZ-900: skills outline: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE3VwUY
• Describe core Azure concepts: https://docs.microsoft.com/en-us/learn/paths/az-900-describe-cloud-concepts
• Describe the different types of cloud computing: https://docs.microsoft.com/en-us/learn/modules/fundamental-azure-concepts/types-of-cloud-computing
• Describe the different categories of cloud services: https://docs.microsoft.com/en-us/learn/modules/fundamental-azure-concepts/categories-of-cloud-services
• Microsoft cloud computing definition: https://azure.microsoft.com/en-in/overview/what-is-cloud-computing
• NIST cloud computing definition: https://www.nist.gov/news-events/news/2011/10/final-version-nist-cloud-computing-definition-published

Challenge yourself with what you have learned in this chapter (Note down the answers that you believe are correct; go back and review the content of this chapter for any you are unsure of):

1. List three public cloud computing platforms and their providers.
2. List three private cloud computing platforms and their providers.
3. Explain a hybrid cloud approach.
4. Explain the definition of cloud computing and Microsoft Azure.
5. What cost expenditure model is used for public, private, and hybrid cloud models?
6. Does adopting a public cloud platform mean you no longer need an on-premises data center?
7. List these architectures in order of evolution: containers, serverless, bare metal, virtual machines.
8. Explain how containers compare to virtual machines.
9. Explain how PaaS compares to serverless (FaaS).
10. What are the three levels to be considered for the Shared Responsibility Model?
11. List three cloud computing delivery models.
12. List a minimum of three characteristics of public cloud computing resources.
13. List a minimum of three characteristics of private cloud computing resources.
14. List a minimum of three characteristics of the hybrid cloud computing approach.
15. List four cloud computing service models.
16. Explain serverless computing.
17. List a minimum of two characteristics of IaaS.
18. List a minimum of two examples of IaaS resources.
19. List a minimum of three characteristics of PaaS.
20. List a minimum of two examples of PaaS resources.
21. List a minimum of three characteristics of serverless (FaaS).
22. List two examples of serverless/FaaS resources.
23. List a minimum of three characteristics of SaaS.
24. List a minimum of two examples of SaaS resources.
25. List a minimum of two non-Microsoft SaaS solutions.