Cloud computing is the dominant delivery model for modern software systems. Applications such as web platforms, mobile back ends, data-processing services, and artificial-intelligence systems increasingly run on infrastructure operated by cloud providers rather than on servers owned and maintained by the application team. For full-stack developers, cloud computing is not merely a hosting location. It is a collection of architectural principles, operational practices, pricing models, and managed services that influence how software is designed, deployed, secured, monitored, and scaled.

This chapter establishes the conceptual foundation required for later work with platforms such as Heroku and infrastructure providers such as Amazon Web Services (AWS). It explains how cloud services evolved from traditional hosting, how physical infrastructure is abstracted through virtualization, and how organizations select among infrastructure, platform, software, and function services. It also introduces regions, availability zones, elasticity, scalability, multitenancy, consumption pricing, deployment models, and the shared-responsibility model.

Learning Objectives

From Traditional Hosting to Cloud-Native Delivery

Early web applications were commonly deployed on a physical server in an organization’s premises or in a colocation facility. The organization purchased hardware, installed an operating system, configured networking, and assigned administrators to maintain the environment. Capacity planning was performed in advance. If demand increased beyond the capacity of the server, acquiring and installing additional hardware could take weeks.

Virtual private servers improved utilization by allowing multiple virtual machines to run on one physical host. Hosting companies could therefore offer customers isolated environments without dedicating an entire physical machine to each customer. However, customers still often managed operating-system updates, application runtimes, backups, and scaling procedures themselves.

Cloud computing extended this model through large, automated pools of computing, storage, and networking resources. A customer can request resources through a web console, command-line tool, or application programming interface (API). Provisioning can occur in minutes or seconds, and resources can be released when they are no longer needed. Cloud providers also expose managed databases, queues, identity systems, monitoring platforms, and deployment pipelines.

Cloud-native delivery is the organizational and technical progression beyond simply moving an existing server to a cloud data center. Cloud-native systems commonly emphasize:

Cloud-native does not mean that every application must use microservices or containers. A well-designed monolith deployed automatically to a managed platform can be more appropriate than a poorly designed collection of microservices.

Essential Cloud Terminology

Cloud computing is a model that provides convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with limited direct management effort. This definition highlights self-service, resource pooling, elasticity, network access, and measured usage.

A workload is a set of computational tasks and associated data, such as a web application, database, or batch process. A resource is a consumable technical capability, including CPU capacity, memory, storage, network bandwidth, or a managed database instance.

A provider operates the cloud infrastructure and services. A tenant is a customer or organizational unit using shared provider resources. A deployment is a particular released version of an application and its configuration. An environment is a context such as development, testing, staging, or production.

An API enables software to request or control cloud resources programmatically. Infrastructure as code (IaC) represents infrastructure configuration in version-controlled files, making environments more reproducible. Observability is the ability to infer a system’s internal condition from outputs such as logs, metrics, and traces.

Virtualization and Resource Abstraction

Virtualization separates the logical view of computing resources from their physical implementation. A hypervisor, also called a virtual machine monitor, allocates hardware resources to virtual machines (VMs). Each VM can run an operating system and applications as though it were a separate computer.

Virtualization provides isolation, improved hardware utilization, and flexible provisioning. A cloud provider can move, start, stop, or replicate VMs through software. Nevertheless, virtualization is not perfect isolation. VMs share physical hardware, and failures or resource contention at the host level can affect performance. Security depends on the correct implementation of the hypervisor and the provider’s operational controls.

Containers provide a lighter abstraction. A container packages an application and its dependencies while sharing the host operating-system kernel with other containers. Containers generally start faster and require fewer resources than full VMs, but they do not eliminate the need for secure isolation. Container images must be patched, scanned, and obtained from trustworthy sources.

Serverless computing is another abstraction. The customer submits code or uses a managed service without managing servers directly. “Serverless” does not mean that servers do not exist; it means that server operation is largely hidden from the customer.

