Cloud, DevOps and Web Delivery

Introduction

Modern web applications are delivered through a chain of activities that begins with source code and ends with a reliable service used by people, businesses, and other systems. That chain includes version control, dependency and package management, automated testing, image construction, infrastructure provisioning, deployment, monitoring, and controlled change management. Cloud platforms provide computing, storage, networking, databases, identity services, and managed execution environments; DevOps provides the practices and culture for delivering software quickly and safely; web-delivery technologies determine how users receive content from regions, data centres, edge locations, or serverless runtimes.

The objective of this chapter is to explain how these elements work together across development, testing, staging, and production. The emphasis is not on one vendor, but on transferable principles that apply to public cloud, private cloud, hybrid infrastructure, serverless platforms, and edge networks.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the relationship between version control, package management, containers, cloud infrastructure, and CI/CD.
2. Compare virtual machines, containers, serverless functions, and edge execution.
3. Design a basic deployment architecture for a web application.
4. Construct a pipeline that validates, packages, scans, and deploys software safely.
5. Distinguish development, testing, staging, and production environments.
6. Apply principles of observability, security, reliability, cost control, and rollback.
7. Evaluate contemporary delivery approaches and their limitations.

1. From Source Code to a Running Web Service

A production web application is more than a collection of source files. It depends on a runtime, libraries, configuration, a database or other persistence service, network access, identity controls, and operational procedures. A useful delivery model is:

Plan → Code → Build → Test → Package → Release → Deploy → Operate → Observe → Improve

This is a continuous loop rather than a one-time sequence. Operational evidence can reveal a performance defect; that evidence informs a code change; the change passes through the same controlled pipeline.

1.1 Version control

Version control records changes to source code and related artefacts. Distributed systems such as Git give every repository clone a history of commits. A commit should represent a coherent, reviewable change. Branches may support parallel work, while pull or merge requests provide review, automated checks, and an auditable decision to integrate code.

Important practices include:

• keep commits small and meaningful;
• protect the main branch;
• require review and automated checks before merging;
• tag released versions;
• never commit passwords, private keys, or production tokens;
• define ownership for critical directories and infrastructure files.

A release should be traceable from a deployed service back to a commit, its build logs, dependency versions, security results, and deployment approval.

1.2 Package management and reproducibility

Applications depend on packages such as web frameworks, database drivers, compilers, and testing libraries. A package manager resolves, downloads, verifies, and records these dependencies. A manifest states direct dependencies; a lockfile records the resolved dependency graph, including transitive dependencies.

The distinction matters. If a manifest permits a version range, two builds performed at different times may resolve different packages. A lockfile makes the resolution reproducible, although operating-system images, compilers, external services, and package repositories must also be controlled.

Good practice includes using private registries where appropriate, checking package provenance, reviewing licences, updating dependencies regularly, and removing unused packages. Dependency confusion, typosquatting, malicious maintainers, and vulnerable transitive packages are supply-chain risks.

2. Cloud Service Models and Infrastructure

Cloud computing supplies resources on demand through programmable interfaces. The main service models are:

The shared-responsibility model is essential. A provider may secure the physical data centre and hypervisor, while the customer remains responsible for identity permissions, application vulnerabilities, data classification, and secure configuration. The exact boundary varies by service.

2.1 Infrastructure as Code

Infrastructure as Code (IaC) expresses networks, compute resources, permissions, databases, and monitoring configuration in reviewable files. Declarative IaC describes the desired state; a tool calculates and applies the required changes. Imperative scripts instead describe a sequence of commands.

IaC improves repeatability and enables infrastructure review, testing, and recovery. State management must be handled carefully: state files can contain sensitive information and must be stored securely with access control, encryption, locking, and backup. Separate accounts, subscriptions, or projects for environments reduce accidental production changes.

2.2 Configuration and secrets

Configuration includes values that vary by environment, such as service endpoints, feature flags, and resource sizes. Secrets include passwords, API tokens, private keys, and signing credentials. Configuration should be injected at deployment or runtime rather than hard-coded into source code or container images. Secrets should be stored in a dedicated secret-management service, rotated, audited, and granted according to least privilege.

A useful rule is: build once, configure per environment. Rebuilding separately for staging and production can create different binaries and undermine confidence in testing.

3. Execution Models: Virtual Machines, Containers, Serverless and Edge

Virtual machines

