This document can help you plan and design the deployment phase of yourmigration to Google Cloud. After you've assessed your currentenvironment, planned the migration to Google Cloud, and built yourGoogle Cloud foundation, you can deploy your workloads.

This document is part of the following multi-part series about migrating toGoogle Cloud:

• Migrate to Google Cloud: Get started
• Migrate to Google Cloud: Assess and discover your workloads
• Migrate to Google Cloud: Plan and build your foundation
• Migrate to Google Cloud: Transfer your large datasets
• Migrate to Google Cloud: Deploy your workloads (this document)
• Migrate to Google Cloud: Migrate from manual deployments toautomated, containerized deployments
• Migrate to Google Cloud: Optimize your environment
• Migrate to Google Cloud: Best practices for validating a migration plan
• Migrate to Google Cloud: Minimize costs

The following diagram illustrates the path of your migration journey.

The deployment phase is the third phase in your migration to Google Cloudwhere you design a deployment process for your workloads.

This document is useful if you're planning a migration from an on-premisesenvironment, from a private-hosting environment, from another cloud provider toGoogle Cloud, or if you're evaluating the opportunity to migrate and wantto explore what it might look like.

In this document, you review the different deployment process types, in orderof flexibility, automation, and complexity, along with criteria on how to pickan approach that's right for you:

1. Deploy manually.
2. Deploy with configuration management (CM) tools.
3. Deploy by using container orchestration tools.
4. Deploy automatically.

Before you deploy your workloads, plan and design your deployment phase. First,you should evaluate the different deployment process types that you implementfor your workloads. When you evaluate deployment process types, you can decideto start with a targeted process and move to a more complex one in the future.This approach can lead to quicker results, but can also introduce friction whenyou move to a more advanced process, because you have to absorb the technicaldebt you accumulated while using the targeted process. For example, if you movefrom fully manual deployments to an automated solution, you might have to manageupgrades to your deployment pipeline and apps.

While it's possible to implement different types of deployment processesaccording to your workloads' needs, this approach can also increase thecomplexity of this phase. If you implement different types of deploymentprocesses, you can benefit from the added flexibility, but you might needexpertise, tooling, and resources tailored to each process, which translates tomore effort on your side.

Deploy manually

A fully manual deployment is backed by a provisioning, configuration, anddeployment process that is completely non-automated. While there might bespecifications and checklists for each step of the process, there is noautomated check or enforcement of those specifications. A manual process isprone to human error, not repeatable, and its performance is limited by thehuman factor.

Fully manual deployment processes can be useful, for example, when you need toquickly instrument an experiment in a sandboxed environment. Setting up astructured, automated process for an experiment that lasts minutes canunnecessarily slow down your pace, especially in the early stages of yourmigration, when you might lack the necessary expertise in the tools andpractices that let you build an automated process.

While this limitation isn't the case with Google Cloud, fully manualdeployments might be your only option when dealing with bare metal environmentsthat lack the necessary management APIs. In this case, you cannot implement anautomated process due to the lack of the necessary interfaces. If you have alegacy virtualized infrastructure that doesn't support any automation, you mightbe forced to implement a fully manual process

We recommend that you avoid a fully manual deployment unless you have no otheroption.

You can implement a fully manual provisioning, configuration, and deploymentprocess by using tools, such asGoogle Cloud console,Cloud Shell,Cloud APIs,andGoogle Cloud CLI.

Deploy with configuration management tools

CM tools let you configure an environment in a repeatable and controlled way.These tools include a set of plugins and modules that already implement commonconfiguration operations. These tools let you focus on the end state that youwant to achieve for your environment, rather than implementing the logic toreach that end state. If the included operations set isn't enough, CM toolsoften feature an extension system that you can use to develop your own modules.While these extensions are possible, try to use the predefined modules andplugins where applicable, to avoid extra development and maintenance burden.

You use CM tools when you need to configure environments. You can also use themto provision your infrastructure and to implement a deployment process for yourworkloads. CM tools are a better process compared to a fully manualprovisioning, configuration, and deployment process because it's repeatable,controlled, and auditable. However, there are several downsides, because CMtools aren't designed for provisioning or deployment tasks. They usually lackbuilt-in features to implement elaborate provisioning logic, such as detectingand managing differences between the real-world state of your infrastructure andthe wanted state, or rich deployment processes, such as deployments with nodowntime orblue-green deployments.You can implement the missing features using the previously mentioned extensionpoints. These extensions can result in extra effort and can increase the overallcomplexity of the deployment process, because you need the necessary expertiseto design, develop, and maintain a customized deployment solution.

You can implement this type of provisioning, configuration, and deploymentprocess by using tools such asAnsible,Chef,Puppet,andSaltStack.

A basic deployment process that uses CM tools can prepare runtime environmentsand deploy workloads in those environments. For example, your process mightcreate a Compute Engine instance, install the required software, anddeploy your workloads. It takes time to configure a runtime environment thatsupports your workloads. To reduce the amount of time needed to configure aruntime environment, you can implement a process that runs CM toolsto produce a template, such as an operating system (OS) image. You can use thistemplate to create instances of your runtime environment that are ready for yourworkloads. For example, you can useCloud Build to build Compute Engine images.These images are often calledgolden images orsilver images, both of whichare immutable templates, such as OS images, that you create for your runtimeenvironments. The difference between the two dependson the amount of work a deployment process must complete before the images canrun a workload:

