FREE CLOUD ARCHITECTURE FOUNDATIONS LEARNING PATH

WikiFree original practice workbook

The cloud cartographer

CASE STATUS: fictional/synthetic teaching material. Do not present the example as real research, employment experience or measured business performance.

OUTCOME
Design a vendor-neutral small web application architecture and explain responsibilities, failure handling and a migration sequence.

BEFORE YOU START
General understanding of websites and files; no coding or cloud account.

CASE
The fictional Willow Workshop currently keeps event sign-ups in a shared local file. It wants a small web service for 200 weekly visitors and a manual fallback during outages. It does not need a complex microservice platform.

INPUTS
Requirement,Design implication
200 weekly visitors,"Start with a small, simple design"
Booking records,Persistent data and backup
Outage fallback,Manual intake and reconciliation
Small team,Minimize operations burden


ENTRY CHECK

Question: Is every application a microservice system?

Self-check: No.

Question: Can a container replace a backup?

Self-check: No. Packaging and durable data protection solve different problems.

Question: What makes a trade-off explicit?

Self-check: The chosen benefit, cost and alternative are documented.

STAGE 1: Translate needs into responsibilities

Prerequisite: General understanding of websites and files; no coding or cloud account.

Instruction: Write requirements in terms of user work before choosing a hosting model. Compare infrastructure, platform and software services by what the team operates and what the provider operates. A small team may prefer fewer operational responsibilities, but still owns its data choices, application behavior and access decisions. Keep optional complexity out of the first design.

Practice task: Create a responsibility table for two hosting options and choose one for the workshop.

Deliverable: A hosting responsibility decision.

Acceptance check: The table names customer duties and a concrete reason for the choice.

If stuck: A list of product names without responsibilities is not a decision record.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 2: Draw the application and data flows

Prerequisite: Bring your previous output: A hosting responsibility decision.

Instruction: A useful architecture diagram shows components, trust boundaries and data direction. For this case, a browser calls an application that reads and writes a database; administrators use a separate management route. Label persistent storage and avoid drawing direct public database access. Keep the diagram small enough that a reviewer can explain one booking from start to finish.

Practice task: Draw the booking request and response, database write, administrator route and backup destination.

Deliverable: A labeled application architecture.

Acceptance check: Every stored booking has a clear write path and a defined persistent location.

If stuck: If arrows have no purpose or direction, label them with the data or request they carry.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 3: Evaluate packaging without overbuilding

Prerequisite: Bring your previous output: A labeled application architecture.

Instruction: Virtual machines and containers package workloads differently; neither automatically provides application resilience. Microservices can add independent deployment boundaries and operational cost. With one small workflow and a small team, a modular single application is a defensible starting point. Document the trigger that might justify splitting a component later.

Practice task: Compare a single application with a three-service alternative. Identify one benefit and two costs of the split.

Deliverable: A packaging and complexity trade-off note.

Acceptance check: The proposed design is proportional to the workload and names a future split trigger.

If stuck: Do not add orchestration solely because it appears in a course diagram.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 4: Design for an ordinary failure

Prerequisite: Bring your previous output: A packaging and complexity trade-off note.

Instruction: Assume a component can fail and trace the user effect. A database outage should produce a clear failure response, not a false booking confirmation. Monitoring should distinguish application health from successful end-to-end bookings. A manual fallback needs later reconciliation so a restored system does not duplicate or lose requests.

Practice task: Write a database-outage scenario with detection, user message, fallback owner and reconciliation steps.

Deliverable: A failure-mode and recovery playbook.

Acceptance check: The playbook never confirms a booking before durable recording and includes duplicate checks after recovery.

If stuck: An uptime check alone cannot verify that bookings are being saved.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 5: Sequence the migration

Prerequisite: Bring your previous output: A failure-mode and recovery playbook.

Instruction: Move in reversible steps: inventory the existing data, make a backup, test a sample import, validate totals and switch with a rollback point. State which system is authoritative at each stage. Running two uncontrolled write locations creates conflicting records. A migration plan should define success checks before the final cutover, even in a paper exercise.

Practice task: Plan a staged migration of 40 fictional existing bookings, with row-count checks, ownership and rollback criteria.

Deliverable: A migration and architecture review pack.

Acceptance check: The plan identifies a single source of truth and accounts for all 40 records.

If stuck: Do not call a migration complete merely because the new page loads.

Record your work, decisions and evidence:




Record your result against the acceptance check:



WORKED CASE
A simple browser–application–database design can meet the scenario. During a database failure, the application must avoid false confirmations; a manual intake log is reconciled by ID after recovery. Complexity is justified by requirements, not by the number of boxes in a diagram.

FINAL PROJECT
Deliver the architecture, responsibility matrix, packaging decision, failure playbook and migration plan. Explain what changes if weekly visitors grow tenfold and which assumptions must be measured first.

REQUIRED CRITICAL CHECK
The design has a persistent data path, truthful failure behavior and a controlled source of truth during migration.

SCORING
Score each of the five stage acceptance checks from 0–16 (0 missing/incorrect; 8 partially supported; 16 complete and evidenced). Score the final integrated project from 0–20 (0 missing; 10 incomplete handover; 20 complete, reproducible and consistent with the case). Target: at least 80/100 AND the critical check must pass. A total score never overrides a failed critical check.

SCOPE LIMIT
This is an architecture reasoning exercise, not a deployed, load-tested or security-certified system.

SOURCES AND ACCESS
Assigned public videos can be watched free. Complete the original case in a text editor, on paper or in a spreadsheet you already have. No paid course, exam or provider certificate is included.

Free Cloud Computing Course: Services and Virtualization
WikiFree: https://wikifree.com/courses/free-cloud-computing-course-services-and-virtualization/
Official source: https://www.youtube.com/playlist?list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ
Why selected: IBM public cloud lessons introduce service models, networking, packaging, observability and migration. Only lessons supporting the small-system design are required.

Stage 1 selected lessons:

1. Software as a Service (SaaS) Explained in 5 mins (5:23)
https://www.youtube.com/watch?v=20QUNgFIrK0&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=1

4. IaaS Explained (8:07)
https://www.youtube.com/watch?v=XRdmfo4M_YA&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=4

5. PaaS Explained (6:38)
https://www.youtube.com/watch?v=QAbqJzd0PEE&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=5

6. What is FaaS (Functions as a Service)? (10:52)
https://www.youtube.com/watch?v=EOIja7yFScs&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=6

Stage 2 selected lessons:

7. What is a Virtual Private Cloud? (4:51)
https://www.youtube.com/watch?v=NbkPRn1mqlU&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=7

15. What is Cloud Native? (4:37)
https://www.youtube.com/watch?v=fp9_ubiKqFU&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=15

Stage 3 selected lessons:

8. What are Microservices? (6:38)
https://www.youtube.com/watch?v=CdBtNQZH8a4&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=8

10. Containerization Explained (8:09)
https://www.youtube.com/watch?v=0qotVMX-J5s&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=10

11. Virtualization Explained (5:20)
https://www.youtube.com/watch?v=FZR0rG3HKIk&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=11

12. Containers vs VMs: What's the difference? (8:08)
https://www.youtube.com/watch?v=cjXI-yxqGTI&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=12

Stage 4 selected lessons:

14. Observability vs. APM vs. Monitoring (9:41)
https://www.youtube.com/watch?v=CAQ_a2-9UOI&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=14

18. What is Cloud Security? (10:17)
https://www.youtube.com/watch?v=jI8IKpjiCSM&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=18

Stage 5 selected lessons:

17. What is Cloud Migration? (4:47)
https://www.youtube.com/watch?v=yWByEVB0VJE&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=17

22. What is Multicloud? How Do You Manage It? (5:59)
https://www.youtube.com/watch?v=AjtdZ3gFRjU&list=PLOspHqNVtKAC-_ZAGresP-i0okHe5FjcJ&index=22

REUSE
Original WikiFree teaching text and synthetic fixtures are supplied for personal learning and adaptation with attribution. Provider lessons remain on their original sites and retain their own terms. No provider certificate is included.