Cloud service models and shared responsibility

Ask what you operate

Deployment models describe the environment; service models describe the capability being consumed. A service can be public-cloud infrastructure while exposing only a private network endpoint.

The exact boundary depends on the product and contract. A hosted VM and a managed publishing service are not interchangeable just because both display a website. Google Cloud's service-model comparison↗.

Carry the Linux lifecycle forward

With an IaaS VM, guest patching and application configuration remain operating tasks even when the provider maintains physical infrastructure. With a managed runtime, some patching shifts to the service operator, but vulnerable application dependencies and excessive permissions can remain your responsibility. This is why the previous virtualization module still matters.

For a concrete provider example, AWS separates its infrastructure responsibilities from customer responsibilities that vary by selected service. The model does not excuse insecure customer configuration or unprotected data. AWS shared responsibility↗.

Compare MicroBank components under two service choices

A MicroBank proposal needs application execution, database storage, and messaging. Serving the React frontend's generated files addresses one component; it does not execute the Accounts API, the Ledger process, or their databases. A static evidence page can teach HTTP without pretending to supply those capabilities.

Compare a VM-operated design with a managed-runtime/managed-database proposal. On a VM, identify who installs and patches the guest OS, language runtimes, and database software. With managed services, check the documented boundary for each product. Application dependencies, schema/query behavior, access configuration, and recovery decisions still need owners.

SaaS means consuming a ready-to-use application. Using a SaaS collaboration tool for the project does not make your own MicroBank API a managed SaaS runtime. Identify the particular service whose responsibility is being discussed.

Make five decisions before deploying

For the proposed MicroBank profile, record:

1. Execution: which process runs Accounts, Ledger, the optional frontend, and messaging dependencies?
2. Identity and access: who changes configuration and which identity each workload uses?
3. Availability and recovery: which failures are in scope and how data plus the user operation are verified?
4. Capacity and cost: which compute, storage, requests, and transfer can grow, and how usage will be measured?
5. Exit: which named resources can stop, what data is retained, and how retirement is verified?

This is an account-free design exercise. Mark product compatibility, actual prices, and unmeasured recovery behavior as unknown until checked against the selected service and environment. Budget notifications and actual spending controls are different capabilities.

A useful answer to “who patches it?” names the layer. In the local OrbStack machine, userspace package work differs from OrbStack's shared-kernel maintenance. A future managed database changes another boundary; it does not prove that a deposit reaches Ledger correctly.

Checkpoint

For a VM-operated MicroBank proposal and a managed-service alternative, assign owners for physical infrastructure, OS/runtime, application dependencies, identity, DNS/HTTPS, database recovery, messaging, and usage monitoring. Mark service-specific unknowns.

Continue to the hosting decision lab. Cloud Foundations develops this map; DevOps Foundations implements the dedicated local application profile.

Apply this to MicroBank

Take Accounts and its PostgreSQL dependency separately. For a VM proposal, identify guest OS, runtime, database, configuration, identity, and recovery owners. For a managed-runtime/managed-database proposal, mark which responsibilities shift and which still belong to the application team. The account-free exercise produces a responsibility map; it does not verify service compatibility or deploy MicroBank.

Keep this observation in the MicroBank readiness project.