1. Overview
   1. An instance group is a collection of virtual machine (VM) instances that can be managed as a single entity
   2. Compute Engine offers two kinds of VM instance groups, managed and unmanaged
   3. Managed instance groups (MIGs) operate apps on multiple identical VMs
   4. Workloads can be made scalable and highly available by taking advantage of automated MIG services
   5. MIG services includes autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating
   6. Each managed instance in a MIG is created from an instance template
   7. Unmanaged instance groups load balance across a fleet of VMs that are self managed
2. Managed instance groups
   1. Managed instance groups (MIGs) are suitable for stateless serving workloads, such as a website frontend
   2. Stateless batch, high-performance, or high-throughput compute workloads, such as image processing from a queue
   3. Stateful applications, such as databases, legacy applications, and long-running batch computations with checkpointing
   4. A zonal MIG deploys instances to a single zone
   5. A regional MIG deploys instances to multiple zones across the same region
   6. Both types offer all of the advantages of MIGs
   7. Regional MIGs add higher availability by spreading application load across multiple zones, which protects workload against zonal failure
   8. Regional MIGs offer more capacity, with a maximum of 2,000 instances per regional group
   9. Google Cloud load balancing can use instance groups to serve traffic
   10. Depending on the type of load balancer chosen, instance groups can be added to a target pool or to a backend service
   11. MIGs support autoscaling that dynamically adds or removes instances from the MIG in response to increases or decreases in load
   12. Turn on autoscaling and configure an autoscaling policy to specify how the group scales
   13. Autoscaling policies include scaling based on CPU utilization, load balancing capacity, Cloud Monitoring metrics
   14. For zonal MIGs, autoscaling policies includes using a queue-based workload like Pub/Sub
   15. Enables easy and safe deployment of new versions of software to instances in a MIG
   16. The rollout of an update happens automatically based on specifications
   17. Control the speed and scope of the update rollout in order to minimize disruptions to the application
   18. Optionally perform partial rollouts, which allows for canary testing
   19. Build highly available deployment of stateful workloads on VMs using stateful managed instance groups (stateful MIGs)
   20. Stateful workloads include applications with stateful data or configuration, such as databases, legacy monolith applications, and long-running batch computations with checkpointing
   21. Improve uptime and resiliency with autohealing, auto-updating, and multi-zone deployments, while preserving each instance's unique state, including customizable instance name, persistent disks, and metadata
   22. For workloads where minimal costs are more important than speed of execution, reduce the cost of workload by using preemptible VM instances in instance group
   23. Preemptible instances last up to 24 hours, and are preempted gracefully— application has 30 seconds to exit correctly
   24. Preemptible instances can be deleted at any time, but autohealing will bring the instances back when preemptible capacity becomes available
   25. Simplify application deployment by deploying containers to instances in managed instance groups
   26. When a container image is specified in an instance template used to create a managed instance group, each VM is created with a container-optimized OS that includes Docker, and container starts automatically on each VM in the group
   27. A managed instance group must reference an existing instance template
   28. The instance template defines the VPC network and subnet that member instances use
   29. For auto mode VPC networks, the subnet can be omitted.
   30. This instructs Google Cloud to select the automatically-created subnet in the region specified in the template
   31. If a VPC network is omitted, Google Cloud attempts to use the VPC network named default.
3. Benefits
   1. If a VM in the group stops, crashes, or is deleted by an action other than an instance group management command, the MIG automatically recreates that VM in accordance with the original instance's specification
   2. Autohealing policies that rely on an application-based health check can be setup to periodically verify that the app responds as expected on each of the MIG's instances
   3. If an app is not responding on a VM, that VM is automatically recreated
   4. Checking that an app responds is more precise than simply verifying that a VM is up and running
   5. Regional MIGs spread app load across multiple zones
   6. Multi zonal replication protects against zonal failures
   7. MIGs work with load balancing services to distribute traffic across all of the instances in the group
   8. When an application requires additional compute resources, autoscaled MIGs can automatically grow the number of instances in the group to meet demand
   9. If demand drops, autoscaled MIGs can automatically shrink to reduce costs
   10. The MIG automatic updater safely deploy new versions of software to instances in MIG and supports a flexible range of rollout scenarios, such as rolling updates and canary updates
   11. The speed and scope of deployment as well as the level of disruption to service can be controlled
   12. MIGs can be used for building highly available deployments and automating operation of applications with stateful data or configuration, such as databases, DNS servers, legacy monolith applications, or long-running batch computations with checkpointing
   13. Stateful MIGs preserve each instance's unique state (instance name, attached persistent disks, and metadata) on machine restart, recreation, auto-healing, or update
4. Autohealing
   1. Managed instance groups maintain high availability of applications by proactively keeping instances available, which means in RUNNING state
   2. A MIG automatically recreates an instance that is not RUNNING, although relying only on VM state may not be sufficient
   3. It may be desirable to recreate instances when an application freezes, crashes, or runs out of memory
   4. Application-based autohealing improves application availability by relying on a health checking signal that detects application-specific issues such as freezing, crashing, or overloading
   5. If a health check determines that an application has failed on a VM, the group automatically recreates that VM instance
   6. The health checks used to monitor MIGs are similar to the health checks used for load balancing, with some differences in behavior
   7. Load balancing health checks help direct traffic away from non-responsive instances and toward healthy instances
   8. These health checks do not cause Compute Engine to recreate instances
   9. Managed instance group health checks proactively signal to delete and recreate instances that become UNHEALTHY
   10. For the majority of scenarios, use separate health checks for load balancing and for autohealing
   11. Health checking for load balancing can and should be more aggressive because these health checks determine whether an instance receives user traffic
   12. In contrast, health checking for autohealing causes MIGs to proactively replace failing instances, so this health check should be more conservative than a load balancing health check
5. Umanaged
   1. Unmanaged instance groups can contain heterogeneous instances that can be arbitrarily added and removed from the group
   2. Unmanaged instance groups do not offer autoscaling, autohealing, rolling update support, multi-zone support, or the use of instance templates
   3. Unmanaged instance groups are not a good fit for deploying highly available and scalable workloads
   4. Use unmanaged instance groups to apply load balancing to groups of heterogeneous instances, or to self manage instances
6. Instance templates
   1. An instance template is a resource used to create VM instances and managed instance groups
   2. Instance templates define the machine type, boot disk image or container image, labels, and other instance properties
   3. Use an instance template to create a managed instance group or to create individual VM instances
   4. Instance templates are a convenient way to save a VM instance's configuration so it can be used later to create new VM instances or groups of VM instances
   5. Instance templates are designed to create instances with identical configurations
   6. It is not possible to update an existing instance template or change an instance template after it has been created
   7. If an instance template goes out of date, or changes made to the configuration, create a new instance template
   8. Can override instance template fields when creating a VM instance from an instance template
   9. An instance template is a global resource that is not bound to a zone or a region
   10. Some zonal resources are specified in an instance template, which restricts the template to the zone where that resource resides
   11. Including a read-only persistent disk from us-central1-b in an instance template, implies the template cannot be used in any other zone because that specific disk exists only in zone us-central1-b
   12. Labels defined within an instance template are applied to all instances created from that instance template
   13. Labels do not apply to the instance template itself