Avoiding vendor lock-in with a particular cloud provider is always a consideration when building cloud native applications. Even though this is a book on Google Cloud, it is still worth considering the potential switching costs of moving to another cloud.
There are several strategies to mitigate lock-in:
Infrastructure based
Aim for the lowest common denominator in infrastructure. This involves building only on IaaS primitives, such as disks, databases, and virtual machines, that are universally available across all clouds. This strategy typically includes self-managing a Kubernetes distribution on the infrastructure to ensure consistency across clouds.
Kubernetes based
Target a managed Kubernetes service as the lowest common denominator. All major cloud providers offer managed Kubernetes services, so it seems logical to use Kubernetes as the common abstraction layer. However, managed Kubernetes services differ across providers, especially regarding versions and maintenance requirements, making this solution less straightforward than it may initially appear.
Open standards based
Embrace open standards and protocols that are supported across various clouds. This approach favors managed services that offer a technology available on other clouds through a higher-level abstraction since these have often become a de facto industry standard. Examples include the PostgreSQL wire protocol, Kubernetes API, Knative, and OCI Containers.
Single-cloud based
Choose the most suitable service on a single cloud, on the assumption that the benefits of using the managed service will outweigh even high switching costs if the probability of needing to switch is low. Technologies like AWS Lambda might fit this category. Even then, implementing patterns that allow developers to abstract away from specific services can make potential transitions more manageable.
As I discussed in Chapter 2, I believe the first two strategies often sacrifice many benefits of cloud native, particularly the ability to use managed services and the integrated experience they provide. By striving for a generic abstraction, you may reduce the switching cost, but it might also lead to losses in speed, efficiency, and potential security. Therefore, the likelihood of needing to switch should be carefully evaluated. I believe this approach only makes sense when an application must be deployed across multiple clouds simultaneously.
If Google Cloud is your chosen platform and the chances of needing to switch to another cloud are minimal, I advocate for the third approach, which is the primary focus of this book. This strategy involves favoring technologies and high-level abstractions available in any cloud, rather than focusing on individual services. While I will discuss many specific Google Cloud services in this book, I’ll always attempt to highlight where these services support an open standard or protocol that’s also available in other environments.