Regions, Availability Zones, and Fault Domains

A region is a geographical area containing one or more data centers or groups of data centers operated as a cloud location. An availability zone (AZ) is an isolated location within a region, designed to reduce the likelihood that a local failure affects all zones. Exact terminology and architecture vary by provider.

Choosing a region involves latency, legal requirements, service availability, disaster-recovery objectives, and price. A region closer to users usually reduces network latency, but data-residency rules may require information to remain within a particular country or economic area.

Deploying application instances across multiple availability zones can reduce dependence on a single facility. However, multi-zone deployment does not automatically guarantee availability. The application must also use redundant data storage, health checks, load balancing, safe deployment procedures, and recovery processes.

Availability is often expressed as a proportion of time during which a service is operational. If a service has uptime U over an observation period T, its unavailable time is:

Here, D is downtime, T is total time, and U is expressed as a decimal. For example, over a 30-day month, availability of 99.9% gives:

This calculation assumes continuous measurement and that the stated availability applies to the entire period. Service-level agreements may define measurement exclusions, maintenance windows, and different calculation rules.

Availability is not the same as reliability or durability. Availability concerns whether a service can be accessed. Reliability concerns failure-free operation over time. Durability concerns the probability that stored data will not be lost.

Service Models

Cloud service models describe how responsibility is divided between the provider and customer. The boundaries are not identical across providers, but the models are useful for comparison.

Model	Provider commonly manages	Customer commonly manages	Typical use
IaaS	Physical facilities, hardware, virtualization	Operating system, runtime, application, much configuration	Custom servers and networks
PaaS	Infrastructure, operating system, runtime platform	Application code, data, configuration	Web and API deployment
SaaS	Application and underlying platform	Users, data, configuration, access policies	Email, collaboration, CRM
FaaS	Infrastructure, runtime execution environment	Function code, event logic, permissions	Event-driven tasks

Infrastructure as a Service

IaaS provides virtual machines, block storage, virtual networks, firewalls, and related infrastructure. It offers substantial control and supports legacy or specialized workloads. The trade-off is operational responsibility. The customer must address operating-system patching, capacity configuration, hardening, backups, and much of the runtime stack.

Platform as a Service

PaaS provides a managed environment in which developers deploy application code without managing the underlying servers. A PaaS may manage the operating system, language runtime, routing, process supervision, deployment workflow, and scaling controls. Heroku is a familiar example of a developer-oriented PaaS. PaaS can increase productivity, although it may impose platform constraints and create migration costs if proprietary features are heavily adopted.

Software as a Service

SaaS delivers a complete application through a browser, mobile client, or API. The provider operates the application and infrastructure. Customers remain responsible for account administration, access control, appropriate data use, and organizational configuration. Using a SaaS product reduces infrastructure work but does not remove governance responsibilities.

Function as a Service

FaaS executes short-lived functions in response to events such as HTTP requests, file uploads, messages, or scheduled triggers. Billing is commonly associated with invocations and execution duration, although exact pricing varies. FaaS is useful for event processing and intermittent workloads, but developers must consider startup latency, execution limits, statelessness, observability, and distributed-system complexity.

Deployment Models

A public cloud is operated by a provider and shared among multiple customers. It offers rapid provisioning and broad service availability. A private cloud is dedicated to one organization, either on premises or operated by a third party. It can support specialized governance requirements but usually requires greater investment and operational expertise.

A hybrid cloud combines private infrastructure with public-cloud services. For example, a company may retain a regulated database privately while using public cloud resources for web traffic. Hybrid designs introduce integration, identity, networking, monitoring, and data-movement complexity.

A community cloud is shared by organizations with common requirements, such as regulatory or mission-specific needs. In practice, public, private, and hybrid arrangements are more common, and the meaning of “community cloud” depends on the provider and governance structure.

