Ref: https://learn.cantrill.io/courses/1820301/lectures/41301389 and https://learn.cantrill.io/courses/1820301/lectures/41301390

• Summary:
• Contents:

CatTube (Example App)

• Example/Reference app: YouTube CatTube = online video sharing platform, where users upload and watch videos about cats 😻
• App components:
  1. Users upload videos
  2. Uploaded videos are processed, generating lots of different versions at different qualities
     • ❗ Most computationally intensive component!
  3. CatTube displays videos, manages playlists and channels. Users can watch videos.
     • Implies storing data to and retrieving data from DBs
• 💡 To understand the different architectures, we will design this same app in all of them
  • Points marked with 💡 apply to CatTube's particular example app

Monolithic Architecture

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/1600-SERVERLESS_and_APPLICATION_SERVICES/00_LEARNINGAIDS/Architecture-1.png

• 🔧 A single monolith (black box or server) with all app components inside
  • Even if components are logically separate in the code, all are hosted in the same server
  • Traditional/historical architecture
• 👍 Simplicity
• 👎 Components tightly coupled:
  • Fail together
    • Failure of one component can affect the whole monolith
    • 💡 If UPLOAD fails, it affects PROCESSING, can also affect STORE & MANAGE
  • Scale together
    • Vertical scaling (generally)
  • Bill together
    • All components are always running → always incurring charges
    • 💡 Even if no new videos have been uploaded and no processing is needed, the processing engine is still running while doing nothing!
• ‼️ Monolithic architectures are some of the least effective ways to architect systems!
  • Even if simple, they usually incur very high costs!

Tiered Architecture

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/1600-SERVERLESS_and_APPLICATION_SERVICES/00_LEARNINGAIDS/Architecture-2.png

• 🔧 Each app component placed into a different tier
  • Monolith broken apart into different tiers (tiers can be in same or different servers)
  • ❗ Each tier connects to endpoint of other tier → Tiers tightly coupled
  • 💡 UPLOAD, PROCESSING, and STORE & MANAGE are all different tiers
• 👍 Immediate benefit: independent scaling for each tier (vertical OR horizontal!)
  • Coupling between tiers can be loosened by placing (internal) LBs between tiers
    • Allows for underlying infrastructure abstraction & horizontal scaling
    • Tiers also become HA
  • 💡 PROCESSING can scale up or down without dragging UPLOAD or STORE & MANAGE tiers. Scaling can be vertical or horizontal.