A virtual machine (VM) emulates a complete computer through a hypervisor. It contains a guest operating system and therefore provides strong isolation and broad compatibility, but it consumes more resources and starts more slowly than a container.

Containers

A container packages an application and its user-space dependencies while sharing the host kernel. A container image is an immutable set of layers identified by a content digest or tag. A container is a running instance of an image, normally treated as replaceable rather than as a permanent server.

A robust image commonly uses a small trusted base image, a multi-stage build, a non-root user, a fixed dependency lockfile, and no embedded secrets. Image labels should record source revision and build information. Tags such as latest are convenient but mutable; production deployments should preferably refer to immutable digests.

Containers do not automatically provide complete security isolation. A vulnerable image, excessive Linux capabilities, an exposed socket, or a compromised host can create serious risk. Runtime policies, network restrictions, resource limits, image scanning, and timely patching remain necessary.

Serverless functions

Serverless functions execute in response to events such as HTTP requests, queue messages, file uploads, or scheduled timers. The platform handles much of the provisioning and scaling. Functions are attractive for intermittent workloads and small event handlers, but they may have startup latency, execution-duration limits, platform-specific interfaces, and more complex distributed tracing.

Edge delivery and edge computing

A content delivery network (CDN) caches static content at geographically distributed points of presence. An edge function may execute logic near users, for example for URL rewriting, authentication decisions, personalisation, or header manipulation. Edge execution can reduce latency, but it introduces restrictions on available runtimes, data locality, debugging, and consistency.

The best execution model depends on workload characteristics, operational capability, compliance requirements, and cost—not on novelty alone.

4. Environments and Promotion

A controlled delivery system separates environments while keeping them sufficiently similar to reduce surprises.

• Development supports rapid local experimentation.
• Testing or integration validates interactions among components.
• Staging or pre-production approximates production and supports final verification.
• Production serves real users and requires the strongest controls.

Environment separation can involve distinct cloud accounts, projects, networks, databases, identities, and secrets. Developers should not normally have unrestricted production access. Production data should not be copied into lower environments without lawful justification, minimisation, masking, and access controls.

Promotion means moving the same tested artefact through environments. A deployment record should include artefact identity, environment, actor or automation identity, time, configuration version, test results, approval, and rollback information.

5. CI/CD Pipeline Design

Continuous Integration (CI) means that changes are integrated frequently and automatically validated. Continuous Delivery means that validated software is always kept in a releasable state. Continuous Deployment extends this idea by automatically releasing eligible changes to production.

A representative pipeline is:

1. A developer creates a branch and commits code.
2. A pull request triggers formatting, linting, unit tests, dependency checks, and secret scanning.
3. After review, the code is merged.
4. The pipeline builds a versioned artefact or container image.
5. Integration, contract, and security tests run against controlled services.
6. The artefact is stored in a registry.
7. It is deployed to staging and subjected to smoke and acceptance tests.
8. A policy determines whether automatic or approved production deployment is permitted.
9. Monitoring evaluates the release; the system promotes, pauses, or rolls back it.

Pipeline stages should fail early on inexpensive checks and reserve slow tests for later stages. However, speed must not be achieved by omitting tests that detect high-impact defects.

5.1 Testing strategy

Unit tests examine small components in isolation. Integration tests evaluate communication with databases, queues, or external services. Contract tests verify that service interfaces remain compatible. End-to-end tests simulate important user journeys. Static analysis examines code without executing it; dynamic testing examines running software. Security testing may include dependency scanning, software composition analysis, secret detection, container scanning, and controlled penetration testing.

No single test type proves correctness. A balanced test suite provides rapid feedback while covering business-critical behaviour, failure paths, accessibility, security, and performance.

5.2 Deployment strategies

A rollback is not always as simple as starting an older application. Database schema changes may be irreversible, messages may have changed format, and external side effects may already have occurred. Backward-compatible migrations and explicit recovery plans are therefore important.

6. Web Delivery Architecture

A common architecture places a DNS service and CDN in front of a load balancer or managed web gateway. Static assets may be stored in object storage and cached at the CDN. Dynamic requests are routed to containers, VMs, or serverless functions. Data services remain behind private network boundaries whenever possible.

Caching requires deliberate design. Cache keys, time-to-live values, invalidation, privacy, and content versioning must be considered. Fingerprinted assets such as app.8f3a.js can receive long cache lifetimes because a new filename represents new content. Personal or confidential responses must not be cached publicly unless the policy is demonstrably safe.

