WEEK 12 — CLOUD COMPUTINGA FIELD GUIDE FOR CURIOUS MINDS

01—08 THE SYSTEM BEHIND THE SCREEN

Behind
every
request.

Every app is a thousand moving parts.
Follow the systems that keep them together.

Enter the system

FIG. 001 APPLICATION LIFECYCLE

SCROLL TO EXPLORE

Orchestration / Kubernetes / Resilience / Observability

EST. 8 MIN READ

01 / ORCHESTRATIONFROM INDIVIDUAL TASKS TO ONE WORKFLOW

The cloud doesn't
run on chance.

A server starts. A network connects. Storage becomes available. Orchestration makes those actions work as one.

It coordinates tasks, dependencies, and policies across cloud resources. Describe the outcome, then let an engine organize the work.

01 / DECLAREDesired stateThe outcome you want

02 / COORDINATECompute · Network · StorageDependencies in the right order

03 / RECONCILERunning systemObserve, compare, adjust

Kubernetes

Orchestrate container workloads.

Terraform

Provision infrastructure from configuration.

Ansible

Automate configuration and operational tasks.

Different layers, complementary tools. The engine turns intent into coordinated actions.

02 / KUBERNETESA CLUSTER IS A COORDINATED SYSTEM

01 / THE IDEA

Containers,
in concert.

Kubernetes is an open-source system for running containerized applications across a cluster. You describe the desired state. It keeps working to make reality match.

Self-healingScalingControlled updates

02 / THE CONTROL PLANE

The decisions
happen here.

API server: The front door for cluster requests.
etcd: The store for cluster configuration and state.
Scheduler: Finds a suitable node for each new Pod.
Controllers: Continuously reconcile actual and desired state.

03 / THE WORKER NODES

Where the
work runs.

Each worker runs a kubelet to manage Pods and a container runtime to execute containers. Cluster networking connects them.

A Pod is the smallest deployable unit: one or more closely related containers that share networking and storage resources.

Service networking commonly uses kube-proxy or an alternative implementation.

04 / DEPLOYMENTS

Define once.
Run in replicas.

A Deployment declares the image, Pod template, and replica count. It manages ReplicaSets, which maintain the requested Pods.

Change the template to roll out a new version. Change the replica count to scale. If a Pod fails, a controller creates a replacement.

Recovery still needs available capacity. Autoscaling needs metrics and configuration.

CLUSTER TOPOLOGYDESIRED STATE

03 / SERVICES & INGRESSFOLLOW A REQUEST

A clear path
through the cloud.

↗THE REQUEST

Browser

campus.example/api

YTHE RULES

Ingress

Host + path routing

◎THE ENDPOINT

Service

Stable DNS + IP

▦THE WORKLOAD

Pods

Ready backends

Pods are replaceable.
The address stays.

A Service selects backends using labels and provides a stable destination. Common types are ClusterIP, NodePort, and LoadBalancer.

One entrance.
Different destinations.

Ingress routes external HTTP(S) by host and path. It needs an Ingress controller to apply those rules. The newer Gateway API supports evolving routing needs.

The Ingress API is frozen. Service and Ingress solve different layers of routing.

04 / FROM THEORY TO TERMINALYOUR FIRST LOCAL DEPLOYMENT

Make it
real.

Create a local cluster. Deploy a web server. Give it an endpoint.

First install minikube, kubectl, and a supported container or VM driver.

Start your cluster
Create the workload
Expose and inspect it
Open the application

LOCAL / KUBECTL

# Start a local Kubernetes cluster
minikube start

# Deploy a web server
kubectl create deployment web \
  --image=nginx:stable

# Expose it inside the local environment
kubectl expose deployment web \
  --port=80 --type=NodePort

# Inspect and open
kubectl get pods,svc
minikube service web

YOUR FIRST APPLICATION, RUNNING ON KUBERNETES.

05 / DEPLOYMENT STRATEGIESCHANGE THE APP. CONTROL THE RISK.

Every release
is a decision.

ROLLING UPDATE

APPLICATION TRAFFIC

01v1

02v1

03v1

04v1

Pods transition to v2 one at a time.

Previous version New version

RollingUpdate and Recreate are built-in Deployment strategies. Blue/green and weighted canary releases need additional release and traffic coordination. All diagrams are illustrative.

06 / DISASTER RECOVERYASSUME SOMETHING WILL FAIL

Thingswill break.Design what happens next.

Disaster recovery restores service after a major disruption. Start with two targets.

