DEV Community: Mohammad Awwaad

The Zero-Cost Cloud Engineer Part 5: Brownfield Terraforming and the 'Zero-Diff' Philosophy

Mohammad Awwaad — Sat, 11 Apr 2026 16:14:54 +0000

The Zero-Cost Cloud Engineer

Part 5: Infrastructure as Code & The Brownfield Migration

In the first four parts of this series, we manually built a highly secure, zero-cost Google Cloud microservice ecosystem. We navigated "ClickOps" UI traps, established isolated networks, and deployed Spring Boot Java applications.

But in enterprise engineering, manual UI clicking is a massive liability. If a disaster strikes, we cannot spend hours trying to remember which IAM roles or network tags we used. We need Infrastructure as Code (Terraform).

However, migrating a currently running, live server into Terraform without accidentally destroying it is a high-risk operation known as a Brownfield Migration. Here is the Architect's guide to doing it safely.

Step 1: The Ephemeral Security Token

Terraform needs permission to manage your GCP resources. A common beginner mistake is generating a permanent Service Account JSON key and leaving it on a local laptop hard drive—a massive security risk.

The Architect's solution is Application Default Credentials (ADC).

From your local machine, run:

gcloud auth application-default login

This generates a deeply encrypted, temporary token linked strictly to your identity. When your Terraform session is finished for the day, you simply run gcloud auth application-default revoke to obliterate the token and harden your machine against compromised scripts.

Step 2: Defining the Provider

Create a main.tf file. This acts as the architectural blueprint. First, declare the Google provider and link it to your specific sandbox project:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = "your-actual-gcp-project-id"
  region  = "us-east1"
  zone    = "us-east1-b"
}

Step 3: The Danger of "Apply" & Importing State

Next, you write out the explicit definition of your previously built e2-micro VM natively in HCL (HashiCorp Configuration Language).

🚨 The Creation Trap: If you run terraform apply immediately after writing your code, Terraform will assume it manages 0 resources and will attempt to create a brand new VM. Google Cloud will heavily reject this attempt, throwing a 409 Conflict: Resource already exists error since the server actually lives in the cloud.

Instead, we must download the exact specifications of the live server into Terraform's "brain" (the .tfstate file) by running an import command:

terraform import google_compute_instance.free_tier_vm projects/[YOUR_PROJECT]/zones/us-east1-b/instances/free-tier-vm

Step 4: Surviving "Forces Replacement"

Once imported, you run terraform plan to see what changes Terraform wants to make. You might be horrified to see: forces replacement displayed in red text.

Terraform is ruthlessly exact. If your code declares image = "debian-cloud/debian-13", but the real cloud server was built using a hyper-specific internal ID string like debian-13-trixie-v20250101, Terraform decides the only way to resolve the mismatch is to wipe your hard drive and delete the server!

The Architect's Fix (ignore_changes):
To survive a Brownfield import, use the lifecycle ignore_changes block. This explicitly tells Terraform to ignore slight discrepancies in specific fields, preventing a catastrophic server wipe:

  lifecycle {
    ignore_changes = [
      boot_disk[0].initialize_params[0].image,
      metadata, # Prevents Terraform from deleting dynamic SSH keys!
    ]
  }

Note: Ignoring metadata is especially crucial in GCP, as Google dynamically injects your SSH keys into the metadata block when you connect natively via the gcloud compute ssh IAP tunnel. Without this exclusion, Terraform will declare war on Google's automation and constantly try to delete your SSH access!

Step 5: The "Zero-Diff" Goal vs. VM Restarts

If you declared your VM's Service Account as email = "default", but Google imported it as 1234567-compute@developer.gserviceaccount.com, Terraform will flag this as a required update (~).

Because modifying core VM identities requires the server to be completely stopped, Terraform will fail the plan, refusing to take a production system down without explicit safety permissions. You can circumvent this by supplying allow_stopping_for_update = true to gracefully cycle it.

The Architect's Pivot:
Do you actually need to restart the VM?
In a perfect Brownfield migration, the Architect's goal is a "Zero-Diff Plan." Instead of forcing a restart to make the server match your generic code snippets, change your code to match the server. Replace "default" with the exact email string retrieved from the cloud.

By perfectly mirroring reality, terraform plan will output "0 to add, 0 to change, 0 to destroy," allowing you to safely wrap your live application in massive automation without incurring a single second of downtime.

