Practical lab guide
Lab: choose a hosting model for MicroBank
Compare local and proposed cloud operating boundaries for MicroBank without creating resources.
Predict before you try
Does moving an application image to a cloud service also move its data and operating responsibilities?
Try it: Start with the MicroBank requirement →On this page
Start with the MicroBank requirement
Use the versioned MicroBank introduction. Identify Accounts, Ledger, their databases, messaging, and the optional browser. Draw the accepted request and later Ledger result as separate checkpoints. This is a design exercise; a full application run is not required here.
The current observed environment is your Linux learning machine and the fixtures completed so far. The MicroBank deployment is a proposed target until the DevOps implementation lab supplies runtime evidence.
Compare two viable proposals
Compare the dedicated future local application profile with one possible cloud alternative. A static host can serve frontend assets or an evidence page; it cannot by itself supply the backend processes, databases, and message route.
| Decision | Local application proposal | Future cloud proposal |
|---|---|---|
| Client entry | Actual host-side URL to verify later | Intended https://microbank.learnwithsk.dev/ entry and separately documented API route |
| Execution | Accounts, Ledger, database, and emulator processes | Documented compute/runtime and dependency capabilities to verify |
| Network | Caller context, listeners, published ports, service names | Entry, application-to-data paths, and intended access controls |
| Maintenance | Host/runtime/application owners | Provider/customer boundaries per selected service |
| Persistence | Database storage separate from source and logs | Data storage, backups, restore scope, and retained evidence |
| Failure | Process, configuration, storage, or message dependency | Proposed service/network/data failure boundaries |
| Cost/capacity | Measured local use when implemented | Billing dimensions and limits to verify; no invented prices |
| Retirement | Named process/profile cleanup with data retention | Resource/state ownership and explicit retained-data plan |
Name the deployment and service model. Keep DNS status, HTTPS response, and backend operation as separate facts. A resolving hostname does not tell you where Accounts runs or whether its data can be recovered.
Test a requirement change
First propose a VM-operated backend with self-managed database software. Now propose a managed database. Which engine/OS maintenance responsibilities move, and which schema, identity, network, backup/restore, and application checks remain? Mark product-specific answers unverified until supported by that service's documentation.
Next ask whether a split across cloud environments solves a real requirement. If none exists, record that conclusion. A local source checkout plus a public project page does not establish hybrid application operation.
Acceptance and handoff
Keep the component inventory, two proposals, responsibility/network/storage table, and unresolved verification list. Distinguish observed local fixtures from planned application operation. No resources are created, so cleanup is limited to your disposable notes if you retire them.
Continue to Linux filesystem and permissions, apply its observations in the MicroBank readiness project, then develop the cloud design in Cloud Foundations.
Apply this to MicroBank
Keep the completed MicroBank hosting comparison with the system map. Mark runtime compatibility, network access, restore behavior, and actual cost as unresolved until the selected environment supplies evidence. Carry those questions into Cloud Foundations before building the delivery automation in DevOps Foundations.
Keep this observation in the MicroBank readiness project.
Sources
NIST deployment models↗, service-model comparison↗, and shared-responsibility example↗. The checklist above describes what to collect; it does not report a deployed or verified hosting service.
Prove what you learned
Inspect the result
Save the component/owner decision, a denied or failed path, and the missing verification.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Change one design requirement and revise only the affected decisions; state the trade-off.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Start with the MicroBank requirement”.
- Save the component/owner decision, a denied or failed path, and the missing verification.
- Explain the transfer challenge and retain the same verification question.
Hint
Separate runtime, identity, network, data, messaging and recovery ownership.
Answer guide: compare after predicting
No. Each boundary needs its own decision and evidence; a design is not a deployment.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall the source-derived MicroBank component map and cloud service responsibility model. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.