Getting started with the essential cloud vocabulary

In this section, we will cover the essential basic skills every Azure architect should have. The cloud has different service models, which all serve different purposes. It is very important to understand the advantages and inconveniences of each model, and to get acquainted with the jargon relating to the cloud.

Cloud service models map

Figure 1.9 demonstrates our first map (not counting our sample map), which depicts the different cloud service models and introduces some vocabulary. This map features two additional dimensions (costs and ops) to each service model, as well as some typical use cases:

Figure 1.9 – Cloud service models

In terms of cost models, we see two big trends: consumption and pre-paid compute/plans. The consumption billing model is based on the actual consumption of dynamically allocated resources. Pre-paid plans guarantee a certain compute capacity that is immediately made available to the cloud consumer. In terms of operations, the map highlights what is done by the cloud provider, and what you still have to do yourself. For instance, very low means that you have almost nothing to do yourself. We will now walk through each service model.

IaaS (Infrastructure as a Service)

IaaS is probably the least disruptive model. It is basically the process of renting a data center from a cloud provider. It is business as usual (the most common scenario) in the cloud. IaaS is not the service model of choice to accomplish a digital transformation, but there are a number of scenarios that we can tackle with IaaS:

• The lift-and-shift of existing workloads to the cloud.
• IaaS is a good alternative for smaller companies that do not want to invest in their own data center.
• In the context of a disaster recovery strategy, when adding a cloud-based data center to your existing on-premises servers.
• When you are short on compute in your own data center(s).
• When launching a new geography (for which you do not already have a data center), and to inherit the cloud provider's compatibility with local regulations.
• To speed up the time to market, providing some legacy practices and processes were adjusted upfront to align with the cloud delivery model.

With regard to costs and operations, they are almost equivalent to on-premises, although it is very hard to compare the total cost of ownership (TCO) of IaaS versus on-premises.

Of course, facilities, physical access to the data center, and more are all managed by the cloud provider. It is no longer necessary to buy and manage the hardware and infrastructure software by yourself. However, you should be aware that most companies today have a hybrid strategy, which consists of keeping a certain number of assets on-premises, while gradually expanding their cloud footprint. In this context, IaaS is a required model to some extent, in order to bridge the on-premises and cloud worlds.

PaaS (Platform as a Service)

PaaS is a fully managed service model that helps you build new solutions (or refactor existing ones) much faster. PaaS reuses off-the-shelves services that already come with built-in functionalities and whose underlying infrastructure is fully outsourced to the cloud provider. PaaS is quite disruptive with regard to legacy systems and practices.

Unlike IaaS, in order to make a successful cloud journey, PaaS requires a heavy involvement from all the layers of the company and a top sponsor from the company's leadership. Make no mistake: this is a journey. With PaaS, much of the infrastructure and most operations are delegated to the cloud provider. The multi-tenant offerings are cost-friendly, and you can easily leverage the economies of scale, providing you adopt the PaaS model. PaaS is suitable for many scenarios:

• Green-field projects
• Internet-facing workloads
• The modernization of existing workloads
• API-driven architectures
• A mobile-first user experience
• An anytime-anywhere scenario, and on any device

The preceding list of use cases is not exhaustive, but it should give you an idea of what this service model's value proposition is.

FaaS (Function as a Service)

FaaS is also known as serverless. It emerged rather recently; it started with stateless functions that were executed on shared multi-tenant infrastructures. Nowadays, FaaS expanded to much more than just functions, and it is the most elastic flavor of cloud computing. While the infrastructure is also completely outsourced to the cloud provider, the associated costs are calculated based on the actual resource consumption (unlike PaaS, where the cloud consumer pre-pays a monthly fee based on a pricing tier). FaaS is ideal in numerous scenarios:

• Event-driven architectures: Receive event notifications and trigger activities accordingly. For example, having an Azure function being triggered by the arrival of a blob on Azure Blob Storage, parsing it, and notifying other processes about the current status of activities.
• Messaging: Azure Functions, Logic Apps, and even Event Grid can all be hooked to Azure Service Bus, handle upcoming messages, and, in turn, push their outcomes back to the bus.
• Batch jobs: You might trigger Azure Logic Apps or schedule Azure Functions to perform some jobs.
• Asynchronous scenarios of all kinds
• Unpredictable system resource growth: When you do not know in advance what the usage of your application is, but you do not want to invest too much in the underlying infrastructure, FaaS may help to absorb this sudden resource growth in a costly fashion.

FaaS allows cloud consumers to focus on building their applications without having to worry about system capacity, while still keeping an eye on costs. The price to pay for the flexibility and elasticity of FaaS is usually a little performance overhead that is caused by the dynamic allocation of system resources when needed, as well as less control over the network perimeter. This leads to some headaches for an internal Security Operations Center (SOC), which is the reason why FaaS cannot be used for everything.

CaaS (Containers as a Service)

CaaS is between PaaS and IaaS. Containerization has become mainstream, and cloud providers could not miss that train. CaaS often involves more operations than PaaS. For example, Azure Kubernetes Service (AKS) involves frequent upgrades of the Kubernetes version on both the control plane and the worker nodes. Rebooting OS-patched worker nodes remains the duty of the cloud consumer. We could say that AKS is a semi-managed service as it is less managed than a PaaS or FaaS one, but it is much more managed than a regular IaaS virtual machine.

On the other hand, Web App for Containers is a fully managed service that sits between PaaS and CaaS, from a feature standpoint. Azure Container Instances (ACI) is also fully managed and sits between serverless (the consumption-pricing model) and CaaS. Admittedly, CaaS is probably the hardest model when it comes to evaluating both costs and the level of operations. It is, nevertheless, suitable for the following scenarios:

• Lift-and-shift: During a transition to the cloud, a company might want to simply lift and shift its assets, which means migrating them as containers. Most assets can be packaged as containers without the need to refactor them entirely.
• Cloud-native workloads: By leveraging the latest cutting-edge and top-notch Kubernetes features and add-ons.
• Batch, asynchronous, or compute-intensive tasks through ACIs.
• Portability: CaaS offers a greater portability, and helps to reduce the vendor lock-in risk to some extent.
• Service meshes: Most microservice architectures rely on service meshes. We will cover them in Chapter 3, Infrastructure Design.
• Modern deployment: CaaS uses modern deployment techniques, such as A/B testing, canary releases, and blue-green deployment. These techniques prevent and reduce downtime in general, through self-healing orchestrated containers.

We will explore the CaaS world in Chapter 2, Solution Architecture, and AKS in Chapter 3, Infrastructure Design.

DBaaS (Database as a Service)

DBaaS is a fully managed service model that exposes storage capabilities. Data stores, such as Azure SQL, Cosmos DB, and Storage Accounts, significantly reduce operations, while offering strong high availability and disaster recovery options. Other services, such as Databricks and Data Factory, do not strictly belong to the DBaaS category, but we will combine them for the sake of simplicity. Until very recently, Azure DBaaS was mostly based on pre-paid resource allocation, but Microsoft introduced the serverless model in order to have more elastic databases. DBaaS brings the following benefits:

• A reduced number of operations, since backups are automatically taken by the cloud provider
• Fast processing with Table Storage
• Potentially infinite scalability with Cosmos DB, providing that the proper engineering practices were taken up front
• Cost optimization, when the pricing model is well chosen and fits the scenario

We will explore DBaaS in Chapter 6, Data Architecture.

XaaS or *aaS (Anything as a Service)

Other service models exist, such as IDaaS (Identity as a Service), to such an extent that the acronym XaaS, or *aaS, was born around 2016, to designate all the possible service models. It is important for an Azure architect to grasp these different models, as they serve different purposes, require different skills, and directly impact the cloud journey of a company.

Important note

We do not cover Software as a Service (SaaS) in this book. SaaS is a fully managed business suite of software that often relies on a cloud platform for its underlying infrastructure. SaaS examples include Salesforce and Adobe Creative Cloud, as well as Microsoft's own Office 365, Power BI, and Dynamics 365 (among others).

Now that we reviewed the most important service models, let's dive a little more into the rationale behind our maps.