Series Conclusion: The Zero-Cost Architect

We started this journey by acknowledging the reality of the expired $300 GCP credit. Instead of giving up or relying on expensive defaults, we purposefully built an entire production-grade ecosystem within the fierce constraints of the Always Free tier.

We provisioned an e2-micro secure island without a public IP. We piped Spring Boot logs natively to Google's Ops Agent. We decoupled our communications safely using Standard Pub/Sub instead of the FinOps trap of "Lite." We managed secrets in a global vault, streamed files securely to Object Storage, and finally brought everything under the strict governance of Immutable Infrastructure as Code.

Building inside constraints is what separates developers from Cloud Architects. You now have a complete, zero-cost Google Cloud laboratory. Keep iterating, keep building, and never accept the console defaults!

The Zero-Cost Cloud Engineer Part 4: Cloud Storage, Secret Manager, and the Legacy Access Trap

Mohammad Awwaad — Fri, 03 Apr 2026 19:06:33 +0000

The Zero-Cost Cloud Engineer

Part 4: Hybrid Storage, Secrets, and the Legacy VM Trap

In our previous tutorials, we secured an internet-less Compute Engine VM, established centralized logging, and decoupled our architecture with Pub/Sub. Now, we hit the next major architectural bottleneck: Our 30GB Hard Drive limit.

If you allow users to upload files directly to your VM's block storage, you will quickly max out your Free Tier limits, crashing your OS. Resilient architectures offload files to Object Storage (Google Cloud Storage) and never hardcode connection properties.

This tutorial covers integrating Google Cloud Storage (GCS) and Secret Manager into a Spring Boot application, entirely zero-cost.

Step 1: Provisioning Hybrid Storage

In Google Cloud Storage (GCS), you don't have "folders"; you have "Buckets" filled with "Objects." For the Always Free tier, GCP gives you 5 GB-months of Standard Storage per month.

🚨 The FinOps Trap (Soft Delete): A "GB-month" calculates storage sequentially. If you upload a 5 GB file and delete it 24 hours later, you consume a fraction of a GB-month. However, Google recently enabled Soft Delete by default with a 7-day retention period. If you delete files to stay under the 5GB limit, Soft Delete secretly retains them, charging your quota and triggering a sudden billing alert.

To provision a strictly free bucket:

Navigate to Cloud Storage Buckets in the GCP Console and click Create.
Give it a globally unique name (e.g., zero-cost-bucket-yourname).
Location: You must choose a Region that matches your VM (e.g., us-east1) to avoid data egress charges.
Storage Class: Choose Standard.
Protection: Expand "Choose how to protect object data" and Disable Soft Delete (or set retention to 0 days) to prevent hidden quota consumption.
Click Create.

Step 2: The Security Vault (Secret Manager)

We don't want to hardcode our new bucket name into our source code. We want to fetch it securely on boot. GCP offers 6 completely free secret versions per month.

Navigate to Secret Manager and click CREATE SECRET.
Name: GCS_BUCKET_NAME
Secret Value: your-bucket-name
Leave replication as Automatic (Global) and click Create.

Step 3: Conquering the Legacy "Access Scopes" Trap

Your Compute Engine VM holds an IAM Identity. You use the GCP Console (IAM & Admin) to attach the Storage Object Admin and Secret Manager Secret Accessor roles to it. You assume you're finished.

🚨 The Legacy Architecture Trap: When you attempt to upload a file in Java, you instantly receive a PERMISSION_DENIED exception. Why? GCE VMs are handcuffed by a legacy system called "Access Scopes."

When you create a VM with GUI defaults, it applies the "Default access" scope, which throttles storage to devstorage.read_only and explicitly blocks Secret Manager—entirely overriding your new IAM admin privileges!

The Architect's Fix: We must transition the VM to modern IAM validation by granting it the cloud-platform scope.

Run these commands from your local laptop to strip the legacy handcuffs:

# 1. Stop the instance
gcloud compute instances stop free-tier-vm --zone=us-east1-b

# 2. Grant full API access (Delegating authority completely to IAM)
gcloud compute instances set-service-account free-tier-vm \
    --zone=us-east1-b \
    --scopes=https://www.googleapis.com/auth/cloud-platform

# 3. Restart the instance
gcloud compute instances start free-tier-vm --zone=us-east1-b

