As a cloud architect or IT administrator, when you plan to run an application inCompute Engine, you need to design a VM topology that you can provision andoperate efficiently.

Compute Engine offers a range of deployment options: for example, you coulddeploy a group of VMs that you manage as a single entity, or you could provisionand manage the VMs as individual resources. Each approach has distinct meritsand limitations. How do you choose an optimal deployment strategy?

1. Start by assessing the key requirements of your application.
2. Review the available deployment options and their relative merits.
3. Select a strategy that meets your requirements and makes optimal use of thecapabilities of Compute Engine.

Note: Compute Engine provides robust and flexible cloud infrastructure forhosting commercial off-the-shelf applications and for migrating workloads fromyour on-premises data centers. To learn about the hosting options inGoogle Cloud for other use cases, such as deploying serverless functions andrunning containerized applications in a Kubernetes cluster, seeApp Hosting on Google Cloud.

Assess your workload

Use the following questions to analyze the key requirements of theworkload that you want to deploy. Your answers will help you map thecapabilities of each deployment option (listed in the next section) to therequirements of your workload.

Important: When migrating an on-premises workload to the cloud, consider any special requirements for the cloud version of the application. For example, the on-premises deployment might run in a single data center, whereas you might need the cloud topology to span more than one Google Cloud zone for higher availability.

• Application state

  • Is the application stateful?

    • Astateful application stores certain data, such as the client orsession ID, until that data is no longer necessary. For example, inan online shopping app, the shopping cart service might storedetails of items that are added or removed as the user continuesshopping, and persist the final cart state when the user startsthe check-out process.
    • Astateless application does not need to store anyclient, transaction, or session data. For example, a web servermight close a session after serving the content that the clientrequested.

    To learn more about stateful and stateless applications, seeHow stateful workloads are different from stateless workloads.

  • Should any instance-specific metadata be preserved when your VMs rebootor when Compute Engine recreates (autoheals) the VMs?

• Provisioning

  • Should the VMs use a mix of machine types or images? For example, dosome VMs need memory-optimized machine types while the others usegeneral-purpose machine types?
  • Should the infrastructure scale automatically in tune with changes inload, so that you maintain an optimal balance between cost and responsetime?
  • Can all the VMs run within a single zone, VPC network, and subnet?
  • Should the application run in the same zone as certain other resources?For example, does the application require a low-latency connection witha database?

• Operations

  • Do you want to manage the VMs as a single group? For example, would youlike to automate rolling out application updates across all the VMs?
  • Do you need to use a custom or third-party tool to manage the VMs?
  • Do you need control over handling failed VMs? For example, if a VMfails, would you like it to remain stopped while you determine the rootcause for the failure?
  • Do you need control over the start-stop-suspend-resume sequence orschedule of your VMs? For example, to save cost, do you plan to stop theVMs during weekends or for certain hours of the day?

• Resilience

  • Does the application need protection against zonal failures? In otherwords, if a zone is down, would you like the application to continueserving requests from VMs in other zones in the region?
  • If a VM stops or crashes for any reason, or if the application doesn'trespond to requests, should Compute Engine recreate the VMautomatically?
  • Does the application need fixed internal or external IP addresses forthe host VMs?

Now that you've assessed your requirements, learn about the deployment optionsthat Compute Engine offers.

Review the available deployment options

Review and understand the features and relative advantages of theoptions that you can consider for deploying your workloads toCompute Engine.

Standalone VMs

With this option, you choose the machine type, image, disks, and otherattributes individually for each VM that you provision. And you manage the VMsas separate resources.

Unmanaged instance group

You can provision standalone VMs and add them to an instance group. You canthen use the unmanaged instance group as a backend to a load balancer.

Managed instance group (MIG)

A MIG is a group of identical or similarly configured instances that youprovision by using aninstance template.

• You can make a MIGstateful, so that specific disks or metadata arepreserved.

• For astateless MIG, you can enable autoscaling and configure a scalingpolicy.

• While creating a MIG, you can choose to deploy the VMs within a single zone,or distribute them across more than one zone in a region for highavailability.

The following table summarizes the key features of each deployment option.

Capability	Standalone VMs	Unmanaged instance group	Stateful MIG	Stateless MIG
Template-based provisioning of a group of VMs
Mix ofmachine types andimages
Fixed internal or external IP addresses
Automatic healing of failed VMs
Control over VMstart-stop andsuspend-resume operations
Setting a group of VMs as a load-balancer backend
Disk and metadata preservation, for stateful workloads
Controlled update of specific VMs
Automatic rolling update of all the VMs
Automatic (and predictive) horizontal scaling

The following diagrams show sample deployments side-by-side to help youunderstand the key differences.

Standalone VMs	Stateful MIG	Stateless MIG
This example shows three VMs created individually.	This example shows a MIG containing three similarly configured VMs, provisioned by using an instance template.	This example shows a MIG containing three identical VMs, provisioned by using an instance template.
Each VM in this example uses a distinct machine type, image, disks, and other attributes. The VMs were added individually to an unmanaged instance group.	The VMs in this example use a machine type and image defined in an instance template. A stateful policy ensures that the boot disks attached to all the VMs are stateful. Per-instance configurations add the required stateful data disks.	In this example, the VMs inherit the machine type and image from an instance template. The disks are recreated when the VM is updated or recreated. The MIG creates and deletes VMs automatically based on an autoscaling configuration.

You've now assessed your workload, reviewed the deployment options thatCompute Engine offers, and are ready to choose a deployment approach.

Select a deployment strategy

The recommendations discussed here are based on a mapping of specific workloadcharacteristics to the capabilities of each Compute Engine deploymentoption.

Use the following decision-making flow. If you prefer a visual guide, see thedecision tree later in this document.

1. Choose between standalone VMs and instance groups.

   Requirements	Recommended deployment strategy
   At least one of the following requirements isessential for your workload. The application must run on VMs that use a mix of machine types or images. The application needs fixed internal or external IP addresses for the host VMs. You need control over handling failed VMs. You need control over your VMs' start-stop or suspend-resume operations. You need to use a custom script or third-party tool to provision and remove VMs.	Choose standalone VMs. If all the standalone VMs can run in a single zone, VPC network, and subnet, consider adding the VMs to an unmanaged instance group. You can then use the unmanaged instance group as a backend to a load balancer. Skip the remainder of this decision-making flow.
   None of the above requirements is essential for your use case.	Use a MIG to set up a Compute Engine topology that is easy to manage, highly available, and scalable. Proceed to the next step.

2. Choose between a stateful and stateless MIG.

   Requirements	Recommended MIG type
   The application requires disk and metadata preservation; that is, the application is stateful.	Choose a stateful MIG, and configure the disks that Compute Engine should preserve during disruptive events like VM recreation, autohealing, and updates. Proceed to the next step.
   The application is not stateful.	Choose a stateless MIG, and take advantage of the autoscaling capability. During disruptive operations, Compute Engine recreates disks according to the instance template. Proceed to the next step.

3. Choose between a zonal and regional MIG.

   Requirements	Recommended MIG type
   The application must run in a single zone, or protection against zonal failures is not essential.	Choose a zonal MIG.
   The application must continue to run even when a zonal failure occurs.	Choose a regional MIG.

Important: Do review and consider the limitations of each MIG type.

Decision tree

The following diagram guides you through the factors to consider when decidingyour Compute Engine deployment strategy:

What's next

• Learn more aboutinstance templates.
• Learnhow stateful MIGs work.
• Learn more aboutregional MIGs.
• Create a MIG.
• Autoscale groups of instances.
• Migrate an existing workload to a stateful MIG.