Lesson 13.6: Cloud Operating Systems

01 Introduction

Lessons 13.1 through 13.5 presented the virtualization's continuum: the virtual machines (the hypervisor's emulation of the hardware), the hypervisors (the software that runs the VMs), the containers (the kernel's mechanisms' isolation), the Docker (the containers' platform: the images, the Dockerfile, the registries), and the container orchestration (the Kubernetes's clusters' management at scale). This lesson presents the cloud operating systems: the platforms that combine those technologies into the on-demand's computing that the modern's applications run on.

The cloud computing is the delivery of the computing's resources (the compute, the storage, the networking, the databases, the analytics, the machine learning, and the many's services) as the services over the network, with the on-demand's self-service, the measured's usage, and the elastic's scaling. The cloud's design's central's observation: the cloud is the service model more than the technology. The virtualization, the containers, and the orchestration are the cloud's enablers (the technologies that make the cloud's economics and the operations possible), but the cloud's essence is the business's model: the providers' capital's investments (the data centers, the hardware, the power, the cooling, the networking) are the operating's expenses for the customers (the pay-as-you-go's pricing), and the customers' capacity's planning is replaced by the providers' elasticity.

The NIST's definition (the National Institute of Standards and Technology's, the 2011's) is the cloud's canonical's definition: the cloud computing is the model for enabling the ubiquitous, the convenient, the on-demand's network's access to the shared's pool of the configurable's computing's resources (the networks, the servers, the storage, the applications, the services) that can be the rapidly's provisioned and the released with the minimal's management's effort or the service's provider's interaction. The NIST's definition's five essential characteristics:

The on-demand's self-service. The consumers provision the computing's capabilities (the server's time, the network's storage) as the needed, automatically, without the human's interaction with the service's providers.
The broad's network's access. The capabilities are the available over the network through the standard's mechanisms (the HTTP's, the REST's, the SSH's, the APIs) that the heterogeneous's client's platforms (the laptops, the phones, the tablets, the servers) use.
The resource's pooling. The provider's computing's resources are the pooled to serve the multiple's consumers (the multi-tenancy's model), with the physical and the virtual resources dynamically assigned and reassigned according to the demand; the consumers generally have no knowledge or control over the exact location of the provided resources (the location's independence), although they may be able to specify the location at the higher level of abstraction (the country, the state, the data center).
The rapid's elasticity. The capabilities can be the elastically provisioned and the released (the scale's out and the scale's in) to the rapidly's commensurate with the demand; to the consumer, the available's capabilities often appear to be the unlimited and can be the purchased in any quantity at any time.
The measured's service. The cloud's systems automatically control and optimize the resource's use by leveraging the metering's capability at some level of abstraction appropriate to the type of service (the storage, the processing, the bandwidth, the active's user's accounts). The resource's usage can be the monitored, the controlled, and the reported, providing the transparency for both the provider and the consumer of the utilized's service.

The cloud's benefits: the cost's efficiency (the capex's to the opex's: the customers pay for the used's capacity rather than the owned's infrastructure), the elasticity (the rapid's scaling: the capacity's adjustment to the demand, the no's overprovisioning), the agility (the rapid's provisioning: the resources are the available in the minutes, not the weeks), the global's reach (the providers' regions: the world's deployment, the latency's reduction), the reliability (the providers' redundancy: the regions, the availability's zones, the managed's services' SLAs), and the innovation (the providers' services: the machine learning's, the analytics', the IoT's, the quantum's; the customers focus on the applications rather than the infrastructure). The cloud's trade-offs: the control's loss (the infrastructure's management is the provider's: the configuration's and the performance's limitations), the vendor's lock-in (the providers' services and the APIs: the migration's difficulty), the security's concerns (the data's residency, the multi-tenancy's isolation, the compliance), the cost's unpredictability (the pay-as-you-go's model: the egress's fees, the idle's resources, the reserved's commitments), and the dependence (the network's connectivity, the providers' outages).

This lesson presents the cloud operating systems. It defines the cloud computing and the NIST's five essential characteristics. It presents the service models (the IaaS's, the PaaS's, the SaaS's, the FaaS's, and the XaaS's family) and the deployment models (the public's, the private's, the hybrid's, the community's, the multi-cloud's). It presents the cloud operating systems (the OpenStack's, the Kubernetes's as the cloud OS, the cloud's providers' stacks) and the cloud's compute (the VMs, the containers, the serverless, the bare metal). It presents the cloud's storage (the object's stores, the block's stores, the file's systems), the cloud's networking (the VPCs, the security's groups, the load's balancers, the CDNs), and the cloud's identity and security (the IAM, the KMS, the shared's responsibility's model). It presents the elasticity and the economics (the capex's to the opex's, the pricing's models), the reliability (the regions, the availability's zones, the SLAs), and the serverless's computing (the FaaS's, the event's model, the cold's start). It closes with the cloud's design's trade-offs and the lesson's synthesis.

Prerequisites

This lesson builds on Lessons 13.1 through 13.5 and the earlier lessons. The virtual machines (Lesson 13.1), the hypervisors (Lesson 13.2), the containers (Lesson 13.3), the Docker (Lesson 13.4), and the container orchestration (Lesson 13.5) are assumed. The network's fundamentals (the IP's addressing, the subnets, the routing, the DNS, the firewalls, the load's balancing), the storage's concepts (the block's and the file's storage, the file systems, the object's storage's basics), the security's principles (Lesson 12.1: the authentication, the authorization, the least privilege, the defence in the depth), and the Linux's command line (Lesson 2.2) are assumed. Familiarity with the cloud's providers' CLIs (the AWS's CLI's, the Azure's CLI's, the Google's Cloud's CLI's, the OpenStack's CLI's, the kubectl's) is helpful, since the interactive activity uses them.

02 Learning objectives

By the end of this lesson you will be able to

Define the cloud computing and explain the NIST's five essential characteristics (the on-demand's self-service, the broad's network's access, the resource's pooling, the rapid's elasticity, the measured's service).
Compare the cloud's service models (the IaaS's, the PaaS's, the SaaS's, the FaaS's, and the XaaS's family) and the deployment models (the public's, the private's, the hybrid's, the community's, the multi-cloud's).
Describe the cloud operating systems (the OpenStack's, the Kubernetes's as the cloud OS, the cloud's providers' stacks) and the cloud's compute's options (the VMs, the containers, the serverless, the bare metal).
Describe the cloud's storage (the object's stores, the block's stores, the file's systems), the cloud's networking (the VPCs, the security's groups, the load's balancers, the CDNs), and the cloud's identity and security (the IAM, the KMS, the shared's responsibility's model).
Explain the cloud's elasticity, the economics (the capex's to the opex's, the pricing's models), and the reliability (the regions, the availability's zones, the SLAs).
Describe the serverless's computing (the FaaS's, the event's model, the cold's start) and evaluate a cloud's architecture against the lesson's criteria.

This lesson contributes to U13.6 and U13.7, and to course learning outcomes CLO1, CLO7, and CLO8.

03 Required reading

Operating System Concepts — Chapter 19, Cloud Computing. The standard treatment of the cloud's concepts, the service models, the deployment models, and the cloud's operating systems.
OSTEP — the Virtualization chapters and the Distributed Systems chapters. OSTEP's treatment of the virtualization's foundations and the distributed systems' concepts is the context for the cloud's discussion.
Tanenbaum & Bos — Modern Operating Systems, Chapter 7, Virtualization and the Cloud. A complementary treatment that develops the cloud's concepts from the virtualization's foundations.
Mell, P., & Grance, T. — The NIST Definition of Cloud Computing. NIST Special Publication 800-145, 2011. The authoritative's definition of the cloud computing, the five essential characteristics, the three service models, and the four deployment models.
Buyya, R., Vecchiola, C., & Selvi, S. T. — Mastering Cloud Computing. Morgan Kaufmann, 2013. The comprehensive's reference for the cloud's architectures and the cloud's operating systems.
Reese, G. — Cloud Application Architectures, 2nd ed. O'Reilly, 2021. The comprehensive's reference for the cloud's applications' architectures, the service models, and the design patterns.
Jackson, K., & Goessling, A. — Architecting Cloud Computing Solutions. Packt, 2018. The practical's reference for the cloud's architectures and the cloud's patterns.
The OpenStack project's documentation (docs.openstack.org). The authoritative reference for the OpenStack's components (the Nova's, the Neutron's, the Cinder's, the Swift's, the Glance's, the Keystone's, the Heat's, the Horizon's) and the cloud's management.
The Kubernetes's documentation (kubernetes.io/docs). The Kubernetes's role as the cloud's operating system's foundation and the cloud's native's applications' platform.
The cloud's providers' documentation: the AWS's (docs.aws.amazon.com), the Azure's (learn.microsoft.com/azure), the Google's Cloud's (cloud.google.com/docs), the Alibaba's Cloud's, the DigitalOcean's. The authoritative references for the cloud's services.
The Cloud Native Computing Foundation (CNCF)'s landscape. The map of the cloud's native's ecosystem.
NIST SP 800-145 (the cloud's definition), NIST SP 800-146 (the cloud's computing's synopsis and the recommendations), NIST SP 800-144 (the public's cloud's security and the privacy's guidelines), and NIST SP 500-292 (the cloud's computing's reference's architecture). The security's and the architecture's references.
The Linux man pages: man 1 aws (the AWS's CLI), man 1 az (the Azure's CLI), man 1 gcloud (the Google's Cloud's CLI), man 1 openstack (the OpenStack's CLI), man 1 terraform (the infrastructure's as the code), man 1 ansible (the configuration's management), man 1 pulumi (the infrastructure's as the code), man 1 kubectl (the Kubernetes's CLI), man 1 helm (the Kubernetes's package's manager), man 1 s3cmd (the S3's CLI), man 1 rclone (the object's stores' CLI), man 1 mc (the MinIO's client), man 1 docker.

Reading strategy

Read the NIST's definition (the SP 800-145) first. It is short (the few's pages), and it is the authoritative's definition of the cloud computing: the five essential characteristics, the three service models, and the four deployment models. The definition's precision matters: the cloud is not the virtualization, the containers, or the Kubernetes (the technologies), and the cloud is the service model (the on-demand's self-service, the metering, the elasticity). Then read the Silberschatz chapter for the formal's treatment of the cloud's concepts and the cloud's operating systems (the OpenStack's, the Kubernetes's, the Eucalyptus's, the OpenNebula's). The Reese's book is the comprehensive's reference for the cloud's applications' architectures, and it is worth reading for the service models' and the design patterns' treatment. The OpenStack's and the Kubernetes's documentation are the practical's references, and they are worth consulting for the specific's components' details. Finally, the cloud's providers' documentation is the authoritative reference for the specific's services (the EC2's, the S3's, the VPC's, the IAM's), and the Linux man pages are the practical's tools. Pay particular attention to the distinction between the cloud (the service model: the metered, the elastic, the self-service's resources) and the virtualization (the technology: the hypervisors, the VMs, the containers). The virtualization is the cloud's enabler (the technology that makes the cloud's pooling and the elasticity possible), and the cloud is the service model (the business's and the operations's model). The observation is the reason the lesson's focus is the cloud's characteristics, the service models, the deployment models, the cloud's operating systems, and the cloud's economics more than the virtualization's mechanisms (the earlier lessons' focus).

04 Core content

4.1 What cloud computing is

The cloud computing is the delivery of the computing's resources as the services over the network, with the on-demand's self-service, the measured's usage, and the elastic's scaling. The cloud's design's central's observation: the cloud is the service model more than the technology (the virtualization, the containers, and the orchestration are the cloud's enablers: the technologies that make the cloud's economics and the operations possible).

The NIST's five essential characteristics (the cloud's definition's core):

The NIST's five essential characteristics
The characteristic	The meaning	The enabling technology
The on-demand's self-service	The consumers provision the capabilities (the server's time, the storage, the network) as needed, automatically, without the human's interaction with the provider	The APIs, the portals, the CLIs, the IaC's tools
The broad's network's access	The capabilities are the available over the network through the standard's mechanisms and the heterogeneous's client's platforms	The internet, the REST's APIs, the SSH's, the VPNs
The resource's pooling	The provider's resources are the pooled to serve the multiple's consumers (the multi-tenancy), with the dynamic's assignment and the location's independence	The virtualization, the containers, the orchestration, the multi-tenancy's isolation
The rapid's elasticity	The capabilities are the elastically provisioned and released (the scale's out, the scale's in), appearing as the unlimited to the consumer	The autoscaling, the orchestration, the load's balancing
The measured's service	The resource's use is the automatically controlled and optimized by the metering (the storage, the processing, the bandwidth, the accounts), providing the transparency for both the provider and the consumer	The monitoring, the metering, the billing's systems

The cloud's benefits:

The cost's efficiency. The capex's to the opex's: the customers pay for the used's capacity rather than the owned's infrastructure, and the observation is the reason the cloud's economics favour the workloads with the variable's demand (the web's applications, the batch's jobs, the development's and the testing's environments).
The elasticity. The rapid's scaling: the capacity's adjustment to the demand (the scale's out during the peaks, the scale's in during the lulls), and the observation is the reason the cloud's workloads' capacity is the demand's function rather than the peak's provisioning.
The agility. The rapid's provisioning: the resources are the available in the minutes (the VMs, the containers, the databases, the queues), not the weeks (the hardware's procurement, the data center's installation), and the observation is the reason the cloud's adoption is the developers' and the startups' driver.
The global's reach. The providers' regions: the world's deployment (the customers' proximity, the data's residency, the disaster's recovery), and the observation is the reason the global's applications (the web's services, the media's streaming, the gaming) use the cloud's regions.
The reliability. The providers' redundancy: the regions, the availability's zones, the managed's services' SLAs, and the observation is the reason the cloud's workloads' reliability is the providers' infrastructure's and the architectures' (the multi-AZ's, the multi-region's) function.
The innovation. The providers' services: the machine learning's (the SageMaker's, the Vertex AI's, the Azure ML's), the analytics' (the Redshift's, the BigQuery's, the Synapse's), the IoT's, the quantum's, and the observation is the reason the cloud's customers focus on the applications rather than the infrastructure.

The cloud's trade-offs:

The control's loss. The infrastructure's management is the provider's: the configuration's and the performance's limitations (the hypervisor's versions, the instance's types, the network's topology), and the observation is the reason the cloud's workloads' design must work within the providers' abstractions.
The vendor's lock-in. The providers' services and the APIs: the migration's difficulty (the proprietary's services: the Lambda's, the DynamoDB's, the BigQuery's; the data's egress's fees; the identity's and the IAM's integrations), and the observation is the reason the multi-cloud's and the portable's designs (the Kubernetes's, the Terraform's, the open-source's services) are the modern's practices.
The security's concerns. The data's residency (the regulations: the GDPR's, the HIPAA's, the data's sovereignty), the multi-tenancy's isolation (the side channels, the hypervisor's vulnerabilities), the compliance (the certifications: the SOC 2's, the ISO 27001's, the FedRAMP's), and the observation is the reason the cloud's security is the shared's responsibility (the provider's and the customer's).
The cost's unpredictability. The pay-as-you-go's model: the egress's fees, the idle's resources, the reserved's commitments, the unexpected's bills (the misconfigured's autoscaling, the runaway's jobs), and the observation is the reason the cloud's cost's management (the FinOps's) is the modern's discipline.
The dependence. The network's connectivity (the internet's outages, the providers' outages), the providers' services' discontinuation, the APIs' changes, and the observation is the reason the cloud's architectures include the resilience's designs (the multi-region's, the multi-cloud's, the hybrid's).

4.2 The service models

The cloud's service models are the different's levels of the abstraction that the providers offer, and the different's levels of the responsibility that the customers retain:

The IaaS (the Infrastructure as a Service): The provider offers the infrastructure: the virtual machines (the compute), the block's and the file's storage, the networks (the VPCs, the subnets, the firewalls), the load's balancers, and the raw's building's blocks. The customer manages the operating systems, the middlewares, the runtimes, and the applications (the customer's responsibility's scope is the largest). The IaaS's examples: the AWS's EC2 (the instances, the EBS's volumes, the VPC's), the Azure's Virtual Machines, the Google's Compute Engine, the OpenStack's Nova (the private's IaaS's). The IaaS's use's cases: the lift-and-shift's migrations (the existing's applications' migration), the custom's operating systems' requirements, the full's control's requirements (the kernel's configuration, the specialized's workloads).
The PaaS (the Platform as a Service): The provider offers the platform: the runtime (the language's runtimes, the application's servers), the databases, the message's queues, the caching, the monitoring, and the deployment's mechanisms. The customer manages the applications and the data (the customer's responsibility's scope is the smaller: the operating systems, the runtimes, and the middlewares are the provider's). The PaaS's examples: the AWS's Elastic Beanstalk, the Heroku's, the Google's App Engine, the Azure's App Service, the Red Hat's OpenShift (the Kubernetes's PaaS's). The PaaS's use's cases: the applications' rapid's development and deployment (the developers focus on the code), the standardized's platforms' requirements, the small's teams.
The SaaS (the Software as a Service): The provider offers the software: the complete's applications (the email's, the CRM's, the office's suites, the collaboration's tools), and the customer uses the applications through the interfaces (the web's browsers, the mobile's apps, the APIs). The customer manages the data and the users (the customer's responsibility's scope is the smallest: the infrastructure, the platform, and the application are the provider's). The SaaS's examples: the Microsoft's 365's, the Google's Workspace's, the Salesforce's, the Slack's, the Zoom's, the Dropbox's. The SaaS's use's cases: the standardized's business's applications (the email's, the collaboration's, the CRM's), the no's infrastructure's management's requirements.
The FaaS (the Function as a Service): The provider offers the functions: the event-driven's compute (the functions are the triggered by the events: the HTTP's requests, the messages, the files, the schedules), and the provider manages the servers, the scaling, and the availability (the serverless's computing). The customer manages the function's code and its configuration (the customer's responsibility's scope: the function's code and the data). The FaaS's examples: the AWS's Lambda, the Azure's Functions, the Google's Cloud Functions, the Cloudflare's Workers, the Knative's (the Kubernetes's serverless's), the OpenFaaS's, the Fission's. The FaaS's use's cases: the event-driven's workloads (the APIs, the data's processing, the IoT's, the automations), the sporadic's workloads (the no's idle's cost: the pay-per-invocation's model), the small's functions.
The XaaS (the Everything as a Service): The XaaS's family: the DBaaS (the Database as a Service: the RDS's, the Aurora's, the Cloud SQL's, the Cosmos DB's), the CaaS (the Container as a Service: the ECS's, the EKS's, the AKS's, the GKE's, the OpenShift's), the MLaaS (the Machine Learning as a Service: the SageMaker's, the Vertex AI's, the Azure ML's), the STaaS (the Storage as a Service: the S3's, the Blob Storage's, the GCS's), the SECaaS (the Security as a Service), the DaaS (the Desktop as a Service), and the many's others. The observation: the XaaS's family is the cloud's services' proliferation, and the observation is the reason the cloud's customers choose the level of the abstraction that matches their requirements (the control's vs. the convenience's).

The service models' comparison (the responsibility's scope):

