Unmanaged instance groups allow you to load balance across a fleet of VMs
that you manage yourself.

Managed instance groups (MIGs)

Managed instance groups (MIGs) are suitable for stateless serving workloads
(such as a website frontend) and for batch, high-performance, or high-throughput
compute workloads (such as image processing from a queue).

Benefits

MIGs offer the following advantages:

High availability

Keeping instances running — If an instance in the group stops,
crashes, or is deleted by an action other than an instance group
management command (for example, an intentional scale-down), the
MIG automatically recreates that instance in accordance with the original
instance's specification (same instance name, same template) so that the
instance can resume its work.

Autohealing — You can also set up an autohealing policy that relies on
an application-based health check, which periodically verifies that your
application is responding as expected on each of the MIG's instances. If
an application is not responding on an instance, that instance is
automatically recreated. Checking that an application responds is more
precise than simply verifying that an instance is up and running.

Regional (multi-zone) coverage — Regional managed instance groups
allow you to spread application load across multiple zones. This
replication protects against zonal failures. If that happens, your
application can continue serving traffic from instances running in the
remaining available zones in the same region.

Load balancing — Managed instance groups work with load balancing
services to distribute traffic across all of the instances in the group.

Scalability — When your applications require additional compute resources,
autoscaled MIGs can automatically grow the number of instances in the group to
meet demand. If demand drops, autoscaled MIGs can automatically shrink to
reduce your costs.

Automated updates — The managed instance group auto-updater allows you to
easily and safely deploy new versions of software to instances in your MIG,
supporting a flexible range of rollout scenarios such as rolling updates and
canary updates. You can control the speed and scope of deployment as well as
the level of disruption to your service.

Overview of MIG capabilities and common workloads

Autohealing

Managed instance groups maintain high availability of your applications by
proactively keeping your instances available, which means in RUNNING state. A
managed instance group will automatically recreate an instance that is not
RUNNING. However, relying only on instance state may not be sufficient. You
may want to recreate instances when an application freezes, crashes, or runs
out of memory.

Application-based autohealing improves application availability by
relying on a health checking signal that detects application-specific issues
such as freezing, crashing, or overloading. If a health check determines that an
application has failed on an instance, the group automatically recreates that
instance.

Health checking

The health checks used to monitor managed instance groups are similar to the
health checks used for load balancing, with some differences in behavior. Load
balancing health checks help direct
traffic away from non-responsive instances and toward healthy instances; these
health checks do not cause Compute Engine to recreate instances. On
the other hand,
managed instance group health checks
proactively signal to delete and recreate instances that become UNHEALTHY.

For the majority of scenarios, use separate health checks for load balancing
and for autohealing. Health checking for load balancing can and should be more
aggressive since these health checks determine whether an instance receives user
traffic. Since customers might rely on your services, you want to catch
non-responsive instances quickly so you can redirect traffic if necessary. In
contrast, health checking for autohealing will cause MIGs to
proactively replace failing instances so this health check should be more
conservative than a load balancing health check.

Both types offer all of the advantages of managed instance groups.
Regional MIGs add higher availability by spreading application load across
multiple zones, which protects your workload against zonal failure, and regional
MIGs offer more capacity, with a maximum of 2000 instances per regional group.

Load balancing

GCP load balancing can use instance groups to serve traffic.
Depending on the type of load balancer you
choose, you can add instance
groups to a target pool or to a backend service.

Autoscaling

Managed instance groups support autoscaling that dynamically adds
or removes instances from a managed instance group in response to increases
or decreases in load. You turn on autoscaling and configure an autoscaling
policy to specify how you want the group to scale. Autoscaling policies include
scaling based on CPU utilization, load balancing capacity, Stackdriver
monitoring metrics, or, for zonal MIGs, by a queue-based workload like
Google Cloud Pub/Sub.

Auto-updating

You can easily and safely deploy new versions of software to instances in a
managed instance group. The rollout of an update happens automatically based
on your specifications: you can control the speed and scope of the update
rollout in order to minimize disruptions to your application. You can optionally
perform partial rollouts which allows for canary testing.

Groups of preemptible instances

For workloads where minimal costs are more important than speed of execution,
you can reduce the cost of your workload by using
preemptible VM instances
in your instance group. Preemptible instances last up to 24 hours, and are
preempted gracefully - your application will have 30 seconds to exit correctly.
Preemptible instances can be deleted at any time, but autohealing will bring the
instances back when preemptible capacity becomes available again.

Containers

You can simplify application deployment by deploying containers to instances in
managed instance groups. When you specify a container image
in an instance template and then use that template to create a managed instance
group, each instance will be created with a container-optimized OS that includes
Docker, and your container will start automatically on each instance in the
group. See
Deploying containers on VMs and managed instance groups.

Network

By default, instances in the group will be placed in the default network and
randomly assigned IP addresses from the regional range.
Alternatively, you can restrict the IP range of the group by creating a
custom mode VPC network and
subnet that uses a smaller IP range, then specifying this subnet in the instance
template.

Demo of MIG capabilities

The following 45-minute video presentation, recorded at GCP NEXT
'18, contains demos and best practices for setting up, running, and updating
scalable and highly-available deployments using Compute Engine managed
instance groups.

You will see how to deploy a container to a managed instance group, set up an
autohealing policy, use a regional group to protect against a zonal failure,
configure autoscaling to meet CPU targets and queue-based demands, and manage
canary and rolling updates.

Unmanaged instance groups

Unmanaged instance groups can contain heterogeneous instances that you can
arbitrarily add and remove from the group. Unmanaged instance groups do not
offer autoscaling, auto-healing, rolling update support, or the use of instance
templates and are not a good fit for deploying highly available and scalable
workloads. Use unmanaged instance groups if you need to apply
load balancing to groups of
heterogeneous instances or if you need to manage the instances yourself.