Deployment, Cloud and DevOps

Introduction

Deployment is the process of making a web application available to its intended users. It is not merely the final act of copying files to a server. A production deployment involves building software, configuring infrastructure, connecting domains, protecting traffic, managing secrets, observing behaviour, recovering from failure and controlling operating cost. Modern web applications may be deployed to a traditional web server, a virtual machine, a container platform, a public cloud, a serverless runtime or a content delivery network (CDN).

DevOps combines development and operations practices so that software can be delivered rapidly, reliably and repeatably. Its central idea is to treat application code, infrastructure configuration and operational procedures as managed, testable artefacts. Continuous integration and continuous delivery or deployment (CI/CD), infrastructure as code, automated testing, monitoring and incident response are practical expressions of this idea.

A useful deployment design balances four concerns: functionality, reliability, security and cost. A technically sophisticated architecture is not necessarily appropriate for a small application; conversely, a simple architecture may become inadequate when traffic, regulatory obligations or availability requirements increase.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain deployment architectures involving web servers, containers, cloud platforms, serverless services and CDNs.
2. Configure domains, DNS, TLS certificates, environments and secrets safely.
3. Design a basic CI/CD pipeline with testing, approval, rollback and observability.
4. Compare virtual machines, containers, managed platforms and serverless deployment.
5. Plan backups, recovery, infrastructure configuration and cost-aware operations.
6. Analyse deployment risks through an applied case.

1. Deployment as a Systems Process

A web application normally contains a client interface, application services, data stores, background workers and external services. Deployment must account for the interfaces among these components. For example, an application may serve HTML and JavaScript through a CDN, send API requests to an application service, and store data in a managed database. A deployment that updates only the application code but ignores database compatibility can cause failure.

A production release should therefore answer the following questions:

• What artefact is being released, and can it be identified by version?
• Which infrastructure and configuration does it require?
• How will it be tested before exposure to users?
• How can operators observe errors, latency and resource use?
• How will the system be restored if the release is defective?
• What data protection, privacy and access-control obligations apply?

Important terminology

A release is a version made available for deployment. A deployment is the act of installing or activating a release in an environment. An environment is a separately configured context such as development, testing, staging or production. An artefact is a packaged output, such as a container image or compiled application bundle. Provisioning creates infrastructure; configuration supplies environment-specific settings. Observability is the ability to infer internal system state from logs, metrics and traces.

2. Deployment Targets and Their Trade-offs

Traditional web servers

A web server such as Nginx or Apache can serve static files, terminate TLS, route requests and reverse-proxy traffic to an application process. A common arrangement places the web server at the public boundary and keeps application and database services on private network addresses.

This approach offers control and can be economical for small systems. However, the operator must manage operating-system updates, process supervision, firewall rules, certificates, scaling and backups. A single server also creates a potential single point of failure unless redundancy is introduced.

Virtual machines and managed compute

A virtual machine (VM) provides an isolated operating-system instance on cloud infrastructure. VMs support long-running processes and custom software, but they require more administration than higher-level services. Managed compute platforms may provide automated patching, load balancing and scaling while limiting operating-system control.

Containers

A container packages an application and its runtime dependencies into an immutable image. A container is not a complete virtual machine: it normally shares the host kernel while using process, filesystem and network isolation. Container images improve consistency between development, testing and production.

A container workflow commonly consists of:

1. A source repository containing application code and a container definition.
2. A build that creates a versioned image.
3. Security and functional tests.
4. Storage in a private image registry.
5. Execution by a container runtime or orchestrator.

Containers do not automatically make an application secure or highly available. Images must be updated, run with least privilege, scanned for vulnerabilities and prevented from containing secrets. Persistent data should generally be placed in a managed database or durable volume rather than relying on a container’s temporary filesystem.

Platform as a Service

A platform as a service (PaaS) abstracts servers and much of the operating system. Developers usually supply source code or an image, environment variables and scaling rules. The provider manages deployment machinery, routing and portions of the runtime. PaaS is productive for teams that value operational simplicity, but it may impose limits on networking, runtime versions, pricing or portability.

Serverless services

In a serverless model, the provider executes functions or services in response to requests, messages or scheduled events. Billing commonly depends on invocation and resource consumption, although exact pricing varies by provider. Serverless systems can scale rapidly and eliminate server administration, but they may experience startup latency, execution limits, provider coupling and more complex distributed debugging.

