Deployment, Cloud Infrastructure, and DevOps

Introduction

A web application is not complete when it runs successfully on a developer’s laptop. It must be packaged, configured, secured, deployed, observed, updated, and recovered in environments that differ from development. Deployment engineering connects software development with computing infrastructure and operations. Its central concern is not merely placing files on a server, but creating a repeatable and reliable path from source code to a usable service.

Modern deployment commonly combines application packaging, containers, cloud services, reverse proxies, domain names, TLS certificates, automated testing, infrastructure as code, database operations, monitoring, and controlled release strategies. DevOps is the organizational and technical discipline that integrates these activities. It encourages shared responsibility among developers, operations engineers, security specialists, and product teams.

This chapter presents the foundations required to deploy a web application responsibly. Examples use general concepts applicable to platforms such as AWS, Microsoft Azure, Google Cloud, and private infrastructure; commands and product names should be adapted to the selected platform.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain the differences among development, testing, staging, and production environments.
2. Package an application using environment configuration and containers.
3. Describe cloud infrastructure, managed services, reverse proxies, domains, and TLS.
4. Design a basic CI/CD pipeline and express infrastructure using code.
5. Plan database deployment, migrations, rollback, observability, and reliability practices.
6. Evaluate scaling and deployment choices with attention to performance, security, and cost.

1. Deployment as a Systems Problem

Deployment is the controlled transition of a software artifact into an environment where users can access it. A deployable unit includes more than source code. It may contain compiled files, runtime libraries, configuration references, database migration scripts, static assets, and metadata identifying the exact version.

A useful distinction is:

• Build artifact: the immutable output of a build, such as a container image or compiled package.
• Release: an approved version of an artifact together with configuration and deployment instructions.
• Deployment: installation or activation of a release in a particular environment.
• Environment: a combination of compute, network, storage, databases, secrets, and policies.

Typical environments include development, testing, staging, and production. Development optimizes for rapid experimentation; production optimizes for security, availability, performance, and controlled change. The principle of environment parity states that environments should be sufficiently similar that behavior tested before release predicts production behavior. Perfect parity is often too expensive, but differences should be explicit and documented.

Configuration must not be hard-coded into application source. Database URLs, API keys, feature flags, logging levels, and external service endpoints should be supplied through environment variables or a managed configuration and secret service. Secrets must never be committed to source control or embedded in container images. Configuration validation should occur at startup so that an invalid deployment fails clearly rather than operating partially.

2. Containers and Application Packaging

A virtual machine includes a complete guest operating system, whereas a container packages an application and its user-space dependencies while sharing the host operating system kernel. Containers improve portability and consistency, but they are not a complete security boundary equivalent to a virtual machine.

A container image is built in layers and identified by a digest or tag. Tags such as latest are convenient but mutable; production systems should prefer immutable version tags or content digests. A Dockerfile or equivalent build specification should use a small trusted base image, install only required dependencies, run as a non-root user, and avoid copying secrets.

A multi-stage build separates compilation from runtime. For example, a frontend may be compiled in a Node.js build stage and served by a minimal web server image. This reduces image size and attack surface. Dependency versions should be locked, and image scanning should identify known vulnerabilities before release.

Containers are generally stateless. User uploads, sessions, and database records should be stored in durable services rather than the container filesystem, because containers may be replaced at any time. Persistent data belongs in a managed database, object storage, or a separately managed volume.

Container orchestration becomes useful when several services must be scheduled, replicated, discovered, and updated. Kubernetes is a prominent example, but managed container platforms and simpler platform-as-a-service products may be more appropriate for small systems. Abstraction has a cost: orchestration introduces networking, scheduling, security, and operational complexity.

3. Cloud Infrastructure and Service Models

Cloud computing provides on-demand access to computing resources through APIs and usage-based billing. The major service models are:

A cloud architecture usually contains a network boundary, subnets, routing rules, compute resources, storage, identity policies, and observability services. Public-facing components should be separated from private databases where possible. The principle of least privilege requires each identity or service to receive only the permissions necessary for its task.