Step 4: The Spring Boot Integration

With modern Spring Boot 3.4+ / 4.x, the config data loader evaluates cloud imports incredibly early. To prevent local tests running on your laptop from blindly seeking GCP credentials, use a profile-guarded application.yaml:

spring:
  application:
    name: hello-gcp
---
spring:
  config:
    activate:
      on-profile: "!test"
    import: sm://

Now, create a controller that demands its configuration strictly from the Secret Manager vault during instantiation:

import com.google.cloud.storage.BlobId;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.*;
import org.springframework.web.multipart.MultipartFile;
import java.io.IOException;

@RestController
@RequestMapping("/api/files")
public class GcsUploadController {

    private final Storage storage;
    private final String bucketName;

    // The sm:// prefix forces a fetch from GCP Secret Manager!
    public GcsUploadController(Storage storage, @Value("${sm://GCS_BUCKET_NAME}") String bucketName) {
        this.storage = storage;
        this.bucketName = bucketName;
    }

    @PostMapping("/upload")
    public String uploadFile(@RequestParam("file") MultipartFile file) throws IOException {
        BlobInfo blobInfo = BlobInfo.newBuilder(BlobId.of(bucketName, file.getOriginalFilename()))
                .setContentType(file.getContentType())
                .build();

        storage.create(blobInfo, file.getBytes());
        return "Uploaded " + file.getOriginalFilename() + " directly to secure bucket!";
    }
}

Note: For local Maven builds (mvn clean package), remember to create a test profile that uses @MockitoBean and spring.cloud.gcp.core.enabled=false to bypass these enterprise connections.

Step 5: End-to-End Verification

Deploy your updated .jar to your internet-less VM via Identity-Aware Proxy (IAP) as we outlined in past tutorials.

To verify the file upload, we bridge our local laptop to the private server using port forwarding:

Establish a Local Tunnel:

gcloud compute ssh free-tier-vm --tunnel-through-iap -- -L 8080:localhost:8080

Trigger the Upload via cURL:

curl -F "file=@/path/to/any/local_test.jpg" http://localhost:8080/api/files/upload

Validate: The terminal will return "Uploaded local_test.jpg directly to secure bucket!". If you refresh the GCP Console Storage Browser, you will see your file sitting securely in the cloud, completely detached from your VM's tiny hard drive.

Summary

By identifying the "Soft Delete" billing trap, locking credentials inside Secret Manager, tearing down the legacy Compute Engine "Access Scopes," and streaming files natively to GCS, you have built a production-grade file repository without spending a dime.

In Part 5, we will bring the entire ecosystem under control natively using Infrastructure as Code (Terraform).

The Zero-Cost Cloud Engineer Part 3: Decoupled Messaging with Pub/Sub on the Always Free Tier

Mohammad Awwaad — Sat, 21 Mar 2026 19:48:07 +0000

The Zero-Cost Cloud Engineer

Part 3: Asynchronous Messaging and the "Lite" Trap

In [Part 2], we established our "Secure Island" foundation—a private Compute Engine VM with no external IP and centralized logging. However, a single VM is a monolith. To build a resilient, cloud-native ecosystem, we need decoupled communication.

This tutorial covers the implementation of an asynchronous messaging loop using Google Cloud Pub/Sub and Spring Boot, strictly within the 10 GB/month Always Free allotment.

Step 1: Provisioning the Pub/Sub Infrastructure

When configuring messaging in Google Cloud, beginners often face a critical choice in the console: Pub/Sub vs. Pub/Sub Lite.

🚨 The FinOps Trap: "Lite" sounds perfect for small-scale zero-cost projects, but it requires provisioned throughput capacity. Google bills you for that reserved capacity immediately, even if you send zero messages. Standard Pub/Sub is serverless, scales to zero, and includes a generous free tier of 10 GB/month.

To set up the zero-cost infrastructure in the GCP Console:

Create a Topic: Navigate to Pub/Sub > Topics and click Create Topic. Name it demo-topic. Uncheck the default subscription option.
Create a Subscription: Under Pub/Sub > Subscriptions, click Create Subscription. Name it demo-subscription and link it to your demo-topic.
Configure Delivery: Select Pull delivery. Ensure "Exactly-Once Delivery" remains unchecked, as guarantees outside of "at-least-once" delivery can fall outside the Always Free tier. We handle message deduplication (idempotency) within our application logic instead to maintain a zero-cost profile.