Transport security should use HTTPS, modern TLS configuration, secure cookies, appropriate security headers, and careful certificate management. Authentication and authorisation are different: authentication identifies a principal, while authorisation determines what that principal may do.

7. Observability, Reliability and Performance

Observability combines logs, metrics, traces, and contextual events. Logs record detailed events; metrics provide numerical time-series measurements; traces show a request’s path across services. Correlation identifiers allow an operator to connect these views.

Useful service-level indicators (SLIs) include availability, latency, error rate, throughput, and queue age. A service-level objective (SLO) states a target, such as the percentage of valid requests completed successfully within a specified latency threshold during a period. An error budget is the permitted unreliability implied by the SLO. If the budget is exhausted, an organisation may pause risky releases and prioritise reliability work.

For an availability calculation, under the simple assumption that downtime is the only unavailability during a measurement period:

Both time values must use the same unit and period. For example, if a 30-day period contains 43,200 minutes and 30 minutes of downtime, availability is:

This calculation does not by itself describe partial failures, degraded performance, or the validity of the monitoring method. Those conditions require an explicitly defined measurement policy.

Performance analysis should consider the whole request path: DNS, connection setup, TLS, CDN cache behaviour, application processing, database access, and response transfer. Horizontal scaling adds instances; vertical scaling adds resources to an instance. Autoscaling policies should use meaningful signals and should not oscillate because of noisy measurements.

8. Security, Governance and Responsible Operation

Cloud delivery expands the number of programmable controls and therefore the number of possible misconfigurations. Core controls include least-privilege identity, multi-factor authentication, network segmentation, encryption in transit and at rest, centralised audit logs, vulnerability management, backup testing, and incident response procedures.

A secure software supply chain should establish where dependencies and base images originate, how they are verified, and who may publish release artefacts. Build systems should be isolated from untrusted pull-request code when necessary, and deployment credentials should be short-lived and narrowly scoped.

Governance includes data protection, retention, residency, accessibility, licensing, auditability, and contractual obligations. Regulations vary by jurisdiction and sector; technical teams must work with legal, security, and compliance specialists rather than assuming that a cloud provider automatically satisfies every obligation.

Ethical concerns include excessive collection of personal data, opaque automated decisions, unequal service performance across regions, energy consumption, and the consequences of outages. Reliability and privacy are not merely technical conveniences when web services support education, health, finance, or public administration.

9. Cost and Capacity Reasoning

Cloud billing commonly combines compute time, storage, data transfer, managed-service operations, and reserved or committed capacity. A simple monthly estimate can be expressed as:

Here, quantity_i is the consumed quantity of resource category i, and unit price_i is its price in the applicable currency per unit. The estimate assumes prices, usage, discounts, taxes, and exchange rates are known and stable; real invoices may include tiered pricing and minimum charges.

Cost optimisation should follow measurement. Removing idle resources, selecting suitable instance sizes, using lifecycle policies for storage, caching repeated content, and controlling data transfer can reduce waste. A cheaper architecture that increases outages, engineering effort, or security exposure may have a higher total cost of ownership.

10. Illustrative Case: Deploying a University Course Platform

Background

A university has a course platform containing a static student portal, an API for enrolments, a relational database, and a document-upload service. Traffic is modest during most weeks but rises sharply before examinations. The existing application runs on one manually configured server.

Problem

Releases require an administrator to copy files to the server. Configuration differs between testing and production. A failed release is difficult to reverse, backups have not been restored in a test, and a database password appears in a deployment script. Examination-period traffic has caused slow responses.

Analysis

The main risks are operational inconsistency, single-server failure, credential exposure, and insufficient capacity planning. The application does not initially require a complex microservice redesign. A managed relational database, object storage, CDN, and two or more replaceable application instances provide a more proportionate improvement.

Approach and solution

The team adopts Git with protected main-branch rules and pull-request review. Dependencies are recorded with a lockfile. A multi-stage container build creates an image tagged with the commit identifier and stored in a private registry. The image runs as a non-root user and receives configuration from an environment-specific secret service.

IaC defines the network, load balancer, application service, database, object-storage bucket, monitoring, and access policies. Development, staging, and production use separate accounts or projects. Synthetic test data is used outside production.

