WikiFree learning path 32 · Beginner
The cloud cartographer
Draw the boundary, then justify the trade-off.
Design a vendor-neutral small web application architecture and explain responsibilities, failure handling and a migration sequence.
Video duration uses the selected lessons only. Reading and practice times are planning estimates; repeat difficult work as needed.
A clear starting point
Who this is for
General understanding of websites and files; no coding or cloud account.
Your practical result
Design a vendor-neutral small web application architecture and explain responsibilities, failure handling and a migration sequence.
This is an architecture reasoning exercise, not a deployed, load-tested or security-certified system.
Access and cost
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.
The project pack contains an original workbook, case inputs, an evidence log and reference notes. Some technical paths include starter code and a runnable reference. Read the pack README before starting.
Three-minute readiness check
Answer first, then open each explanation. A missed answer identifies what to revisit; it does not stop you from starting.
Is every application a microservice system?
No.
Can a container replace a backup?
No. Packaging and durable data protection solve different problems.
What makes a trade-off explicit?
The chosen benefit, cost and alternative are documented.
The case you will work on
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.
| 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 |
These are supplied synthetic inputs, not observations from a real organization. Label assumptions and any additional data you create.
Keep an evidence trail
Save each stage output in the project folder. In evidence_log.csv, record the decision, the artifact or test that supports it, what failed, and the revision you made.
Your route from learning to evidence
- Stage 1Translate needs into responsibilitiesA hosting responsibility decision.55 minutes of original practice
- Stage 2Draw the application and data flowsA labeled application architecture.70 minutes of original practice
- Stage 3Evaluate packaging without overbuildingA packaging and complexity trade-off note.60 minutes of original practice
- Stage 4Design for an ordinary failureA failure-mode and recovery playbook.70 minutes of original practice
- Stage 5Sequence the migrationA migration and architecture review pack.65 minutes of original practice
- Final projectMake the evidence reviewableConnect the five stage outputs and test a change.180 minutes estimated
Progress stays in this browser. Tick a stage only after its evidence check passes. This is a personal checklist, not a certificate.
Why these source courses
The path uses selected material from courses already published on WikiFree. The original exercises below connect that material to one practical outcome. Follow only the listed assignments; completing the full source courses is optional.
IBM
Free Cloud Computing Course: Services and Virtualization
IBM public cloud lessons introduce service models, networking, packaging, observability and migration. Only lessons supporting the small-system design are required.
Access: Free Video
Certificate: Free video viewing; IBM certification is not included
Learn it, apply it, check it
Work in order. Every stage produces something the next stage uses. Revisit the repair instruction when a check fails.
Translate needs into responsibilities
General understanding of websites and files; no coding or cloud account.
The idea to use
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.
Watch the selected lessons
- 1. Software as a Service (SaaS) Explained in 5 mins5:23
- 4. IaaS Explained8:07
- 5. PaaS Explained6:38
- 6. What is FaaS (Functions as a Service)?10:52
Selected video time: 31m. Open this course on WikiFree.
Your 55-minute lab
Create a responsibility table for two hosting options and choose one for the workshop.
Save: A hosting responsibility decision..
Evidence check
The table names customer duties and a concrete reason for the choice.
If it fails: A list of product names without responsibilities is not a decision record.
Draw the application and data flows
Bring your previous output: A hosting responsibility decision.
The idea to use
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.
Watch the selected lessons
Selected video time: 9m. Open this course on WikiFree.
Your 70-minute lab
Draw the booking request and response, database write, administrator route and backup destination.
Save: A labeled application architecture..
Evidence check
Every stored booking has a clear write path and a defined persistent location.
If it fails: If arrows have no purpose or direction, label them with the data or request they carry.
Evaluate packaging without overbuilding
Bring your previous output: A labeled application architecture.
The idea to use
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.
Watch the selected lessons
- 8. What are Microservices?6:38
- 10. Containerization Explained8:09
- 11. Virtualization Explained5:20
- 12. Containers vs VMs: What's the difference?8:08
Selected video time: 28m. Open this course on WikiFree.
Your 60-minute lab
Compare a single application with a three-service alternative. Identify one benefit and two costs of the split.
Save: A packaging and complexity trade-off note..
Evidence check
The proposed design is proportional to the workload and names a future split trigger.
If it fails: Do not add orchestration solely because it appears in a course diagram.
Design for an ordinary failure
Bring your previous output: A packaging and complexity trade-off note.
The idea to use
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.
Watch the selected lessons
Selected video time: 20m. Open this course on WikiFree.
Your 70-minute lab
Write a database-outage scenario with detection, user message, fallback owner and reconciliation steps.
Save: A failure-mode and recovery playbook..
Evidence check
The playbook never confirms a booking before durable recording and includes duplicate checks after recovery.
If it fails: An uptime check alone cannot verify that bookings are being saved.
Sequence the migration
Bring your previous output: A failure-mode and recovery playbook.
The idea to use
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.
Watch the selected lessons
Selected video time: 11m. Open this course on WikiFree.
Your 65-minute lab
Plan a staged migration of 40 fictional existing bookings, with row-count checks, ownership and rollback criteria.
Save: A migration and architecture review pack..
Evidence check
The plan identifies a single source of truth and accounts for all 40 records.
If it fails: Do not call a migration complete merely because the new page loads.
A worked reference to compare
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.
Compare your reasoning as well as the result. If your answer differs, state the assumption or input that explains the difference. Reference notes are for checking after an attempt; copying them is not evidence of independent work.
Your final project
Your brief
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.
Time box: 3h 00m estimated. Extend it if a gate needs repair.
Hand in these artifacts
- A hosting responsibility decision.
- A labeled application architecture.
- A packaging and complexity trade-off note.
- A failure-mode and recovery playbook.
- A migration and architecture review pack.
- A short README: outcome, how to inspect or run the work, assumptions and limitations.
- A before-and-after change test and the completed evidence log.
Run a final review
- Use the supplied reference to reconcile the baseline result.
- Choose one relevant input or constraint to change. Write your expected effect before testing it.
- Run the calculation, walkthrough or test again and save the actual result.
- Ask a peer to inspect the evidence, or perform a separate self-review. Label which review you used.
- Score the work using the rubric and repair every critical failure.
Review rubric · 100 points
| Criterion | Points | Evidence to inspect |
|---|---|---|
| Practical outcome and case reasoning | 25 | Design a vendor-neutral small web application architecture and explain responsibilities, failure handling and a migration sequence. |
| Five stage checks | 30 | Award 6 points for each stage only when its stated gate is demonstrably met. |
| Traceable evidence | 20 | Artifacts, inputs and calculations or tests are reproducible; synthetic and simulated evidence is labelled. |
| Revision after a changed condition | 15 | Change one input or constraint, predict the effect, test it and record the result. |
| Handoff quality | 10 | A reviewer can find the files, follow the instructions and understand the remaining limitations. |
Completion target: at least 80/100, all five stage gates passed, and every critical issue below corrected. This is a learning benchmark, not an accredited qualification.
Critical issue: The design has a persistent data path, truthful failure behavior and a controlled source of truth during migration.
Before you go further
What will I be able to produce?
Design a vendor-neutral small web application architecture and explain responsibilities, failure handling and a migration sequence.
Is the whole path free?
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.
Do I need to finish every source course?
No. Follow the selected assignments at each stage. Source courses provide context, while the original case, labs and final review build the practical result. Extra study is optional.
What counts as completion?
Complete all five stage checks, earn at least 80/100 on the final rubric and correct every critical issue. This is an architecture reasoning exercise, not a deployed, load-tested or security-certified system.
Questions & discussion
Share a useful question or correction. Comments appear after moderation. Please avoid personal or sensitive information.