A serverless function should usually be stateless and idempotent: repeating the same event should not corrupt data or produce an unintended duplicate effect. Long-running work is better delegated to a queue and worker service where appropriate.

Content delivery networks

A CDN distributes cached content through geographically distributed edge locations. It is especially effective for images, stylesheets, JavaScript bundles, video segments and other static assets. A CDN reduces distance to users and decreases origin load. Dynamic content may also be accelerated, but caching must be designed carefully: private or user-specific responses must not be publicly cached.

Cache-control headers determine freshness and revalidation. A common strategy is content-addressed filenames such as app.8f31.js, allowing long cache lifetimes because a changed file receives a new name. Sensitive responses should use suitable directives such as private or no-store according to their requirements.

3. Domains, DNS and TLS

A domain name is mapped to network services through the Domain Name System (DNS). An A record maps a name to an IPv4 address; an AAAA record maps it to IPv6. A CNAME maps one name to another name, while MX records identify mail servers. DNS changes are distributed through caching, governed partly by the record’s time to live (TTL).

A typical web configuration might use example.com for the public site and api.example.com for an API. DNS alone does not prove that a server is authorised to represent the domain. TLS certificates provide authenticated encryption when a client connects using HTTPS. Certificate issuance normally verifies control of the domain, and automated renewal should be configured before expiration.

TLS provides confidentiality, integrity and server authentication when correctly implemented. Production applications should redirect HTTP to HTTPS, use secure protocol configurations, protect cookies with Secure and HttpOnly attributes where appropriate, and avoid mixed content. HSTS can instruct browsers to use HTTPS, but it should be introduced carefully because configuration errors can make recovery difficult.

TLS termination may occur at a CDN, load balancer, reverse proxy or application server. If traffic continues through an internal network after termination, the organisation must decide whether internal encryption is also required. The decision depends on threat models, regulatory obligations and network trust assumptions.

4. Environments, Configuration and Secrets

Separating environments reduces the risk that testing changes affect real users or production data. Development is optimised for rapid feedback; testing validates integration; staging resembles production; production serves users and requires strict controls.

The application binary or image should be the same wherever practical, while configuration varies by environment. Configuration includes service endpoints, feature flags, logging levels and resource identifiers. It should not be hard-coded into source code.

Secrets include passwords, API keys, private certificates and signing keys. They should be stored in a dedicated secret manager or protected CI/CD secret store, accessed by narrowly scoped identities and rotated periodically. Secrets must not be committed to repositories, written into public images or exposed in logs. A secret manager should also support audit records and controlled retrieval.

The principle of least privilege means that each identity receives only the permissions required for its task. A deployment identity may update one service but should not automatically have unrestricted access to every database and storage bucket. Production access should use multi-factor authentication, temporary credentials and auditable approval where feasible.

5. CI/CD and Release Strategies

Continuous integration (CI) automatically builds and tests changes as they enter a shared repository. Continuous delivery makes validated releases ready for production, usually requiring an approval. Continuous deployment automatically promotes qualifying releases to production.

A dependable pipeline commonly includes:

1. Source checkout and dependency installation.
2. Static analysis, formatting and dependency checks.
3. Unit and integration tests.
4. Build of a versioned artefact.
5. Vulnerability scanning and provenance recording.
6. Deployment to a temporary or staging environment.
7. Smoke tests and health checks.
8. Controlled production promotion.
9. Monitoring and, if necessary, rollback.

A pipeline should fail safely. Tests should not use production credentials, logs should redact secrets, and parallel jobs should not create conflicting database migrations. Branch protection, code review and signed or traceable artefacts improve accountability.

Deployment strategies

A recreate deployment stops the old version before starting the new one. It is simple but causes downtime. A rolling deployment gradually replaces instances. It reduces disruption but requires compatibility between versions. A blue-green deployment maintains two environments, switches traffic to the new one and retains the old environment for rapid reversal. It can require temporary double capacity.

A canary deployment exposes a small percentage of traffic to the new version. Operators compare error rates, latency and business indicators before expanding exposure. A feature flag separates code deployment from feature activation, allowing controlled release, experimentation or rapid disablement. Flags must be governed and removed when obsolete.

Rollback is not always a complete solution. If a release has changed a database schema incompatibly, returning to the old application may fail. Database changes should use an expand-and-contract approach: first add backward-compatible structures, then deploy code that uses them, migrate data, and only later remove obsolete structures.

6. Reliability, Backups and Recovery