Multicloud means using services from multiple public-cloud providers. It may improve negotiating leverage or provide access to specialized services, but it can also increase complexity in identity, networking, deployment automation, skills, and monitoring. Multicloud should be adopted for a specific benefit rather than as an automatic sign of architectural maturity.

Scalability and Elasticity

Scalability is the ability of a system to handle increased workload by adding resources or improving resource efficiency. Vertical scaling increases the capacity of an existing instance, such as adding memory or CPU. Horizontal scaling adds more instances and distributes work among them.

Elasticity is the ability to adjust capacity dynamically as demand changes. A system can be scalable without being elastic if it can grow only through manual intervention. Elasticity is valuable when demand is variable, but automatic scaling requires accurate signals, safe limits, and sufficient time to provision resources.

A stateless web tier is generally easier to scale horizontally because any instance can handle a request. Session data should therefore be stored in a shared data store or represented using carefully protected tokens rather than kept only in local process memory. Databases, file systems, queues, and third-party dependencies may become bottlenecks even when the web tier scales successfully.

A useful conceptual measure is speedup. If a workload takes time T₁ on one resource and T_n on n resources, speedup is:

This formula is descriptive, not a guarantee. Real systems experience coordination overhead, serial work, network latency, contention, and service limits. Consequently, doubling instances rarely produces exactly double performance.

Multitenancy and Isolation

Multitenancy occurs when multiple customers use shared application or infrastructure resources while their data and permissions remain logically separated. It is a central economic principle of public cloud computing because sharing improves utilization and reduces the cost per customer.

Isolation can exist at several levels: separate accounts, virtual networks, VMs, containers, database schemas, or application records. Stronger physical separation may improve isolation but reduce utilization and increase cost. Logical isolation requires correct authorization checks, tenant identifiers, encryption practices, testing, and monitoring.

A common application-level pattern is to include a tenant identifier with every data access and enforce it through centralized authorization controls. Developers must not rely solely on a user-supplied tenant identifier. The server should derive the permitted tenant context from authenticated identity and enforce it consistently.

Consumption-Based Pricing

Cloud pricing commonly charges for resources consumed rather than requiring a large upfront purchase. Charges may include compute time, storage capacity, database usage, requests, data transfer, licenses, and support. The exact unit and billing granularity differ by service.

Each term represents a category of cost over a defined billing period. This is an analytical model, not a universal provider invoice. Taxes, discounts, reservations, minimum charges, and free tiers may alter the actual amount.

Consumption pricing aligns cost with usage and enables experimentation. It can also produce unexpected bills when resources are left running, data transfer is excessive, logs grow without limits, or an automated process makes excessive requests. Cost management therefore includes budgets, alerts, tagging, rightsizing, lifecycle policies, and regular review.

The economic distinction between fixed and variable cost is important. A traditional data center may require substantial capital expenditure before demand is known. Cloud services often convert more expenditure into operating cost, although organizations can still make long-term commitments through reserved capacity or enterprise agreements.

The Shared-Responsibility Model

Cloud security is a shared responsibility. The provider is generally responsible for security of the cloud: physical facilities, hardware, core networking, and managed-service foundations. The customer is generally responsible for security in the cloud: identities, permissions, application code, data classification, secrets, and configuration. The precise boundary depends on the service model.

Concern	IaaS customer responsibility	PaaS customer responsibility	SaaS customer responsibility
Physical data center	Provider	Provider	Provider
Operating system	Customer	Usually provider	Provider
Application code	Customer	Customer	Provider
Identity and access	Customer	Customer	Customer configuration
Data classification and use	Customer	Customer	Customer
Network configuration	Shared, often customer-led	Partly abstracted	Provider-led, customer policies

The model is not an excuse to transfer accountability. A provider may secure the platform, but an exposed storage bucket, excessive administrator permissions, vulnerable dependency, or leaked API key remains a customer problem. Security best practices include least privilege, multifactor authentication, encryption in transit and at rest, secret management, patching where applicable, centralized logging, vulnerability scanning, backups, and tested recovery procedures.