The service models' responsibility's scope
The layer	The IaaS's	The PaaS's	The SaaS's	The FaaS's
The applications	The customer's	The customer's	The provider's	The customer's (the function's code)
The data	The customer's	The customer's	The customer's	The customer's
The runtimes	The customer's	The provider's	The provider's	The provider's
The middlewares	The customer's	The provider's	The provider's	The provider's
The operating systems	The customer's	The provider's	The provider's	The provider's
The virtualization	The provider's	The provider's	The provider's	The provider's
The servers, the storage, the network	The provider's	The provider's	The provider's	The provider's

4.3 The deployment models

The cloud's deployment models (the NIST's four, plus the multi-cloud's):

The public's cloud: The cloud's infrastructure is the provisioned for the open use by the general public (the providers' data centers: the AWS's, the Azure's, the Google's Cloud's, the Alibaba's Cloud's, the Oracle's Cloud's), and the resources are the shared among the many's tenants. The public's cloud's advantages: the elasticity (the providers' scale), the cost's efficiency (the pay-as-you-go's, the no's capital's investment), the global's reach, the providers' services (the managed's services: the databases, the machine learning's, the analytics'). The public's cloud's disadvantages: the control's loss, the security's and the compliance's concerns (the data's residency, the multi-tenancy), the vendor's lock-in, the cost's unpredictability.
The private's cloud: The cloud's infrastructure is the provisioned for the exclusive use by a single's organization (the on-premises's data center, the hosted's private's cloud), and the organization manages the infrastructure (the OpenStack's, the VMware's vSphere's, the Kubernetes's on the bare metal). The private's cloud's advantages: the control (the configuration, the security, the compliance), the data's residency (the regulated's workloads), the cost's predictability (the owned's infrastructure). The private's cloud's disadvantages: the capital's investment, the operations's burden (the hardware's maintenance, the software's upgrades), the elasticity's limits (the owned's capacity), the slower's innovation (the providers' services' absence).
The hybrid's cloud: The cloud's infrastructure is the composition of the two or more distinct's clouds (the private's and the public's), bound by the standardized or the proprietary's technology that enables the data and the applications' portability (the bursting: the private's cloud's baseline with the public's cloud's peaks; the data's placement: the sensitive's data in the private's cloud and the analytics in the public's; the disaster's recovery: the private's cloud's backups in the public's). The hybrid's cloud's advantages: the control's and the elasticity's balance, the workload's placement's flexibility, the gradual's migration's path. The hybrid's cloud's disadvantages: the complexity (the two's environments' management, the network's connectivity, the identity's integration), the cost's (the private's infrastructure plus the public's usage).
The community's cloud: The cloud's infrastructure is the provisioned for the exclusive use by a specific's community of the consumers from the organizations that have the shared's concerns (the mission, the security's requirements, the policy, the compliance). The community's cloud's examples: the government's clouds (the GovCloud's, the government's community's clouds), the research's clouds (the academic's, the scientific's), the industry's clouds (the healthcare's, the finance's). The community's cloud's advantages: the shared's cost's and the operations's among the members, the compliance's and the security's requirements' alignment. The community's cloud's disadvantages: the governance's complexity, the members' coordination.
The multi-cloud's: The multi-cloud's is the use of the two or more's public's clouds (the AWS's and the Azure's, the GCP's and the Alibaba's), often with the different's services and the different's providers. The multi-cloud's purposes: the vendor's lock-in's avoidance (the negotiating's leverage, the portability), the best-of-breed's services (the each's provider's strengths), the resilience (the providers' outages' tolerance), the compliance (the data's residency in the different's jurisdictions). The multi-cloud's disadvantages: the complexity (the the environments' management, the the networking, the the identity), the the skills' requirements, the the cost's (the the egress's fees, the the duplicated's services).

Figure 13.6 — The cloud's service models and the cloud's architecture. The top diagram shows the cloud's service models: the on-premises, the IaaS, the PaaS, the SaaS, and the FaaS, with the responsibility's boundary moving from the customer (the on-premises: the everything) to the provider (the FaaS: the servers, the runtimes, the operating systems). The bottom diagram shows the cloud's architecture: the region (the geographic's area) with the multiple's availability's zones (the isolated's failure's domains), the VPCs (the virtual's networks), the subnets (the public's and the private's), the instances (the VMs), the containers, the storage (the block's, the object's), the databases, the load's balancers, the security's groups, and the global's services (the IAM, the DNS, the CDN, the monitoring, the billing, the KMS).

4.4 The cloud operating systems

The cloud operating system is the software's platform that manages the data center's resources (the compute, the storage, the network) and exposes them as the cloud's services (the on-demand's, the metered's, the elastic's). The cloud operating systems' examples:

The OpenStack: The OpenStack is the open-source's cloud's operating system (the Rackspace's and the NASA's, the 2010's): the platform for the private's and the public's clouds, with the components: the Nova (the compute's service: the VMs' lifecycle, the scheduling, the placement), the Neutron (the network's service: the virtual's networks, the routers, the security's groups, the load's balancing), the Cinder (the block's storage's service: the volumes), the Swift (the object's storage's service: the containers, the objects, the eventual's consistency), the Glance (the image's service), the Keystone (the identity's service: the authentication, the authorization, the projects, the roles), the Heat (the orchestration's service: the templates' infrastructure's as the code), the Horizon (the web's dashboard), the Placement (the resources' inventory and the tracking), the Barbican (the secrets' management), and the others. The OpenStack's design: the modular's architecture (the components are the separate's services with the REST's APIs), the open-source's governance (the OpenInfra Foundation's), and the broad's ecosystem (the vendors' distributions: the Red Hat's OpenStack's Platform, the Canonical's Charmed OpenStack, the Mirantis's, the VMware's Integrated OpenStack). The observation: the OpenStack is the private's and the public's clouds' open-source's standard, and the observation is the reason the organizations with the data's residency's and the compliance's requirements (the telecommunications, the governments, the research) use the OpenStack.
The Kubernetes as the cloud OS: The Kubernetes (the Lesson 13.5's discussion) is the container's orchestration's platform, and its role as the cloud OS: the Kubernetes's clusters are the cloud's compute's platform (the nodes' pools, the pods' scheduling, the services' networking, the persistent's storage), and the Kubernetes's ecosystem (the operators: the databases', the message's queues', the monitoring's, the machine learning's; the CRDs; the controllers) extends the Kubernetes's scope from the containers' orchestration to the applications' platform (the databases, the queues, the caches, the ML's models). The observation: the Kubernetes is the modern's cloud's application's operating system (the applications' platform's abstraction), and the observation is the reason the cloud's providers' managed's services (the EKS's, the AKS's, the GKE's, the OKE's) and the on-premises's distributions (the OpenShift's, the Rancher's, the VMware's Tanzu's) are the Kubernetes's ecosystems.
The cloud's providers' stacks: The cloud's providers' stacks (the AWS's, the Azure's, the Google's Cloud's, the Alibaba's Cloud's, the Oracle's Cloud's): the providers' proprietary's platforms that combine the virtualization (the Nitro's, the Hyper-V's, the KVM's), the storage (the S3's, the EBS's, the Blob's, the GCS's), the networking (the VPC's, the load's balancers, the CDNs), the identity (the IAM's, the Active Directory's, the Cloud IAM's), the managed's services (the databases, the queues, the analytics, the ML), and the management's tools (the CLIs, the SDKs, the IaC's: the CloudFormation's, the ARM's, the Deployment Manager's). The observation: the providers' stacks are the public's clouds' platforms, and the observation is the reason the public's cloud's adoption (the AWS's, the Azure's, the Google's Cloud's market shares) is the cloud's market's central's feature.
The Kubernetes's alternatives and the hybrid's platforms: The Kubernetes's alternatives and the hybrid's platforms: the OpenShift (the Red Hat's Kubernetes's distribution: the enterprise's features: the security, the monitoring, the CI/CD), the Rancher (the multi-cluster's management), the VMware's Tanzu (the vSphere's integration), the Anthos (the Google's multi-cloud's Kubernetes's), the Azure's Arc (the Microsoft's hybrid's), the Harvester (the SUSE's hyperconverged's), and the observation: the alternatives and the hybrid's platforms are the Kubernetes's enterprise's and the multi-cloud's ecosystems, and the observation is the reason the modern's organizations use the platforms that bridge the clouds.

4.5 The cloud's compute

The cloud's compute options:

The virtual machines (the IaaS's compute). The instances (the EC2's, the Azure's VMs, the GCE's, the OpenStack's Nova's): the full's operating systems' control (the kernel's, the drivers', the packages'), the instance's types (the CPU's, the memory's, the storage's, the network's), the auto-scaling's groups (the instances' pools with the scaling's policies), and the spot's instances (the unused's capacity at the discounted's prices, with the interruption's risk). The VMs' use's cases: the lift-and-shift's migrations, the custom's operating systems, the full's control's requirements, the legacy's applications.
The containers (the CaaS's compute). The containers (the ECS's, the EKS's, the GKE's, the AKS's, the OKE's, the OpenShift's, the self-managed's Kubernetes's): the images' packages (the applications and their dependencies), the pods' scheduling, the services' networking, the autoscaling's, and the orchestration's (the Lesson 13.5's discussion). The containers' use's cases: the microservices, the cloud's native's applications, the CI/CD's, the portable's workloads.
The serverless (the FaaS's compute). The functions (the Lambda's, the Azure's Functions, the Google's Cloud Functions, the Cloudflare's Workers, the Knative's): the event-driven's model (the functions are the triggered by the events), the provider's scaling (the functions scale automatically, including the zero), the pay-per-invocation's pricing, the cold's start (the first's invocation's latency), the execution's limits (the timeout's, the memory's, the package's size), and the stateless's design (the state is the external's: the databases, the object's stores, the queues). The serverless's use's cases: the event-driven's workloads (the APIs, the data's processing, the IoT's, the automations), the sporadic's workloads (the no's idle's cost), the glue's code (the integrations).
The bare metal (the dedicated's compute). The bare-metal's servers (the AWS's EC2's Bare Metal's, the Azure's BareMetal's, the OVHcloud's, the Equinix's Metal's, the Packet's): the physical's servers without the hypervisor (the dedicated's hardware), with the high's performance (the no's virtualization's overhead), the specific's hardware's requirements (the GPUs, the FPGAs, the custom's hardware), the licensing's requirements (the licensing is the per-socket's, not the per-core's: the bare metal avoids the virtualization's licensing's complexities), and the compliance's requirements (the some's workloads require the dedicated's hardware). The bare metal's use's cases: the high-performance's computing (the HPC's), the GPU's workloads (the ML's training's), the databases (the no's noisy's neighbors), the regulated's workloads.
The GPU's and the accelerator's compute. The GPU's instances (the EC2's P's and G's families, the Azure's NC's and ND's, the GCE's A's and the others), the TPUs (the Google's tensor's processing's units), the FPGAs, the inference's accelerators (the AWS's Inferentia's, the Trainium's), and the observation: the accelerators are the cloud's machine learning's and the high-performance's compute's central's offerings, and the observation is the reason the cloud's providers offer the specialized's instances.

4.6 The cloud's storage

The cloud's storage services:

The object's storage: The object's stores (the AWS's S3, the Azure's Blob Storage, the Google's Cloud Storage, the OpenStack's Swift, the MinIO's): the data is the stored as the objects (the unstructured's data: the files, the media, the backups, the logs) in the buckets (the containers) with the keys (the names), and the access is the HTTP's API (the REST's: the GET's, the PUT's, the DELETE's, the LIST's). The object's storage's characteristics: the massive's scale (the unlimited's capacity), the durability (the the providers' replication: the 11 nines's: the 99.999999999%'s durability), the availability (the 99.99%'s), the eventual's consistency (the some's providers: the S3's the strong's read-after-write's consistency for the new objects; the historical's eventual's consistency for the overwrites and the deletes), the metadata (the custom's metadata), the versioning (the objects' versions), the lifecycle's policies (the transitions to the colder's tiers: the infrequent's access, the archive's: the Glacier's), the encryption (the at-rest's and the in-transit's), and the access's control (the bucket's policies, the ACLs, the IAM's). The object's storage's use's cases: the static's content, the media, the backups, the data's lakes, the logs, the artifacts.
The block's storage: The block's stores (the AWS's EBS's, the Azure's Managed Disks, the Google's Persistent Disks, the OpenStack's Cinder's): the virtual's disks (the volumes) that the instances attach, with the types (the general's purpose: the SSD's and the HDD's; the provisioned's IOPS's; the throughput's optimized), the snapshots (the point-in-time's copies), the encryption, and the performance's characteristics (the IOPS's, the throughput's, the latency). The block's storage's characteristics: the low's latency (the microseconds to the milliseconds), the random's access (the unlike the object's storage), the the single's attach (the the some's multi-attach's: the the clustered's file systems'), and the the durability (the the replicated within the AZ). The block's storage's use's cases: the databases, the file systems, the boot's volumes, the applications with the random's I/O's.
The file's storage: The file's systems (the AWS's EFS's and the FSx's, the Azure's Files, the Google's Filestore, the OpenStack's Manila's): the shared's file's systems (the NFS's, the SMB's) that the multiple's instances mount, with the access's modes (the shared's), the performance's tiers (the general's purpose, the max's I/O), and the the use's cases (the the shared's content's, the the home's directories, the the lift's and the shift's applications that need the the shared's file's system).
The storage's tiers and the lifecycle: The storage's tiers: the hot's (the frequent's access: the the standard's object's storage, the the SSD's block's storage), the the warm's (the the infrequent's access: the the S3's Standard-IA's, the the Azure's Cool's, the the GCS's Nearline's), the the cold's (the the rare's access: the the S3's Glacier's, the the Azure's Archive's, the the GCS's Coldline's and the Archive's), and the the the lifecycle's policies (the the automatic's transitions between the tiers, the the expiration's, the the the cost's optimization). The observation: the storage's tiers are the cloud's cost's management's central's mechanism, and the observation is the reason the data's lifecycle's policies (the the retention's, the the transitions', the the deletions') are the cloud's architectures' concerns.

4.7 The cloud's networking

The cloud's networking services:

The VPC (the Virtual Private Cloud). The virtual's network (the AWS's VPC's, the Azure's VNet's, the Google's VPC's, the OpenStack's Neutron's): the isolated's network within the cloud (the customer's private's network), with the subnets (the public's: the internet's gateway's; the private's: the no's direct's internet's access), the route tables (the routing's rules), the internet's gateways (the public's subnets' internet's access), the NAT's gateways (the private's subnets' outbound's internet's access), the security's groups (the stateful's firewall's rules: the instance's level), the network's ACLs (the stateless's firewall's rules: the subnet's level), and the peering (the VPCs' interconnection) and the VPNs (the on-premises's networks' connection).
The load's balancers. The load's balancers (the AWS's ELB's: the ALB's (the application's: the HTTP and the HTTPS's), the NLB's (the network's: the TCP and the UDP's), the CLB's (the classic's); the Azure's Load Balancer's and the Application Gateway's; the Google's Cloud Load Balancing's; the OpenStack's Octavia's): the traffic's distribution across the targets (the instances, the containers, the IPs), the health's checks, the TLS's termination, the session's affinity, and the scaling.
The DNS and the CDN. The DNS's services (the Route 53's, the Azure's DNS's, the Google's Cloud DNS's): the domain's management, the routing's policies (the latency's, the geolocation's, the failover's, the weighted's), and the health's checks. The CDNs (the CloudFront's, the Azure's CDN's, the Google's Cloud CDN's, the Cloudflare's, the Akamai's): the content's caching at the edge's locations, the latency's reduction, the origin's offload, and the DDoS's protection.
The network's security. The network's security's mechanisms: the security's groups (the stateful's: the allow's rules and the the no's deny's rules), the network's ACLs (the stateless's: the allow's and the deny's rules), the WAF's (the Web Application Firewall: the the HTTP's and the HTTPS's inspection), the the DDoS's protection's (the the Shield's, the the Azure's DDoS Protection's, the the Google's Cloud Armor's), the the private's connectivity's (the the PrivateLink's, the the VPC's endpoints', the the VPNs', the the Direct Connect's), and the the zero-trust's designs (the the beyond the VPC's: the the identity's and the the device's verification's).

4.8 The cloud's identity and security

The cloud's identity and security:

The IAM (the Identity and Access Management). The IAM's mechanisms (the AWS's IAM's, the Azure's Entra ID's (the Active Directory's), the Google's Cloud IAM's, the OpenStack's Keystone's): the identities (the users, the groups, the roles, the service's accounts), the policies (the permissions: the allow's and the deny's rules: the the actions', the the resources', the the conditions'), the roles (the temporary's credentials: the the assumed's roles, the the instance's profiles, the the OIDC's federation's), the federation (the external's identity's providers: the the SAML's, the the OIDC's, the the social's), and the auditing (the the CloudTrail's, the the Activity Log's, the the Cloud Audit Logs's: the API's calls' records). The observation: the IAM is the cloud's security's foundation (the Lesson 12.3's authorization's and the Lesson 12.4's access's control's concepts applied to the cloud), and the observation is the reason the IAM's policies (the the least's privilege's, the the roles' the temporary's credentials', the the conditions') are the cloud's security's central's concerns.
The KMS (the Key Management Service). The KMS's mechanisms (the AWS's KMS's, the Azure's Key Vault's, the Google's Cloud KMS's, the HashiCorp's Vault's): the encryption's keys' management (the creation, the rotation, the the policies, the the auditing), the encryption's services (the at-rest's encryption for the the storage's, the the databases', the the volumes', the the secrets'), the the envelope's encryption (the the data's keys' the master's keys' wrapping), and the the secrets' management (the the Secrets Manager's, the the Parameter Store's). The observation: the KMS is the cloud's encryption's central's mechanism, and the observation is the reason the cloud's the at-rest's encryption and the the secrets' management are the the KMS's and the the IAM's combination.
The shared's responsibility's model. The cloud's security's division: the provider is the responsible for the security's of the cloud (the data centers' physical's security, the hardware, the hypervisors, the managed's services' security), and the customer is the responsible for the security's in the cloud (the data, the identities, the configurations, the applications, the operating systems (in the IaaS), the network's configurations, the encryption's choices). The observation: the shared's responsibility's model is the cloud's security's central's concept (the Lesson 12.1's principles applied to the cloud), and the observation is the reason the misconfigurations (the public's S3's buckets, the open's databases, the excessive's IAM's permissions) are the cloud's security's common's breaches (the customer's responsibility's scope).
The cloud's security's services. The providers' security's services: the WAF's, the DDoS's protection's, the SIEM's (the the GuardDuty's, the the Security Hub's, the the Sentinel's, the the Chronicle's), the the vulnerability's scanning's, the the compliance's tools (the the AWS's Config's, the the Azure's Policy's, the the Google's Security Command Center's), the the secrets' management's, the the key's management's, and the the identity's governance's (the the IAM's Access Analyzer's, the the Entra's Permission Management's).

4.9 The cloud's elasticity, economics, and reliability

The cloud's elasticity: the capacity's automatic's adjustment to the demand. The mechanisms: the horizontal's scaling (the instances' and the containers' count's adjustment: the Auto Scaling's groups, the Kubernetes's HPA's), the vertical's scaling (the instance's sizes' adjustment: the larger or the smaller's instance's types), the scheduled's scaling (the predictable's patterns: the business's hours, the batch's windows), the predictive's scaling (the machine learning's forecasts), and the serverless's elasticity (the functions scale automatically, including the zero). The observation: the elasticity is the cloud's NIST's characteristic, and the observation is the reason the cloud's workloads' capacity is the demand's function (the no's overprovisioning) and the cost is the used's function (the no's idle's cost, the except the serverless's zero's scale).

The cloud's economics: the capex's to the opex's shift. The pricing's models:

The on-demand's pricing. The pay-as-you-go's model: the resources are the billed by the second (the compute), the GB (the storage), the requests (the API's calls), the egress (the data's transfer out), and the observation: the on-demand's pricing is the cloud's most flexible's model (the no's commitment, the the workloads with the unpredictable's demand).
The reserved's pricing. The commitment's model: the customers commit to the one's or the three's years in exchange for the significant's discounts (the 30–72%), and the observation: the reserved's pricing is the cloud's cost's optimization's mechanism for the predictable's workloads (the the steady's state's capacity).
The spot's pricing. The market's model: the customers bid for the providers' unused's capacity (the discounts of the 60–90%), and the provider can reclaim the instances with the short's notice (the two's minutes), and the observation: the spot's pricing is the cloud's cheapest's model for the interruption's tolerant's workloads (the batch's jobs, the stateless's web's servers, the CI/CD's runners).
The savings's plans and the committed's use's discounts. The flexible's commitment's models (the AWS's Savings Plans's, the Azure's Reservations's, the Google's Committed Use Discounts's): the customers commit to the spending's levels (not the specific's resources) in exchange for the discounts, and the observation: the savings's plans are the cloud's cost's optimization's mechanism with the flexibility's.
The free's tiers and the credits. The providers' free's tiers (the limited's usage of the services: the the 12-months's free's tier's, the the always's free's tier's) and the credits (the the startups', the the research's, the the education's), and the observation: the free's tiers and the credits are the cloud's adoption's mechanisms.
The hidden's costs. The cloud's cost's traps: the egress's fees (the data's transfer out: the the significant's costs for the the data's intensive's workloads), the the idle's resources (the the forgotten's instances, the the unattached's volumes, the the old's snapshots), the the NAT's gateways' costs (the the per-GB's processing's), the the cross-AZ's traffic's (the the inter-AZ's data's transfer's), the the managed's services' premiums (the the convenience's cost's), and the observation: the hidden's costs are the cloud's cost's management's (the FinOps's) central's concerns.

The cloud's reliability: the cloud's failure's model and the designs:

The regions. The geographic's areas (the AWS's us-east-1's, the Azure's East US's, the Google's us-central1's, the OpenStack's regions): the isolated's geographic's areas with the independent's infrastructure (the power, the cooling, the network), and the observation: the regions are the cloud's disaster's recovery's and the data's residency's units.
The availability's zones. The isolated's data centers within a region (the the AWS's AZs's, the the Azure's Availability Zones's, the the Google's zones's): the separate's power, cooling, and network, with the low's latency (the the milliseconds' between the the AZs in the the same's region) and the the synchronous's replication's (the the databases', the the storage's), and the observation: the AZs are the cloud's high's availability's units (the the multi-AZ's designs: the the databases', the the load's balancers', the the applications').
The SLAs (the Service Level Agreements). The providers' commitments: the the availability's (the the 99.9%'s, the the 99.99%'s, the the 99.999%'s), the the durability's (the the 11 nines's for the object's storage), the the performance's (the the IOPS's, the the latency's), and the the remedies (the the service's credits's, the the no's direct's damages's), and the observation: the SLAs are the cloud's reliability's contracts, and the observation is the reason the workloads' designs (the the multi-AZ's, the the multi-region's, the the retries', the the circuit's breakers') must exceed the SLAs.
The failure's designs. The cloud's failure's designs: the the multi-AZ's (the the databases' the synchronous's replication's, the the applications' the load's balancing's across the AZs), the the multi-region's (the the active-active's, the the active-passive's, the the DNS's failover's), the the chaos's engineering's (the the deliberate's failures: the the Netflix's Chaos Monkey's, the the AWS's Fault Injection Simulator's), and the the resilience's patterns (the the retries' with the the exponential's backoff's, the the circuit's breakers', the the bulkheads', the the timeouts', the the graceful's degradation's).