Availability is the proportion of time a service is usable according to a defined measurement period. If a service is unavailable for 43.2 minutes in a 30-day month, its approximate availability is:

Here, both time values must use the same unit. The calculation is an approximation when maintenance windows, partial outages or measurement boundaries are treated differently. A target of 99.9% availability permits approximately 43.2 minutes of unavailability in a 30-day month, because 30 × 24 × 60 × 0.001 = 43.2 minutes.

A recovery point objective (RPO) states the maximum acceptable amount of data loss measured in time. An RPO of one hour implies that recovery should lose no more than approximately one hour of updates. A recovery time objective (RTO) states the target time to restore service. These are business requirements, not merely technical settings.

Backups should be automated, encrypted, access-controlled and tested through restoration exercises. The 3-2-1 principle recommends at least three copies, on two types of storage, with at least one copy off-site; it is guidance rather than a guarantee. Backups must be protected from accidental deletion and ransomware, and retention should reflect legal and business requirements.

High availability uses redundancy, health checks, load balancing, replication and failure isolation. Redundancy without independent failure domains may create only the appearance of resilience. A database replica, for example, may fail with its primary if both share the same zone or faulty deployment.

7. Infrastructure as Code and Operational Design

Infrastructure as code (IaC) defines networks, compute resources, permissions, databases and policies in version-controlled declarative files. It supports review, repeatability and disaster recovery. A safe IaC workflow uses separate state management, state locking, plan or preview steps, protected production accounts and controlled credentials.

Configuration drift occurs when real infrastructure differs from its declared configuration. Drift can arise from manual changes, emergency fixes or provider defaults. Teams should either prevent unauthorised changes or reconcile them deliberately. Manual emergency intervention should be documented and incorporated into IaC afterward.

Observability has three complementary forms:

• Logs record discrete events and diagnostic context.
• Metrics represent measured values such as request rate, latency, error count and CPU use.
• Traces follow a request across services and reveal where time is spent.

Health checks should distinguish liveness—whether a process is running—from readiness—whether it can safely receive traffic. Monitoring should produce actionable alerts rather than notifying operators about every harmless fluctuation. Useful service-level indicators include availability, latency and error rate. Service-level objectives define desired performance; an error budget represents the tolerated level of failure and helps balance release speed with reliability.

8. Cost-Aware Cloud Operations

Cloud cost is influenced by compute time, memory, storage capacity, database operations, network transfer, requests, managed-service tiers and support plans. A low unit price does not guarantee a low total cost. Unused development resources, excessive logs, cross-region traffic and oversized databases are common sources of waste.

Cost-aware practice includes tagging resources, assigning budgets and alerts, deleting unused environments, selecting suitable instance sizes, using autoscaling carefully and applying storage lifecycle policies. Autoscaling should be based on meaningful demand indicators and bounded by safe minimum and maximum values. It is not a substitute for performance testing.

Teams should compare total cost of ownership rather than only provider invoices. Administration time, migration risk, observability tools, backup storage and downtime consequences are also relevant. Cost reduction must not silently remove encryption, backups or necessary reliability controls.

9. Security, Governance and Ethics

Deployment security is a socio-technical problem. Technical controls include secure defaults, patching, dependency scanning, network segmentation, identity management, encryption, rate limiting and secret rotation. Governance controls include approvals, audit trails, separation of duties, incident procedures and documented retention.

Privacy laws and sector regulations may govern personal data, cross-border processing, retention and breach notification. Teams should minimise collected data, define its purpose, restrict access and delete it when no longer required. Logs can contain personal or confidential information and therefore require the same seriousness as application data.

Supply-chain security is increasingly important. A project may depend on packages, base images, build actions and third-party services. Pinning or carefully updating dependencies, generating a software bill of materials, verifying image provenance and reviewing transitive dependencies reduce risk. No tool eliminates the need for judgement.

Automation also creates ethical responsibilities. An automated deployment can spread a defect at high speed; an automated scaling policy can incur unexpected cost; and an AI-assisted coding tool may introduce insecure or licence-incompatible code. Human review, testing, ownership and rollback remain necessary. AI-generated infrastructure or application code should be treated as untrusted output until verified.

10. Illustrative Case: Deploying a University Course Portal

Background

A fictional university team has built a course portal that serves lecture materials, provides assignment submission and exposes an API for a mobile client. During the semester, usage is moderate, but assignment deadlines produce sharp traffic peaks. The team has three developers and no dedicated operations engineer.

Problem

