Engineering of AI Systems · HIT

Week 2   Part I · Foundations & the Cloud

Cloud Computing Fundamentals

Instructor lesson plan: lecture (2 h) and practice (2 h).

Learning objectives

Tools this week

cloud free tierVM (IaaS)object storage (S3)serverless / PaaScost calculatorbudget alerts

🎓Lecture · 2 hours

0:00-0:1010 minRecap & objectives
  • Recall: SLOs and the five layers; two retrieval questions on week 1.
  • Today: the platform everything runs on. No prior cloud experience assumed.
0:10-0:2515 minMotivation: the bill and the blast radius
  • Every production AI system runs on someone's cloud; the design decisions are rent-versus-build decisions.
  • Two stories: a forgotten GPU instance that cost a month's budget in a weekend, and a single-AZ outage that took a 'redundant' service down.
  • Cost and failure domains are design inputs from day one.
0:25-0:5025 minCompute: from metal to functions
  • Virtual machines: a rented computer; you own the OS upward.
  • Containers on managed runtimes: you own the image, the platform runs it.
  • Serverless functions: you own only code and configuration; cold starts and time limits in exchange for zero idle cost.
  • The control-versus-toil axis as the single picture to remember.
  • Board work: place the three course use cases on that axis and defend the placement.
0:50-1:1020 minStorage & managed services
  • Object storage (the S3 model): cheap, durable, URL-addressable; the default home for datasets, models, logs, and the data lake to come in week 5.
  • Block storage belongs to one VM; file shares for legacy POSIX needs.
  • Managed databases and queues: paying the provider to carry backups, patching, and failover.
  • Rule of thumb: artifacts and data in object storage, state in a managed database, glue in functions.
1:10-1:2010 minBreak
1:20-1:4020 minNetworking, regions & the deployment models
  • Virtual networks, subnets, security groups; load balancers and DNS; HTTPS termination.
  • Regions and availability zones: what multi-AZ protects against, and what it does not.
  • IaaS versus PaaS versus SaaS named precisely; where serverless sits.
  • The shared-responsibility model: the provider secures the cloud, you secure what is in it.
1:40-1:5515 minThe cost model (predict, then run)
  • Pay-as-you-go: compute time, storage volume, requests, and the one everyone forgets: egress.
  • Live exercise: the class predicts the monthly cost of the chatbot use case at 10k requests/day, then we price it together in the calculator.
  • Budgets, alerts, and tagging as non-negotiable hygiene.
1:55-2:005 minWrap-up & practice previewPractice provisions the project's real cloud footprint, with a budget alert set before anything else.
Common misconception to confront.

Students often think: The cloud is just someone else's computer, so nothing really changes.
Set it straight: Elasticity, managed services, per-use billing, and the shared-responsibility split change how systems are designed, costed, and secured. A design that ignores them is either fragile or expensive.

Check for understanding (pose during the concept blocks; let students answer before revealing).
You need to store trained model artifacts and serve them to many machines. Object, block, or file storage, and why?
Object storage: cheap, durable, URL-addressable, and built for many readers. Block storage belongs to one VM; file shares scale poorly for this.
What failure does deploying across two availability zones protect against?
The loss of a single data center (power, cooling, network). It does not protect against a region-wide outage or a bad deploy you ship to both zones.
Key takeaways.

📚Reading & resources

💻Practice · 2 hours

In the practice session the instructor demonstrates the tooling live and teaches the hands-on topics that belong at the keyboard. There are no separate weekly labs: each session closes with the project-integration brief, the increment every team adds to its end-to-end system before next week.

0:00-0:1010 minSetup & recap
  • Cloud free-tier accounts confirmed for every team.
  • Recap the primitives and the control-versus-toil axis.
0:10-0:3525 minFirst things first: budgets, then a VM
  • Set a budget alert on every team account before provisioning anything.
  • Launch a small VM, connect to it, and run the week-1 container on it.
  • Read the instance metadata: region, zone, type, hourly price.
0:35-1:0025 minObject storage for the project
  • Create the team bucket that will carry the project's data and artifacts all semester.
  • Upload and download from code (not the console): the SDK pattern.
  • Show URL-addressability and access control; why this bucket becomes the data lake in week 5.
1:00-1:1010 minBreak
1:10-1:3525 minSame app, three deployment models
  • Deploy the hello-service on the VM (IaaS), then as a managed container/PaaS app, then as a serverless function.
  • Compare: effort to deploy, cold start, cost at zero traffic, control retained.
  • Each team records the comparison table; it becomes part of the Presentation-1 architecture rationale.
1:35-1:5015 minStudents drive: price your project
  • Each team prices its shortlisted use case at target load in the calculator.
  • Instructor reviews the two most expensive line items per team.
1:50-2:0010 minProject-integration briefTeardown discipline demonstrated live; then the 'Project integration' card: the team's cloud footprint must exist, budgeted and torn down clean, before next week.
Common pitfalls to pre-empt.

Project integration (this week)

Curated references Project brief

PreviousWeek 1: Production Engineering & the Ops LandscapeNextWeek 3: CI/CD, Testing & REST Services