The CI pipeline runs unit, integration, dependency, secret, and image scans. The same image is deployed to staging and then to production using a canary strategy. The canary is evaluated using error rate, latency, and application-specific enrolment checks. A database migration is designed to be backward compatible: new fields are added before application code begins relying on them. Backups are automated, and a restoration exercise is scheduled.

Static assets use content-hashed filenames and CDN caching. Uploaded documents are stored privately and accessed through short-lived authorised links. Multi-factor authentication and least-privilege roles protect administrative access.

Outcome

Releases become repeatable and auditable. The platform can add application instances during examination traffic, while the CDN reduces repeated delivery from the application tier. The team can identify which version is running and can stop a canary without replacing the entire service. Remaining risks include database capacity, third-party availability, and the need to maintain pipeline credentials and dependency updates.

Learning points

The case demonstrates that DevOps is not synonymous with a particular cloud product. The improvement comes from traceability, automation, environment discipline, secure configuration, replaceable infrastructure, observable releases, and tested recovery. Architecture should match the problem: managed services and containers are useful because they reduce operational burden, not because every application needs maximum distribution.

11. Contemporary Developments and Limitations

Platform engineering teams increasingly provide internal templates, approved pipeline components, service catalogues, and standard observability. This can improve developer productivity, but a platform becomes a bottleneck if it hides important trade-offs or cannot accommodate legitimate requirements.

Software supply-chain frameworks increasingly emphasise signed artefacts, provenance, reproducible builds, and policy enforcement. Artificial intelligence can assist with log summarisation, test generation, anomaly detection, and configuration review. It should not be treated as an autonomous authority: generated code and operational recommendations require human review, testing, privacy assessment, and clear accountability.

Multi-cloud adoption may reduce dependence on one provider or satisfy regulatory needs, but it also increases complexity in identity, networking, monitoring, skills, and data movement. Edge computing can improve latency but may complicate consistency and debugging. Serverless can reduce infrastructure management but may create vendor dependence and unexpected costs under high invocation volume.

The central limitation of automation is that it automates decisions encoded by people. A fast pipeline can deploy insecure or incorrect software faster. Controls must therefore be risk-based, observable, and continuously improved.

Best Practices Checklist

• Store all application and infrastructure changes in version control.
• Use lockfiles, trusted registries, dependency review, and routine updates.
• Build immutable, minimal images and avoid running as root.
• Separate environments, accounts, credentials, and data appropriately.
• Build once and promote the same artefact.
• Automate tests, security checks, approvals, and deployment records.
• Use progressive delivery for high-risk changes.
• Design database migrations and rollback procedures explicitly.
• Monitor user-facing indicators, not only infrastructure statistics.
• Test backups, restoration, incident response, and access revocation.
• Treat cost, privacy, accessibility, sustainability, and compliance as design concerns.

Chapter Summary

Cloud, DevOps, and web delivery form an integrated discipline for turning source code into reliable services. Version control provides history and collaboration; package management supports reproducible builds; containers and other execution models package or host workloads; cloud services supply programmable infrastructure; and IaC makes that infrastructure repeatable. CI/CD pipelines connect review, testing, security validation, artefact creation, deployment, and operational feedback.

Safe delivery depends on environment separation, immutable or traceable artefacts, least-privilege access, secret management, observability, progressive deployment, tested rollback, and explicit governance. VMs, containers, serverless functions, CDNs, and edge runtimes offer different trade-offs in isolation, scalability, latency, cost, and operational complexity. Effective professionals select among them according to requirements rather than fashion. Finally, automation must be combined with human accountability because reliability, security, privacy, accessibility, and ethical service delivery cannot be delegated entirely to tools.

Key Terms

Version control: A system for recording, reviewing, and managing changes to digital artefacts.

Commit: A recorded, identifiable set of changes in a version-control repository.

Package manager: A tool that resolves, installs, verifies, and records software dependencies.

Lockfile: A file that records exact or resolved dependency versions and their relationships.

Infrastructure as Code: Management of infrastructure through declarative or scripted files kept under version control.

Cloud computing: On-demand access to shared configurable computing resources through networks and programmable interfaces.

Container: An isolated process environment that packages an application and user-space dependencies.

Container image: An immutable packaged filesystem and metadata used to create containers.

Serverless: A cloud execution model in which the provider manages most server provisioning and scaling.

Edge computing: Processing or content delivery performed close to end users or data sources.

Continuous Integration: Frequent integration of code with automated validation.

Continuous Delivery: Keeping validated software ready for controlled release.

Continuous Deployment: Automatically releasing eligible changes to production.

