Digital transformation is disruptive, a growth catalyst, and foundational in changing how an organization will deliver “time to value.”

Figure 2.1 outlines the value that cloud computing as a digital transformation enabler can realize for an organization:

Figure 2.1 – Cloud computing as a digital transformation enabler

Cloud computing can be seen as a vital part of any digital transformation journey. However, the reality is that it is less about the “technology model” and more about the “business model,” the “people,” and the “process.”

It is a fact that people do not like change and generally only change direction when they have to. However, there must be a “trigger” to induce the action.

Next, you will look at digital transformation triggers.

Digital Transformation Triggers

The reason to adopt any disruptive technology, especially one that can have a business impact, must start with a “trigger” that’s relevant to the stakeholder’s pain points or objectives and any business operations or technical operations drivers.

This move often begins with a “business directive-led” discussion rather than a “technology-led” one. A business leader will always ask a technology leader what the benefits are, not the features.

The approach to digital transformation comprises steps to identify and resolve triggers. Once triggers have been identified, an approach can be planned. You can think of the triggers as the “why” and the approach as the “how.”

Figure 2.2 outlines some of the triggers for digital transformation initiatives:

Figure 2.2 – Digital transformation triggers

These triggers are an important aspect of defining your cloud adoption strategy and driving your priorities. Knowing the rationale and motivation for adopting cloud resources and migrating your workloads is important. The following section looks at the migration approach.

Migration Approach

The next step in the transformation journey is to grasp the processes, methods, and services that could be used to execute the transition to cloud services. This is outlined in the following list, along with the example services that can be applied:

1. Phase 1 | Assess: This phase is an exercise in learning an organization’s business operations and technical operations. It starts with discovery, which provides an inventory of people, processes, apps, data, infrastructure, and, critically, any dependencies. This will help you decide on the best strategy for each area of the captured inventory.

Here are some example services for this phase:

• Azure Migrate Assessments: https://packt.link/kco1y
• Azure TCO calculator: https://packt.link/Mvleh

2. Phase 2 | Move: This phase is the physical exercise of moving inventory items to their cloud services target, for instance, moving to Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or serverless cloud computing services.

An example service for this phase is Azure Migrate migrations: https://packt.link/Pqxsr

3. Phase 3 | Optimize: This phase occurs after a period of bedding in – typically a period of months. This may include right-sizing activities better to suit the workload for cost and performance benefits.

Here are some example services for this phase:

• Azure Advisor: https://packt.link/BMrtC
• Cost Management: https://packt.link/pWPJc

4. Phase 4 | Secure and Manage: This ongoing operations phase should include governance and control, security, and the protection of the network, app, data, and identities.

Here are some example services:

• Azure Monitor: https://packt.link/qVNZd
• Azure Policy: https://packt.link/CCvK6
• Microsoft Defender for Cloud: https://packt.link/Nk8FJ
• Microsoft Sentinel: https://packt.link/YdwLd
• Azure Backup: https://packt.link/KfDYD
• Azure Site Recovery: https://packt.link/JLP5V
• Azure Firewall: https://packt.link/oZNM9
• Azure App Gateway/Web Application Firewall: https://packt.link/sWRl1

You have explored cloud computing as a digital transformation enabler, the triggers, and the migration approach in this section. The following section will look closely at the cloud computing mindset.

The biggest challenge to cloud adoption is not technology but changing the “mindset” and “culture” within an organization.

The same thing has been happening with DevOps over the years. The realization over time has been that “DevOps” is not a technology or a job title but a “cultural shift” in a people and process model. To facilitate knowledge, this chapter will explain the terms, such as Capital Expenditure (CapEx) and Operating Expenditure (OpEx), referenced in the following section.

The next section explores different mindsets that have been helpful in the adoption of cloud computing.

What Is a Traditional Computing Model Mindset?

The following is an outline of the traditional computing model mindset:

• CapEx cost expenditure model
• Over-provision for peak demand and build in five-year growth from day one
• Fixed size and scaling approach
• Placing an order three months before you need it due to procurement lead times and project deployment times
• Monolithic, tightly coupled infrastructure stack approach
• Always-on 24/7 operation

The following section compares and contrasts the traditional computing model mindset with the cloud computing mindset.

What Is a Cloud Computing Mindset?

The following outlines a cloud computing model mindset that you can compare with a traditional computing mindset:

• OpEx cost expenditure model
• Usage versus provisioning; just-in-time, demand-driven provisioning
• Cloud computing is designed to be elastic, scale in and out, and burst to meet demand
• Consume and pay for what you use for as long as you need it when you need it; shut down or pause when you do not
• Microservices, loosely coupled, business logic-centric approach
• Cloud-agnostic thought pattern

Now that you have learned about the cloud computing mindset and how it differs from the traditional cloud computing mindset, the following section looks at the computing operating model, one of the key differentiators between traditional and cloud computing.

Cloud computing is “elastic,” “scalable,” “agile,” “fault-tolerant,” highly “available,” and helps with “disaster recovery.” These operational model characteristics in cloud computing add value and benefit an organization’s operational model.

These inherent and defining characteristics allow a workload deployed into a cloud computing environment to become highly available and scale in and out (both vertically and horizontally), which maps closely to demand. This ability to be elastic in nature allows the agility to provide a highly effective operations and economics model to flex with the changing demands of a business.

By optimizing running hours and right-sizing resources in line with demand and changing requirements, switching to a consumption-based system of paying as you use resources allows monitored spending without the over-commitment of a traditional computing cost model.

Figure 2.3 outlines the computing resources demand model and shows the implications of actual demand against implemented resources based on predicted demand:

Figure 2.3 – Cloud computing resource demand model

You can also see the traditional computing mindset from the last section in Figure 2.4. This traditional computing mindset means over-provisioning resources to meet predicted demand, leaving many resources underutilized. When actual demand exceeds the predicted demand, no resources are available as there is no burst capacity or scale to meet the demand. To compound things, this demand has dropped off by the time these extra resources have been implemented and are no longer needed.

With the cloud computing mindset, resource utilization can be tracked and right-sized to demand. So, there is never a case of over-provisioning and paying for more resources than are needed.

With this knowledge of the cloud computing operations model, you will look more closely at the characteristics of cloud computing that deliver benefits and value over the traditional computing model.

Operational Benefits of Cloud Computing

This section will look at the operational benefits cloud computing can add to an organization compared to those provided in a traditional computing model. Cloud computing platforms primarily provide the following operational benefits over traditional computing models:

• Scalability
• Elasticity
• Agility
• High availability (and geo-distribution)
• Disaster recovery
• Cost model

These operational benefits may be an inherent built-in platform function that provides features as part of the service, as is typically the case with PaaS or Function as a Service (FaaS) and SaaS. These operational benefits just need to be enabled in some cases, if not automatically included as part of the services.

These operational benefits could also be something that needs to be designed into part of the solution as an individual set of resources that need to be implemented to enable these characteristics.

For example, IaaS virtual machines will not provide scale, elasticity, high availability, and disaster recovery without these being designed into the solution and then implementing resources to provide the functionality to provide each of these characteristics.

The key takeaway is that cloud platform providers will generally provide these functions and characteristics. You may layer on additional functionality as your needs dictate.

Of course, not everything is perfect with the cloud computing model. Here are some challenges that can be overcome but must be considered and provided for:

• Network dependency—that is, reliability, stability, quality, and performance
• Confidentiality, Integrity, Availability (CIA) of users, apps, and data
• Access control and operational governance
• Cost control

With the operational benefits and challenges considered in this section, it is time to look at the benefits of cloud computing in more detail.

What Is Scalability?

Scalability refers to how to react to and increase resources based on demand, usually in an automated way triggered upon a metric such as a time or resource threshold being reached. The following two concepts are related to the scalability of computing resources:

• Scaling up (vertical scaling): This means capacity is increased within the resource, such as increasing the processor or memory by resizing a virtual machine; the opposite is “scaling down,” where resource capacity is decreased.
• Scaling out (horizontal scaling): This means additional resource instances, such as adding other virtual machines or compute node/scale units; the opposite is “scaling in,” where resource instances are de-allocated.

Scalability should not be confused with fault tolerance, which moves a workload automatically to another resource or system when it detects a failure or unhealthy state.

What Is Elasticity?

Elasticity refers to the ability to shape the resources needed automatically, to burst and scale to meet any peak in demand, and to return to a normal operating baseline.

What Is Agility?

Agility means deploying and configuring resources effectively and efficiently in a short space of time to meet any change in requirements or operational needs.

What Is High Availability?

High availability and geo-distribution mean deploying resources to operate within the required or mandated Service-Level Agreement (SLA) for those resources. An SLA sets out an expected level of service that a customer can expect from their service provider. This agreement will set out terms such as availability metrics, service availability, responsibilities, claims, and credit processes, as well as the vocabulary and terminology that will be used to express these aspects of the agreement.