The initial system runs on one manually configured VM. It has no tested backup, deployment requires SSH access, certificates are renewed manually and uploaded files are stored on the VM’s local disk. A defective release once caused a 40-minute outage.

Analysis

The single VM is a failure concentration. Local uploaded files are vulnerable to disk failure and make horizontal scaling difficult. Manual deployment is not reproducible, while unrestricted SSH access weakens accountability. The university also has privacy obligations because submissions may contain personal information.

Approach and solution

The team first defines requirements: an RTO of two hours, an RPO of one hour, HTTPS for all traffic, private storage for submissions and an auditable release process. It then adopts the following design:

• A CDN serves versioned static assets.
• A managed load balancer terminates TLS and routes requests to two application containers.
• The containers are built in CI, scanned and stored in a private registry.
• A managed relational database receives automated backups and point-in-time recovery where available.
• Assignment files move to encrypted object storage with restricted access and lifecycle rules.
• A queue handles email notifications so submission requests do not wait for email delivery.
• CI runs tests and deploys to staging; production uses a canary release with health checks.
• Secrets are stored in a secret manager, and deployment identities have limited permissions.
• Logs, metrics and traces are centralised; alerts monitor error rate, latency, storage failure and certificate expiry.

The database schema migration process uses backward-compatible additions first. The team performs a restoration exercise and records the actual recovery time rather than assuming the target has been achieved.

Outcome

The design removes dependence on a single application process, makes releases repeatable and separates durable files from ephemeral compute. It introduces additional cloud cost and operational concepts, but resource budgets and automatic shutdown of non-production environments control expenditure. Most importantly, reliability is treated as a tested property rather than a hopeful feature.

Learning points

The case demonstrates that deployment architecture should follow requirements. Containers alone do not solve backup, privacy or rollback problems. Managed services can reduce administrative work, but they still require configuration, monitoring and cost governance. A small team benefits from automation that removes repetitive risk, not from unnecessary architectural complexity.

11. Practical Deployment Checklist

Before production release, verify that:

• The artefact is versioned and reproducible.
• Tests, dependency checks and security scans have completed.
• Configuration is environment-specific and secrets are not in source control.
• DNS, TLS renewal and redirect behaviour have been tested.
• Health checks, logs, metrics and alerts are available.
• Database migrations are backward compatible or a tested recovery plan exists.
• Backups have been created and restoration has been exercised.
• Access uses least privilege and production changes are auditable.
• The deployment strategy and rollback trigger are explicit.
• Resource limits, budgets and cost alerts are configured.
• Privacy, retention and regulatory requirements have been reviewed.

Contemporary Developments and Limitations

Platform engineering is creating internal tools and standard deployment paths so development teams can use reliable infrastructure without mastering every cloud detail. GitOps applies the principle that a version-controlled repository describes desired operational state and automated agents reconcile the environment. Edge computing moves selected processing closer to users, reducing latency but complicating deployment consistency and data governance.

These approaches are not universal solutions. Managed platforms and serverless services can create vendor dependence; Kubernetes can impose substantial complexity; CDNs can make invalidation and privacy difficult; and highly automated pipelines can magnify mistakes. Sound engineering therefore favours proportionate design, explicit assumptions, measurable objectives and continuous learning from incidents.

Chapter Summary

Deployment is a lifecycle involving artefacts, infrastructure, configuration, security, observability and recovery. Web servers and VMs provide control, containers improve reproducibility, PaaS reduces administration, serverless supports event-driven elasticity, and CDNs accelerate content delivery. Domains depend on DNS, while TLS protects authenticated web communication.

Reliable deployment separates environments, stores secrets securely, uses least privilege and automates CI/CD. Rolling, blue-green, canary and feature-flag strategies offer different balances among risk, complexity and capacity. Backups, RPO, RTO, health checks and restoration exercises convert availability goals into operational practice. Infrastructure as code improves repeatability, while logs, metrics and traces support diagnosis.

Cloud operations must consider total cost, privacy, supply-chain security and governance. The most appropriate architecture is determined by requirements and organisational capability, not by fashion. A professional deployment is one that can be understood, monitored, secured, recovered and operated within budget.

Key Terms

Deployment: Making a software release available in an environment.

DevOps: Practices integrating software development and IT operations.

Artefact: A versioned output such as a build package or container image.

Container: An isolated process packaged with its runtime dependencies.

Virtual machine: A software-defined computer with an operating-system instance.

PaaS: A managed platform that abstracts much server administration.