4.10 The serverless's computing

The serverless's computing is the cloud's model where the provider manages the servers (the provisioning, the scaling, the patching, the availability), and the customers provide only the code (the functions) and the configuration. The serverless's characteristics:

No server's management. The customers do not provision or manage the servers: the provider handles the infrastructure (the Lesson 13.1's and 13.2's virtualization's, the Lesson 13.5's orchestration's, the containers') behind the abstraction, and the customers focus on the code.
The event-driven's model. The functions are the triggered by the events: the HTTP's requests (the API's gateways), the messages (the queues, the streams), the files (the object's stores' events), the schedules (the cron's), the database's changes (the DynamoDB's streams, the Aurora's), and the custom's events (the event's buses).
The automatic's scaling. The functions scale automatically (the concurrent's executions), including the zero (the no's idle's cost), and the observation: the serverless's scaling is the cloud's elasticity's extreme's case (the the demand's function's, the no's capacity's planning's).
The pay-per-invocation's pricing. The functions are the billed by the invocations' count, the execution's duration (the the milliseconds's), and the allocated's memory, and the observation: the pay-per-invocation's pricing is the cloud's granular's pricing (the the no's idle's cost, the the sporadic's workloads' the cost's efficiency).
The cold's start. The first's invocation's latency (the the provider initializes the execution's environment: the the container's, the the runtime's, the the code's), and the observation: the cold's start is the serverless's central's concern (the the latencies' the tens's to the the seconds's), and the observation is the reason the providers' mechanisms (the the provisioned's concurrency's, the the warm's pools, the the snapshots's, the the smaller's runtimes's: the the Rust's, the the Go's, the the Node.js's) reduce the cold's start's impact.
The stateless's design. The functions are the stateless: the state is the external's (the databases, the object's stores, the queues, the caches), and the observation: the stateless's design is the serverless's scalability's and the resilience's requirement, and the observation is the reason the serverless's applications use the managed's state's services (the DynamoDB's, the S3's, the SQS's, the ElastiCache's).
The execution's limits. The providers' limits: the the timeout's (the the 15 minutes's for the Lambda's), the the memory's (the the 128 MB's to the the 10 GB's), the the package's size (the the zipped's, the the container's images'), the the concurrent's executions, and the observation: the execution's limits are the serverless's design's constraints, and the observation is the reason the serverless's architectures (the the orchestration's, the the queues', the the step's functions': the the AWS's Step Functions's, the the Azure's Durable Functions's) decompose the long's workloads into the shorter's functions.
The serverless's ecosystem. The serverless's ecosystem: the frameworks (the the Serverless Framework's, the the AWS's SAM's, the the SST's, the the Chalice's, the the Zappa's), the the local's development's tools (the the SAM's Local's, the the Serverless Offline's, the the LocalStack's), the the observability's (the the Lumigo's, the the Thundra's, the the Datadog's Serverless's), and the the managed's services (the the databases', the the queues', the the API's gateways', the the authentication's).

4.11 Common misconceptions

"The cloud is the virtualization."

The virtualization is the cloud's enabler (the technology: the hypervisors, the VMs, the containers), and the cloud is the service model (the NIST's five characteristics: the on-demand's self-service, the broad's network's access, the resource's pooling, the rapid's elasticity, the measured's service). The observation: the virtualization without the cloud's service model is the on-premises's VMs (the no's self-service, the no's metering), and the observation is the reason the cloud's discussion (the service models, the deployment models, the economics) goes beyond the virtualization's mechanisms.

"The cloud is the cheaper's."

The cloud's cost's efficiency depends on the workload: the cloud is the cheaper for the workloads with the variable's demand (the no's overprovisioning, the pay-as-you-go's) and the sporadic's workloads (the the serverless's), and the cloud is the more expensive for the workloads with the steady's, the high's utilization (the the reserved's instances can help, but the on-premises's hardware is the cheaper for the the maxed's utilization's), and the observation: the cloud's cost's analysis (the the TCO's: the the total's cost's of the ownership's) must account for the the egress's fees, the the operations's costs, the the idle's resources, and the the reserved's commitments.

"The cloud is the secure's by definition."

The cloud's security is the shared's responsibility: the provider secures the cloud (the data centers, the hardware, the hypervisors, the managed's services), and the customer secures the in the cloud (the data, the identities, the configurations, the applications, the network's configurations). The observation: the cloud's security's breaches are the often the customer's responsibility's scope (the public's S3's buckets, the excessive's IAM's permissions, the open's databases), and the observation is the reason the cloud's security's practices (the IAM's least's privilege's, the encryption's, the network's segmentation's, the monitoring's) are the customer's ongoing's concerns.

"The serverless is the cheaper's."

The serverless's cost's efficiency depends on the workload: the serverless is the cheaper for the sporadic's and the event-driven's workloads (the no's idle's cost), and the serverless can be the more expensive for the steady's, the high's volume's workloads (the the per-invocation's pricing's the the always-on's instances can be the cheaper), and the observation: the serverless's cost's analysis must account for the the invocations', the the durations', the the memory's, and the the surrounding's services' (the the API's gateways', the the databases', the the queues', the the observability's).

"The multi-cloud is the always's better."

The multi-cloud's benefits (the the vendor's lock-in's avoidance, the the resilience's, the the best-of-breed's services) come with the costs (the the complexity's: the the multiple's environments, the the networking's, the the identity's; the the skills' requirements's; the the egress's fees's; the the duplicated's services's), and the observation: the multi-cloud's design must be the deliberate (the the specific's requirements's: the the compliance's, the the resilience's), not the default, and the observation is the reason the the single-cloud's designs with the the portable's abstractions (the the Kubernetes's, the the Terraform's, the the open-source's services') are the often the pragmatic's choice.

"The cloud's availability's is the provider's problem."

The providers' SLAs guarantee the services' availability (the the EC2's, the the S3's), and the the applications' availability is the customer's responsibility (the the architectures': the the multi-AZ's, the the multi-region's, the the retries', the the circuit's breakers', the the graceful's degradation's). The observation: the providers' services can fail (the the AZ's failures, the the region's failures, the the services' outages), and the observation is the reason the the applications' availability (the the 99.99%'s, the the 99.999%'s) requires the the architectures' that tolerate the the providers' failures.

"The cloud's egress's is the free's."

The cloud's data's transfer is the asymmetric's: the ingress (the data's transfer into the cloud) is the often the free's, and the egress (the data's transfer out) is the metered's and the often the expensive's (the the 0.05–0.12's per GB's for the AWS's, the the similar's for the others). The observation: the egress's fees are the cloud's cost's management's central's concern (the the data's intensive's workloads, the the multi-cloud's designs, the the migrations), and the observation is the reason the the architectures' minimize the the egress's (the the caching's, the the CDNs', the the same-region's designs', the the object's stores' the internal's access's).

"The cloud's services are the compatible's."

