cloud.google.com/terms/services.
Reduced Levels of Services
One way to reduce costs is to accept lower levels of service in exchange for lower costs. In GCP there are a number of opportunities to reduce cost in exchange for lower levels of service, including the following:
Using preemptible virtual machines instead of standard virtual machines
Using standard tier networking instead of Premium tier
Using Pub/Sub Lite instead of Pub/Sub
Using Durable Reduced Availability Storage
These examples are representative of the kinds of trade-offs we make when opting for a lower-cost service.
Preemptible Virtual Machines
One way to minimize computing costs is to use preemptible virtual machines, which are short-lived VMs that cost about 80 percent less than their nonpreemptible counterparts. Here are some things to keep in mind about preemptible VMs when considering business and technical requirements:
Preemptible VMs may be shut down at any time by Google. They will be shut down after running for 24 hours.
GCP will signal a VM before shutting down. The VM will have 30 seconds to stop processes gracefully.
Preemptible VMs can have local SSDs and GPUs if additional storage and compute resources are needed.
If you want to replace a preempted VM automatically, you can create a managed instance group for preemptible VMs. If resources are available, the managed instance group will replace the preempted VM.
Preemptible VMs can be used with some managed services, such as Cloud Dataproc, to reduce the overall cost of the service.
Preemptible VMs are well suited for batch jobs or other workloads that can be disrupted and restarted. They are not suitable for running services that need high availability, such as a database or user-facing service, like a web server.
Preemptible VMs are also not suitable for applications that manage state in memory or on the local SSD. Preemptible VMs cannot be configured to live migrate; when they are shut down, locally persisted data and data in memory are lost. If you want to use preemptible VMs with stateful applications, consider using Cloud Memorystore, a managed Redis or memcached service for caching data, or a database to store state.
Standard vs. Premium Tier Networking
Google Cloud offers two levels or tiers of networking, Standard and Premium.
Standard Tier networking is the lower-performance option. Performance and availability are typically like other cloud providers that depend on the public internet. There are no global SLAs, and Cloud Load Balancing is limited to regional load balancing.
With Premium Tier networking, you experience high performance and reliability, low latency, and a global SLA. You can also use global load balancers that can distribute load across regions. Network traffic is carried on Google's network, not the public internet.
Pub/Sub Lite vs. Pub/Sub
Pub/Sub is a highly scalable messaging service in Google Cloud. Pub/Sub Lite is also horizontally scalable but costs less and provides lower levels of service than Pub/Sub.
Pub/Sub provides for per-message parallelism, automatic scaling, and global routing. Service endpoints are global and regional.
Pub/Sub Lite offers lower availability and durability than Pub/Sub. Messages replication is limited to a single zone unlike Pub/Sub, which provides multizone replication in a single region. Pub/Sub Lite service endpoints are regional, not global. The Lite service also requires users of the service to manage resource capacity.
Pub/Sub Lite can cost up to 85 percent less than Cloud Pub/Sub, but Google recommends that Pub/Sub as the default choice for a managed messaging service.
Durable Reduced Availability Storage
Durable Reduced Availability (DRA) Storage is like Standard Storage but with lower performance and availability. DRA Storage has a 99 percent availability, while Standard Storage has greater than 99.99 percent availability in dual-regions and multiregions and 99.99 percent in regions.
cloud.google.com/storage/docs/storage-classes)
Data Lifecycle Management
When assessing the application design and cost implications of business requirements, consider how to manage storage costs. Storage options lie on a spectrum from short-term to archival storage.
Memorystore is a cache, and data should be kept in cache only if it is likely to be used by an application in the very near future. The purpose of this storage is to reduce the latency of accessing data.Caches are not durable. Data stored in Memorystore can disappear at any time. Only data that can be retrieved from another source or regenerated should be stored in a cache.
Databases, like CloudSQL and Firestore, store data that needs to be persistently stored and readily accessed by an application or user. Data should be stored in the database when it could possibly be queried or updated. When data is no longer required to be queried or updated, it can be exported and stored in object storage.
In the case of time-series databases, data may be aggregated by larger time spans as