How long can the application be unavailable? How much recent data can you afford to lose? Those answers shape the architecture.

LAST RECOVERY POINT

DISRUPTION

SERVICE RESTORED

RPO

Acceptable data loss,
measured in time.

RTO

Target time to
restore service.

Choose your
recovery posture.

More readiness generally means faster recovery and higher running cost.

Backup & restore

Protected copies. Rebuild when needed.

Pilot light

Keep core services ready. Scale up for recovery.

Warm standby

A smaller working stack waits to take over.

Active / active

Multiple sites already serve traffic.

07 / RECOVERY IN PRACTICETHE RUNBOOK MUST WORK

A plan you
can execute.

01 / PREPARE

Know what matters.

Map critical services and dependencies. Set RTO and RPO. Assign owners, contacts, and recovery priorities.

02 / PROTECT

Keep a way back.

Maintain recoverable backups, replicated data, infrastructure definitions, and clear runbooks.

03 / RESPOND

Restore with intent.

Detect the disruption, activate the plan, restore dependencies, and validate the application and its data.

04 / REHEARSE

Test before you need it.

Run recovery drills, measure results, improve the plan, and fail back safely when the primary is ready.

LOAD BALANCING & FAILOVER

Give traffic
a healthy destination.

Health checks and routing policies can shift traffic away from an unavailable site. The recovery environment must already have the capacity and data it needs.

A load balancer does not restore lost data. Cross-region recovery may also use DNS or global traffic management.

Scroll through a simplified failover sequence.

08 / APPLICATION MONITORINGOBSERVE THE SYSTEM YOU CREATED

Listen to
the signals.

Running is not the same as healthy.
Measure what users experience.

01 / METRICS

What changed?

Numerical trends reveal latency, traffic, error rates, and resource saturation.

02 / LOGS

What happened?

Events add detail and context to a failure, request, or system action.

03 / TRACES

Where did it slow?

Follow a request across services to locate delays and failed dependencies.

Choose APM
for your application.

Prioritize stack support, useful signals, actionable alerts, data handling, and total cost. Connect instrumentation to diagnosis and response.

TOOLS IN THE OBSERVABILITY STACK

Prometheus + Grafana
Jaeger
Datadog
New Relic

OpenTelemetry collects and exports telemetry.
Monitoring backends store, query, and visualize it.

THE APPLICATION LIFECYCLE

Orchestrate.Recover.Observe.

Every signal informs the next decision.
The loop keeps going.

Back to the beginning

Behind
every
request.

The cloud doesn't
run on chance.

Kubernetes

Terraform

Ansible

Containers,
in concert.

The decisions
happen here.

Where the
work runs.

Define once.
Run in replicas.

A clear path
through the cloud.

Browser

Ingress

Service

Pods

Pods are replaceable.
The address stays.

One entrance.
Different destinations.

Make it
real.

Every release
is a decision.

Rolling update

Recreate

Blue / green

Canary

Choose your
recovery posture.

Backup & restore

Pilot light

Warm standby

Active / active

A plan you
can execute.

Know what matters.

Keep a way back.

Restore with intent.

Test before you need it.

Give traffic
a healthy destination.

Listen to
the signals.

What changed?

What happened?

Where did it slow?

Choose APM
for your application.

Behindeveryrequest.

The cloud doesn'trun on chance.

Kubernetes

Terraform

Ansible

Containers,in concert.

The decisionshappen here.

Where thework runs.

Define once.Run in replicas.

A clear paththrough the cloud.

Browser

Ingress

Service

Pods

Pods are replaceable.The address stays.

One entrance.Different destinations.

Make itreal.

Every releaseis a decision.

Rolling update

Recreate

Blue / green

Canary

Disaster recovery

Choose yourrecovery posture.

Backup & restore

Pilot light

Warm standby

Active / active

A plan youcan execute.

Know what matters.

Keep a way back.

Restore with intent.

Test before you need it.

Give traffica healthy destination.

Listen tothe signals.

What changed?

What happened?

Where did it slow?

Choose APMfor your application.

Behind
every
request.

The cloud doesn't
run on chance.

Containers,
in concert.

The decisions
happen here.

Where the
work runs.

Define once.
Run in replicas.

A clear path
through the cloud.

Pods are replaceable.
The address stays.

One entrance.
Different destinations.

Make it
real.

Every release
is a decision.

Choose your
recovery posture.

A plan you
can execute.

Give traffic
a healthy destination.

Listen to
the signals.

Choose APM
for your application.