Professional Cloud Developer
Professional Cloud Developer
Intermediate
Gauge your current knowledge
Intermediate
Gauge your current knowledge
Defining resource requirements for workloads
...
Professional Cloud Developer
Gauge your current knowledge
Gauge your current knowledge
Deciding on compute resources starts with identifying whether your application is stateful or stateless. A stateful application stores data such as session IDs, whereas a stateless application does not retain data between transactions. Your control needs will guide whether you deploy your workload on Compute Engine, Google Kubernetes Engine (GKE), or Cloud Run.
Selecting the correct machine type helps balance your performance requirements with your budget. Google Cloud provides predefined options, but you can also configure custom machine types to precisely match your CPU and memory needs without paying for unused resources. For workloads like databases that need consistently high performance, you should choose the C4 machine series.
To save money on flexible, fault-tolerant workloads, you can deploy your application on Spot VMs. These are preemptible instances that utilize spare Google Cloud capacity but can be stopped if the capacity is needed elsewhere. This resource type offers a significant discount compared to standard compute instances.
You can optimize your compute performance by modifying vCPU settings and network configurations. Disabling multithreading for tasks that need heavy calculations allows you to allocate physical cores directly. Enabling Tier_1 networking provides higher network bandwidth for data-heavy applications, while compact placement policies physically group VMs together to minimize network latency.
Finally, automated scaling ensures your resources match your workload demand dynamically. You can use Managed Instance Groups (MIGs) or GKE autoscalers to add or remove instances in real time. To continuously optimize costs, the Recommender tool analyzes usage patterns and suggests right-sizing adjustments.
Designing high-performing workloads requires you to analyze storage demands based on IOPS (Input/Output Operations Per Second) and throughput. Matching your storage tier to these requirements prevents performance bottlenecks and controls costs. You must choose from several disk options based on how your applications write and access data.
For block storage, Google Cloud provides Google Cloud Hyperdisk and Persistent Disk options. Choosing Hyperdisk Balanced allows you to provision IOPS and throughput separately, giving you maximum flexibility. For standard virtual machines, Zonal Persistent Disk provides reliable storage within a single zone, while Regional Persistent Disk offers synchronous replication across two zones for higher durability. For extreme performance with heavy data loads, you should use Hyperdisk Extreme.
When applications require the absolute lowest latency, Local SSD provides ephemeral storage with sub-millisecond speeds. However, because this storage is physically attached to the host, data is lost if the virtual machine is deleted. If multiple virtual machines must share files, you can use Filestore, which replicates data across three zones in its Regional tier to maintain high availability.
For object storage, you can use Cloud Storage to securely store unstructured data files. Developers must select the appropriate storage class based on how often their data is accessed. Additionally, you must choose between Regional, Dual-region, or Multi-region buckets to balance access latency with geographic redundancy.
Ensuring your storage choice remains correct over time requires capacity planning and application benchmarking. You should use Google Cloud Observability to monitor active utilization metrics. Benchmarking the application reveals actual resource usage, allowing you to right-size your storage systems and avoid over-provisioning.
Establishing resource baselines ensures your application has enough CPU and memory to run smoothly under different conditions. Developers use Cloud Monitoring to profile performance and capture resource consumption trends. By conducting regular load tests, you can find the minimum hardware baseline required to support your application without wasting money.
Capacity planning requires active benchmarking where you simulate real-world traffic to see how the system behaves. This helps you forecast the application load by finding out how many requests a single instance can handle before performance drops. You should build redundancy into your plan using an N+1 strategy so the system stays online even if a node fails.
Once baselines are set, autoscaling policies automatically expand or shrink your resources as demand fluctuates. In Compute Engine, you use Managed Instance Groups (MIGs) to automatically add or remove virtual machines when resource thresholds are reached. This mechanism ensures your environment scales dynamically to match user traffic.
For containerized workloads managed by GKE, you can apply specialized autoscaling tools. These tools manage resources at both the container level and the virtual machine level. You can use three distinct autoscalers depending on your cluster requirements:
For containerized applications that run on serverless infrastructure, Cloud Run provides built-in scaling that responds directly to incoming web traffic. This service can automatically scale down to zero when there is no traffic, eliminating idle resource costs entirely. To keep your scaling policies accurate over time, you can use the Recommender tool to analyze usage and find right-sizing opportunities.