How Will This Solution Scale? – Scaling Up

by Ali Axelrod Advantages of Cloud, Command Line Interface, Google Cloud Certification Exams, Kubernetes Configuration, New Project Creation, Reintroducing Terraform

Here, you have seen a mixture of cloud native and traditional technologies. Although GKE Autopilot is not serverless, it is cloud native. As demand increases, more instances of the fact service will be created by the horizontal autoscaler. As more instances are scheduled, the GKE Autopilot cluster will automatically add additional nodes to deal with the extra pods.

GKE Autopilot also appears considerably faster to service requests than the same container running on Cloud Run. This could be down to the way networking is configured, with requests reaching the service by a more direct route.

This solution will not scale to zero in the same way as Cloud Run, and there will always need to be one pod running to service requests (if individual instances are still running in a single pod). Remember, however, that if demand suddenly increases, it will take a few minutes for both the GKE Autopilot cluster to provision the extra resources required for running the post and then for the pods to start.

While the service can be scaled almost indefinitely, the real bottleneck is the Cloud SQL database, which is not cloud native. There are two related limitations. The first is that the database cannot be dynamically scaled. You have to specify the tier of the machine used for the database, and while this can be changed manually with a database restart, it cannot change automatically in response to load. More importantly, there is a limit to the number of database connections from the instances of the services.

This means that if the instances increase without limit, they will exhaust the number of connections available to the database and fail to connect. For this reason, it is important to limit the number of instances so that the number (instances × connections per instance) is below the maximum number of connections available to the database.

However, you have seen that with some minor adjustments, you can allow the fact service to work with Google Cloud Spanner, a cloud native database with the potential to scale far beyond the limitations of Cloud SQL, creating a full cloud native solution.

How Much Will This Solution Cost?

Unlike Cloud Run, GKE Autopilot does not have a cost per request; you will be billed for the pods running on the cluster and a cluster management fee per hour. At the time of writing, the first 720 hours of cluster management per month are included per account, so you effectively get one cluster free.

The cost of pods is based on the amount of CPU, memory, and ephemeral storage requested by scheduled pods. This is billed per second. The most significant cost is for CPU. Therefore, it is very important to make sure the resources you request for your pod are adequate but not excessive. Remember that a Kubernetes pod can use additional resources up to the limit specified; the requested resources are the ones that are reserved.

As each pod is charged per second, it does not make sense to keep a pod running for a second longer than it needs to. Therefore, using horizontal autoscaling to dynamically increase and decrease the number of running pods to fit demand will help keep costs down.

The cost of Cloud Spanner in this minimal configuration is under $100 per month. That is still ten times the cost of a minimal Cloud SQL instance. However, another advantage of the cloud is that it allows you to experiment with services like advanced databases for short periods, without the massive outlay of money or effort you would have if you were to experiment on-premises. On the cloud, you just switch off the service again and stop paying, so if you wanted to try Spanner for an hour for a few cents, you can.

Summary

This chapter should have given you a glimpse at how you can go further in Google Cloud. However, it is a powerful platform with many services and features. There is a lot more to learn.

For this project, you used the following services directly:

  • GKE Autopilot is used as the container runtime to run the container.
  • Cloud SQL is used as the database backend for the application.
  • Cloud Secrets Manager is used to securely store the database password.
  • Cloud Spanner is used as an alternative database backend for the application.

Chapter 15 wraps up your Google Cloud journey and looks at some options for further learning.