Cloud selection should consider latency, regulatory requirements, data residency, service maturity, portability, support, and cost—not only raw computing price. Vendor-managed services reduce administrative work but can create dependency on proprietary APIs and migration costs.

4. Reverse Proxies, Domains, and TLS

A reverse proxy receives client requests and forwards them to one or more application servers. It can terminate TLS, route by hostname or path, serve static files, compress responses, apply rate limits, and balance traffic. The application server should generally not be directly exposed to the public internet.

A domain name maps human-readable names to network endpoints through the Domain Name System (DNS). Common records include:

• A: maps a name to an IPv4 address.
• AAAA: maps a name to an IPv6 address.
• CNAME: aliases one name to another name.
• TXT: carries verification or policy information.

DNS uses caching and time-to-live values, so changes are not necessarily visible immediately. DNS is not a replacement for application health checking or access control.

TLS provides encryption, server authentication, and integrity for HTTP traffic. HTTPS should be used for all authenticated or sensitive traffic and, in practice, for the entire application. Certificates are issued by trusted certificate authorities and must be renewed automatically where possible. Secure configuration includes disabling obsolete protocols, redirecting HTTP to HTTPS, using secure cookies, and applying an appropriate Content Security Policy. TLS encrypts traffic in transit, but it does not protect compromised servers or improperly authorized users.

5. CI/CD and Release Automation

Continuous integration (CI) automatically builds and tests changes when they enter a shared repository. Continuous delivery keeps software in a releasable state; continuous deployment automatically releases approved changes to production.

A representative pipeline is:

1. Developer opens a pull request.
2. Formatting, static analysis, unit tests, and dependency checks run.
3. Integration and security tests execute in an isolated environment.
4. An immutable artifact is built and scanned.
5. The artifact is promoted through staging.
6. Approval or an automated policy permits production release.
7. Health checks and deployment metrics are monitored.

The pipeline itself is production infrastructure and requires access control, audit logs, protected branches, secret management, and reproducible runners. A build should be repeatable: the same source revision and dependency lockfile should produce functionally equivalent output.

A deployment strategy must be selected according to risk:

Rollback is the restoration of a known-good application version. It is safest when artifacts are immutable and database changes are backward compatible. A deployment should define a rollback trigger, responsible person, maximum decision time, and verification procedure before it begins.

6. Infrastructure as Code

Infrastructure as code (IaC) defines networks, compute, identity, databases, and policies in version-controlled files. Declarative tools describe the desired state; the tool calculates changes required to reach that state. This improves repeatability, reviewability, and disaster recovery.

A sound IaC workflow is:

1. Define resources in code.
2. Validate syntax and policy in CI.
3. Generate and review a change plan.
4. Apply changes using controlled credentials.
5. Record state securely and protect it from concurrent modification.
6. Test the resulting infrastructure.

IaC does not eliminate risk. A mistaken rule can expose a database or delete storage. State files may contain sensitive information and require encryption, access control, versioning, and backup. Separate accounts or projects for development and production reduce accidental cross-environment changes. Manual changes create drift and should either be imported into code or removed.

7. Database Deployment and Migration

Database deployment is more difficult than application deployment because data is persistent and schema changes may affect old and new application versions simultaneously. A migration is a versioned, ordered change to database structure or data.

A safe pattern is expand and contract:

1. Expand: add a nullable column, table, or compatible index.
2. Deploy application code that can use both old and new structures.
3. Backfill or transform data in controlled batches.
4. Switch reads and writes to the new structure.
5. Contract: remove obsolete columns only after no supported code depends on them.

Large migrations should avoid long locks and unbounded transactions. Before applying a migration, take a verified backup and measure its expected duration. A backup is useful only if restoration has been tested. Data migrations require special attention to privacy, auditability, and integrity constraints.

Application rollback and database rollback are not always identical. A schema change may be irreversible without losing newly written data. Therefore, backward-compatible migrations are usually preferable to attempting to reverse every change.