Privacy and regulatory responsibilities must also be considered. Organizations may need to address data residency, retention, breach notification, access by subprocessors, audit evidence, and sector-specific obligations. Legal compliance cannot be inferred solely from a provider’s marketing claims; it requires organizational assessment and appropriate contractual and technical controls.

Deployment and Delivery Practices

A modern deployment pipeline commonly moves code through source control, automated tests, artifact creation, security checks, staging, approval or automated promotion, and production monitoring. Continuous integration frequently means merging and testing changes regularly. Continuous delivery means keeping software in a releasable state. Continuous deployment automatically releases qualifying changes to production.

Configuration should be separated from application code. Environment variables or managed configuration systems can hold non-secret settings, while secrets should be stored in dedicated secret-management systems rather than committed to repositories. Production and development environments should be sufficiently similar to reduce deployment surprises, but access and data must be appropriately separated.

A release strategy should support rollback or forward correction. Blue-green deployment maintains two production environments and shifts traffic between them. Canary deployment exposes a new version to a small proportion of users before wider release. Rolling deployment replaces instances gradually. Each strategy has different cost, complexity, and risk characteristics.

Illustrative Case: Deploying a Student Marketplace

Background

A fictional university team develops a marketplace where students list used textbooks. The application contains a web front end, an API, a relational database, image uploads, and email notifications.

Problem

During the semester, traffic is moderate. At the beginning of term, usage increases sharply. The team initially stores uploaded images on the application server and keeps user sessions in local memory. Deployments require manually logging into the server. A single-server failure causes downtime, and developers cannot reliably reproduce the production environment.

Analysis

The local image directory is unsuitable for horizontal scaling because different instances may not contain the same files. Local sessions create a similar problem: a request routed to another instance may not find the session. Manual deployment creates configuration drift and makes rollback difficult. The expected traffic pattern indicates a need for elasticity, but the database and image-storage design may become bottlenecks.

Approach

The team deploys the stateless web and API processes on a PaaS. Images are placed in object storage, and the database is provided as a managed relational service with automated backups. Session state is moved to a shared store or replaced with carefully designed signed tokens. Source control triggers automated tests and creates a reproducible release artifact. Environment-specific configuration is injected during deployment, and secrets are stored separately.

A load balancer distributes requests across multiple application instances. Health checks remove unhealthy instances. The team defines monitoring for request latency, error rate, database connections, storage usage, and queue depth. Autoscaling is enabled with conservative limits and tested against realistic load. A staging environment is used before production release, and a rollback procedure is documented.

Outcome

The application can add instances during term-start demand and reduce them afterward. A failed application instance no longer causes complete service interruption. Deployments are repeatable, and image data persists independently of application processes. Costs become more variable, so the team adds budgets and alerts. The database remains a carefully monitored shared dependency rather than assuming that scaling the web layer solves every problem.

Learning Points

The case demonstrates that cloud adoption is an architectural change, not merely a server relocation. Stateless design, managed services, automation, observability, security, and cost controls must be considered together. The correct solution is not necessarily the most distributed design; it is the simplest design that satisfies availability, performance, security, and operational requirements.

Limitations and Critical Considerations

Cloud platforms provide flexibility but introduce dependence on providers, network connectivity, service limits, regional outages, and proprietary interfaces. Abstraction reduces operational burden but can reduce visibility and control. Managed services may simplify operations while increasing switching costs.

Cloud migration can also fail when organizations move poorly designed systems without revising assumptions. A vertically scaled legacy application may work in the cloud but produce high cost and limited resilience. Conversely, premature adoption of microservices, containers, or complex orchestration can increase failure modes and staffing requirements.

