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 one site under two service choices

Assume a personal site needs only generated HTML, CSS, and images. On a rented VM, you install/configure the operating system and web server, publish files, manage access, and arrange patching and recovery. The provider operates physical infrastructure, but cannot infer your intended file permissions or content backup.

On a managed static publishing service, the operator usually manages the serving platform. You still decide who can publish, which content is public, how a domain connects, what usage is acceptable, and how to restore the source/content. The exact TLS, logging, backup, and deployment behavior must be checked for the product. “Managed” does not mean every responsibility has disappeared.

Now change one requirement: the site executes PHP for each request. A static-only host cannot execute that runtime merely because you upload a .php file. You need a compatible managed runtime or a VM/container arrangement that supplies it. The service-model label helps identify questions, but the product's documented capabilities decide whether it fits.

Try filling this ownership comparison without choosing a vendor:

For SaaS, such as a ready-to-use publishing application, you consume the application itself rather than supply its runtime. Account permissions, data policy, configuration, and export still need an owner. Service categories can overlap in a larger solution; identify the particular service being discussed.

Make five decisions before deploying

For a proposed personal site, record:

1. Execution: generated HTML only, or a PHP runtime? A static host does not execute PHP source.
2. Identity and access: who publishes, who reads, and where credentials are stored.
3. Availability and recovery: what failure the design tolerates and how source/content are restored.
4. Capacity and cost: what can grow—requests, storage, compute, outbound transfer—and how usage is observed.
5. Exit: how to stop publishing, remove resources, and retain your source and content.

Answer these as design questions. You do not need a provider account or deployed resource, and you will need to check current pricing and any free-tier terms before using a service. A budget notification is not a universal hard spending cap; verify the chosen service's controls before provisioning.

A useful answer to “who patches it?” names the component. The physical host, guest OS, language runtime, application dependencies, and your own content may have different owners. For the local OrbStack site, you patch distribution userspace while OrbStack maintains its shared kernel; a future cloud proposal changes that division according to the selected service.

Self-check: if the provider handles TLS certificates, have you also solved accidental publication of private notes? No. Certificate management and content access are separate. Carry the comparison into the design lab without creating an account or resource.

Checkpoint

For one VM-hosted site and one managed-site proposal, assign an owner for physical infrastructure, guest OS/runtime, application dependencies, identity, DNS/HTTPS, content backups, and usage monitoring. Mark service-specific unknowns rather than guessing.

Continue to the hosting decision lab. Provider-specific AWS IAM, networking, Terraform, and local cloud emulation stay in DevOps foundations.