The cloud's services are the often the similar's (the the object's stores: the the S3's, the the Blob Storage's, the the GCS's; the the databases: the the RDS's, the the Azure's SQL's, the the Cloud SQL's; the the functions: the the Lambda's, the the Functions's, the the Cloud Functions's), and the the APIs' and the the semantics' are the different's (the the IAM's, the the networking's, the the services' limits', the the pricing's), and the observation: the cloud's portability (the the migration's between the providers) requires the the abstractions' (the the Kubernetes's, the the Terraform's, the the open-source's services': the the PostgreSQL's, the the Kafka's, the the Redis's) rather than the the providers' proprietary's services'.

05 Worked example

The following example designs a cloud's architecture for a web application, compares the service models' choices, and estimates the costs.

Designing a cloud's architecture

Consider a company that is migrating its web application (a three-tier's application: a web's frontend, an API's backend, a PostgreSQL's database) to the cloud. The application's requirements:

The traffic: the 100,000 daily's active's users, with the peaks of the 5,000 concurrent's requests per second and the lulls of the 100 concurrent's requests per second.
The data: the 500 GB of the relational's data (the database), the 2 TB of the user's uploads (the images, the videos), and the 100 GB of the logs.
The latency: the 200 ms's target for the web's requests, the 50 ms's for the API's calls.
The availability: the 99.95%'s (the ~4.4 hours' downtime per year).
The compliance: the GDPR's (the EU's users' data must be the stored in the EU's regions).
The budget: the $10,000 per month's target.

The architecture's design

The architecture's components:

The tier	The cloud's service	The design's rationale
The web's frontend	The containers (the EKS's) on the auto-scaling's node's groups, behind the ALB's and the CloudFront's CDN	The containers: the portability, the fast's deployments; the auto-scaling: the 5,000 → 100 RPS's elasticity; the CDN: the static's content's caching (the latency's reduction, the origin's offload)
The API's backend	The containers (the EKS's) with the HorizontalPodAutoscaler, the ALB's, the ElastiCache's (the Redis's)	The containers: the microservices, the autoscaling's; the cache: the database's load's reduction, the 50 ms's API's target
The database	The managed's PostgreSQL (the RDS's) with the multi-AZ's deployment and the read's replicas	The managed's service: the backups, the patching, the failover; the multi-AZ's: the 99.95%'s availability; the read's replicas: the read's scaling
The user's uploads	The object's storage (the S3's) with the lifecycle's policies and the CloudFront's	The object's storage: the 2 TB's scale, the durability, the cost's efficiency; the lifecycle's policies: the colder's tiers for the older's uploads; the CDN: the media's delivery
The logs	The object's storage (the S3's) with the lifecycle's transitions to the Glacier's, and the CloudWatch's for the metrics	The object's storage: the cheap's logs' retention; the lifecycle's: the archive's tier after the 90 days; the CloudWatch's: the operational's metrics
The networking	The VPC's with the public's subnets (the ALB's), the private's subnets (the EKS's nodes, the RDS's), the NAT's gateways, the security's groups, the VPC's endpoints	The private's subnets: the no's direct's internet's exposure; the NAT's gateways: the outbound's access; the VPC's endpoints: the S3's and the ECR's access without the internet
The identity	The IAM's roles with the IRSA (the IAM's Roles for the Service's Accounts: the pods assume the IAM's roles), the least's privilege's policies	The IAM's roles: the temporary's credentials, the no's static's keys; the IRSA's: the per-pod's permissions; the least's privilege's: the minimal's permissions
The security	The WAF's, the Shield's, the KMS's (the encryption at rest), the Secrets Manager's (the database's credentials), the GuardDuty's (the threat's detection), the CloudTrail's (the API's auditing)	The layered's security: the defence in the depth; the KMS's: the at-rest's encryption; the GuardDuty's and the CloudTrail's: the detection and the auditing
The observability	The CloudWatch's (the metrics, the logs, the alarms), the X-Ray's (the traces), the Prometheus's and the Grafana's (the Kubernetes's)	The observability: the metrics, the logs, the traces; the alarms: the SLO's monitoring
The reliability	The multi-AZ's (the every tier), the RDS's multi-AZ's, the S3's (the multi-AZ's by default), the Route 53's health's checks	The multi-AZ's: the 99.95%'s availability; the health's checks: the failover; the stateless's tiers: the easy's replacement

The cost's estimate

The monthly's cost's estimate (the approximate's, the us-east-1's prices):

The component	The quantity	The unit's price	The monthly's cost
The EKS's nodes (the m6i.large's, the on-demand's)	6 instances	$0.096/h	~$420
The EKS's control's plane	1 cluster	$0.10/h	~$73
The RDS's PostgreSQL (the db.m6g.large's, the multi-AZ's)	2 instances (the primary's + the standby's)	$0.164/h each	~$240
The RDS's storage (the gp3's)	500 GB	$0.08/GB-month	~$40
The S3's storage (the user's uploads: the Standard's; the logs: the Glacier's)	2 TB + 100 GB	$0.023/GB + $0.004/GB	~$48
The data's transfer out	2 TB/month	$0.09/GB	~$180
The load's balancers (the ALB's, the NLB's)	2	$0.0225/h + the LCU's	~$50
The NAT's gateways	2 (the multi-AZ's)	$0.045/h + $0.045/GB	~$130
The CloudFront's CDN	5 TB/month	$0.085/GB	~$425
The ElastiCache's Redis (the cache.m6g.large's)	2 nodes	$0.126/h each	~$185
The CloudWatch's, the X-Ray's, the GuardDuty's, the WAF's	—	—	~$250
The total	—	—	~$2,041

The cost's analysis's observations:

The budget's headroom. The $2,041's estimate is well under the $10,000's budget, and the headroom provides the room for the growth (the traffic's increases, the data's growth), the additional's services (the analytics, the ML's), and the reserved's instances' discounts (the 30–40%'s savings for the steady's capacity).
The cost's drivers. The largest's components: the compute (the EKS's nodes and the EKS's control's plane: the ~$493's, the 24%), the CDN's (the $425's, the 21%), the managed's services (the RDS's, the ElastiCache's: the ~$465's, the 23%), the networking (the NAT's gateways, the load's balancers, the data's transfer out: the ~$360's, the 18%), and the observability's and the security's (the ~$250's, the 12%).
The cost's optimization's opportunities. The reserved's instances (the 30–40%'s savings for the EKS's nodes and the RDS's instances), the Savings Plans, the S3's lifecycle's policies (the colder's tiers), the CloudFront's caching's optimization (the cache's hit's rate), the NAT's gateways' replacement with the VPC's endpoints (the S3's and the ECR's access without the NAT), the Graviton's instances (the ARM's: the 20%'s cheaper), and the egress's reduction (the CDN's, the same-region's designs).

The service models' comparison

The same application's deployment under the different's service models:

The model	The architecture	The estimated's monthly's cost	The operational's burden
The IaaS's (the EC2's instances, the self-managed's PostgreSQL's, the self-managed's Redis's)	The instances, the EBS's volumes, the VPC's, the self-installed's operating systems, the databases, the middlewares	~$1,500	The highest (the operating systems' patching, the databases' tuning, the backups, the failover)
The CaaS's (the EKS's, the managed's RDS's, the managed's ElastiCache's)	The containers, the managed's database, the managed's cache, the VPC's	~$2,041	The moderate (the containers' and the clusters' management, the databases' tuning)
The PaaS's (the Elastic Beanstalk's or the App Runner's, the managed's RDS's)	The application's platform, the managed's database, the minimal's operations	~$2,500	The low (the code's deployments, the platform's configuration)
The FaaS's (the Lambda's, the API Gateway's, the Aurora's Serverless's, the DynamoDB's)	The functions, the managed's API's gateway, the serverless's database, the event's integrations	~$1,800 (the variable's, the traffic's function)	The lowest (the code, the configuration, the monitoring)

The service models' comparison's observations: the IaaS is the cheapest's in the raw's compute (the no's managed's services' premiums) but the most expensive's in the operations (the self-managed's databases, the operating systems' patching); the CaaS and the PaaS are the balance (the managed's services' convenience and the operations' reduction); the FaaS is the cheapest's for the variable's traffic (the no's idle's cost) and the most expensive's for the steady's, the high's volume's traffic (the per-invocation's pricing's); and the observation: the service models' choice is the control's and the convenience's trade-off (the the responsibility's scope's the Lesson's 4.2's table's), and the observation is the reason the modern's architectures combine the models (the CaaS's for the applications, the PaaS's for the databases, the FaaS's for the event-driven's tasks, the IaaS's for the specialized's workloads).

The reliability's design

The application's availability's design:

The component	The failure's mode	The design's mitigation
The EKS's nodes	The node's failure	The multi-AZ's node's groups, the Kubernetes's self-healing (the pods are the rescheduled on the healthy's nodes), the ClusterAutoscaler
The RDS's database	The AZ's failure, the instance's failure	The multi-AZ's deployment (the synchronous's replication, the automatic's failover), the read's replicas (the read's scaling), the automated's backups
The S3's storage	The AZ's failure	The S3's multi-AZ's replication (the default), the cross-region's replication (the disaster's recovery)
The CDN's	The edge's location's failure	The CDN's multiple's edge's locations, the origin's failover
The region's	The region's failure	The cross-region's replication (the RDS's cross-region's read's replicas, the S3's cross-region's replication), the Route 53's failover's routing, the infrastructure's as the code (the Terraform's: the rapid's re-creation's)
The application's	The dependency's failures (the slow's responses, the errors)	The timeouts, the retries with the exponential's backoff's, the circuit's breakers, the bulkheads, the graceful's degradation

The reliability's design's observations: the multi-AZ's design achieves the 99.95%'s availability (the ~4.4 hours' downtime per year), and the multi-region's design achieves the 99.99%'s or the higher (the ~53 minutes' downtime per year). The observation: the reliability's design is the layered's (the defence in the depth's: the the AZ's, the the region's, the the application's patterns), and the observation is the reason the cloud's architectures' reliability's designs (the the multi-AZ's, the the multi-region's, the the resilience's patterns') are the availability's engineering's central's concerns.

06 Interactive activity

Activity · explore the cloud's services on a live system

The goal of this activity is to use the cloud's providers' CLIs (or the local's emulators) to explore the cloud's services, to provision the resources, and to inspect the cloud's architecture's components. Work through the steps in your course VM. Note: the activity requires a cloud's account (the AWS's free's tier's, the Azure's free's account's, the Google's Cloud's free's tier's) or the local's emulators (the LocalStack's, the MinIO's, the DevStack's, the OpenStack's all-in-one's, the kind's/minikube's for the Kubernetes's). The activity uses the aws's, the az's, the gcloud's, the openstack's, the kubectl's, the s3cmd's, the mc's (the MinIO's client), and the rclone's commands, with the local's alternatives.

Inventory the cloud's tools. Check the available cloud's tools and the local's emulators.

# The cloud's CLIs
which aws az gcloud openstack ibmcloud doctl 2>/dev/null

# The IaC's tools
which terraform pulumi ansible 2>/dev/null

# The Kubernetes's tools
which kubectl helm k9s kind minikube 2>/dev/null

# The object's stores' tools
which s3cmd mc rclone 2>/dev/null

# The local's emulators
which localstack docker podman 2>/dev/null

# The versions (if the tools are installed)
aws --version 2>/dev/null
az --version 2>/dev/null | head -1
gcloud --version 2>/dev/null | head -1
kubectl version --client --short 2>/dev/null

Which cloud's tools are available? Which local's emulators are available? Write down what you find.

Explore the object's storage. Use the object's storage's tools (the MinIO's or the S3's or the LocalStack's) to create a bucket, to upload the objects, and to inspect the lifecycle.

# Start the local's object's store (the MinIO's)
docker run -d --name minio \
    -p 9000:9000 -p 9001:9001 \
    -e MINIO_ROOT_USER=minioadmin \
    -e MINIO_ROOT_PASSWORD=minioadmin \
    minio/minio server /data --console-address ":9001" 2>/dev/null

# The MinIO's client
which mc 2>/dev/null
mc alias set local http://localhost:9000 minioadmin minioadmin 2>/dev/null

# Create a bucket
mc mb local/myapp-bucket 2>/dev/null
mc ls local/ 2>/dev/null

# Upload the objects
echo "Hello from the object's storage!" > /tmp/test.txt
mc cp /tmp/test.txt local/myapp-bucket/ 2>/dev/null
mc ls local/myapp-bucket/ 2>/dev/null

# The object's metadata
mc stat local/myapp-bucket/test.txt 2>/dev/null

# The object's versions (if the versioning is enabled)
mc version enable local/myapp-bucket 2>/dev/null
mc cp /tmp/test.txt local/myapp-bucket/ 2>/dev/null
mc ls --versions local/myapp-bucket/ 2>/dev/null

# The cleanup
mc rm --recursive --force local/myapp-bucket 2>/dev/null
docker rm -f minio 2>/dev/null
rm /tmp/test.txt

Did the object's storage's operations work? What are the object's metadata? How does the versioning work? Write down your observations.

Explore the cloud's compute (the Kubernetes's). Use the local's Kubernetes's cluster to explore the cloud's compute's abstractions.

# Start the cluster
minikube start --cpus=2 --memory=4096 2>/dev/null
# or
kind create cluster --name cloud-demo 2>/dev/null

# The cluster's nodes
kubectl get nodes -o wide
kubectl describe nodes | head -40

# The nodes' labels (the cloud's instance's types, the zones)
kubectl get nodes --show-labels

# The cluster's capacity
kubectl top nodes 2>/dev/null

# Deploy the application
kubectl create namespace demo 2>/dev/null
kubectl create deployment web --image=nginx:alpine -n demo 2>/dev/null
kubectl expose deployment web --port=80 --type=ClusterIP -n demo 2>/dev/null

# The deployment's state
kubectl get all -n demo

# The pods' placement
kubectl get pods -n demo -o wide

# The service's discovery
kubectl run test --rm -it --image=busybox -n demo --restart=Never -- \
    wget -q -O - http://web.demo.svc.cluster.local/ 2>/dev/null | head -3

# The cleanup
kubectl delete namespace demo 2>/dev/null
minikube stop 2>/dev/null
# or
kind delete cluster --name cloud-demo 2>/dev/null

