General considerations

We'll take a deeper look at the strengths and weaknesses of these individual technologies in their respective chapters, but there are a few high-level points that should be considered when evaluating a platform fit for a given solution. Generally speaking, less abstract solutions provide more user control, which greatly increases the flexibility in how solutions are implemented.

Most solutions implemented in a higher-abstraction service can also be implemented in a lower-abstraction service, albeit likely with a considerable amount of operational overhead. Conversely, services providing higher levels of abstraction tend to forfeit some level of user control, potentially limiting their use cases. For example, a set of stateless microservices can be run on App Engine fairly easily. The same services could be deployed on a fleet of Compute Engine VMs, even though the effort to do so will generally be higher than that of App Engine. In opting for the more abstract App Engine solution, developers are able to avoid much of the effort of provisioning infrastructure, allowing them to focus on core business problems. In choosing the less abstract Compute Engine solution, developers take on the responsibility of managing infrastructure, but gain far more control on how that infrastructure is managed. If desired, teams could even opt to run some other PaaS such as Cloud Foundry on a set of Compute Engine VMs.

Something else to consider is that integrations with the larger Cloud platform catalog varies between compute services. For example, Cloud Functions offers easily configured integrations with Cloud Storage, allowing functions to be invoked when an object changes in a given Cloud Storage bucket. This same functionality does not exist for other Google Cloud compute services, making Cloud Functions a good candidate for such operations.

Another consideration when evaluating potential compute services is that many solutions will benefit from leveraging more than one service. Google Cloud offers strong cross-service integrations between compute services, making spreading solutions across compute services a fairly straightforward process.

For example, it tends to be easier to migrate legacy on-premises services to Compute Engine or Kubernetes Engine compared to App Engine. A logical approach is to perform lift-and-shift migrations of these services to GCE or GKE as needed, while extending functionality in the form of microservices running on App Engine.