8. Observability and Reliability

Observability is the ability to infer internal system behavior from external outputs. Its three commonly discussed signals are:

• Logs: timestamped records of events, ideally structured and correlated with request identifiers.
• Metrics: numerical time-series measurements such as latency, error rate, throughput, and resource use.
• Traces: a distributed representation of a request as it crosses services.

Monitoring asks whether known conditions are occurring; observability helps investigate unfamiliar failures. Logs should exclude passwords, tokens, and unnecessary personal data. Access to telemetry must itself be controlled.

Service-level indicators (SLIs) measure user-relevant behavior, such as successful request proportion or latency percentile. A service-level objective (SLO) is a target for an SLI. A service-level agreement (SLA) is a contractual commitment, potentially including remedies.

For an availability objective, define the error budget as the permitted unavailability over a period:

Here, the SLO is expressed as a fraction and T is the measurement period. For a 99.9% monthly availability objective and a 30-day month, the budget is (1 − 0.999) × 30 days = 0.03 days = 43.2 minutes, assuming the service is measured continuously and the month is treated as 30 days. The result is a planning approximation; provider-specific measurement rules may differ.

Reliability practices include health checks, timeouts, bounded retries with exponential backoff and jitter, circuit breakers, graceful degradation, capacity reserves, backups, disaster-recovery exercises, and documented incident response. Retries must be used carefully: retrying a non-idempotent operation can create duplicate effects, and synchronized retries can overload a failing service.

Recovery objectives quantify disaster planning:

• RTO (Recovery Time Objective): maximum acceptable time to restore service.
• RPO (Recovery Point Objective): maximum acceptable amount of data loss measured in time.

A system with an RPO of 15 minutes must have a backup or replication process capable of limiting recoverable data loss to approximately that interval; it does not guarantee that every incident will be resolved within 15 minutes.

9. Scaling and Cost Awareness

Vertical scaling increases the capacity of one instance; horizontal scaling adds instances. Horizontal scaling generally improves resilience but requires stateless application design, shared or external session storage, load balancing, and coordination of background jobs.

Autoscaling policies can respond to CPU utilization, request rate, queue depth, or latency. CPU alone is often a poor proxy for user experience. Scaling should account for startup time, database connection limits, rate limits, and downstream capacity.

A simple monthly cost model is:

Each term is a cost in the selected billing currency for the same billing period. The model is an accounting decomposition, not a universal pricing formula. Actual costs depend on reserved capacity, data transfer direction, requests, storage operations, licensing, and provider-specific tiers.

Cost-aware engineering includes deleting unused resources, selecting appropriate instance sizes, setting budgets and alerts, using lifecycle policies for object storage, reducing unnecessary log retention, and reviewing idle environments. Optimization must not compromise security, legal retention, or recovery requirements.

10. Security, Governance, and Ethics

Deployment systems possess powerful credentials and are attractive targets. Controls should include multi-factor authentication, short-lived credentials, role separation, secret rotation, dependency and image scanning, network segmentation, patch management, and audit logging. Production access should be justified, limited, and reviewable.

Privacy regulations may impose requirements concerning consent, data minimization, retention, access requests, breach notification, and cross-border transfers. Logs and backups can contain personal data and must be governed accordingly. An application team should know what data it collects, why it collects it, where it is stored, how long it is retained, and who can access it.

Artificial intelligence may assist with log summarization, anomaly detection, test generation, and incident investigation. It should not autonomously make high-impact production changes without appropriate approval and safeguards. Generated configuration and code must be reviewed because an apparently plausible recommendation can introduce insecure permissions or inaccurate diagnoses.

11. Illustrative Case: Deploying a University Course Portal

Background. A university course portal allows students to view schedules, submit assignments, and receive notifications. Its initial deployment uses one server, a local database, manual file copying, and no tested backup.

Problem. Releases cause intermittent downtime, credentials are stored in a configuration file, and peak registration periods produce slow responses. The team cannot determine whether failures originate in the application, database, or network.

Analysis. The portal has four major risks: non-reproducible deployment, insecure secrets, a single failure domain, and insufficient observability. Its database contains important student records, so data loss is more serious than short-term inconvenience.

Approach. The team creates a locked dependency file and a multi-stage container image. CI runs tests, builds an image identified by the source revision, scans dependencies, and publishes the image to a private registry. A managed relational database is placed in a private network with automated backups and tested restoration. Secrets move to a managed secret store. A reverse proxy terminates TLS and forwards requests to stateless application containers. Static files are placed in object storage and served through a content delivery service.

Infrastructure is defined in version control. A staging environment is updated automatically, while production requires approval. Database changes follow expand-and-contract migration rules. Structured logs, request metrics, traces, and alerts are introduced. During registration, the system scales application instances horizontally, while database connection pooling prevents excessive connections.

Outcome. Releases become repeatable, credentials are removed from source control, and the team can identify slow database queries using traces and metrics. Blue-green deployment permits rapid application rollback. The team discovers that a database migration cannot safely be reversed, so future migrations are required to remain compatible with the previous application version.

Learning points. Reliability comes from the interaction of architecture, process, and evidence. Containers alone do not provide reliability; they must be combined with immutable artifacts, secure configuration, tested recovery, observability, and an operationally realistic database strategy.

12. Challenges and Limitations

Cloud platforms reduce the need to operate physical hardware but do not remove complexity. Distributed systems fail partially, networks introduce latency, and managed services can experience outages or impose quotas. Multi-cloud adoption may improve bargaining power or resilience in selected cases, but it also multiplies operational skills, monitoring systems, and configuration differences.

Automation can accelerate defective changes. A pipeline that lacks meaningful tests merely delivers mistakes faster. Monitoring can create alert fatigue when thresholds are noisy or alerts are not actionable. High availability may increase cost and architectural complexity beyond what a small application requires. Good engineering therefore matches controls to risk, users, regulatory obligations, and business value.

Contemporary Practices and Best Practices

Current professional practice increasingly emphasizes platform engineering, policy-as-code, software supply-chain security, signed artifacts, provenance records, zero-trust access, OpenTelemetry-compatible telemetry, and progressive delivery. These practices should be adopted incrementally rather than as fashionable checklists.

A practical baseline is to:

1. Keep source, configuration definitions, migration scripts, and deployment policies version controlled.
2. Build once and promote the same immutable artifact.
3. Keep secrets outside source code and images.
4. Automate tests, scanning, deployment, and rollback checks.
5. Separate public traffic from private data services.
6. Make database changes backward compatible whenever possible.
7. Monitor user-facing indicators, not only infrastructure utilization.
8. Test backups, restoration, failover, and incident procedures.
9. Apply least privilege and record administrative actions.
10. Review reliability and cloud cost together.

Chapter Summary

Deployment is a systems discipline involving artifacts, environments, configuration, infrastructure, data, security, and operations. Containers improve consistency but require careful image construction and externalized state. Cloud services provide flexible infrastructure, while managed services trade operational effort for provider dependency and usage cost. Reverse proxies, DNS, and TLS form the public access path for secure web applications.

CI/CD makes delivery repeatable; IaC makes infrastructure reviewable and reproducible. Database migrations require compatibility planning because persistent data cannot always be rolled back like application code. Observability combines logs, metrics, and traces, while SLOs, error budgets, RTO, and RPO provide useful reliability language. Scaling and cost decisions must consider user demand, downstream limits, security, recovery, and organizational capability.

Key Terms

Artifact: A versioned output suitable for deployment.

Container: An isolated process environment packaging an application and its dependencies.

Continuous integration: Automated building and testing of shared code changes.

Continuous delivery: Keeping software in a releasable condition.

Continuous deployment: Automatically releasing approved changes to production.

DNS: The distributed naming system that maps domain names to network information.

Error budget: The permitted unreliability implied by an SLO.

Infrastructure as code: Version-controlled definition and management of infrastructure.

Immutable artifact: A build output that is not modified after publication.