How do the Kubernetes's abstractions map to the cloud's compute? What are the nodes' labels? Write down what you find.

Explore the cloud's CLI (the provider's). If the cloud's account is available, use the CLI to explore the cloud's services (the account's identity, the regions, the services' list).

# The AWS's CLI
aws sts get-caller-identity 2>/dev/null
aws ec2 describe-regions --query 'Regions[].RegionName' --output table 2>/dev/null | head -20
aws ec2 describe-availability-zones --region us-east-1 --query 'AvailabilityZones[].ZoneName' --output table 2>/dev/null
aws s3 ls 2>/dev/null
aws ec2 describe-instance-types --query 'InstanceTypes[0:5].[InstanceType,VCpuInfo.DefaultVCpus,MemoryInfo.SizeInMiB]' --output table 2>/dev/null

# The Azure's CLI
az account show 2>/dev/null | head -10
az account list-locations --query '[].name' --output table 2>/dev/null | head -20
az group list --output table 2>/dev/null

# The Google's Cloud's CLI
gcloud auth list 2>/dev/null
gcloud compute regions list 2>/dev/null | head -10
gcloud config list 2>/dev/null

What are the account's identity and the regions? What are the availability's zones? What are the instance's types? Write down what you find. Note: the queries are the read-only's (the describe's, the list's): the activity does not create the billable's resources.

Compare the service models. Compare the service models' responsibilities with the cloud's documentation and the CLI's outputs.

# The IaaS's services (the compute, the storage, the network)
aws ec2 describe-instances 2>/dev/null | head -5
aws ec2 describe-volumes 2>/dev/null | head -5
aws ec2 describe-vpcs 2>/dev/null | head -5

# The PaaS's services (the managed's databases)
aws rds describe-db-instances 2>/dev/null | head -5
aws elasticache describe-cache-clusters 2>/dev/null | head -5

# The FaaS's services (the functions)
aws lambda list-functions 2>/dev/null | head -5
aws lambda get-account-settings 2>/dev/null | head -10

# The serverless's framework (if available)
which serverless sam 2>/dev/null

# The container's services
aws ecs list-clusters 2>/dev/null
aws eks list-clusters 2>/dev/null

# The object's storage's service
aws s3api list-buckets 2>/dev/null

Which services are the IaaS's, the PaaS's, the FaaS's? How do the services' APIs differ? Write down what you find.

Explore the cloud's IaC (the infrastructure's as the code). Use the Terraform's (or the OpenTofu's) configuration to define the cloud's resources.

# Check the tools
which terraform tofu 2>/dev/null

# Create the Terraform's configuration (the local's provider's)
mkdir -p /tmp/tf-demo && cd /tmp/tf-demo
cat > main.tf << 'EOF'
terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.0"
    }
  }
}

resource "local_file" "example" {
  content  = "Hello from the Terraform's infrastructure's as the code!"
  filename = "/tmp/tf-demo/output.txt"
}

output "file_path" {
  value = local_file.example.filename
}
EOF

# Initialize and apply
terraform init 2>/dev/null
terraform plan 2>/dev/null
terraform apply -auto-approve 2>/dev/null
cat /tmp/tf-demo/output.txt

# The state's inspection
terraform state list 2>/dev/null
terraform show 2>/dev/null | head -20

# The destroy
terraform destroy -auto-approve 2>/dev/null

# The cleanup
rm -rf /tmp/tf-demo

Did the Terraform's workflow work? What does the state's list show? How does the IaC's model (the declarative's, the state's) compare with the cloud's console's operations? Write down your observations.

Explore the cloud's networking. If the cloud's account is available, explore the VPC's, the subnets, the security's groups, and the load's balancers.

# The VPCs and the subnets
aws ec2 describe-vpcs --query 'Vpcs[].[VpcId,CidrBlock,IsDefault]' --output table 2>/dev/null
aws ec2 describe-subnets --query 'Subnets[0:5].[SubnetId,VpcId,CidrBlock,AvailabilityZone,MapPublicIpOnLaunch]' --output table 2>/dev/null

# The security's groups
aws ec2 describe-security-groups --query 'SecurityGroups[0:5].[GroupId,GroupName,Description]' --output table 2>/dev/null

# The load's balancers
aws elbv2 describe-load-balancers --query 'LoadBalancers[].LoadBalancerName' --output table 2>/dev/null

# The route tables
aws ec2 describe-route-tables --query 'RouteTables[0:3].[RouteTableId,VpcId]' --output table 2>/dev/null

What are the VPCs, the subnets, and the security's groups? How does the cloud's networking compare with the traditional's data center's networking? Write down what you find.

Read the man pages. Read the man pages that document the cloud's interfaces.
```
man 1 aws
man 1 az
man 1 gcloud
man 1 openstack
man 1 terraform
man 1 ansible
man 1 pulumi
man 1 kubectl
man 1 helm
man 1 s3cmd
man 1 rclone
man 1 mc
man 1 docker
```
For each, write a sentence describing its main contribution to your understanding of the cloud. The man 1 aws page documents the AWS's CLI; the man 1 terraform page documents the infrastructure's as the code; the man 1 kubectl page documents the Kubernetes's CLI.

