---
title: "Cloud Computing"
subtitle: "November 18 · Managed does not mean ownerless"
author: "MaDS Databases & SQL"
format:
  revealjs:
    theme: [default, mads-sql-reveal.scss]
    slide-number: c/t
    chalkboard: true
    code-line-numbers: true
    transition: fade
    footer: "Adapted from Alex Reinhart · MADS Computing"
---

## One question will organize today

::: {.question}
What did Azure take off the team's plate—and what can still fail because of us?
:::

## Course source and adaptation

::: {.source-note}
Today's sequence follows Alex Reinhart's [Cloud Computing](https://www.refsmmat.com/courses/msp-computing/data-engineering/cloud.html), applied to the course's Azure Database for PostgreSQL Flexible Server and current Microsoft service behavior.

Current reference: [Azure PostgreSQL service overview](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/service-overview) and [reliability guidance](https://learn.microsoft.com/en-us/azure/reliability/reliability-database-postgresql).
:::

## By the end of class

You should be able to:

- explain rental computing and managed services,
- map responsibilities across provider, instructor, builder, and receiver,
- audit access, backups, observability, and cost,
- distinguish availability from recoverability,
- propose one proportionate cloud improvement.

## Cloud is somebody else's computer—plus an API

Cloud changes how quickly resources can be:

- provisioned and resized,
- addressed and permissioned,
- metered and stopped,
- backed up and replaced.

It does not remove architecture or operations.

## Why rent instead of own?

- minutes to provision,
- pay for chosen capacity and time,
- managed database/backup services,
- repeatable infrastructure APIs,
- access from multiple locations.

Tradeoffs include cost surprises, lock-in, outages, and opaque limits.

## Compute, storage, and database are different products

```text
object storage: durable source files and artifacts
compute:        ingestion and report processes
database:       transactions, indexes, concurrent SQL
```

Using PostgreSQL for every raw file is not automatically simpler.

## Managed PostgreSQL splits responsibility {.smaller}

Microsoft manages much of the underlying hardware, operating system, patching, and
service backup machinery.

The course still owns:

- schema and query correctness,
- roles and passwords,
- network/access choices,
- retention configuration,
- restore testing,
- application retries and monitoring,
- data provenance and deletion.

## Checkpoint 1 · Responsibility map

::: {.checkpoint}
Assign each inherited-system responsibility to Microsoft, instructor, builder, receiver, or shared. Mark any item with no named owner.
:::

Include firewall/network access, credentials, schema changes, backups, restore, query correctness, and cost alerts.

## Identity answers “who?”; authorization answers “what?”

Use separate roles for:

- administration/migrations,
- pipeline writes,
- analyst reads,
- receiver operation.

Do not transfer one shared owner password as knowledge transfer.

## Least privilege is testable

Receiver role should be able to:

- connect,
- read documented schemas,
- execute approved functions or write to its extension schema.

It should fail at an intentionally forbidden action.

## Availability is not recovery

- **High availability:** keep service available through some infrastructure failures.
- **Backup:** retain recoverable history.
- **Restore:** create a usable state from that history.
- **Application resilience:** reconnect/retry safely.

An accidental `DROP` can replicate to a standby.

## Define RPO and RTO in client language

- **RPO:** how much recent data can the client afford to lose?
- **RTO:** how long can the client wait for a usable system?

Course-project answers can be modest, but they must be explicit.

## Checkpoint 2 · Recovery tabletop

::: {.checkpoint}
At 9:00 a receiver deletes or corrupts a trusted table. Write the first five actions, the latest acceptable restored point, and evidence that service is safe to reopen.
:::

Identify which step you can actually test with course permissions.

## Observability crosses layers

| Layer | Useful evidence |
|---|---|
| Azure service | availability, CPU, storage, connections |
| PostgreSQL | locks, slow queries, database size |
| Pipeline | run status, rows, rejects, freshness |
| Client result | coverage and domain metric |

Green infrastructure can serve stale data.

## Cost is an engineering constraint

Know:

- compute tier and whether it can stop,
- provisioned storage and growth,
- backup/retention choices,
- HA/replica multipliers,
- forgotten test resources,
- who sees and acts on budget alerts.

## Stop/start has operational meaning

Stopping low-use development compute can reduce cost, but the runbook must say:

- who may stop/start it,
- expected startup delay,
- how jobs fail while stopped,
- how receivers distinguish “stopped” from “broken.”

## Checkpoint 3 · Audit one inherited risk

::: {.checkpoint}
Choose access, recovery, monitoring, or cost. Gather one piece of current evidence and propose the smallest improvement with an owner and acceptance test.
:::

## Cloud portability is a spectrum

Portable:

- standard SQL and `psycopg`,
- source files retained in open formats,
- documented environment configuration.

Less portable:

- provider-specific identity, networking, monitoring, and orchestration.

Choose deliberately; do not pretend lock-in is zero.

## Project transfer

::: {.project-prompt}
Add a one-page operations matrix to the inherited runbook: owner, evidence, safe action, and escalation for access, backup/restore, monitoring, and cost.
:::

## Homework starts here

Homework 3 may use a tested cloud operations improvement. A recommendation alone is not
enough: include current evidence and the check that would prove the improvement works.

## The pattern to keep

```text
name the service boundary
  → assign every responsibility
  → minimize privilege
  → separate availability from recovery
  → monitor data meaning
  → control cost
  → test the runbook
```

Next: decide whether the inherited workload actually needs distributed data or computation.