Cloud computing is somewhat of a misnomer; it's a marketing term for a technology model that an organization may adopt to consume computing resources. It can benefit many audiences, addressing a need to access on-demand computing resources that are self-service, automated, and elastic to cater to demand.
Its value to a business is as an enabler for digital transformation and innovation, quicker time to market and value, economies of scale, a flexible cost model, and an agile operating model; this ability gives a choice in how computing resources can be provided and consumed by a business to suit their operating model in the most appropriate way.
Microsoft, Amazon, and Google are some of the public cloud computing platform providers. These providers own hardware on their facilities, from which they create computing resources that are made available to all tenants on the platform, which use their portion of the resources and get billed only for what they use. The users of these computing resources benefit through what is described as economies of scale.
The objectives for this chapter cover the AZ-900 Azure Fundamentals exam skills area Describe Cloud Concepts.
By the end of this chapter, you will have learned the skills to be able to do the following:
In addition, this chapter's goal is also to take your knowledge beyond the exam content so you are prepared for a real-world, day-to-day Azure-focused role.
It is important to note that in November 21 some Microsoft Security Services have been renamed. These are renamed as follows:
You can learn more about the update of Microsoft security services at this url: https://docs.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction
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:
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.
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:
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:
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:
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.
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:
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.
To recap, a public cloud is a shared entity (multi-tenant) computing model.
The following are the characteristics of public cloud computing resources:
The following giants are use case examples of public cloud platforms: Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).
To recap, a private cloud is a dedicated entity (single-tenant) computing model.
The following are the characteristics of private cloud computing resources:
The following are examples of private cloud platforms: Azure Stack or VMware VCloud.
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 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:
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:
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.
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:
In the following illustration, we liken this to consuming pizza:
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.
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:
In the following illustration, we again liken this to consuming pizza:
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:
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.
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:
The following are examples of Microsoft IaaS resources:
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:
The following are examples of Microsoft PaaS services:
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:
The following are examples of Microsoft Serverless resources:
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 following are examples of Microsoft SaaS solutions:
The following are examples of other vendors' SaaS solutions:
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:
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):
Shipping Details
USA:
'Economy: Delivery to most addresses in the US within 10-15 business days
Premium: Trackable Delivery to most addresses in the US within 3-8 business days
UK:
Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable
Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands
EU:
Premium: Trackable delivery to most EU destinations within 4-9 business days.
Australia:
Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.
Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.
India:
Premium: Delivery to most Indian addresses within 5-6 business days
Rest of the World:
Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days
Asia:
Premium: Delivery to most Asian addresses within 5-9 business days
Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.
Unfortunately, due to several restrictions, we are unable to ship to the following countries:
Customs duty are charges levied on goods when they cross international borders. It is a tax that is imposed on imported goods. These duties are charged by special authorities and bodies created by local governments and are meant to protect local industries, economies, and businesses.
The orders shipped to the countries that are listed under EU27 will not bear custom charges. They are paid by Packt as part of the order.
List of EU27 countries: www.gov.uk/eu-eea:
A custom duty or localized taxes may be applicable on the shipment and would be charged by the recipient country outside of the EU27 which should be paid by the customer and these duties are not included in the shipping charges been charged on the order.
The amount of duty payable varies greatly depending on the imported goods, the country of origin and several other factors like the total invoice amount or dimensions like weight, and other such criteria applicable in your country.
For example:
Cancellation Policy for Published Printed Books:
You can cancel any order within 1 hour of placing the order. Simply contact customercare@packt.com with your order details or payment transaction id. If your order has already started the shipment process, we will do our best to stop it. However, if it is already on the way to you then when you receive it, you can contact us at customercare@packt.com using the returns and refund process.
Please understand that Packt Publishing cannot provide refunds or cancel any order except for the cases described in our Return Policy (i.e. Packt Publishing agrees to replace your printed book because it arrives damaged or material defect in book), Packt Publishing will not accept returns.
Return Policy:
We want you to be happy with your purchase from Packtpub.com. We will not hassle you with returning print books to us. If the print book you receive from us is incorrect, damaged, doesn't work or is unacceptably late, please contact Customer Relations Team on customercare@packt.com with the order number and issue details as explained below:
On the off chance your printed book arrives damaged, with book material defect, contact our Customer Relation Team on customercare@packt.com within 14 days of receipt of the book with appropriate evidence of damage and we will work with you to secure a replacement copy, if necessary. Please note that each printed book you order from us is individually made by Packt's professional book-printing partner which is on a print-on-demand basis.
Currently, no tax is charged on the purchase of any print book (subject to change based on the laws and regulations). A localized VAT fee is charged only to our European and UK customers on eBooks, Video and subscriptions that they buy. GST is charged to Indian customers for eBooks and video purchases.
You can pay with the following card types:
Shipping Details
USA:
'Economy: Delivery to most addresses in the US within 10-15 business days
Premium: Trackable Delivery to most addresses in the US within 3-8 business days
UK:
Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable
Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands
EU:
Premium: Trackable delivery to most EU destinations within 4-9 business days.
Australia:
Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.
Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.
India:
Premium: Delivery to most Indian addresses within 5-6 business days
Rest of the World:
Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days
Asia:
Premium: Delivery to most Asian addresses within 5-9 business days
Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.
Unfortunately, due to several restrictions, we are unable to ship to the following countries: