Google Cloud / Intermediate: Service Contracts and Operations / Lesson 7
Compute Engine and Instance Lifecycles
Choose VM responsibility, disk ownership, instance-group behavior, and rollout constraints as one operating contract.
On this page
Lesson goals
- Separate host management from guest/application responsibility.
- Distinguish instances, templates, disks, and managed groups.
- Model rollout availability without provisioning anything.
A virtual machine still has an operating system owner
Compute Engine provides virtual-machine infrastructure with documented machine, image, disk, network, and scheduling choices. Google manages the underlying platform, while the workload owner must plan guest configuration, application updates, identity, data protection, and observability under the selected service features. A VM being RUNNING is not proof that its application is ready or secure.
Choose a VM when its execution and operating-system requirements fit, not merely because it resembles an existing server. Record startup, shutdown, persistent state, licensing, supported images, and capacity needs. Machine families and availability vary by zone and current product support; a sample machine name is not a promise of available capacity.
An inspection command is still a real environment action
The illustrative command would request an instance description in an explicitly selected project and zone. It remains non-runnable here and has no fabricated output. A real operator would need approved credentials, the correct target, and relevant permission. Default CLI configuration is not a substitute for recording the intended project and zone in an operational review.
Read an actual instance description as one layer of evidence: guest identity, disks, network interfaces, scheduling, and state can explain a design. It does not prove that an application transaction succeeds or that backups restore. This course never invokes the command or inspects a configured cloud environment.
gcloud compute instances describe INSTANCE_NAME --project=PROJECT_ID --zone=ZONE
This command is documentation only. No CLI, credentials, API, or VM inspection is executed.
Templates describe instances; disks carry separate state
An instance template captures configuration used to create managed instances. A managed instance group can support autoscaling, autohealing, controlled updates, and regional distribution, according to its mode and configuration. An unmanaged group organizes VMs that remain individually managed. Do not infer identical lifecycle behavior from the common phrase instance group.
Disks, snapshots, images, and application state have different roles. A stateful MIG configuration preserves documented per-instance state; it does not turn an arbitrary database into a replicated correct service. Deletion policies, disk attachment, and restoration requirements must be explicit. Recreating a VM from a template can lose local state that was never externalized or protected.
Availability during change needs a capacity budget
The offline program models a desired fleet of six with one unavailable slot and two surge slots. It computes a minimum of five available and a maximum of eight total under that declared model. This is not an exact simulator of every MIG update policy or quota rule. It exposes the arithmetic an application owner should compare with required serving capacity.
A health check used for load balancing can redirect traffic, while an autohealing check can trigger instance recreation. Their purposes and aggressiveness should differ appropriately. A bad application-specific signal can cause destructive restart loops. Test readiness meaning and startup grace rather than treating any HTTP200 as proof that replacement is safe.
desired = 6
max_unavailable = 1
max_surge = 2
assert 0 <= max_unavailable <= desired
print(f"minimum_available={desired - max_unavailable} maximum_total={desired + max_surge}")
minimum_available=5 maximum_total=8
The declared model permits five serving slots and up to eight total slots; it creates no VM.
A lifecycle plan includes repair, patching, and recovery
Define guest patching, image provenance, boot dependencies, identity permissions, disk protection, and controlled rollback. Spot or other interruptible capacity has documented interruption semantics and is not a substitute for recovery design. Autoscaling responds to configured signals and constraints; it does not create unlimited quota or fix a serialized database bottleneck.
Use approved evidence for instance health, application SLIs, rollout progress, and backup tests before a real change. Keep resource cleanup separate from incident experimentation. This lesson validates only a local arithmetic model and describes the review a live implementation still needs; no machine, disk, image, or group is created, restarted, or deleted.
Common errors and fixes
RUNNING is reported as application readiness.
- Why it happens
- VM state and service health were conflated.
- How to fix it
- Define and inspect an application-specific readiness signal.
- Prevent it next time
- Separate infrastructure and user-facing indicators.
Recreation loses a required file.
- Why it happens
- The lifecycle relied on unprotected local state.
- How to fix it
- Externalize or protect state under an explicit disk/recovery design.
- Prevent it next time
- Test recreation assumptions before a real rollout.
A rollout has insufficient survivors.
- Why it happens
- Update limits were chosen without serving-capacity analysis.
- How to fix it
- Compare minimum available capacity with the workload requirement.
- Prevent it next time
- Include quota and startup constraints in review.
Check your understanding
1. A fleet needs six healthy instances at peak, but its update model allows one of six to be unavailable. What follows?
Show worked solution
The model can leave only five serving instances, below the stated peak requirement. Add justified headroom, change the update policy, schedule under an approved lower-load condition, or define accepted degradation. Check actual MIG semantics, quotas, startup, and dependency capacity before implementation. The local subtraction identifies a design inconsistency but does not execute a rollout.
2. Why should load-balancing and autohealing health checks not be assumed interchangeable?
Show worked solution
One controls traffic eligibility, while the other can cause an instance to be replaced. An aggressive transient failure signal may be acceptable for steering requests yet harmful if it repeatedly recreates instances. Define what each checks, how startup is treated, and the consequence of failure. Validate the applicationโs recovery and state assumptions under the approved lifecycle process.
Key takeaways
- VM, disk, template, and application lifecycles are different.
- Managed groups automate configured behavior rather than infer application correctness.
- A rollout needs capacity and state-recovery arguments.