Let’s evaluate the solution in terms of cost.
Overall, this is a low-cost solution; it is taking good advantage of cloud native services. The costs are broken down as follows.
Firestore
Firestore is a relatively cheap way to store data, as you are not paying for compute resources and are only storing small amounts of data. Billing is based on the following:
- The number of documents you read, write, and delete
- The number of index entries matched by aggregation queries
- The amount of storage that your database uses, including overhead for metadata and indexes
- The amount of network bandwidth that you use
However, there are generous free tiers for all of these, and you will need to have over 50,000 reads and 20,000 writes per day and store over 1 GB of data before the costs start kicking in. As this service is storing small profiles, the cost of storing the data is likely to be negligible.
Cloud Run
The cost of Cloud Run is also likely to be small; the service is written in Go with minimal resource requirements and only executes for a small amount of time in response to an event. As the free tier allows for 2 million requests per month and 400,000 GB seconds per month, the cost of running the service is likely to be negligible.
Cloud Pub/Sub
Pub/Sub has the following components in its cost:
- Throughput costs for message publishing and delivery
- Egress costs associated with throughput that crosses a Google Cloud zone or region boundary
- Storage costs for snapshots, messages retained by topics, and acknowledged messages retained by subscriptions
As you are not retaining messages or crossing boundaries, the cost of using Pub/Sub is limited to the costs for message publication and delivery.
The cost of message publication is based on the number of messages published and the size of the messages. The free tier for Pub/Sub is 10GiB per month, so as it stands, the volume of messages would need to be considered before this service-occurred cost is high.
Summary
Although a simple example, this is representative of true cloud native service. The service is event-driven and stateless. It is written in a cloud native language (Go) and uses a cloud native storage service (Firestore). It also uses a serverless runtime (Cloud Run), and it is not running all the time and only executes when an event is triggered. The service is also scalable; it is scaled up or down as required. As a result, the service is highly available and fault-tolerant, but also so cost-effective that it is almost free. This is the type of service that made me excited when I first started using the cloud—services that can be run for next to nothing but can perform in a way that would have previously needed a lot of hardware.
For this project, you used the following services directly:
- Cloud Pub/Sub is used to store the profiles.
With all the services in place, in Chapter 9, you will be bringing them together into a single API and providing a UI interface for users to interact with.