Serverless: Provider-managed execution activated by requests or events.

CDN: A distributed network that caches and delivers content near users.

DNS: The naming system that maps domain names to services.

TLS: A protocol providing encrypted and authenticated network communication.

Secret: Confidential data such as a password, token or private key.

CI/CD: Automated integration, testing and delivery or deployment practices.

Canary deployment: Gradual exposure of a release to a limited user group.

Rollback: Reverting or redirecting to a previously working release.

RPO: Maximum acceptable data loss measured as a time interval.

RTO: Target time for restoring service after disruption.

Infrastructure as code: Version-controlled definition of infrastructure resources.

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

Infrastructure drift: Difference between declared and actual infrastructure configuration.

Least privilege: Granting an identity only the permissions it requires.

Review Questions

Short Answer Questions

1. What is the difference between a container and a virtual machine?
2. Why should secrets not be stored in source code or container images?
3. Distinguish continuous delivery from continuous deployment.
4. What do RPO and RTO measure?
5. Why are CDN cache headers important for web applications?

Long Answer Questions

1. Compare web servers, containers, PaaS and serverless deployment across control, scalability and operational responsibility.
2. Explain how a CI/CD pipeline can reduce deployment risk while preserving human accountability.
3. Describe a secure design for domains, DNS, TLS, environments and secrets.
4. Explain backup, restoration, high availability and failure-domain considerations for a production application.
5. Discuss how infrastructure as code, observability and cost governance support sustainable cloud operations.

Analytical / Application Questions

1. A release works in staging but causes high latency for 10% of production users. Design a canary analysis and rollback decision process, identifying the metrics and safeguards required.
2. A university portal has an RPO of one hour and an RTO of two hours. Propose database, file-storage and restoration practices that could realistically meet these objectives, and explain how they would be tested.
3. A small business is choosing between one VM, a container platform and serverless functions. Analyse the choice using traffic pattern, team expertise, compliance, portability, reliability and cost as decision criteria.

Multiple Choice Questions with Answers

Question 1

Which deployment target most directly distributes cached static content close to users?

A. Content delivery network

B. Relational database

C. Message queue

D. Secret manager

Correct Answer: A. Content delivery network

Question 2

What is the principal purpose of TLS in an HTTPS connection?

A. To compile JavaScript code

B. To provide encrypted and authenticated communication

C. To schedule database backups

D. To increase disk capacity

Correct Answer: B. To provide encrypted and authenticated communication

Question 3

Which practice best protects an API key used by a production application?

A. Commit it to a private repository

B. Place it in a public container label

C. Store it in a managed secret store with limited access

D. Include it in a frontend JavaScript bundle

Correct Answer: C. Store it in a managed secret store with limited access

Question 4

A 30-day month contains 43.2 minutes of downtime. What is the approximate availability?

A. 99.0%

B. 99.9%

C. 99.99%

D. 90.0%

Correct Answer: B. 99.9%

Question 5

Which deployment strategy initially exposes a new version to only a small proportion of users?

A. Recreate deployment

B. Canary deployment

C. Static deployment

D. Backup deployment

Correct Answer: B. Canary deployment

Question 6

What does an RPO of one hour indicate?

A. The service must restart within one hour

B. The application may lose no more than approximately one hour of data

C. TLS certificates expire after one hour

D. A deployment must be reviewed hourly

Correct Answer: B. The application may lose no more than approximately one hour of data

Question 7

Which statement about containers is correct?

A. They are always complete virtual machines

B. They remove the need for vulnerability scanning

C. They package an application with runtime dependencies and usually share the host kernel

D. They guarantee high availability without orchestration

Correct Answer: C. They package an application with runtime dependencies and usually share the host kernel

Question 8

Which observability signal records a request’s path across multiple services?

A. Trace

B. DNS record

C. Container image

D. Cache-control header

Correct Answer: A. Trace

Question 9

Why is an expand-and-contract database migration useful during rolling deployment?

A. It eliminates the need for backups

B. It maintains compatibility between old and new application versions

C. It prevents all network failures

D. It encrypts every database column automatically

Correct Answer: B. It maintains compatibility between old and new application versions

Question 10

Which action is most consistent with cost-aware cloud operations?

A. Leave all test environments running indefinitely

B. Disable backups to reduce every invoice

C. Tag resources, set budgets and remove unused environments

D. Choose the largest instance for every service

Correct Answer: C. Tag resources, set budgets and remove unused environments