IaC drift: Difference between declared infrastructure and actual infrastructure.

Migration: A versioned database structure or data change.

Observability: Ability to infer internal behavior from system outputs.

RPO: Maximum acceptable data loss expressed as time.

RTO: Maximum acceptable time to restore service.

Reverse proxy: A server that receives client requests and forwards them to backend services.

SLO: A target for a measured service-level indicator.

TLS: A protocol providing encryption, authentication, and integrity in transit.

Canary deployment: Releasing a new version to a small traffic fraction before wider release.

Review Questions

Short Answer Questions

1. Why should production secrets not be stored in a container image?
2. Distinguish continuous delivery from continuous deployment.
3. What roles do a reverse proxy and DNS play in a web deployment?
4. Define RTO and RPO.
5. Why are database migrations often more difficult to roll back than application code?

Long Answer Questions

1. Explain how a container-based CI/CD pipeline can improve deployment repeatability, and discuss its limitations.
2. Compare rolling, blue-green, and canary deployment strategies.
3. Describe an expand-and-contract database migration with an example.
4. Explain how logs, metrics, traces, SLOs, and error budgets support reliability engineering.
5. Design a secure cloud architecture for a small public web application, including networking, TLS, storage, identity, and backups.

Analytical / Application Questions

1. A service has a 99.9% monthly SLO and is measured over a 30-day month. Calculate its approximate error budget in minutes and explain how that budget could influence release decisions.
2. A deployment passes unit tests but causes high latency in production. Propose an investigation using observability signals and identify at least three possible causes.
3. A team wants to reduce cloud cost by deleting backups and disabling logs. Evaluate this proposal and recommend a risk-balanced alternative.

Multiple Choice Questions with Answers

Question 1

Which practice best protects application secrets during deployment?

A. Embedding them in the container image

B. Committing them to a private repository

C. Supplying them through a managed secret service

D. Printing them in startup logs

Correct Answer: C. Supplying them through a managed secret service

Question 2

What is the primary purpose of a reverse proxy?

A. To replace the database schema

B. To receive client requests and forward them to backend services

C. To compile source code

D. To define DNS ownership

Correct Answer: B. To receive client requests and forward them to backend services

Question 3

Which deployment strategy sends a small fraction of traffic to a new version first?

A. Recreate

B. Canary

C. Full replacement

D. Static deployment

Correct Answer: B. Canary

Question 4

For a 99.9% SLO over a 30-day month, the approximate error budget is:

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 0.432 minutes

Correct Answer: B. 43.2 minutes

Question 5

Which database migration approach adds compatible structures before removing obsolete ones?

A. Expand and contract

B. Delete and recreate

C. Direct overwrite

D. Rollback-only migration

Correct Answer: A. Expand and contract

Question 6

What does RPO measure?

A. Maximum acceptable service restoration time

B. Maximum acceptable data loss measured in time

C. Average CPU utilization

D. Certificate renewal duration

Correct Answer: B. Maximum acceptable data loss measured in time

Question 7

Which item is an example of observability telemetry?

A. A source-code comment only

B. A structured request log with a correlation identifier

C. A domain registrar invoice

D. A compiler license

Correct Answer: B. A structured request log with a correlation identifier

Question 8

What is a major benefit of infrastructure as code?

A. It makes all infrastructure changes risk-free

B. It removes the need for access control

C. It makes infrastructure definitions reviewable and repeatable

D. It guarantees zero cloud cost

Correct Answer: C. It makes infrastructure definitions reviewable and repeatable

Question 9

Which scaling method adds additional application instances?

A. Horizontal scaling

B. Vertical scaling

C. Source minification

D. Certificate rotation

Correct Answer: A. Horizontal scaling

Question 10

Why are immutable artifact versions preferred over a mutable tag such as latest in production?

A. They make network latency zero

B. They ensure the deployed content can be identified and reproduced

C. They eliminate the need for testing

D. They automatically encrypt databases

Correct Answer: B. They ensure the deployed content can be identified and reproduced