Teams should evaluate workload suitability, latency, compliance, data gravity, recovery objectives, skills, provider maturity, exit strategy, and total cost. A workload should not be judged only by hourly compute price. Engineering time, data transfer, support, security controls, downtime risk, and migration effort are part of the total economic decision.

Contemporary Developments

Cloud delivery increasingly incorporates containers, managed Kubernetes, event-driven architecture, edge computing, platform engineering, and infrastructure automation. Artificial-intelligence services are also commonly consumed through cloud APIs. These developments increase capability but introduce concerns about data protection, model-provider dependence, inference cost, explainability, and the accuracy of automated outputs.

Platform engineering teams increasingly build an internal developer platform that provides approved deployment paths, templates, observability, security defaults, and self-service environments. This approach aims to reduce cognitive load for application developers while preserving organizational governance.

The central professional skill remains systems thinking. Developers must understand not only how to write code, but also how code behaves under failure, load, changing configuration, security threats, and financial constraints.

Best-Practice Checklist

Chapter Summary

Cloud computing provides on-demand access to pooled computing resources through self-service interfaces and measured usage. Its foundations include virtualization, resource abstraction, automation, multitenancy, elasticity, and distributed infrastructure. Regions provide geographical placement, while availability zones provide isolated failure domains within a region.

IaaS offers control over virtual infrastructure; PaaS abstracts much of the operational platform; SaaS delivers complete applications; and FaaS runs event-driven functions without direct server management. Public, private, hybrid, community, and multicloud arrangements represent different ownership and governance choices.

Scalability concerns a system’s ability to handle greater workload, whereas elasticity concerns dynamic adjustment of capacity. Consumption pricing creates flexibility but requires financial governance. The shared-responsibility model clarifies that providers and customers have different security obligations. Finally, cloud-native delivery combines automation, reproducibility, observability, resilient design, and continuous delivery. Effective cloud engineering balances technical capability with security, compliance, reliability, simplicity, and cost.

Key Terms

Cloud computing: On-demand access to shared, configurable computing resources over a network.

Virtualization: Abstraction of physical computing resources into logical environments such as virtual machines.

Virtual machine: A software-defined computer running an operating system on virtualized hardware.

Container: An isolated application environment that shares the host operating-system kernel.

Region: A geographical cloud-provider location containing one or more infrastructure sites.

Workload: An application, service, or processing task together with its required resources.

IaaS: Infrastructure as a Service, providing virtualized computing, storage, and networking.

PaaS: Platform as a Service, providing a managed application execution platform.

SaaS: Software as a Service, providing a complete application managed by a provider.

FaaS: Function as a Service, executing event-triggered functions on managed infrastructure.

Scalability: The ability to handle increased workload by adding capacity or improving efficiency.

Multitenancy: Shared use of resources by multiple customers with logical separation.

Shared responsibility: Division of security and operational duties between provider and customer.

Infrastructure as code: Declarative or programmatic management of infrastructure through version-controlled definitions.

Observability: The ability to understand internal system behavior through logs, metrics, and traces.

Cloud-native: An approach emphasizing automation, resilience, reproducibility, and managed or distributed services.

Review Questions

Short Answer Questions

Long Answer Questions

Analytical / Application Questions

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes cloud computing from traditional fixed-capacity hosting?

Question 2

Correct Answer: B. To isolate infrastructure failure domains within a region

Question 3

Which service model generally gives the customer responsibility for the operating system?

Question 4

Question 5

In the shared-responsibility model, which item is normally the customer’s responsibility?

Question 6

Why can storing uploaded files only on an application instance create a problem?

Correct Answer: B. Files may not be available when another instance receives the request

Question 7

A service has 99.9% availability over a 30-day month. Approximately how much downtime does this represent?

Question 8

Question 9

Correct Answer: C. It can increase integration, skills, and monitoring complexity

Question 10

Which deployment model combines private infrastructure with public-cloud services?

Chapter 1 Cloud Computing and Deployment Foundations

Cloud Computing and Deployment Foundations

Introduction