Google Cloud Adoption: Mapping As-Is to Leverage Cloud Value: OS, Application Servers and DBs

Welcome to the continuation of the Google Cloud Adoption and Migration: From Strategy to Operation series.

In the previous part, we looked at how to map the as-is infrastructure components. In this part we’ll cover operating systems, application servers and, and databases.

A quick refresh of the HoaP:

White tiers are in scope for this article

As with the previous part, the goal is to recommend some target states you could and should move to, as part of your adoption of Google Cloud. I won’t be covering “How” in this part; that’s coming later in the series. The recommended target (and elimination of as-is platforms) will align to my set of Cloud Adoption and Cloud Consumptions principles:

1. Host in public cloud
2. Use managed services
3. Use cloud-native services
4. Avoid commercially licensed software
5. Automate deployments and installs
6. Immutable infrastructure (“cattle, not kittens”)
7. Document everything
8. Manage lock-in
9. Systemic FinOps

Operating Systems and Containers

Existing VMs