The SLA is a guaranteed measure of uptime, which is the amount of time services are online, available, and operational. The following are the concept of availability in the context of computing and systems:

• Availability is the percentage of time a resource is available to service requests.
• Service availability is expressed as the uptime percentage over time, for example, 99.9%.
• Availability depends on resilient systems, meaning that a system can continue to function after recovering from failures.
• Increasing availability often results in an increase in costs due to the complexity of the solutions required to deliver the level of availability.
• Failover is another critical factor in availability. This means one system takes over from another when a resource fails and becomes unavailable and is part of an availability and disaster recovery strategy.

Microsoft defines an SLA as follows:

Microsoft’s commitments to uptime and connectivity, meaning the amount of time the services are online, available, and operational.

Microsoft provides each service with an individual SLA that will detail what is covered by the agreement and any exceptions. For any service that does not meet the guarantees, a percentage of the monthly fees are eligible to be credited; each service has its own defined SLA.

While you see lots of references to availability and uptime when looking at an SLA that will be provided for a service, the customer and consumer of the services will want to know what that means in the real world and what impact any breach may have on them. Therefore, it is often the case that the real metric that matters is downtime, which means for a given SLA, how long is that service permitted to be down (that is, the service is not available from the service provider)? You should scrutinize any SLA to determine whether that level of downtime is acceptable.

The service availability depends on the number of nines (as in the three nines is 99.9% and five nines is 99.999%) of the SLA. Microsoft SLAs are expressed on a monthly basis, so 99.9% would have an allowed service downtime of 43.2 minutes per month.

Table 2.1 illustrates examples of SLA commitments and downtime permitted per month as part of an SLA:

Table 2.1 – The SLA for a service indicating the acceptable level of downtime per month

Observe that 99.9% is the minimum SLA that Microsoft provides; 99.999 % is the maximum. It should be noted that 100% cannot be provided by Microsoft.

You should also be aware of the concept of a composite SLA; this means that when you combine services (such as virtual machines and the underlying services such as storage, networking components, and so on), the overall SLA is lower than the individual highest SLA on one of the services. This is because each service that you add increases the probability of failure and increases complexity.

The following actions will “positively” impact and “increase” your SLA:

• Using services that provide an SLA (or improve the service SLA), such as Entra ID Premium editions and Premium SSD managed disks
• Adding redundant resources, such as resources to additional/multiple regions
• Adding availability solutions, such as using availability sets and availability zones

The following actions will “negatively” impact and “decrease” your SLA:

• Adding multiple services due to the nature of composite SLAs
• Choosing non-SLA-backed services or free services

The following actions will have no impact on your SLA:

• Adding multiple tenancies
• Adding multiple subscriptions
• Adding multiple admin accounts

