Now let’s look at how the solution will scale and how much it will cost.
How Will This Solution Scale?
This solution is designed with scalability in mind.
First, the service itself has been designed to handle vertical scaling. This means that each instance’s capacity can be increased by augmenting memory and CPU resources. This is done by adjusting the –memory and –cpu parameters during service deployment. Changing these parameters allows the service to handle a larger number of requests.
The solution also supports horizontal scaling. It can dynamically adjust—scale up or down—to handle fluctuations in the volume of requests. Even though it currently maintains a minimum of one running instance, this baseline could be raised to swiftly respond to traffic surges.
On the other hand, the database presents a slightly different story. It primarily supports vertical scaling, which means its capacity can be increased by adjusting the –tier, or the machine’s specification on which the database operates. However, this process isn’t automated and necessitates a database restart. This can result in a brief downtime period, which isn’t ideal.
Moreover, there’s another crucial aspect to bear in mind. The database can handle only a limited number of connections, dependent on the machine’s size. Therefore, it’s important to ensure that the total number of connections, which is the number of instances multiplied by the connections in each pool, doesn’t exceed the available connections. This careful management of resources contributes to the overall robustness and efficiency of the solution.
How Much Will This Solution Cost?
Cloud Run is billed based on the number of requests and the amount of memory used by the service. The first two million requests are free and after that, it is $0.0002 per request. The memory is billed at $0.00001667 per GB per hour at the time of writing.
As the service needs to always be responsive, you will keep at least one instance running all the time. This is going to be the most significant cost. However, you can minimize this by setting the CPU and memory to the minimum required to run the service and allowing more instances to be scaled up to handle more requests.
Another significant cost is going to be the database, as it will be running all the time. The database is billed based on the amount of storage used and the tier the machine is running on. At the moment, you are using the smallest available database and storage amount, which keeps costs to a minimum. In Chapter 14, you will see how using other more cost-effective services where possible can help us keep the cost of this database down.
Tip
Be aware that there is a charge per request; even though it may not seem significant when services are receiving millions of requests per month, it may start to become significant. At that point, GKE Autopilot, covered in Chapter 14, might be worth considering from a cost point of view alone.
The database is billed based on the amount of storage used and the tier of the machine it is running on. With the minimal configuration currently in use, the cost should be less than $10 per month.
Summary
You have created a REST service using Spring Boot and deployed it to Cloud Run. You have also added authentication using Identity Platform and a database backend using Cloud SQL. You have followed cloud native principles and made good use of the features of the Google Cloud Platform without getting too tied to it.
For this project, you used the following services directly:
- Cloud Run 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
- Identity Platform is used to authenticate users
In Chapter 8, you will create a service to respond asynchronously when the facts change.