• Golden image: A template that you createfor your runtime environments or prepare from a base template. Golden imagesinclude all data and configuration information that your runtime environmentsneed to accomplish their assigned tasks. You can prepare several types ofgolden images to accomplish different tasks. Synonyms for golden image typesincludeflavors,spins, andarchetypes.
• Silver image: A template that you createfor your runtime environments by applying minimal changes to a golden image ora base template. Runtime environments running a silver image complete theirprovisioning and configuration upon the first boot, according to the needs ofthe use cases that those runtime environments must support.

Deploy by using container orchestration tools

If you already invested, or plan to invest in the containerization of yourworkloads, you can use a container orchestration tool to deploy yourworkloads.

A container orchestration tool takes care of managing the infrastructureunderpinning your environment, and supports a wide range of deploymentoperations and building blocks to implement your deployment logic that you canuse when the built-in ones aren't enough. By using these tools, you can focus oncomposing the actual deployment logic using the provided mechanisms, instead ofhaving to implement them.

Container orchestration tools also provide abstractions that you can use togeneralize your deployment processes to different underlying environments, soyou don't have to design and implement multiple processes for each of yourenvironments. For example, these tools usually include the logic for scaling andupgrading your deployments, so you don't have to implement them by yourself. Youcan even start leveraging these tools to implement your deployment processes inyour current environment, and you can then port them to the target environment,because the implementation is largely the same, by design. By adopting thesetools early, you gain the experience in administering containerizedenvironments, and this experience is useful for your migration toGoogle Cloud.

You use a container orchestration tool if your workloads are alreadycontainerized or if you can containerize them in the future and you plan toinvest in this effort. In the latter case, you should run a thorough analysis ofeach workload to determine the following:

• Ensure that a containerization of the workload is possible.
• Assess the potential benefits that you could gain by containerizing theworkload.

If the potential pitfalls outweigh the benefits of containerization, you shouldonly use a container orchestration tool if your teams are already committed tousing them and if you don't want to manage heterogeneous environments.

For example, data warehouse solutions aren't typically deployed using containerorchestration tools, because they aren't designed to run in ephemeralcontainers.

You can implement this deployment process usingGoogle Kubernetes Engine (GKE) on Google Cloud. If you're interested in a serverless environment, you canuse tools, such asCloud Run.

Deploy automatically

Regardless of the provisioning, configuration, deployment, and orchestrationtools you use in your environment, you can implement fully automated deploymentprocesses to minimize human errors and to consolidate, streamline, andstandardize the processes across your organization. You can also insert manualapproval steps in the deployment process if needed, but every step isautomated.

The steps of a typical end-to-end deployment pipeline are as follows:

1. Code review.
2. Continuous integration (CI).
3. Artifact production.
4. Continuous deployment (CD), with eventual manual approvals.

You can automate each of those steps independently from the others, so you cangradually migrate your current deployment processes towards an automatedsolution, or you can implement a new process directly in the target environment.For this process to be effective, you need testing and validation procedures ineach step of the pipeline, not just during the code review step or the CIstep.

For each change in your codebase, you should perform a thorough review toassess the quality of the change. Most source code management tools have atop-level support for code reviews. They also often support the automaticcreation and initialization of reviews by looking at the source code area thatwas modified, provided that you configured the teams responsible for each areaof your codebase. In each review you can also run automated checks on the sourcecode, such aslintersandstatic analyzers to enforce consistency and quality standards across the codebase.

After you review and integrate a change in the codebase, the CI tool canautomatically run tests, evaluate the results, and then notify you about anyissues with the current build. You can add value to this step by following atest-driven development process for a complete test coverage of the features of each workload.

For each successful build, you can automate the creation of deploymentartifacts. Such artifacts represent a ready-to-deploy version of your workloads,with the latest changes. As part of the artifact creation step, you can alsoperform an automated validation of the artifact itself. For example, you run avulnerability scan against known issues and approve the artifact for deploymentonly if no vulnerabilities are found. For example, you can useArtifact Registry to scan your artifacts for known vulnerabilities.

Finally, you can automate the deployment of each approved artifact in thetarget environment. If you have multiple runtime environments, you can alsoimplement unique deployment logic for each one, even adding manual approvalsteps, if needed. For example, you can automatically deploy new versions of yourworkloads in your development, quality assurance, and pre-productionenvironments, while still requiring a manual review and approval from yourproduction control team to deploy in your production environment.

While a fully automated end-to-end process is one of your best options if youneed an automated, structured, streamlined, and auditable process, implementingthis process isn't a trivial task. Before choosing this kind of process, youshould have a clear view on the expected benefits, the costs involved, and ifyour current level of team knowledge and expertise is sufficient to implement afully automated deployment process.

You can implement fully automated deployment processes withCloud Deploy.

What's next

• Learn how tomigrate your deployment processes.
• Learn when tofind help for your migrations.
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.

Contributors

Author:Marco Ferrari | Cloud Solutions Architect