If you want to scale the application to millions of users globally, you need to consider how you can scale the database. Cloud SQL for PostgreSQL is a great choice for a relational database, but it can only scale vertically. This means that you can only scale it by increasing the size of the machine it runs on. The other option is to add read replicas, which as their name suggests are read-only. This can help scale reads but not writes.
The alternative is Cloud Spanner, Google’s globally distributed relational database. Cloud Spanner is a great choice for a globally distributed application, as it is designed to scale horizontally across multiple regions. It makes full use of all those primitive Google Cloud building blocks described in Chapter 2. Most importantly, it decouples compute from storage, meaning they can be deployed and scaled independently. However, Spanner is also a relational database, which means that you can use it similarly to Cloud SQL for PostgreSQL.
Cloud Spanner challenges the constraints of the CAP theorem, which states that a distributed system cannot simultaneously provide consistency, availability, and partition tolerance. However, it doesn’t completely break these boundaries. In the balance between these three pillars, Spanner leans toward consistency and partition tolerance, while making certain concessions in availability.
What sets Spanner apart is its innovative approach to managing availability. Leveraging highly precise clocks, it significantly reduces the availability trade-off. Spanner’s reliance on TrueTime API, which uses atomic clocks and GPS receivers, allows for precise synchronization across its global network. This system enables Spanner to make strong consistency and high availability a practical reality, making it a unique offering in the world of distributed databases.
As you will see, however, there are a few limitations that you need to be aware of so that an application can run on both Cloud SQL for PostgreSQL and Cloud Spanner without modification.
Kubernetes Service Accounts
Previously, you created a service account to use from Cloud Run with permissions to access Cloud SQL and the secret stored in Secret Manager. You can refer to this as a Google service account.
In Kubernetes, there is also the concept of service accounts. Similarly, this is a way to grant pods access to other services. However, this is a completely separate concept from the Google service account you created before. You can refer to this as a Kubernetes service account; it is generic to Kubernetes and completely different from a Google service account.
Workload Identity
In this chapter, the goal is for the fact service pod running in a GKE Autopilot Kubernetes cluster to be able to access the database and secret, which are Google Cloud resources. To allow a pod on GKE Autopilot to access Google Cloud resources, you need to bind the Kubernetes service account to the Google service account. This is done through a mechanism called Workload Identity.
Skaffold
Previously, you used Skaffold to automate the building of containers and deployment to local Kubernetes. In this case, you can use it to automate your development process to a GKE Autopilot cluster on Google Cloud.