The Azure status page (https://packt.link/DdVgV) provides a global overview of the service health across all regions; this should be the first place you visit, should you suspect there is a wider issue affecting the availability of services globally. From the status page, you can click through to Azure Service Health in the Azure portal, which provides a personalized view of the availability of the services that are being used within your Azure subscriptions.

Service credits are paid through a claims process by a service provider when they do meet the guarantees of the agreed service level; each service has its own defined SLA. You should evaluate all your services to ensure that, where required, you always have an SLA-backed service; as they say, there is often an operational impact that’s felt from “free services”.

If you suspect that your services have been affected and that Microsoft has not been able to meet its SLA, then it is your responsibility to take action and pursue credit; you must submit a claim to receive service credit. For most services, you must submit the claim the month after the month the service was impacted. If your services are provided through the Microsoft Cloud Solution Provider (CSP) channel, they will pursue this claim on your behalf and provide the service refunds accordingly.

Note

You can find more details about Microsoft SLAs for Azure services and the composite SLA at https://packt.link/X5G0B and https://packt.link/qzOnf.

What Is Disaster Recovery?

Disaster recovery is based upon a set of practices or measures to ensure that, when a system fails, it can be restored to operation by failing over to a replicated instance in another region.

A “disaster recovery strategy” will be determined by the required Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Replication technologies allow for much shorter RTOs and RPOs that can be achieved with backups. The following are the crucial elements in creating comprehensive disaster recovery plans:

• RTO: This refers to the maximum duration of acceptable downtime for the system.
• RPO: This refers to how much data loss is acceptable to a system.

This is represented in Figure 2.4:

Figure 2.4 – RTO and RPO

Having grasped the operational benefits, read on to compare disaster recovery to high availability and backup concepts.

Comparing Disaster Recovery, High Availability, and Backup

High availability and disaster recovery can be classified as system protection, whereas backup can be classified as data protection. The following concepts help in building robust and resilient systems in cloud computing environments like Microsoft Azure:

• High availability: When systems fail and are not available, you can run a second instance in the same Azure region.
• Disaster recovery: When systems fail and are not available, you can run a second instance in another Azure region.
• Backup: When data is corrupted, deleted, lost, or irretrievable (perhaps due to ransomware), you can restore the instance from another copy of the system.

Figure 2.5 outlines the three preceding points of high availability, disaster recovery, and backup:

Figure 2.5 – Comparing backup, high availability, and disaster recovery

High availability, disaster recovery, and backup should not be an “either-or” decision in a strategy for business continuity; any strategy should include “all three” as they serve different purposes.

Fault tolerance is a means of providing high availability in systems. It is similar to Auto Scale, in which workloads can be moved from one system to another. The trigger for fault tolerance is a health check on a failed system, as opposed to a system under load from demand.

Challenges of Implementing Business Continuity

Cost, complexity, and compliance are the biggest challenges for business continuity. These challenges result in systems that are often not covered by disaster recovery or protected by backups, which challenges your ability to comply with any regulatory or internal mandatory policy.

While you may be familiar with the traditional causes of a disaster or business disruption, a threat to business operations can also come from a “global pandemic.” Mitigation and planning for a pandemic have not often been included in a disaster recovery or business continuity strategy.

While not a disaster or outage, a “pandemic” certainly causes a significant business disruption that almost nobody can foresee. It is reasonable to say that those who had already adopted some form of cloud services and a remote working strategy before the COVID-19 pandemic were probably better prepared than others.

Figure 2.6 shows that when you adopt a cloud computing model, your cost model changes; you may have reduced complexity, and your compliance levels may increase:

Figure 2.6 – Challenges to implementing business continuity

Adopting a cloud strategy utilizing Microsoft Azure can address many of these challenges. The challenges are often centered around costs, and the benefit and driver can be the changing cost model that can be provided by the cloud.

An additional benefit is that there is no need to maintain and purchase the resources required for a secondary site. With Microsoft Azure as the secondary site, only what is used is paid for in a consumption-based model.

From the content in this section, you have now learned about the cloud computing operations model, including aspects of the demand model, and operational benefits, as well as comparing disaster recovery, high availability, and backup. The following section will cover the economics of cloud computing, the consumption model, and the cost-expenditure model.

This section will look at the consumption-based model, one of the two economic characteristics of cloud computing. The second economic characteristic that cloud computing is based on is the cost-expenditure model of operational expenditure.

Consumption Model

In a nutshell, a consumption model means paying only for the time you use the resource. This can be likened to leasing/renting something instead of purchasing and owning the asset outright.

Some resources, such as virtual machines, can be stopped and started to reduce costs, so you only pay while running them. This is one of the key business benefits of the cloud computing cost model over a traditional computing cost model.

Now take a closer look at the cost-expenditure models.

Defining the Expenditure Models

It is essential to know the finance terms CapEx and OpEx. The details are as follows:

• CapEx: This is the “upfront commitment” of a large amount of money to purchase assets, such as investment in data center facilities, network circuit implementation, physical hardware, or software, as a “one-off payment” that you then own for the lifespan of those assets. You can liken this to the model of purchasing a vehicle or a mobile phone handset outright with a sum of money. You own it until it needs replacing, so you have to find another lump sum of money to reinvest to purchase another one in a few years.
• OpEx: Essentially, a pay-as-you-go model for consuming assets and resources is the ongoing running costs, which require a recurring payment when the asset or resource is required and in use to deliver services or functionality to a business. This could include staffing costs, data center facility management costs, power, and software that is not purchased outright but leased on a subscription basis.

There is no upfront commitment of money to buy assets. Every month, you pay only for the amount you use during a certain period. You can liken this to the model of renting a vehicle or mobile phone handset and paying every month. You never own the asset but use it for as long as you need. You may swap it, upgrade it, and downgrade it as you wish within the terms.

Figure 2.7 aims to represent this:

Figure 2.7 – Cost expenditure models

The value of cloud computing to a business is not so much the technology but the economic model it provides. The utilization of the cost model is often the value driver, with the technology being secondary.

You have learned about the cost expenditure models for a business that apply to cloud computing and traditional computing models. It is time to look at how those expenditure models are used and the benefits and value of cloud computing’s cost model.

Applying Cost Expenditure Models to Cloud Computing

In the traditional computing model (pre-cloud platforms), hardware resources and software were purchased upfront with a one-off lump sum. These business assets would be seen as depreciating assets; this is the CapEx model.

In contrast to the public cloud computing model, resources provided by the cloud platform are shared with others. This means there has been “no CapEx” to provision hardware, so you can start using these resources on demand. These resources are treated as day-to-day “OpEx.”

The exception is reserved instance resources, where you can commit to a usage term of one to three years, paying upfront (or monthly) on a CapEx basis to reserve predicted resource usage. This is more cost-effective over a one- to three-year period than paying on the pay-as-you-go consumption model.

In the case of the private cloud computing model, cloud computing technologies are hosted on dedicated, single-tenant hardware resources. Typically, these technologies are self-hosted on hardware in a facility (colocation) but may also be hosted with a third-party hosting provider. In this model, there is an element of CapEx and OpEx. The most significant portion is CapEx for purchasing hardware and assets, with usage (and often licensing and software) as OpEx.

The hybrid cloud approach will give the greatest flexibility in the expenditure model. This approach will allow you to decide the resources and respective expenditure models that they utilize to fit the business’s needs best (Figure 2.8):

Figure 2.8 – Application of cost expenditure models

The consumption cost model of cloud computing ensures not committing large amounts of capital expenditure on depreciating assets. Instead, by keeping that money within the business to use for day-to-day expenses, paying for what you need when you need it, and only for as long as you need it, you can keep your costs much closer to actual demand rather than over-committing to costs for a predicted demand. When resource demand exceeds predicted demand, the nature of the cloud computing model will ensure you have resources that can be scaled in and out to meet that demand.

The economics of cloud computing were covered in this section. You looked at the consumption model and how the cost expenditure models are applied, in addition to the benefits and value of the OpEx model of cloud computing. This concludes this chapter.

This chapter included complete coverage of the Describe the benefits of using cloud services skills area of the AZ-900 Azure Fundamentals exam.

In this chapter, you learned about the benefits of using cloud services. You looked at cloud computing as a digital transformation enabler, the triggers, the cloud migration approach, and adopting a cloud mindset. In addition, you learned about various aspects of a cloud operations model and the economics of cloud computing.

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

The next chapter will look at Azure’s Core Architectural Components.

Apart from a solid understanding of key concepts, being able to think quickly under time pressure is a skill that will help you ace your certification exam. That is why working on these skills early on in your learning journey is key.

Chapter review questions are designed to improve your test-taking skills progressively with each chapter you learn and review your understanding of key concepts in the chapter at the same time. You’ll find these at the end of each chapter.

How To Access These Resources

To learn how to access these resources, head over to the chapter titled Chapter 11, Accessing the Online Practice Resources.

To open the Chapter Review Questions for this chapter, perform the following steps:

1. Click the link – https://packt.link/AZ900E2_CH02.

Alternatively, you can scan the following QR code (Figure 2.9):

Figure 2.9 – QR code that opens Chapter Review Questions for logged-in users

2. Once you log in, you’ll see a page similar to the one shown in Figure 2.10:

Figure 2.10 – Chapter Review Questions for Chapter 2

3. Once ready, start the following practice drills, re-attempting the quiz multiple times.

Exam Readiness Drill

For the first three attempts, don’t worry about the time limit.

ATTEMPT 1

The first time, aim for at least 40%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix your learning gaps.

ATTEMPT 2

The second time, aim for at least 60%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix any remaining learning gaps.

ATTEMPT 3

The third time, aim for at least 75%. Once you score 75% or more, you start working on your timing.

Tip

You may take more than three attempts to reach 75%. That’s okay. Just review the relevant sections in the chapter till you get there.

Target: Your aim is to keep the score the same while trying to answer these questions as quickly as possible. Here’s an example of how your next attempts should look like:

Table 2.2 – Sample timing practice drills on the online platform

Note

The time limits shown in the above table are just examples. Set your own time limits with each attempt based on the time limit of the quiz on the website.

With each new attempt, your score should stay above 75% while your “time taken” to complete should “decrease”. Repeat as many attempts as you want till you feel confident dealing with the time pressure.

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

• Microsoft Learn certification further information:
  • AZ-900 - Microsoft Azure Fundamentals exam guide: https://packt.link/dfOv9
  • AZ-900 - Microsoft Azure Fundamentals study guide: https://packt.link/musyY
• Microsoft Learn training further information:
  • AZ-900 - Microsoft Azure Fundamentals course: https://packt.link/YNKhL