Preparation– Scaling Up

by Ali Axelrod Command Line Interface, Deletion of bucket, Exams of Google Cloud, Google Cloud Certification Exams

There are some small changes to the fact service needed to prepare it for Kubernetes and Cloud Spanner.

Getting Ready for Kubernetes

For Cloud Run, you are not strictly required to configure health checks for the application. For GKE Autopilot, you will need to use the Kubernetes readiness and liveness probes to check the health of the application. This is a great way to ensure that the application is running correctly and is ready to receive traffic:

Liveness check

This indicates that a pod is healthy. If it fails, Kubernetes restarts the application.

Readiness check

This indicates that the application is ready to receive traffic. Kubernetes will not send traffic to the pod until it is successful.

As your Spring Boot application takes several seconds to start, it is helpful to use the readiness probe to ensure the application is ready to receive traffic before Kubernetes sends any.

Fortunately, Spring Boot provides a health endpoint that you can use for this purpose. You can configure the readiness and liveness probes to use this endpoint.

You use these endpoints in the Kubernetes configuration to configure the readiness and liveness probes.

Getting Ready for Spanner

There are a few things to consider when using Spanner. Although it is PostgreSQL compatible, it is not fully PostgreSQL compliant, and this means there are some limitations.

The first is that it does not support sequences, so it is not possible to automatically generate primary keys, as it was with Cloud SQL. This version of fact service in this chapter uses universally unique identifiers (UUIDs) for primary keys instead of an ID that is auto-incremented by the database.

Hibernate, the ORM library the fact service uses, has a nice feature of automatically updating schemas. This is not supported by Spanner, so you need to manually create the schema. Fortunately, the single table is simple in this case, so it’s not a big issue. However, this does add an extra step to the deployment process.

In Google Cloud Spanner, you can use the TIMESTAMP data type to store timestamp values. The precision of the TIMESTAMP data type is up to nanoseconds, but it does not store time zone information as Cloud SQL does. This means there is more information in the LocalDateTime Java type that can be stored in Spanner’s TIMESTAMP type.

To solve this issue, the common practice is to use two fields in your entity, one for the timestamp and another for the time zone. You store the timestamp as a String in a standardized format, like ISO 8601, and you store the time zone as another String. When you retrieve the data, you can parse the timestamp and apply the time zone. This is what has been done in this version of the fact service.

These are the type of limitations you need to be aware of when using Spanner; they are small but significant. It is not a drop-in replacement for PostgreSQL. An application written to work with Cloud SQL for PostgreSQL will not necessarily work with Spanner. However, an application written to work within the limitations of Spanner’s PostgreSQL will likely work with Cloud SQL for PostgreSQL. If you just target PostgreSQL, you will likely not be able to use Spanner without modification.

Tip

This is the trade-off you make when using a cloud native database. You get scalability and performance, but you lose some features of a traditional database. However, in this case, the benefits are large and the limitation relatively small.