Reflect: the cloud is the modern's computing's central's paradigm, and its design's trade-offs (the control's loss, the vendor's lock-in, the security's concerns, the cost's unpredictability) are the engineering's and the business's ongoing's concerns. The cloud's service models (the IaaS's, the PaaS's, the SaaS's, the FaaS's) are the different's balances of the control's and the convenience's, and the cloud's operating systems (the OpenStack's, the Kubernetes's, the providers' stacks) are the platforms that manage the data center's resources at the scale. Which of the cloud's characteristics (the on-demand's self-service, the broad's network's access, the resource's pooling, the rapid's elasticity, the measured's service) is the most important for the workloads you care about, and why? What would you change about the cloud's design if you could? How would you explain the shared's responsibility's model to someone who thinks the cloud is the security's outsourcing? What is the right balance between the cloud's convenience and the control's requirements?

07 Knowledge check

Check your understanding

Question 1

Define the cloud computing and explain the NIST's five essential characteristics (the on-demand's self-service, the broad's network's access, the resource's pooling, the rapid's elasticity, the measured's service). Distinguish the cloud from the virtualization, and explain the cloud's benefits and trade-offs.

Show answer

The cloud computing is the delivery of the computing's resources as the services over the network, with the on-demand's self-service, the measured's usage, and the elastic's scaling. The NIST's five essential characteristics: the on-demand's self-service (the consumers provision the capabilities (the server's time, the storage, the network) as the needed, automatically, without the human's interaction with the provider); the broad's network's access (the capabilities are the available over the network through the standard's mechanisms and the heterogeneous's client's platforms); the resource's pooling (the provider's resources are the pooled to serve the multiple's consumers (the multi-tenancy), with the dynamic's assignment and the location's independence); the rapid's elasticity (the capabilities are the elastically provisioned and released (the scale's out, the scale's in), appearing as the unlimited to the consumer); and the measured's service (the resource's use is the automatically controlled and optimized by the metering (the storage, the processing, the bandwidth, the accounts), providing the transparency for both the provider and the consumer). The cloud's distinction from the virtualization: the virtualization is the cloud's enabler (the technology: the hypervisors, the VMs, the containers, the orchestration), and the cloud is the service model (the NIST's five characteristics: the on-demand's self-service, the metering, the elasticity, the pooling, the network's access). The observation: the virtualization without the cloud's service model is the on-premises's VMs (the no's self-service, the no's metering). The cloud's benefits: the cost's efficiency (the capex's to the opex's: the pay-as-you-go's pricing, the no's capital's investment), the elasticity (the rapid's scaling: the capacity's adjustment to the demand, the no's overprovisioning), the agility (the rapid's provisioning: the resources are the available in the minutes, not the weeks), the global's reach (the providers' regions: the world's deployment, the latency's reduction, the data's residency), the reliability (the providers' redundancy: the regions, the availability's zones, the SLAs), and the innovation (the providers' services: the machine learning's, the analytics', the IoT's, the quantum's). The cloud's trade-offs: the control's loss (the infrastructure's management is the provider's: the configuration's and the performance's limitations), the vendor's lock-in (the providers' services and the APIs: the migration's difficulty), the security's concerns (the data's residency, the multi-tenancy's isolation, the compliance), the cost's unpredictability (the pay-as-you-go's model: the egress's fees, the idle's resources, the reserved's commitments), and the dependence (the network's connectivity, the providers' outages).

Question 2

Compare the cloud's service models (the IaaS's, the PaaS's, the SaaS's, the FaaS's, and the XaaS's family) and the deployment models (the public's, the private's, the hybrid's, the community's, the multi-cloud's). What is each model's responsibility's scope, and when is each appropriate?

Show answer

The cloud's service models: the IaaS (the provider offers the infrastructure: the VMs, the block's and the file's storage, the networks, the load's balancers; the customer manages the operating systems, the middlewares, the runtimes, and the applications: the customer's responsibility's scope is the largest; the examples: the AWS's EC2's, the Azure's VMs's, the Google's Compute Engine's, the OpenStack's Nova's; the appropriate for the lift-and-shift's migrations, the custom's operating systems, the full's control's requirements); the PaaS (the provider offers the platform: the runtimes, the databases, the message's queues, the caching, the monitoring; the customer manages the applications and the data; the examples: the Elastic Beanstalk's, the Heroku's, the App Engine's, the App Service's, the OpenShift's; the appropriate for the applications' rapid's development and deployment, the small's teams); the SaaS (the provider offers the software: the complete's applications; the customer manages the data and the users: the customer's responsibility's scope is the smallest; the examples: the Microsoft's 365's, the Google's Workspace's, the Salesforce's, the Slack's, the Zoom's; the appropriate for the standardized's business's applications, the no's infrastructure's management's requirements); the FaaS (the provider offers the functions: the event-driven's compute; the customer manages the function's code and the data; the examples: the Lambda's, the Azure's Functions's, the Cloud Functions's, the Cloudflare's Workers's, the Knative's; the appropriate for the event-driven's workloads, the sporadic's workloads, the small's functions); and the XaaS's family (the DBaaS's, the CaaS's, the MLaaS's, the STaaS's, the SECaaS's, the DaaS's, and the others: the cloud's services' proliferation, and the observation is the reason the customers choose the level of the abstraction that matches their requirements). The cloud's deployment models: the public's cloud (the open use by the general public: the providers' data centers; the resources are the shared among the many's tenants; the advantages: the elasticity, the cost's efficiency, the global's reach, the providers' services; the disadvantages: the control's loss, the security's concerns, the vendor's lock-in); the private's cloud (the exclusive use by a single's organization: the on-premises's data center, the hosted's private's cloud; the advantages: the control, the data's residency, the cost's predictability; the disadvantages: the capital's investment, the operations's burden, the elasticity's limits); the hybrid's cloud (the composition of the two or more distinct's clouds: the private's and the public's; the advantages: the control's and the elasticity's balance, the workload's placement's flexibility, the gradual's migration's path; the disadvantages: the complexity, the cost's); the community's cloud (the exclusive use by a specific's community: the shared's concerns: the mission, the security's requirements, the policy, the compliance; the examples: the government's clouds, the research's clouds; the advantages: the shared's cost's and the operations's, the compliance's alignment; the disadvantages: the governance's complexity); and the multi-cloud's (the use of the two or more's public's clouds: the purposes: the vendor's lock-in's avoidance, the best-of-breed's services, the resilience, the compliance; the disadvantages: the complexity, the skills' requirements, the cost's).

Question 3

Describe the cloud operating systems (the OpenStack's, the Kubernetes's as the cloud OS, the cloud's providers' stacks) and the cloud's compute's options (the VMs, the containers, the serverless, the bare metal, the GPU's and the accelerator's compute). What is each option's purpose, and when is each appropriate?

Show answer

The cloud operating system is the software's platform that manages the data center's resources (the compute, the storage, the network) and exposes them as the cloud's services (the on-demand's, the metered's, the elastic's). The examples: the OpenStack (the open-source's cloud's operating system: the components: the Nova (the compute's), the Neutron (the network's), the Cinder (the block's storage's), the Swift (the object's storage's), the Glance (the image's), the Keystone (the identity's), the Heat (the orchestration's), the Horizon (the dashboard's), the Placement (the resources' inventory's); the modular's architecture, the open-source's governance, the broad's ecosystem; the private's and the public's clouds' open-source's standard; the appropriate for the organizations with the data's residency's and the compliance's requirements); the Kubernetes as the cloud OS (the container's orchestration's platform: the clusters are the cloud's compute's platform, and the ecosystem (the operators, the CRDs, the controllers) extends the Kubernetes's scope from the containers' orchestration to the applications' platform (the databases, the queues, the caches, the ML's models); the modern's cloud's application's operating system; the appropriate for the cloud's native's applications, the portable's workloads); and the cloud's providers' stacks (the AWS's, the Azure's, the Google's Cloud's, the Alibaba's Cloud's, the Oracle's Cloud's: the proprietary's platforms that combine the virtualization, the storage, the networking, the identity, the managed's services, and the management's tools; the public's clouds' platforms). The cloud's compute's options: the virtual machines (the IaaS's compute: the instances with the full's operating systems' control, the instance's types, the auto-scaling's groups, the spot's instances; the appropriate for the lift-and-shift's migrations, the custom's operating systems, the legacy's applications); the containers (the CaaS's compute: the images' packages, the pods' scheduling, the services' networking, the autoscaling's; the appropriate for the microservices, the cloud's native's applications, the CI/CD's, the portable's workloads); the serverless (the FaaS's compute: the functions, the event-driven's model, the provider's scaling, the pay-per-invocation's pricing, the cold's start, the stateless's design; the appropriate for the event-driven's workloads, the sporadic's workloads, the glue's code); the bare metal (the dedicated's compute: the physical's servers without the hypervisor, the high's performance, the specific's hardware's requirements, the licensing's requirements, the compliance's requirements; the appropriate for the high-performance's computing, the GPU's workloads, the databases, the regulated's workloads); and the GPU's and the accelerator's compute (the GPU's instances, the TPUs, the FPGAs, the inference's accelerators; the appropriate for the machine learning's training's and the inference's, the high-performance's computing's).

Question 4

Describe the cloud's storage (the object's stores, the block's stores, the file's systems, the tiers and the lifecycle), the cloud's networking (the VPCs, the subnets, the security's groups, the load's balancers, the CDNs), and the cloud's identity and security (the IAM, the KMS, the shared's responsibility's model, the cloud's security's services). What is each service's purpose, and how do the services relate to the traditional's data center's components?

Show answer

The cloud's storage: the object's storage (the S3's, the Blob Storage's, the GCS's, the Swift's, the MinIO's: the data is the stored as the objects (the unstructured's data: the files, the media, the backups, the logs) in the buckets with the keys, and the access is the HTTP's API; the characteristics: the massive's scale, the durability (the 11 nines's), the availability, the metadata, the versioning, the lifecycle's policies, the encryption, the access's control; the appropriate for the static's content, the media, the backups, the data's lakes, the logs, the artifacts); the block's storage (the EBS's, the Managed Disks's, the Persistent Disks's, the Cinder's: the virtual's disks that the instances attach, with the types, the snapshots, the encryption, the performance's characteristics; the appropriate for the databases, the file systems, the boot's volumes, the applications with the random's I/O's); the file's storage (the EFS's, the FSx's, the Azure's Files's, the Filestore's, the Manila's: the shared's file's systems (the NFS's, the SMB's) that the multiple's instances mount; the appropriate for the shared's content, the home's directories, the lift-and-shift's applications); and the storage's tiers and the lifecycle (the hot's, the warm's, the cold's tiers, and the lifecycle's policies: the automatic's transitions, the expirations, the cost's optimization). The cloud's networking: the VPC (the virtual's network: the isolated's network within the cloud, with the subnets (the public's, the private's), the route tables, the internet's gateways, the NAT's gateways, the security's groups (the stateful's firewall's rules), the network's ACLs (the stateless's firewall's rules), the peering, the VPNs); the load's balancers (the ALB's, the NLB's, the CLB's, the Azure's Load Balancer's, the Google's Cloud Load Balancing's, the Octavia's: the traffic's distribution, the health's checks, the TLS's termination, the session's affinity); the DNS and the CDN (the Route 53's, the Azure's DNS's, the Cloud DNS's: the domain's management, the routing's policies; the CloudFront's, the Azure's CDN's, the Cloud CDN's, the Cloudflare's, the Akamai's: the content's caching at the edge's locations); and the network's security (the security's groups, the network's ACLs, the WAF's, the DDoS's protection's, the private's connectivity's, the zero-trust's designs). The cloud's identity and security: the IAM (the AWS's IAM's, the Azure's Entra ID's, the Google's Cloud IAM's, the Keystone's: the identities, the policies, the roles, the federation, the auditing; the observation: the IAM is the cloud's security's foundation, and the observation is the reason the IAM's policies (the least's privilege's, the roles' the temporary's credentials') are the cloud's security's central's concerns); the KMS (the AWS's KMS's, the Azure's Key Vault's, the Cloud KMS's, the Vault's: the encryption's keys' management, the encryption's services, the envelope's encryption, the secrets' management); the shared's responsibility's model (the provider is the responsible for the security's of the cloud: the data centers, the hardware, the hypervisors, the managed's services; the customer is the responsible for the security's in the cloud: the data, the identities, the configurations, the applications); and the cloud's security's services (the WAF's, the DDoS's protection's, the SIEM's, the vulnerability's scanning's, the compliance's tools, the secrets' management's, the identity's governance's). The cloud's services' relation to the traditional's data center's components: the object's storage replaces the network's file systems and the archives, the block's storage replaces the SAN's and the DAS's, the file's storage replaces the NAS's, the VPC replaces the VLANs and the firewalls, the load's balancers replace the hardware's load's balancers, the IAM replaces the directory's services and the RBAC's, and the KMS replaces the HSM's and the key's management's systems. The observation: the cloud's services are the traditional's data center's components re-imagined as the managed's, the elastic's, the metered's services, and the observation is the reason the cloud's architectures' designs (the the stateless's, the the loosely's coupled's, the the disposable's) differ from the traditional's data center's designs.

Question 5

Describe the cloud's elasticity, the economics (the capex's to the opex's, the pricing's models), the reliability (the regions, the availability's zones, the SLAs), and the serverless's computing (the FaaS's, the event's model, the cold's start). What are the design's trade-offs, and how do the mechanisms affect the cloud's architectures?

Show answer

The cloud's elasticity: the capacity's automatic's adjustment to the demand: the horizontal's scaling (the instances' and the containers' count's adjustment: the Auto Scaling's groups, the Kubernetes's HPA's), the vertical's scaling (the instance's sizes' adjustment), the scheduled's scaling (the predictable's patterns), the predictive's scaling (the machine learning's forecasts), and the serverless's elasticity (the functions scale automatically, including the zero). The observation: the elasticity is the cloud's NIST's characteristic, and the observation is the reason the cloud's workloads' capacity is the demand's function (the no's overprovisioning) and the cost is the used's function (the no's idle's cost, the except the serverless's zero's scale). The cloud's economics: the capex's to the opex's shift, with the pricing's models: the on-demand's pricing (the pay-as-you-go's: the resources are the billed by the second, the GB, the requests, the egress: the most flexible's model); the reserved's pricing (the commitment's model: the one's or the three's years in exchange for the 30–72%'s discounts: the predictable's workloads' optimization); the spot's pricing (the market's model: the bid for the unused's capacity with the 60–90%'s discounts and the interruption's risk: the interruption's tolerant's workloads); the savings's plans and the committed's use's discounts (the flexible's commitment's models: the spending's levels in exchange for the discounts); the free's tiers and the credits (the adoption's mechanisms); and the hidden's costs (the egress's fees, the idle's resources, the NAT's gateways' costs, the cross-AZ's traffic's, the managed's services' premiums: the cost's management's (the FinOps's) concerns). The cloud's reliability: the regions (the geographic's areas with the independent's infrastructure: the disaster's recovery's and the data's residency's units), the availability's zones (the isolated's data centers within a region: the separate's power, cooling, and network, with the low's latency and the synchronous's replication: the high's availability's units), the SLAs (the providers' commitments: the availability's, the durability's, the performance's, with the service's credits's remedies), and the failure's designs (the multi-AZ's, the multi-region's, the chaos's engineering's, the resilience's patterns: the retries', the circuit's breakers', the bulkheads', the timeouts', the graceful's degradation's). The observation: the cloud's reliability is the providers' infrastructure's and the customers' architectures' function, and the observation is the reason the applications' availability (the 99.99%'s, the 99.999%'s) requires the architectures' that tolerate the providers' failures. The serverless's computing: the provider manages the servers, and the customers provide only the code (the functions) and the configuration. The characteristics: the no server's management, the event-driven's model (the functions are the triggered by the events: the HTTP's requests, the messages, the files, the schedules, the database's changes), the automatic's scaling (including the zero), the pay-per-invocation's pricing (the invocations' count, the execution's duration, the allocated's memory), the cold's start (the first's invocation's latency: the provider initializes the execution's environment), the stateless's design (the state is the external's), the execution's limits (the timeout's, the memory's, the package's size), and the serverless's ecosystem (the frameworks, the local's development's tools, the observability's, the managed's services). The design's trade-offs: the cloud's elasticity and the economics favour the workloads with the variable's demand (the no's overprovisioning, the pay-as-you-go's, the serverless's), and the cloud's control's loss and the vendor's lock-in favour the workloads that can use the providers' abstractions; the cloud's reliability requires the architectures' that tolerate the failures (the multi-AZ's, the multi-region's, the resilience's patterns); and the serverless's design's trade-offs (the no server's management, the automatic's scaling, the pay-per-invocation's vs. the cold's start, the stateless's design, the execution's limits, the the debugging's difficulty). The mechanisms' effects on the cloud's architectures: the elasticity's mechanisms (the autoscaling's, the load's balancing's) shape the applications' scaling's designs; the economics' models (the reserved's, the spot's) shape the capacity's planning's; the reliability's mechanisms (the multi-AZ's, the multi-region's, the SLAs) shape the availability's designs; and the serverless's characteristics shape the event-driven's architectures' (the functions', the managed's services', the orchestration's).

08 Unit discussion

Discussion prompt

The cloud is the modern's computing's central's paradigm, and its history is the history of the computing's commoditization. The classical's computing was the owned's infrastructure (the data centers, the servers, the storage, the network), and the organizations' capacity's planning was the annual's exercise (the procurement's cycles, the overprovisioning's for the peaks, the idle's capacity during the lulls). The cloud's arrival (the AWS's EC2's in the 2006's, the S3's in the 2006's, the Azure's in the 2010's, the Google's Cloud's in the 2008's, the OpenStack's in the 2010's) changed the computing's economics: the capex's to the opex's, the capacity's planning's to the elasticity's, the weeks' procurement's to the minutes' provisioning, and the ownership's to the services'. Each stage was the response to the previous stage's limitations, and each was shaped by the technology and the business's models of its time.

The trend is toward the managed's services and the abstraction's. The classical's cloud (the IaaS's: the VMs, the storage, the network) required the customers' operations (the operating systems, the middlewares, the databases, the patching); the modern's cloud (the managed's services: the databases, the queues, the caches, the machine learning's, the serverless's) removes the operations' burden and the customers' responsibility's scope shrinks (the Lesson 4.2's table's). The trend's driver is the customers' focus (the applications and the data rather than the infrastructure), and the observation is the reason the cloud's providers' portfolios are the dominated by the managed's services (the databases, the analytics, the ML, the serverless's) and the reason the cloud's native's architectures (the Kubernetes's, the serverless's, the managed's services') are the modern's applications' designs.

The trend also raises a question about the portability and the lock-in. The cloud's managed's services (the Lambda's, the DynamoDB's, the BigQuery's, the Cosmos DB's) are the proprietary's, and the observation is the reason the multi-cloud's and the portable's designs (the Kubernetes's, the Terraform's, the open-source's services: the PostgreSQL's, the Kafka's, the Redis's) are the modern's practices. The observation: the cloud's convenience (the managed's services' features, the integration's, the operations's reduction) and the portability (the open-source's services, the Kubernetes's, the IaC's) are the two sides of the cloud's design's trade-off, and the observation is the reason the modern's organizations balance the two (the the critical's workloads on the portable's services, the the differentiating's workloads on the managed's services).

Which of the cloud's characteristics (the on-demand's self-service, the broad's network's access, the resource's pooling, the rapid's elasticity, the measured's service) is the most important for the modern's workloads, and why? Should the cloud's design prioritize the convenience (the managed's services, the serverless's, the integration's) or the portability (the open-source's services, the Kubernetes's, the multi-cloud's)? What is the right balance between the cloud's cost's efficiency and the control's requirements? How should the cloud's design evolve for the AI's workloads, the edge's computing, and the sustainability's requirements? Post your response to the Unit 13 discussion forum and reply to at least two classmates. Supports CLO1, CLO7, and CLO8.

09 Practice exercise

This ungraded exercise consolidates the lesson and prepares you for Lesson 13.7. Aim to spend 60–90 minutes on it.

Compare the service models. Write a short essay (400–500 words) comparing the cloud's service models (the IaaS's, the PaaS's, the SaaS's, the FaaS's). Your essay should address:
- Each model's responsibility's scope (the customer's and the provider's).
- Each model's control's level.
- Each model's operational's burden.
- Each model's cost's characteristics.
- Each model's appropriate workloads.
- The models' combinations in the modern's architectures.
Conclude with a recommendation for a startup's MVP and for an enterprise's migration.
Design a cloud's architecture. A company is building a media's streaming's platform (the video's uploads, the transcoding, the streaming's, the recommendations). Design the cloud's architecture:
- The compute (the VMs's, the containers', the serverless's, the GPU's).
- The storage (the object's, the block's, the file's; the tiers and the lifecycle's).
- The networking (the VPC's, the subnets', the load's balancers', the CDN's).
- The database (the relational's, the NoSQL's, the cache's).
- The identity and the security (the IAM's, the KMS's, the WAF's, the secrets').
- The observability (the metrics's, the logs', the traces').
- The reliability (the multi-AZ's, the multi-region's, the SLAs).
- The cost's estimate and the optimization's opportunities.
Justify your design through the lesson's principles.

Compare the object's storage's services. On your VM, compare the object's storage's services (the MinIO's, the S3's, the Azure's Blob Storage's, the GCS's):

# Start the MinIO's local's object's store
docker run -d --name minio \
    -p 9000:9000 -p 9001:9001 \
    -e MINIO_ROOT_USER=minioadmin \
    -e MINIO_ROOT_PASSWORD=minioadmin \
    minio/minio server /data --console-address ":9001" 2>/dev/null

# The MinIO's client
mc alias set local http://localhost:9000 minioadmin minioadmin 2>/dev/null
mc mb local/test-bucket 2>/dev/null

# The operations
mc cp /etc/hostname local/test-bucket/ 2>/dev/null
mc ls local/test-bucket/ 2>/dev/null
mc stat local/test-bucket/hostname 2>/dev/null

# The versioning and the lifecycle (the MinIO's)
mc version enable local/test-bucket 2>/dev/null
mc ilm add --expiry-days 30 local/test-bucket 2>/dev/null
mc ilm ls local/test-bucket 2>/dev/null

# The S3's API's compatibility (the aws's CLI with the MinIO's endpoint)
aws --endpoint-url http://localhost:9000 s3 ls s3://test-bucket/ 2>/dev/null

# The cleanup
mc rb --force local/test-bucket 2>/dev/null
docker rm -f minio 2>/dev/null

What are the object's storage's operations? How does the S3's API's compatibility work? Write a report (500–750 words).

Analyze the cloud's cost's management. Write a short report (500–750 words) on the cloud's cost's management (the FinOps's):
- The pricing's models (the on-demand's, the reserved's, the spot's, the savings's plans).
- The cost's drivers (the compute, the storage, the network, the managed's services).
- The hidden's costs (the egress's fees, the idle's resources, the cross-AZ's traffic, the NAT's gateways).
- The optimization's strategies (the right-sizing, the reserved's instances, the spot's instances, the storage's lifecycle's, the architecture's patterns).
- The FinOps's practices (the tagging, the budgets, the alerts, the showback's and the chargeback's).
- The tools (the AWS's Cost Explorer, the Azure's Cost Management, the GCP's Cost Management, the Kubecost's, the OpenCost's).
Design the cloud's reliability. A financial's application requires the 99.99%'s availability (the ~53 minutes' downtime per year) and the recovery's point's objective (the RPO's) of the 5 minutes and the recovery's time's objective (the RTO's) of the 30 minutes. Design the reliability's architecture:
- The multi-AZ's design (the compute, the database, the storage).
- The multi-region's design (the active-passive's or the active-active's, the data's replication's, the DNS's failover's).
- The backups (the automated's, the cross-region's, the point-in-time's).
- The resilience's patterns (the retries', the circuit's breakers', the bulkheads', the timeouts', the graceful's degradation's).
- The monitoring and the alerting (the SLO's, the error's budgets, the alarms).
- The chaos's engineering (the failure's injection's, the game's days's).
- The incident's response (the runbooks's, the on-call's, the postmortems's).
Justify your design through the lesson's principles.
Design a serverless's application. A team is building an image's processing's pipeline (the users upload the images, the pipeline generates the thumbnails, the metadata is extracted, the images are the stored). Design the serverless's architecture:
- The ingestion (the API's gateway, the presigned's URLs, the object's store's events).
- The processing (the functions, the orchestration's: the step's functions', the queues).
- The storage (the object's store for the original's and the processed's images, the database for the metadata).
- The state's management (the DynamoDB's, the S3's, the SQS's).
- The error's handling (the dead-letter's queues, the retries, the idempotency).
- The observability (the traces, the metrics, the logs).
- The cost's analysis (the invocations, the durations, the storage).
- The limits (the timeout's, the memory's, the concurrency's).
Justify your design through the lesson's principles.
Compare the cloud's providers. Write a short paragraph (200–250 words) comparing the major's cloud's providers (the AWS's, the Azure's, the Google's Cloud's, the Alibaba's Cloud's, the Oracle's Cloud's, the IBM's Cloud's). Your paragraph should address:
- Each provider's strengths (the services' breadth, the enterprise's integration, the data's and the analytics', the AI's, the cost's).
- Each provider's regions and the compliance's certifications.
- Each provider's market's position.
- Each provider's appropriate workloads.
- The multi-cloud's considerations (the portability's, the complexity's).
Analyze a cloud's migration. Choose a known cloud's migration's case (the Netflix's, the Capital One's, the Dropbox's, the GitLab's, the Basecamp's, the 37signals's, the Maersk's) and analyze it:
- The migration's motivation (the cost's, the scale's, the agility's, the reliability's).
- The migration's strategy (the lift-and-shift's, the re-platform's, the re-architect's, the repurchase's).
- The architecture's changes (the microservices's, the serverless's, the containers').
- The cost's outcomes (the savings's or the increases's, and the reasons).
- The lessons for the cloud's migrations.
Write a report (500–750 words).
Reflect. In your own words, explain the cloud computing and the NIST's five essential characteristics, and describe the service models, the deployment models, the cloud operating systems, the compute, the storage, the networking, the identity and the security, the economics, the reliability, and the serverless's computing. Then describe one situation in your own experience — a cloud's service you have used, a migration you have participated in, or an architecture you have designed — where the cloud's characteristics affected the outcome. What was the situation, and how would a different design have changed the outcome?

10 Summary

The cloud computing is the delivery of the computing's resources as the services over the network, with the on-demand's self-service, the measured's usage, and the elastic's scaling. The NIST's five essential characteristics: the on-demand's self-service, the broad's network's access, the resource's pooling, the rapid's elasticity, and the measured's service. The cloud is the service model more than the technology (the virtualization, the containers, and the orchestration are the cloud's enablers).
The cloud's service models: the IaaS (the infrastructure: the VMs, the storage, the network), the PaaS (the platform: the runtimes, the databases, the middlewares), the SaaS (the software: the complete's applications), the FaaS (the functions: the event-driven's compute), and the XaaS's family (the DBaaS's, the CaaS's, the MLaaS's, the STaaS's, the others). The cloud's deployment models: the public's, the private's, the hybrid's, the community's, and the multi-cloud's.
The cloud operating systems: the OpenStack (the open-source's: the Nova's, the Neutron's, the Cinder's, the Swift's, the Glance's, the Keystone's, the Heat's, the Horizon's, the Placement's), the Kubernetes (the modern's cloud's application's operating system: the clusters' compute and the ecosystem's operators), and the cloud's providers' stacks (the AWS's, the Azure's, the Google's Cloud's, the Alibaba's Cloud's, the Oracle's Cloud's).
The cloud's compute: the VMs (the IaaS's: the full's control), the containers (the CaaS's: the images, the pods, the services, the autoscaling), the serverless (the FaaS's: the functions, the events, the automatic's scaling, the pay-per-invocation's), the bare metal (the dedicated's: the high's performance, the licensing's, the compliance's), and the GPU's and the accelerator's compute (the ML's, the HPC's).
The cloud's storage: the object's stores (the S3's, the Blob Storage's, the GCS's, the Swift's: the objects in the buckets, the HTTP's API, the durability, the versioning, the lifecycle's), the block's stores (the EBS's, the Managed Disks's, the Persistent Disks's, the Cinder's: the virtual's disks, the snapshots, the IOPS's), the file's systems (the EFS's, the FSx's, the Azure's Files's, the Filestore's: the shared's file's systems), and the tiers and the lifecycle (the hot's, the warm's, the cold's, the lifecycle's policies).
The cloud's networking: the VPCs (the virtual's networks: the subnets, the route tables, the internet's and the NAT's gateways, the security's groups, the network's ACLs, the peering, the VPNs), the load's balancers (the ALB's, the NLB's, the CLB's, the Azure's, the Google's, the Octavia's), the DNS and the CDN (the Route 53's, the CloudFront's, the Cloudflare's, the Akamai's), and the network's security (the WAF's, the DDoS's protection's, the private's connectivity's).
The cloud's identity and security: the IAM (the identities, the policies, the roles, the federation, the auditing: the cloud's security's foundation), the KMS (the encryption's keys' management, the encryption's services, the envelope's encryption, the secrets' management), the shared's responsibility's model (the provider's and the customer's scopes), and the cloud's security's services (the WAF's, the DDoS's, the SIEM's, the compliance's, the secrets', the identity's governance's).
The cloud's elasticity, economics, and reliability: the elasticity (the horizontal's, the vertical's, the scheduled's, the predictive's, the serverless's scaling), the economics (the capex's to the opex's: the on-demand's, the reserved's, the spot's, the savings's plans' pricing, and the hidden's costs), and the reliability (the regions, the availability's zones, the SLAs, the failure's designs: the multi-AZ's, the multi-region's, the chaos's engineering's, the resilience's patterns).
The serverless's computing: the provider manages the servers, and the customers provide only the code and the configuration: the event-driven's model, the automatic's scaling (including the zero), the pay-per-invocation's pricing, the cold's start, the stateless's design, the execution's limits, and the serverless's ecosystem.

Looking ahead

This lesson presented the cloud operating systems: the cloud's definition and the NIST's five essential characteristics, the service models (the IaaS's, the PaaS's, the SaaS's, the FaaS's, the XaaS's), the deployment models (the public's, the private's, the hybrid's, the community's, the multi-cloud's), the cloud operating systems (the OpenStack's, the Kubernetes's, the providers' stacks), the compute (the VMs's, the containers', the serverless's, the bare metal's, the GPU's), the storage (the object's, the block's, the file's, the tiers), the networking (the VPCs, the load's balancers, the CDNs), the identity and the security (the IAM's, the KMS's, the shared's responsibility's model), the elasticity and the economics, the reliability, and the serverless's computing. It referred several times to the future trends — the edge's computing, the confidential's computing, the WebAssembly's, the AI's infrastructure, the sustainability's — that are reshaping the cloud and the operating systems. Lesson 13.7, the unit's final's lesson, presents the future trends: the edge's computing (the latency's, the bandwidth's, the data's sovereignty's drivers), the confidential computing (the SEV's, the TDX's, the enclaves'), the WebAssembly's (the portable's binaries, the sandboxes'), the unikernels and the microVMs, the serverless's evolution (the edge's functions, the WebAssembly's functions), the AI's infrastructure (the GPU's clusters, the model's serving's, the MLOps's), the sustainability's (the energy's efficiency, the carbon's awareness, the ARM's and the RISC-V's), the quantum's computing, and the operating system's future (the microkernels' revival, the Rust's in the kernel, the formal's verification, the AI-assisted's operations). The lesson is the unit's synthesis and the course's conclusion.

11 References

Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 19.
Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, the Virtualization and the Distributed Systems chapters. Available online at ostep.org.
Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 7.
Mell, P., & Grance, T. The NIST Definition of Cloud Computing. NIST Special Publication 800-145, 2011.
Buyya, R., Vecchiola, C., & Selvi, S. T. Mastering Cloud Computing. Morgan Kaufmann, 2013.
Reese, G. Cloud Application Architectures, 2nd ed. O'Reilly, 2021.
Jackson, K., & Goessling, A. Architecting Cloud Computing Solutions. Packt, 2018.
The OpenStack project's documentation (docs.openstack.org).
The Kubernetes's documentation (kubernetes.io/docs).
The cloud's providers' documentation: the AWS's (docs.aws.amazon.com), the Azure's (learn.microsoft.com/azure), the Google's Cloud's (cloud.google.com/docs).
The Cloud Native Computing Foundation (CNCF)'s landscape.
NIST SP 800-146 (the cloud's computing's synopsis), NIST SP 800-144 (the public's cloud's security), NIST SP 500-292 (the cloud's reference's architecture).
Linux man-pages: man 1 aws, man 1 az, man 1 gcloud, man 1 openstack, man 1 terraform, man 1 ansible, man 1 pulumi, man 1 kubectl, man 1 helm, man 1 s3cmd, man 1 rclone, man 1 mc, man 1 docker.