Canary deployment: A release strategy that sends a limited proportion of traffic to a new version.

Observability: The ability to understand internal system behaviour through outputs such as logs, metrics, and traces.

Service-level objective: A stated target for a service indicator, such as availability or latency.

Infrastructure drift: Difference between declared infrastructure configuration and actual deployed state.

Least privilege: Granting only the access necessary for an identity or process to perform its task.

Content delivery network: A distributed network that caches and serves content near users.

Rollback: Returning a service or deployment to a previous known state or version.

Review Questions

Short Answer Questions

1. What is the purpose of a lockfile in package management?
2. Distinguish continuous delivery from continuous deployment.
3. Why should secrets not be stored in source code or container images?
4. State two differences between a virtual machine and a container.
5. What are logs, metrics, and traces used for in observability?

Long Answer Questions

1. Explain how version control, package management, containers, and CI/CD combine to produce a reproducible deployment.
2. Compare recreate, rolling, blue-green, canary, and feature-flag deployment strategies.
3. Discuss the shared-responsibility model and its implications for cloud security.
4. Design an environment and promotion strategy for a web application used by a university.
5. Explain why database migration design is important when rolling back application releases.

Analytical / Application Questions

1. A service operates for 43,200 minutes in a 30-day period and experiences 30 minutes of downtime. Calculate its availability and explain one limitation of this measure.
2. A team wants to move a single-server application directly to a complex multi-cloud microservice architecture. Analyse the technical and organisational risks and recommend a more proportionate migration path.
3. Design a canary-release decision policy using error rate, latency, security checks, and rollback criteria for an online examination platform.

Multiple Choice Questions with Answers

Question 1

Which artefact most directly improves reproducibility by recording resolved dependency versions?

A. A lockfile

B. A load balancer

C. A DNS record

D. A monitoring dashboard

Correct Answer: A. A lockfile

Question 2

Under the shared-responsibility model, which responsibility normally remains with the cloud customer?

A. Maintaining the provider’s physical data-centre building

B. Patching the provider’s hypervisor

C. Managing application permissions and secrets

D. Replacing failed provider-owned disks

Correct Answer: C. Managing application permissions and secrets

Question 3

What is the main characteristic of a canary deployment?

A. All users are immediately moved to the new version

B. A limited proportion of traffic initially uses the new version

C. The old version is permanently deleted before testing

D. The application is deployed without monitoring

Correct Answer: B. A limited proportion of traffic initially uses the new version

Question 4

Which practice best supports the principle ‘build once, configure per environment’?

A. Recompile the application separately in every environment

B. Store production passwords in the image

C. Promote the same immutable artefact and inject environment configuration

D. Allow developers to edit production files manually

Correct Answer: C. Promote the same immutable artefact and inject environment configuration

Question 5

A container image should preferably be identified in production by which property?

A. A mutable tag such as latest only

B. An immutable content digest

C. The developer’s username

D. The time of day it was deployed

Correct Answer: B. An immutable content digest

Question 6

Which statement correctly distinguishes authentication from authorisation?

A. Authentication identifies a principal; authorisation determines permitted actions

B. Authentication encrypts data; authorisation compresses data

C. Authentication creates backups; authorisation restores them

D. Authentication measures latency; authorisation measures throughput

Correct Answer: A. Authentication identifies a principal; authorisation determines permitted actions

Question 7

Using the chapter’s availability formula, what is the availability when total time is 43,200 minutes and downtime is 30 minutes?

A. 99.30%

B. 99.93%

C. 99.99%

D. 93.00%

Correct Answer: B. 99.93%

Question 8

Which execution model commonly responds to events while the provider manages most server provisioning and scaling?

A. Function as a Service

B. Bare-metal hosting managed entirely by the customer

C. A local text editor

D. A static Git branch

Correct Answer: A. Function as a Service

Question 9

Why are content-hashed static filenames useful for CDN delivery?

A. They allow changed content to receive a new cache key

B. They guarantee that private data is publicly cacheable

C. They eliminate the need for HTTPS

D. They prevent all application errors

Correct Answer: A. They allow changed content to receive a new cache key

Question 10

Which practice is most directly associated with least privilege?

A. Giving every developer administrator access

B. Using one shared production password

C. Granting each identity only the permissions required for its task

D. Disabling audit logs to reduce storage cost

Correct Answer: C. Granting each identity only the permissions required for its task