Managing and provisioning a cloud solution infrastructure

Configuring Network Topologies

The Foundation of Cloud Networking

A network topology in GCP starts with a Virtual Private Cloud (VPC) that defines the IP address range for all resources. Within the VPC, subnets divide the network into smaller segments, and each subnet lives in a specific region. Resources within the same subnet can communicate directly using internal IP addresses, while resources in different subnets route traffic through the VPC's internal network. The VPC also defines firewall rules that control which traffic is allowed in and out of the network.

Connecting to the Internet

Traffic from the outside world enters through the Cloud Load Balancing service, which distributes requests across multiple backend resources. The load balancer sits in a public subnet and accepts traffic from the internet, while application servers typically sit in private subnets that do not have direct internet access. When private resources need to reach external services, traffic leaves through a Cloud NAT gateway, which allows outbound connections but blocks incoming ones. DNS resolution happens through Cloud DNS, which translates domain names to IP addresses and can point users toward the load balancer or CDN.

Advanced Networking Options

For high-bandwidth or low-latency needs, Cloud Interconnect creates dedicated physical connections between on-premises networks and GCP, bypassing the public internet. Cloud CDN caches content at edge locations near users, reducing latency and load on origin servers. Cloud Armor provides security at the edge by filtering malicious traffic before it reaches the load balancer. These services work together: traffic might flow from the user to Cloud Armor, then to the load balancer, then to the application servers in private subnets, with the CDN caching static content at each step.

Configuring Individual Storage Systems

Choosing Storage Based on Data Type

GCP offers different storage services for different needs, and choosing the right one depends on what kind of data the application handles. Cloud Storage works for unstructured data like images, videos, and backups, and it stores data as objects in buckets with global unique names. Cloud SQL provides managed relational databases for structured data that needs SQL queries, supporting both PostgreSQL and MySQL. Cloud Spanner offers globally distributed relational databases for applications that need horizontal scaling and strong consistency across regions. Bigtable handles massive amounts of structured data for analytics and operational workloads, while Firestore provides a NoSQL document database for mobile and web applications.

Storage Classes and Lifecycle Management

Cloud Storage offers several storage classes that balance cost with access frequency. Standard storage costs more but works best for frequently accessed data, while Nearline and Coldline cost less but charge retrieval fees for data accessed less often. A lifecycle policy can automatically move objects between classes or delete them when they are no longer needed, so administrators do not have to manually manage it. The choice of storage class affects cost but also performance, so applications that need fast access should use Standard storage, while archival data can use Coldline.

Data Access Patterns

Applications access storage in different ways depending on the service. Cloud Storage serves files over HTTP(S) and integrates with CDNs for fast delivery. Cloud SQL and Spanner accept connections from application servers and return query results, with Spanner automatically sharding data across many servers. Firestore provides mobile and web SDKs that sync data automatically and work offline. Each service manages its own availability and replication, so the application does not need to handle those details.

Configuring Compute Systems

Compute Options Overview

GCP provides several ways to run application code, each with different tradeoffs between control and convenience. Compute Engine runs virtual machines, giving full control over the operating system and installed software, which fits applications with specific configuration needs. Google Kubernetes Engine (GKE) runs containers orchestrated by Kubernetes, letting teams deploy applications packaged with their dependencies and scale them automatically. Cloud Run runs containers in a fully managed serverless environment, handling scaling and infrastructure automatically. App Engine offers a platform-as-a-service model where the platform manages the runtime and scaling, letting developers focus on code.

When to Choose Each Option

Choose Compute Engine when the application needs specific operating system settings, custom software, or must run continuously without restarts. Choose GKE when the team already uses containers and wants automated scaling, rolling updates, and self-healing. Choose Cloud Run when the workload is event-driven or intermittent, because it scales to zero when not in use and only charges for actual usage. Choose App Engine when the team wants the simplest path to deployment and does not need fine-grained control over the infrastructure.

Scaling and Availability

Each compute option scales differently in response to demand. Compute Engine uses managed instance groups that add or remove VMs based on a scaling policy watching signals like CPU usage. GKE automatically adds pods to handle load and removes them when demand drops, with the horizontal pod autoscaler making these decisions. Cloud Run automatically scales the number of container instances from zero to many based on incoming requests. Each service also handles availability by distributing instances across multiple zones, so a zone failure does not take down the entire application.

Leveraging Vertex AI for End-to-End ML Workflows

The ML Pipeline Overview

Vertex AI provides a unified platform for building, deploying, and managing machine learning models. The workflow starts with data preparation, where datasets are uploaded and labeled for training. Feature Store within Vertex AI stores and serves features (input variables) to training jobs and prediction servers, ensuring consistency between training and production. The training job uses the dataset to build a model that learns patterns from the labeled data, and the trained model gets registered in the Model Registry for version tracking.

Training and Deployment

Training can use custom code running on Vertex's training infrastructure or AutoML, which automatically selects algorithms and hyperparameters. Once trained, the model deploys to an endpoint, which is a served version that accepts prediction requests. The endpoint scales automatically based on request volume, and Vertex AI handles the underlying compute. Predictions flow from the application to the endpoint, which returns results, and the endpoint can be versioned so that new models roll out gradually without disrupting traffic.

MLOps and Model Management

Vertex AI integrates with tools for continuous training and deployment, supporting MLOps practices. The model registry tracks versions, and each version can be evaluated against test data to measure performance. Feature Store ensures that the same features used during training are available at prediction time, preventing training-serving skew. Pipelines can orchestrate the entire workflow from data preparation through training and deployment, automating repetition and ensuring reproducibility.

Configuring Prebuilt Solutions or APIs with Vertex AI

Using Pretrained APIs

GCP offers pretrained APIs that provide machine learning capabilities without requiring custom model training. The Vision API analyzes images for labels, text (OCR), facial recognition, and landmark detection. The Natural Language API extracts syntax, sentiment, and entities from text. The Translation API translates text between languages, and the Speech-to-Text and Text-to-Speech APIs convert between audio and text. These APIs work by sending data to the service, which processes it and returns results, so developers do not need ML expertise to use them.

AutoML for Custom Models

For cases where pretrained APIs do not fit, AutoML lets teams train custom models without writing ML code. AutoML Vision trains image classification models, AutoML Natural Language trains text classification models, and AutoML Tables trains tabular data models. The team uploads labeled data, selects the target variable, and AutoML handles algorithm selection, hyperparameter tuning, and training. The resulting model deploys to an endpoint just like a custom-trained model, so the same serving infrastructure works for both approaches.

Choosing Between Options

Use pretrained APIs when the capability matches the need, because they require no training data and are ready immediately. Use AutoML when the pretrained APIs do not cover the specific use case but the team lacks ML expertise to build custom models. Use custom training when the team has ML expertise and needs full control over the model architecture, training process, or serving behavior. Each option trades off flexibility versus convenience, and the right choice depends on the specific problem and team skills.