Step 2: Granting Identity-Aware Permissions (IAM)

Our VM identity (the Compute Engine default service account) has no inherent permission to interact with Pub/Sub.

What happens if you skip this? If you deploy your Spring Boot app now, it will crash immediately with a PermissionDeniedException. We must explicitly "stamp its passport" for messaging.

Navigate to IAM & Admin > IAM in the GCP Console.
Locate the principal named: [PROJECT_NUMBER]-compute@developer.gserviceaccount.com.
Click the pencil icon (Edit Principal) next to it.
Click Add Another Role and attach these two specific roles:
- Pub/Sub Publisher
- Pub/Sub Subscriber
Click Save.

Step 3: Integrating Spring Boot

To enable Pub/Sub in your Spring Boot application, include the Spring Cloud GCP Pub/Sub Starter in your pom.xml.

(Architect's Note: If you are building on a modern stack like **Spring Boot 4.x* and Java 25, you must align with Spring Cloud GCP 8.x or newer. Earlier versions use legacy package structures incompatible with modern auto-configuration).*

The Publisher

Implement a simple REST endpoint to broadcast messages:

import org.springframework.web.bind.annotation.*;
import com.google.cloud.spring.pubsub.core.PubSubTemplate;

@RestController
public class PubSubController {
    private final PubSubTemplate pubSubTemplate;

    public PubSubController(PubSubTemplate pubSubTemplate) {
        this.pubSubTemplate = pubSubTemplate;
    }

    @GetMapping("/publish")
    public String publish(@RequestParam("message") String message) {
        pubSubTemplate.publish("demo-topic", message);
        return "Message published: " + message;
    }
}

The Subscriber

Implement a background service to pull and acknowledge messages:

import org.springframework.stereotype.Service;
import com.google.cloud.spring.pubsub.core.PubSubTemplate;
import jakarta.annotation.PostConstruct;

@Service
public class PubSubSubscriber {
    private final PubSubTemplate pubSubTemplate;

    public PubSubSubscriber(PubSubTemplate pubSubTemplate) {
        this.pubSubTemplate = pubSubTemplate;
    }

    @PostConstruct
    public void subscribe() {
        pubSubTemplate.subscribe("demo-subscription", (msg) -> {
            String data = msg.getPubsubMessage().getData().toStringUtf8();
            System.out.println("Received message: " + data);
            // Process message and acknowledge
            msg.ack();
        });
    }
}

Step 4: The Secure Island Deployment

Since our VM is isolated from the public internet, we deploy using the Identity-Aware Proxy (IAP) tunnel.

Deployment Workflow:

Cleanup: Before uploading, connect to your VM via IAP SSH and ensure a clean environment by stopping existing processes and removing old artifacts (like the jar from Part 2):
```
pkill -9 java
rm -f ~/*.jar
```
Transfer the Artifact: Build your application locally (mvn clean package) and transfer the artifact from your laptop's local terminal:
```
gcloud compute scp target/hello-gcp.jar free-tier-vm:~/ --tunnel-through-iap
```
Run with Observability: Execute the application on the VM, piping output to the syslog file (which we configured the Ops Agent to read in Part 2) to ensure visibility in Cloud Logging:
```
java -jar ~/hello-gcp.jar 2>&1 | logger -t spring-boot &
```

Step 5: End-to-End Verification

To verify the messaging loop, we need to hit the /publish REST endpoint to trigger the process.

🚨 The Network Trap: Because the VM has no public IP, you cannot simply curl http://<VM_IP>:8080/publish. The connection will be refused.

To bridge our local machine to the private VM without exposing it to the internet, we establish a Local Port Forwarding Tunnel:

Establish a Local Tunnel from your laptop terminal:

gcloud compute ssh free-tier-vm --tunnel-through-iap -- -L 8080:localhost:8080

Trigger the Publisher: Use your laptop's web browser or local curl to hit the mapped port:
http://localhost:8080/publish?message=HelloZeroCost
Validate in Logs Explorer: Navigate to the GCP Logs Explorer in the console and query for your specific message:
jsonPayload.message:"Received message: HelloZeroCost"

If the log appears, your decoupled architecture is successfully operating entirely within the "Secure Island" constraints!

Summary

We have successfully moved from a standalone VM to a decoupled messaging architecture without incurring a single cent in costs. By choosing the serverless Standard Pub/Sub model over Lite, managing permissions through IAM, and implementing a robust local-tunnel verification workflow, we maintain a production-grade environment within the Always Free tier.

In Part 4, we will solve the storage bottleneck of our 30GB persistent disk by offloading files securely to Google Cloud Storage (GCS).

The Zero-Cost Cloud Engineer: Observability and the 'Where are my logs?' Problem

Mohammad Awwaad — Wed, 11 Mar 2026 03:16:12 +0000

The Zero-Cost Cloud Engineer: Mastering GCP on the Always Free Tier

Part 2: Observability and the "Where are my logs?" Problem

In [Part 1], we successfully spun up our "Always Free" e2-micro VM, secured it by removing the public IP address, and learned how to access it via the GCP Console's Identity-Aware Proxy (IAP) SSH button.

But a secure VM is useless if we can't see what's happening inside it. If our application crashes or our tiny 1GB of memory maxes out, we need to know instantly. We need Observability.

The Dream: Centralized Logging

Why not just read logs directly in the SSH terminal? While easier for a single VM, "The Cloud Way" treats servers as disposable cattle, not beloved pets:

VMs die unexpectedly: If your VM crashes and its hard drive is wiped, your terminal logs vanish. If logs are streamed to a central dashboard, you can investigate why it crashed post-mortem.
Horizontal Scaling: When your app scales to 10 VMs, you can't manually scan 10 SSH terminals. You need one aggregated window.
Automated Alerting: A central dashboard can automatically email you if the word "Exception" appears. A raw terminal cannot.

This is exactly how Netflix and Uber manage their fleets. Google Cloud's centralized dashboard is called Cloud Logging (generously free up to 50 GiB/month) and Cloud Monitoring (free for massive metric allotments).

We just need to install the Google Cloud Ops Agent on our VM to ship the data there.

The GUI Trap: OS Policies on a Tiny VM

Following our rule of prioritizing the "ease of the UI," you naturally navigate to the VM details page in the GCP Console, click the Observability tab, and click the cheerful Install Agent button.

Instantly, an error pops up: "The following instance is not eligible for installing or updating Ops Agent via OS policy assignment."

What Happened?
The GUI installer is actually a massive enterprise feature under the hood called "OS Config Policies," designed for forcing software updates across fleets of thousands of VMs simultaneously. An e2-micro VM is simply too small to run these heavy background synchronization services reliably, so the GUI bulk installer rejects it.

We have to fall back to the terminal.

The Terminal Trap: A VM without Internet

You click the SSH button in the Console to open the terminal and paste the official manual installation command:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh && sudo bash add-google-cloud-ops-agent-repo.sh --also-install

The terminal hangs. Ten seconds pass. Thirty seconds pass. Nothing prints to the screen.

What Happened?
Remember our security posture from Part 1? We explicitly removed the External IP address to avoid getting billed. Because of that, the VM has zero outbound internet access. The curl command is desperately trying to reach the internet to download the script, and the VPC network is silently dropping it.

The Solution: Private Google Access

How do private, disconnected servers download critical updates?

We use a 100% free Google networking feature called Private Google Access. This incredibly powerful feature acts as a secure internal tunnel, allowing isolated VMs to reach Google's internal services (like OS package repositories and Cloud Storage) without needing the public internet.

Let's fix it using the UI:

In the GCP Console search bar, type VPC networks.
Click on the subnet matching your VM's region (e.g., default in us-east1).
Click EDIT at the top.
Locate the Private Google Access toggle, turn it ON, and hit Save. (Ignore any promotional popups or overlapping IP warnings).
Go back to your VM's SSH terminal, cancel the hanging command with Ctrl+C, and run it again.

It immediately succeeds! Google's internal traffic routing kicks in. If you wait a minute and refresh the Observability tab on the VM details page, beautiful CPU and Memory graphs will begin populating.

Deploying Spring Boot

Let's test our setup.
Instead of dealing with Maven commands on a tiny VM—which wouldn't work anyway because our secure VM has no internet access to download dependencies from Maven Central—use the incredibly easy Spring Initializr UI (start.spring.io) or your local IDE (IntelliJ/Eclipse) to generate a basic Spring Boot project on your laptop. Add a simple @Scheduled task that prints a log every 5 seconds.

Build the .jar locally on your laptop, and transfer it over the secure IAP tunnel directly from your local terminal:

gcloud compute scp target/demo-0.0.1-SNAPSHOT.jar <YOUR_VM_NAME>:~/ --zone=<YOUR_VM_ZONE> --tunnel-through-iap

Back in the VM's SSH window, run it:

java -jar ~/demo-0.0.1-SNAPSHOT.jar

The Final Boss: "Where are my logs?"

The app prints logs securely to your SSH terminal. Excellent.
Now, open the Logs Explorer in the GCP Console to view them centrally.

The page is entirely blank. Your Spring Boot logs are nowhere to be found.

What Happened?
The Ops Agent doesn't monitor foreground terminal processes. Furthermore, in newer versions of the agent, Google turned off text logging by default to protect massive clients from accidentally sending petabytes of logs and racking up huge bills. It only collects metrics out of the box.

We must forcefully configure it.

First, stop your terminal process and change how you execute the app. Pipe the standard output to the central Linux diary (/var/log/syslog) using the logger tool:

   java -jar ~/demo-0.0.1-SNAPSHOT.jar 2>&1 | logger -t spring-boot

Second, tell the Ops Agent to listen to the syslog. In the SSH terminal, edit /etc/google-cloud-ops-agent/config.yaml to include exactly this:

   logging:
     receivers:
       syslog:
         type: files
         include_paths:
         - /var/log/syslog
     service:
       pipelines:
         default_pipeline:
           receivers: [syslog]

Restart the agent: sudo systemctl restart google-cloud-ops-agent.

Now, go back to the Logs Explorer and query for:

logName=~".*syslog"
jsonPayload.message=~"spring-boot"

Boom! Your Java application is now reporting enterprise-grade, centralized logs entirely from a secure, internet-less server—and you haven't been charged a single cent.

In Part 3, we'll explore Pub/Sub and decouple our architecture.

The Zero-Cost Cloud Engineer: The $300 Dilemma and Provisioning the Free VM

Mohammad Awwaad — Sun, 08 Mar 2026 19:17:19 +0000

The Zero-Cost Cloud Engineer: Mastering GCP on the Always Free Tier

Part 1: The $300 Dilemma and Provisioning the Free VM

It’s a tale as old as time for developers: You sign up for Google Cloud Platform (GCP). You see that glorious "$300 Free Trial Credit" banner. You think of all the massive, distributed microservice architectures you are going to build over the weekend to learn the cloud.

Then, life happens. Work gets busy. You blink, and 90 days have passed. You log back in, and your $300 credit has silently expired. You didn't even have time to spin up a single database.

Don't panic. This is actually a blessing in disguise.

When you have $300 of "funny money," you don't learn how to architect systems efficiently. You over-provision RAM. You leave databases running overnight. You accidentally pay for public IP addresses you don't need.

By losing the credit, you are now forced to explore the "Always Free" Tier. This tier never expires, but it imposes strict limits on disk space, memory, and network usage. Building a functioning ecosystem inside these constraints makes you a significantly better Cloud Engineer because you are forced to understand exactly what every resource costs and how to optimize it.

Step 1: Designing the Zero-Cost VM

Our entry point to the cloud is a core compute instance (a VM). However, if you simply click "Create VM" and accept the defaults, Google will aggressively charge you.

To stay 100% free, your VM must strictly adhere to these rules:

Machine Type: e2-micro (2 vCPUs, 1 GB memory)
Region: Must be in an eligible US region like us-east1, us-west1, or us-central1.
Disk: 30 GB standard persistent disk (CRITICAL: Ensure this is not an SSD balanced disk, which is the default in the UI and will immediately start charging you hourly!).

Step 2: Warding Off the Hidden Costs

There are two major traps that catch beginners and start generating bills on the very first day:

The Default SSD Trap: When you create a VM, GCP defaults the boot disk to a "Balanced persistent disk" (SSD). The Always Free tier only covers a basic "Standard persistent disk." If you don't manually change this dropdown, you will be billed.
The External IP Trap: By default, GCP assigns your new VM an External IP Address (a public IPv4 address). As of 2024, Google charges for all public IPv4 addresses, regardless of whether you are actually serving web traffic. Furthermore, having a public IP means bots will immediately start probing your tiny 1GB VM, eating up your precious CPU cycles.

The Golden Rule: We prefer the GCP graphical UI over command-line interfaces for provisioning infrastructure as beginners. CLI defaults can easily sneak in public IPs if you aren't paying close attention.

Step 3: Preparing for Java 25 (The Startup Script Catch-22)

To run a Spring Boot application, our VM needs Java. The most efficient way to install software on a new VM is using a Startup Script. We want to use Debian 13 (Trixie) and install the latest Java 25 (LTS).

Here is the exact startup script we need:

#!/bin/bash
# 1. Set up 2GB of swap space (crucial for 1GB VMs)
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab

# 2. Install dependencies & Add Adoptium repository
apt-get update
apt-get install -y wget apt-transport-https gnupg
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/trusted.gpg.d/adoptium.gpg > /dev/null
echo "deb https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list

# 3. Install Java 25 (LTS)
apt-get update
apt-get install -y temurin-25-jdk

🚨 The Catch-22: If we provision the VM with No External IP from the start, this script will immediately fail. The VM won't be able to reach deb.debian.org or packages.adoptium.net to download Java.

The Workaround: We will provision the VM with a temporary External IP, let the script run, and then instantly delete the IP so we don't get billed for it.

Step 4: Provisioning via the GCP Console

Here is how to safely provision your VM and apply the workaround:

Open the GCP Console.
Navigate to Compute Engine > VM instances and click Create Instance.
Name your instance (e.g., free-tier-vm).
Select us-east1 as your region.
In the Machine Configuration, change the series to E2 and the machine type to e2-micro.
Scroll down to the Boot Disk section. Click Change. Select the Debian 13 image, ensure the disk type is "Standard Persistent Disk", and set the size to 30 GB.
Expand the Advanced Options, then expand Management.
In the Automation > Startup script text box, paste the Bash script from Step 3.
Temporarily leave the networking settings alone (let it assign a public IPv4 address).
Click Create at the bottom.

Wait roughly 2 minutes for the VM to fully boot and the backend script to finish installing Java.

Step 5: Securing the Island (Stripping the IP)

Now, we must immediately lock down the VM to prevent getting billed for the public IP.

Go back to your VM's details page.
Click EDIT at the top top.
Scroll down to Network interfaces and click the default network.
Under External IPv4 address, change it from "Ephemeral" to None.
Click Save.

Your VM is now a perfectly secure, completely free, Java 25-equipped island.

Step 6: Accessing the Disconnected Island

How do you, the developer, access a VM with no public IP?

If you try to use standard terminal SSH on your laptop (ssh user@<ip>), it will fail because there is no public IP to hit.

Instead, go back to your VM instances page in the GCP Console. Next to your new VM, click the SSH button.

A new browser window will open, and a terminal will appear. You are in!

Connecting via your Local Terminal
If you prefer to work from your local laptop terminal instead of a browser pop-up, Google provides a seamless command that leverages this exact same secure tunnel via the gcloud CLI:

gcloud compute ssh free-tier-vm --zone=<YOUR_REGION> --tunnel-through-iap

(Replace <YOUR_REGION> with the zone your VM is in, e.g., us-east1-b).

How does this magic work?
Whether using the browser button or the gcloud ssh command, Google is using a free service under the hood called Identity-Aware Proxy (IAP). It securely tunnels your traffic through Google's internal backbone directly into your private VM, all without exposing the VM to the public internet.

You now have a perfectly secure, absolutely free cloud server.

But having a running VM is just the "entry ticket." To truly learn Google Cloud, you should use this isolated VM as a secure hub to explore the other "Always Free" services natively, building out a production-like ecosystem without ever generating a monthly bill.

In Part 2, we will use our new hub to solve absolute necessity: Observability, and we'll learn exactly why your Java applications seem to magically hide their logs when deployed to a secure cloud VM.

I Built a Production-Ready Spring Boot Architecture (So You Don't Have To)

Mohammad Awwaad — Fri, 06 Mar 2026 10:38:07 +0000

I Built a Production-Ready Spring Boot Microservices Architecture (So You Don't Have To)

The Problem: The "Hello World" Trap

Every time we start a new microservices project, we fall into the same trap. Setting up a basic Spring Boot app is fast—but taking it to production readiness is exhausting.

You need to configure an API Gateway, set up an Identity Provider (like Keycloak), figure out how to securely serve both a web app and mobile clients, configure distributed tracing, establish a robust PostgreSQL + Redis baseline, and wire it all together in Docker. Suddenly, you've burned two weeks of dev time before writing a single line of business logic.

I got tired of repeating this process, so I built an Enterprise Spring Microservices Template that solves these infrastructural headaches out of the box.

In this article, I want to walk through the architectural decisions behind this template, specifically focusing on the "Two-Lane" Security Architecture and Defense in Depth.

🏗️ The "Two-Lane" Architecture: BFF for Web, JWT for Mobile

One of the biggest security debates in modern web development is where to store your authentication tokens. Storing JWTs in localStorage in the browser makes your app vulnerable to Cross-Site Scripting (XSS).

To solve this, this architecture implements the Backend-For-Frontend (BFF) pattern for browser clients, while keeping standard Token-based access for mobile clients.

Lane 1: The Web Application (Angular 18)

Web applications should never touch the actual JWT. Instead:

The Angular HTTP interceptor prefixes all API calls with /bff/api/{service}.
The BFF handles the OAuth2 Login flow with Keycloak and receives the tokens.
The BFF stores the tokens securely and issues an HttpOnly, Secure Session Cookie to the browser.
When Angular makes a request, the BFF attaches the saved JWT and forwards the request to the Spring Cloud Gateway.

Lane 2: The Mobile Application

Mobile apps don't suffer from the same browser XSS vulnerabilities. iOS and Android have secure enclaves (like Keychain) to store tokens.

The mobile app authenticates directly with Keycloak and receives the JWT.
The mobile app makes requests directly to the API Gateway using the Authorization Header (Bearer <token>).

🛡️ Defense in Depth: Zero-Trust Security

Just securing the outer perimeter isn't enough anymore. If an attacker breaches the API Gateway, your internal microservices shouldn't blindly trust the incoming request.

This template enforces a strict Defense in Depth strategy using JWKS (JSON Web Key Sets).

1. Gateway Validation

The Spring Cloud Gateway acts as the first line of defense. It completely strips the BFF prefix and restructures the path.

UI Request: -> /bff/api/profile-service/users
BFF Forwards: -> /profile-service/users
Gateway Rewrites: -> /api/users (Routes to profile-service)

At the Gateway, the JWT signature and basic claims are validated before the request ever touches an internal network.

2. Service-Level Validation (Microsegmentation)

Even though the Gateway validated the token, every individual microservice validates it again.
Each Spring Boot service fetches the JWKS from Keycloak to cryptographically verify the token. Furthermore, fine-grained Role-Based Access Control (RBAC) is enforced at the method or endpoint level within the specific service.

⏱️ Solving the Token Expiry Edge Case (Proactive Token Refresh)

Have you ever experienced a bug where a user clicks a button, the request goes through, but the request fails mid-flight because the token expired a millisecond too soon?

This template addresses token lifecycle issues with a 60-Second Proactive Refresh Buffer.
When the client (BFF or Mobile app) prepares to make a request, it checks the token's expiration. If the token is set to expire in the next 60 seconds, it actively requests a refresh before dispatching the API call.

This eliminates mid-flight 401 Unauthorized errors and provides a perfectly smooth user experience.

📊 Observability First

When a request travels through an Angular app -> BFF -> Gateway -> Microservice, finding out where it failed is a nightmare without traceability.

This architecture has Observability included by default:

Micrometer Tracing: Generates and propagates standard traceId and spanId across all services.
Loki / Grafana: Centralized structured logging. You can query logs by traceId to instantly see the entire lifecycle of a request.
Zipkin: Visualizes request latency and bottlenecks.

You don't need to manually inject UUIDs into your logs; the context is already handled by the framework.

🚀 Get Started Immediately

If you want to skip the boilerplate phase of your next project and start directly with a scalable, secure, and observable baseline, you can use this template.

The Stack:

Backend: Java 25 (LTS), Spring Boot 4.x, Spring Cloud Gateway
Frontend: Angular 18
Infrastructure: Keycloak, PostgreSQL, Redis
DevOps: Fully containerized with Docker / Maven

🔗 GitHub Repository
🔗 GitLab Repository

If you found this architecture breakdown helpful, consider giving the repository a ⭐️ on GitHub! I'd love to hear your thoughts on the Two-Lane approach in the comments.