Cloud Computing

November 18 · Managed does not mean ownerless

MaDS Databases & SQL

One question will organize today

What did Azure take off the team’s plate—and what can still fail because of us?

Course source and adaptation

Today’s sequence follows Alex Reinhart’s Cloud Computing, applied to the course’s Azure Database for PostgreSQL Flexible Server and current Microsoft service behavior.

Current reference: Azure PostgreSQL service overview and reliability guidance.

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

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

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

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

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

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

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

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.