DEV Community: Kamal Rhrabla

How Traveling Shaped My Mind and Helped Me Respect Other Cultures

Kamal Rhrabla — Wed, 27 May 2026 19:21:07 +0000

Traveling is more than moving from one place to another. It is not only about seeing new places, taking pictures, or trying different foods. For me, traveling has been one of the most important experiences in shaping my psychological thinking, widening my perspective, and teaching me how to respect other people’s cultures.

When you travel, you do not only discover the world, you also discover yourself. You learn how people live differently, think differently, eat differently, and express themselves differently. This helps you become more open-minded, more understanding, and more human.

Traveling and psychological growth

One of the biggest benefits of traveling is psychological growth. When a person stays in only one environment for too long, it is easy to think that their way of living is the normal or correct way. But traveling teaches the opposite. It teaches that there are many ways to live a meaningful life.

Travel helps a person become mentally flexible. It challenges assumptions, reduces narrow thinking, and builds empathy. You begin to understand that culture shapes behavior, values, traditions, and even communication styles. Instead of judging differences, you begin to appreciate them.

Traveling also helps build confidence and independence. When you visit new places, adapt to unfamiliar situations, and communicate with different people, your mind becomes stronger. You become better at observing, learning, and adjusting. These experiences improve not only knowledge, but also emotional intelligence.

Learning respect through culture

Respecting other cultures is one of the most valuable lessons travel can teach. Every country and every city has its own traditions, food, social rules, and way of life. When we travel with curiosity and respect, we stop seeing difference as something strange. We start seeing it as something beautiful.

Culture is not something to compare in order to decide which is better. It is something to understand. By meeting people from different backgrounds, we learn that values such as kindness, hospitality, family, and community can exist everywhere, even if they are expressed differently.

Travel taught me that respect begins with listening and observing. It means entering another place with humility, not superiority. It means learning from people instead of assuming we already know enough.

My experience with external traveling

Traveling outside Morocco expanded my thinking even more. Visiting Thailand, Malaysia, and Saudi Arabia helped me understand the world from a broader perspective.

Thailand

Thailand left a strong impression on me because of its beauty, culture, and atmosphere. The nature there is remarkable, with tropical landscapes, beaches, and a relaxing environment. The food culture is also very rich and memorable. Thai food is known for its strong flavors, balance, and creativity. Experiencing their food showed me how deeply culture can be expressed through taste.

What I also appreciated in Thailand was the calmness and kindness often shown in social interactions. It made me reflect on the importance of respect, politeness, and peaceful coexistence.

Malaysia

Malaysia gave me a strong sense of multicultural harmony. It is a country where different cultures, religions, and communities exist together in a visible way. That was very meaningful to me. It showed me that diversity can be a source of strength.

The food in Malaysia was another important part of the experience. It reflects a blend of cultural influences, which makes it rich and varied. The natural landscapes, urban development, and cultural diversity together made the country feel dynamic and educational.

Traveling there made me think more about coexistence and how societies can be shaped by openness and exchange.

Saudi Arabia

Saudi Arabia gave me a different kind of experience, one that felt deeply connected to tradition, religion, and identity. The culture there carries strong values related to family, faith, and hospitality. Visiting Saudi Arabia helped me better understand a society where tradition plays a central role in daily life.

The food, clothing, social manners, and environment all reflected a strong cultural identity. This experience reminded me that every country has its own rhythm and logic. Understanding that helps a person become less judgmental and more respectful.

My experience with internal traveling in Morocco

Since I was a child, I had the chance to travel inside Morocco, and these experiences had a big impact on me. Morocco itself is a country full of diversity. Each city has its own atmosphere, identity, and cultural beauty.

Merzouga

Traveling to Merzouga gave me a special connection with nature. The desert has a unique silence that makes a person reflect deeply. The golden dunes, the open sky, and the peaceful atmosphere create a different kind of thinking. In Merzouga, I felt the beauty of simplicity. Life there teaches patience, calmness, and appreciation for natural beauty.

Marrakech

Marrakech showed me energy, color, and tradition. The city is full of life, from its markets to its architecture. The food, the people, the movement, and the historical feeling of the city make it unforgettable. Marrakech taught me how culture can be alive in everyday life. It is a place where tradition and activity meet in a powerful way.

Chefchaouen

Chefchaouen gave me a feeling of calm and simplicity. The blue streets, the mountains around the city, and the peaceful atmosphere make it feel different from anywhere else. Walking through its small alleys feels relaxing and timeless. The city taught me that beauty does not always need noise or speed. Chefchaouen is a place where nature, color, and peace exist together in harmony.

Essaouira

Essaouira showed me freedom, art, and the spirit of the ocean. The sound of the waves, the old medina, and the windy streets create a unique atmosphere full of creativity and history. The city feels both traditional and open to the world at the same time. Essaouira taught me how a place can stay calm while still being full of life and inspiration.

Rabat

Rabat gave me a different impression. It feels organized, calm, and elegant. As the capital of Morocco, it reflects both history and modernity. Traveling there helped me see another side of Moroccan identity, one that is political, intellectual, and balanced. It made me appreciate the variety that exists even within one country.

Tangier

Tangier felt unique because of its geographic and cultural position. It has a special charm, influenced by both Moroccan and international history. The sea, the atmosphere, and the cultural richness of Tangier gave me the feeling of openness. It is a city that naturally connects worlds, and that made me think more about how cultures meet and influence each other.

Through traveling in Morocco from childhood, I learned that even inside one country, people live in different ways. Their accents, habits, foods, and environments may change from one city to another. This taught me early in life to respect diversity and to stay curious.

Food, nature, and the human connection

One of the most beautiful parts of traveling is how food and nature become ways of understanding people. Food is not just something we eat, it carries memory, history, and identity. Every dish tells a story about the land, the climate, and the traditions of a place.

Nature also changes the way we think and feel. Deserts, seas, mountains, forests, and cities all affect the human mind differently. Traveling through these environments helps us feel the variety of life more deeply.

When I think about Morocco, Thailand, Malaysia, and Saudi Arabia, I do not only remember places. I remember feelings, colors, flavors, conversations, and lessons. That is what makes travel powerful.

Conclusion

Traveling has helped me grow not only as a person who sees the world, but as a person who understands it more deeply. It improved my psychological thinking by making me more open-minded, adaptable, and respectful of other cultures. It taught me that differences are not barriers, they are opportunities to learn.

My external travels to Thailand, Malaysia, and Saudi Arabia expanded my vision and helped me understand the richness of global cultures. My internal travels in Morocco, from Merzouga to Marrakech, Rabat, and Tangier, taught me to appreciate diversity within my own country.

In the end, travel is one of the best teachers. It teaches respect, humility, curiosity, and human connection. And most importantly, it reminds us that no matter how different people may seem, there is always something valuable we can learn from one another.

How Some Books Shaped My Way of Thinking

Kamal Rhrabla — Wed, 27 May 2026 19:12:49 +0000

Some books entertain you for a few days. Others quietly reorganize the way you see yourself, your work, and your future. For me, Atomic Habits by James Clear, Deep Work by Cal Newport, and The Mountain Is You by Brianna Wiest are three of those books.

Each one helped me in a different way. Together, they changed how I think about growth, discipline, focus, and self-sabotage. They did not just give me advice. They gave me frameworks. And once you have a better framework, your choices start to change naturally.

1. Atomic Habits taught me that small actions shape identity

Before reading Atomic Habits, it was easy to think of improvement as something dramatic. I thought change had to feel big to matter. James Clear helped me understand the opposite: real change often begins in tiny, repeatable actions.

The most powerful idea from the book is that habits are not just about results — they are about identity. Every repeated action is a vote for the kind of person you want to become. That idea changed my thinking because it moved me away from chasing motivation and toward building proof.

Instead of saying, “I want to be productive,” I started thinking, “What would a productive person do today?”
Instead of saying, “I want to be healthier,” I started asking, “What small habit would reinforce that identity?”

This way of thinking feels more realistic and more sustainable. It removes the pressure of instant transformation and replaces it with consistency. It helped me realize that success is rarely one giant decision. More often, it is the outcome of many small decisions repeated over time.

2. Deep Work taught me that focus is a skill, not just a mood

Deep Work helped me see how much modern life trains distraction. It is easy to stay busy all day and still avoid meaningful progress. Cal Newport makes a strong distinction between shallow work and deep work. Shallow work keeps you occupied. Deep work creates real value.

This book changed my mindset by showing me that concentration should be trained and protected. I stopped thinking of focus as something that appears when I “feel like it.” Instead, I began to see it as a discipline.

That shift matters a lot. When you treat focus like a skill, you stop waiting for perfect conditions. You start creating them. You protect your time, reduce distractions, and make space for serious thought.

Because of this book, I think more carefully about where my attention goes. Attention is not a small thing. It shapes output, learning, and even confidence. When I can focus deeply on one thing, I feel more capable, more calm, and more in control of my direction.

3. The Mountain Is You taught me that the real challenge is often internal

While Atomic Habits focuses on behavior and Deep Work focuses on attention, The Mountain Is You goes deeper into the emotional side of growth. Its main message is powerful: many of our biggest obstacles are not external. They come from within.

That idea forced me to think differently about self-sabotage. Sometimes procrastination is not laziness. Sometimes inconsistency is not lack of ability. Sometimes fear, unresolved emotions, or limiting beliefs are quietly shaping behavior.

This book helped me become more honest with myself. Instead of only asking, “Why am I not doing better?” I started asking, “What part of me is resisting change, and why?”

That question changes everything. It encourages self-awareness instead of self-judgment. It reminds me that growth is not only about pushing harder. Sometimes it is about healing, understanding, and letting go of patterns that no longer serve you.

4. How these books work together

What makes these three books especially powerful is how well they connect.

Atomic Habits teaches me how to build better systems
Deep Work teaches me how to protect my attention and produce meaningful work
The Mountain Is You teaches me how to understand the inner resistance that gets in the way

Together, they create a fuller picture of personal growth.

One book says: start small and stay consistent.

Another says: focus deeply on what matters.

The third says: understand yourself well enough to stop becoming your own obstacle.

That combination has helped my way of thinking become more intentional. I now think less about overnight success and more about daily structure. I think less about being constantly busy and more about being deeply effective. I think less about blaming circumstances and more about understanding my own patterns.

5. How they changed my mindset in everyday life

These books influenced me beyond reading. They affect how I approach normal days.

Discipline

I no longer see discipline as punishment. I see it as a way of making life easier. Good habits reduce decision fatigue. Focus reduces chaos. Self-awareness reduces repeated mistakes.

Progress

I have become more patient with growth. Small improvements matter. Quiet work matters. Internal change matters. Not every breakthrough looks impressive in the moment.

Self-awareness

I now pay more attention to what triggers avoidance, distraction, or inconsistency. That awareness helps me respond better instead of reacting automatically.

Personal responsibility

These books helped me take more ownership of my life. Not in a harsh way, but in an empowering way. They remind me that while I cannot control everything, I can control many of my systems, choices, and responses.

Conclusion

Atomic Habits, Deep Work, and The Mountain Is You each gave me a different lens for understanding growth. One taught me the power of small repeated actions. One taught me the value of intense focus. One taught me to confront the internal struggles that shape behavior.

Together, they helped me think in a more mature and constructive way. They made me more intentional, more reflective, and more aware that real change happens both externally and internally.

If I had to summarize their impact in one sentence, I would say this: they taught me that becoming better is not about forcing a new life overnight — it is about building better habits, protecting deeper focus, and understanding yourself enough to stop standing in your own way.

How Space Made Me Love Technology

Kamal Rhrabla — Tue, 26 May 2026 18:48:25 +0000

When I was a child, my uncle gave me a book about the cosmos, the planets, and the great mysteries of space.

At that age, I could not fully understand the science behind what I was reading. I did not know how gravity worked, how planets moved, or why the universe seemed so vast and endless. But even without understanding the details, something inside me changed forever.

I still remember spending long hours turning the pages of that book, staring at the images of planets, stars, and galaxies. Every page felt like an invitation to imagine a world far beyond my own. I would look at the illustrations and wonder what existed beyond Earth, beyond the Moon, and beyond everything I could see in the night sky.

Among all the planets, Uranus was always the one that fascinated me the most. Maybe it was its mysterious blue color, its incredible distance from the Sun, or simply the fact that it seemed so different from the others. To me, Uranus felt silent, cold, and unknown, like a hidden world waiting patiently to be discovered and understood.

Looking back now, I believe that book was one of the first reasons I became deeply interested in technology and science. It planted a question in my mind that never truly disappeared: How do humans understand things so far away from us? That question slowly became curiosity, and curiosity eventually became passion.

As I grew older, I began learning more about astronomy, rockets, astronauts, satellites, and the extraordinary engineering behind space exploration. The more I learned, the more amazed I became. Space was no longer just about beautiful planets or distant stars. It became a story of human intelligence, persistence, and imagination.

What fascinated me most was not only the astronauts, but also the thousands of people behind them.

When people think about space missions, they often imagine the astronauts standing at the center of history. But behind every launch, every landing, and every moment of success, there are teams of engineers, scientists, mathematicians, programmers, and technicians working together with precision and dedication. That realization changed the way I saw technology.

The Apollo missions, for example, were not only about reaching the Moon.

They were about collaboration.

They were about discipline, mathematics, engineering, communication, and belief.

Inside Houston’s mission control center, countless professionals worked together toward one final objective: landing human beings on the Moon and bringing them safely back to Earth. Every calculation mattered. Every system mattered. Every person mattered.

Even today, it still feels almost unreal to think about what humanity achieved during that era.

One of the most unforgettable moments in history came with the words:

“Houston, Tranquility Base here. The Eagle has landed.”

That sentence captured the success of years of effort, sacrifice, and innovation. It was not only a message from the Moon, it was proof that human beings could turn an impossible dream into reality.

And then came the moment that inspired millions of people around the world:

“That’s one small step for man, one giant leap for mankind.”

Neil Armstrong’s words represented far more than a person walking on the Moon. They represented the power of curiosity guided by knowledge, and the power of technology guided by vision.

As a child, watching astronauts, rockets, and space documentaries made me realize something important: technology is not just about machines or computers. Technology is imagination transformed into reality. It is the bridge between an idea and an achievement.

Behind every rocket launch, there were people solving problems no one had solved before. There were programmers writing systems, engineers designing machines, mathematicians checking trajectories, and teams making decisions under pressure. These were people who dedicated years of their lives to make the impossible possible.

I think this is one of the reasons I became so passionate about technology and software engineering.

For me, technology has always been more than code, devices, or systems. It is a human effort to create, improve, and explore. It is a way of turning curiosity into progress.

Today, whenever I learn something new about programming, systems, or engineering, I still remember that child sitting with a book of planets and dreaming about space. I remember the wonder I felt, the questions I asked, and the excitement of discovering something bigger than myself.

That feeling never completely disappeared.

And maybe that is the most beautiful part of it all: sometimes, a simple childhood memory can shape an entire future.

Using Google Cloud Storage as an S3 Alternative (AWS S3 --> GCS Guide)

Kamal Rhrabla — Mon, 20 Apr 2026 00:36:36 +0000

If you’re coming from AWS, Amazon S3 is usually the default choice for object storage. On Google Cloud, the direct equivalent is Google Cloud Storage (GCS).

This article explains how to think about GCS if you already know S3, including:

Concept mapping (bucket/object/policy)
Common features (versioning, lifecycle, encryption)
Access control (IAM vs ACLs)
Signed URLs (pre-signed URLs equivalent)
A small hands-on walkthrough with gcloud (and optional gsutil)

1) Quick mapping: S3 concepts → GCS concepts

AWS S3	Google Cloud Storage
Bucket	Bucket
Object	Object
Prefix / “folder”	Object name prefix (folders are virtual)
S3 Versioning	Object Versioning
S3 Lifecycle Rules	Lifecycle Management
Bucket Policy / IAM	Cloud IAM policies (preferred)
ACLs	ACLs (supported, but often discouraged)
SSE-S3 / SSE-KMS	Google-managed encryption / CMEK (Cloud KMS)
Pre-signed URL	Signed URL
S3 Event Notifications	Pub/Sub Notifications + Eventarc (common patterns)

Mental model: GCS is object storage like S3: you store objects in buckets, and you control access with policy.

2) Why choose GCS over S3?

You might choose GCS when:

Your workloads already run on GCP (Cloud Run, GKE, Compute Engine)
You want tight integration with IAM, Cloud KMS, Cloud Logging, BigQuery
You need a clean path to analytics or pipelines (e.g., GCS → BigQuery/Dataflow)

You might stick with S3 when:

Your ecosystem is primarily AWS-based
You heavily rely on S3-specific features or tooling already standardized in your org

3) Create a bucket (the GCS way)

Pick a naming + location strategy

Bucket names are globally unique
You choose a location type (region / dual-region / multi-region)
You can also choose a storage class (Standard, Nearline, Coldline, Archive)

Create a bucket with `gcloud`

Replace placeholders and run:

PROJECT_ID="your-project-id"
BUCKET_NAME="your-unique-bucket-name"
LOCATION="us-central1"

gcloud storage buckets create gs://$BUCKET_NAME \
  --project=$PROJECT_ID \
  --location=$LOCATION

If you used aws s3 mb s3://..., this is the equivalent.

4) Upload, download, list objects

Upload a file

echo "hello gcs" > hello.txt

gcloud storage cp hello.txt gs://$BUCKET_NAME/hello.txt

List objects

gcloud storage ls gs://$BUCKET_NAME

Download the object

rm hello.txt
gcloud storage cp gs://$BUCKET_NAME/hello.txt hello.txt
cat hello.txt

5) Access control: IAM vs ACLs (S3 users pay attention here)

The recommended approach: IAM + Uniform bucket-level access

On GCS, the modern best practice is typically:

Use IAM for access control
Enable Uniform bucket-level access (UBLA)
Avoid object-level ACL complexity unless you really need it

Enable UBLA:

gcloud storage buckets update gs://$BUCKET_NAME --uniform-bucket-level-access

Then grant permissions using IAM.

Example: grant read-only access to a user for a bucket

USER_EMAIL="dev@example.com"

gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
  --member="user:$USER_EMAIL" \
  --role="roles/storage.objectViewer"

S3 analogy:

This is closer to controlling access via IAM policy rather than relying on object ACLs.

6) Public buckets: how to do it (and how to avoid accidents)

Public access is often a footgun. If your goal is “public website assets,” consider using:

Cloud Storage + Cloud CDN (or a load balancer) depending on needs

If you do need public read access, do it intentionally.

Make objects publicly readable (example)

gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
  --member="allUsers" \
  --role="roles/storage.objectViewer"

If this feels similar to an S3 bucket policy allowing s3:GetObject for "Principal": "*", it is.

Tip: For production, pair this with guardrails:

Organization policies
Security reviews
Logging + alerting

7) Signed URLs: the “pre-signed URL” equivalent

Signed URLs are a common pattern when you want:

Users to download private objects without logging in
Users to upload directly to storage without exposing service credentials

Generate a signed URL (example)

There are multiple ways to do this on GCP (CLI, libraries, service accounts).
A typical pattern is:

Use a service account with permission to sign URLs
Generate a URL with an expiration time

If you want, tell me your stack (Node.js / Python / Go) and I’ll add a copy/paste snippet to generate:

Signed download URLs
Signed upload URLs (PUT/POST)

8) Lifecycle rules: manage cost like S3 lifecycle policies

Lifecycle rules help you:

Delete objects older than N days
Move objects to cheaper classes after N days
Clean up incomplete uploads (S3 concept; in GCS you typically manage temp objects differently)

Example lifecycle JSON (delete after 30 days)

Create a file named lifecycle.json:

{
  "rule": [
    {
      "action": { "type": "Delete" },
      "condition": { "age": 30 }
    }
  ]
}

Apply it:

gcloud storage buckets update gs://$BUCKET_NAME --lifecycle-file=lifecycle.json

9) Versioning: protect against accidental overwrites

Enable object versioning:

gcloud storage buckets update gs://$BUCKET_NAME --versioning

This is very similar to enabling S3 Versioning: you keep older generations of objects when overwritten/deleted (depending on lifecycle/retention settings).

10) Encryption: default vs customer-managed keys (CMEK)

By default, GCS encrypts data at rest. If you need tighter control (compliance, audit, key rotation requirements), you can use:

CMEK with Cloud KMS

This resembles S3 SSE-KMS.

If you want, I can write a follow-up post:

“GCS + Cloud KMS (CMEK) step-by-step”
including least-privilege IAM for the KMS key

11) Logging and auditing (don’t skip this)

For production:

Make sure you understand Cloud Audit Logs for storage access
Use Cloud Logging to track access patterns
Add alerts for suspicious behavior (e.g., many deletes, access from unexpected identities)

12) Common pitfalls for S3 users moving to GCS

Bucket names are global (same as S3), so naming can be frustrating—plan ahead.
“Folders” aren’t real (same as S3). Everything is just object prefixes.
IAM vs ACLs: don’t mix unless you know why—prefer UBLA + IAM.
Public access is easy to misconfigure—avoid “quick public” in real systems.
Costs depend on storage class, operations, and egress—use lifecycle rules early.

Wrap-up

If you know S3, you already understand 80% of GCS. The biggest shift is usually access control: on GCP, you’ll typically standardize on IAM + Uniform bucket-level access, plus signed URLs for controlled sharing.

Terraform Modules for Reusable GCP Infrastructure (With a Real VPC Module Example)

Kamal Rhrabla — Sat, 18 Apr 2026 19:01:16 +0000

Terraform modules are the best way to stop copy/pasting infrastructure code across projects and environments. Instead of rewriting the same VPC, subnets, firewall rules, and settings over and over, you wrap that logic in a module and reuse it with clean inputs/outputs.

This post shows:

What a module is (in practice)
How to structure modules in a repo
How to write a reusable GCP VPC module
How to call it for dev and prod
Common module mistakes (and how to avoid them)

What is a Terraform module?

A Terraform module is just a folder containing Terraform files (.tf) that expose:

inputs (variables.tf)
outputs (outputs.tf)
resources (main.tf, etc.)

You can call a module multiple times with different parameters, like:

module "network_dev" {
  source     = "../modules/vpc"
  project_id = "my-dev-project"
  vpc_name   = "dev-vpc"
}

Recommended repository structure

Here’s a clean layout that works well for real teams:

terraform/
  modules/
    vpc/
      main.tf
      variables.tf
      outputs.tf
      versions.tf
      README.md
  envs/
    dev/
      main.tf
      providers.tf
      backend.tf
      terraform.tfvars
    prod/
      main.tf
      providers.tf
      backend.tf
      terraform.tfvars

Idea: keep modules generic and environments thin.

Module example: a reusable GCP VPC module

This VPC module will create:

1 VPC network
N subnets (from a list)
Optional firewall rules (basic example)

`modules/vpc/versions.tf`

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 5.0.0"
    }
  }
}

`modules/vpc/variables.tf`

variable "project_id" {
  description = "GCP project ID where resources will be created."
  type        = string
}

variable "vpc_name" {
  description = "Name of the VPC."
  type        = string
}

variable "routing_mode" {
  description = "VPC routing mode: REGIONAL or GLOBAL."
  type        = string
  default     = "REGIONAL"

  validation {
    condition     = contains(["REGIONAL", "GLOBAL"], var.routing_mode)
    error_message = "routing_mode must be REGIONAL or GLOBAL."
  }
}

variable "subnets" {
  description = <<EOT
List of subnets to create.

Example:
[
  { name="public-us-central1", region="us-central1", cidr="10.10.0.0/24", private_google_access=true },
  { name="private-us-central1", region="us-central1", cidr="10.10.1.0/24", private_google_access=true }
]
EOT

  type = list(object({
    name                  = string
    region                = string
    cidr                  = string
    private_google_access = bool
  }))
}

variable "firewall_rules" {
  description = <<EOT
Optional firewall rules.
Keep it simple: allow protocol/ports from source ranges to target tags.
EOT

  type = list(object({
    name          = string
    direction     = optional(string, "INGRESS")
    priority      = optional(number, 1000)
    source_ranges = list(string)
    target_tags   = list(string)
    protocol      = string
    ports         = list(string)
  }))

  default = []
}

`modules/vpc/main.tf`

resource "google_compute_network" "this" {
  project                 = var.project_id
  name                    = var.vpc_name
  auto_create_subnetworks = false
  routing_mode            = var.routing_mode
}

resource "google_compute_subnetwork" "this" {
  for_each = { for s in var.subnets : s.name => s }

  project                  = var.project_id
  name                     = each.value.name
  ip_cidr_range            = each.value.cidr
  region                   = each.value.region
  network                  = google_compute_network.this.id
  private_ip_google_access = each.value.private_google_access
}

resource "google_compute_firewall" "this" {
  for_each = { for r in var.firewall_rules : r.name => r }

  project     = var.project_id
  name        = each.value.name
  network     = google_compute_network.this.name
  direction   = each.value.direction
  priority    = each.value.priority
  target_tags = each.value.target_tags

  source_ranges = each.value.source_ranges

  allow {
    protocol = each.value.protocol
    ports    = each.value.ports
  }
}

`modules/vpc/outputs.tf`

output "network_id" {
  description = "The ID of the VPC network."
  value       = google_compute_network.this.id
}

output "network_name" {
  description = "The name of the VPC network."
  value       = google_compute_network.this.name
}

output "subnet_ids" {
  description = "Subnet IDs keyed by subnet name."
  value       = { for k, s in google_compute_subnetwork.this : k => s.id }
}

Using the module: dev environment example

`envs/dev/main.tf`

module "vpc" {
  source     = "../../modules/vpc"
  project_id = var.project_id
  vpc_name   = "dev-vpc"

  subnets = [
    {
      name                  = "dev-us-central1-public"
      region                = "us-central1"
      cidr                  = "10.10.0.0/24"
      private_google_access = true
    },
    {
      name                  = "dev-us-central1-private"
      region                = "us-central1"
      cidr                  = "10.10.1.0/24"
      private_google_access = true
    }
  ]

  firewall_rules = [
    {
      name          = "dev-allow-ssh-from-office"
      source_ranges = ["203.0.113.10/32"]
      target_tags   = ["ssh"]
      protocol      = "tcp"
      ports         = ["22"]
    }
  ]
}

`envs/dev/variables.tf`

variable "project_id" {
  type        = string
  description = "Dev project ID"
}

Module tips (this is what saves you later)

1) Keep modules “dumb” and input-driven

Avoid hardcoding:

regions
CIDRs
environment names
project IDs

2) Prefer composable small modules

Instead of a huge “platform module”, consider:

modules/vpc
modules/cloud_run
modules/cloud_sql
modules/iam

Then compose them per environment.

3) Be careful with IAM resources

Some IAM resources are authoritative and can remove access unexpectedly.
When in doubt, start with *_iam_member resources and grow from there.

4) Version your modules

If you publish modules (Git tags), you can pin versions:

module "vpc" {
  source = "git::https://github.com/YOUR_ORG/YOUR_REPO.git//modules/vpc?ref=v1.0.0"
}

Wrap-up

Terraform modules turn your GCP infrastructure into reusable building blocks:

less duplication
safer changes
consistent environments

Getting Started with Google Cloud Platform (GCP): A Practical Guide for Developers

Kamal Rhrabla — Thu, 09 Apr 2026 22:08:22 +0000

Google Cloud Platform (GCP) is Google’s suite of cloud services for building, deploying, and operating applications at scale. If you’ve used AWS or Azure, GCP will feel familiar but it also has some “Google-native” strengths like BigQuery, first-class Kubernetes support, and strong data/ML tooling.

This post is a developer-focused introduction: what GCP is great at, the core services you should know, and a simple path to start shipping real projects.

Why use GCP?

GCP is a strong choice if you care about:

Managed compute that scales cleanly (especially serverless)
Containers + Kubernetes (Google created Kubernetes)
Data workloads (analytics, warehousing, streaming)
Machine learning tooling (MLOps, training, model hosting)
Global infrastructure + networking

It’s also easy to start small (serverless) and grow into more complex architecture only when you need it.

The mental model: how GCP is organized

Before jumping into services, it helps to know the hierarchy:

Organization (company/domain; optional for personal projects)
Folders (optional grouping)
Projects (the main unit for billing, IAM, and resources)
Resources (VMs, buckets, databases, etc.)

For most developers, a Project is where everything begins.

Tip: Use separate projects for dev, staging, and prod if you can especially once billing and IAM start to matter.

Core GCP services developers should know

1) Compute (where your code runs)

Cloud Run: Run containers without managing servers. Great default for APIs, web apps, and workers.
App Engine: PaaS-style deploys (less common in brand-new systems, but still used).
Compute Engine: Virtual machines (full control).
GKE (Google Kubernetes Engine): Managed Kubernetes for orchestration at scale.

Rule of thumb:

If you can containerize it → start with Cloud Run
If you need orchestration across many services → consider GKE
If you need low-level control → use Compute Engine

2) Storage (files and blobs)

Cloud Storage: Object storage for uploads, artifacts, backups, media, static assets.

Good use cases:

User uploads (images/video)
Build artifacts (zips, containers metadata)
Data exports/imports
Static website assets behind CDN

3) Databases (store application data)

Cloud SQL: Managed PostgreSQL / MySQL / SQL Server.
Firestore: NoSQL document database (great for event-driven/mobile/web apps).
Spanner: Globally distributed relational DB (powerful, enterprise-grade).

If you’re building a typical web backend, Cloud SQL (Postgres) is a great starting point.

4) Messaging + async workloads

Pub/Sub: Event streaming and messaging.
Cloud Tasks: Managed task queues (great for background jobs triggered by HTTP).

A common “serverless backbone” looks like:

Cloud Run (API) → Pub/Sub (events) → Cloud Run (worker)

5) IAM (permissions)

IAM controls who can do what.

Prefer least privilege over broad admin access
Use service accounts for apps and automation
Avoid giving everyone Owner (it’s convenient and also risky)

IAM feels annoying until it saves you from accidental production changes or surprise bills.

A practical starter architecture (small, modern, scalable)

If you want a “default” GCP stack for a new product:

Cloud Run for your API (containerized)
Cloud SQL (Postgres) for relational data
Cloud Storage for file uploads
Secret Manager for secrets (DB passwords, API keys)
Cloud Logging + Error Reporting for observability
Cloud Build for CI/CD (optional, but very handy)

This setup is production-friendly without forcing you to operate servers.

Getting hands-on: a simple path to ship something

Here’s a practical 30–60 minute plan:

Create a GCP project
Enable billing (many services require it)
Install the Google Cloud SDK (gcloud)
Deploy a small container to Cloud Run
Add Cloud SQL only after your service is deployed and reachable

The key is momentum: deploy something tiny first, then iterate.

Common mistakes (and how to avoid them)

Using Owner everywhere → create scoped roles/service accounts.
Mixing regions randomly → pick a region near your users and keep services aligned.
No budgets/alerts → set a budget alert on day one.
Starting with Kubernetes too early → Cloud Run often covers your needs for a long time.

When GCP really shines

GCP is especially strong for:

Analytics-heavy products (BigQuery is a standout)
Event-driven systems (Pub/Sub + Cloud Run)
Kubernetes-based platforms (GKE + ecosystem)
ML workflows (Vertex AI + data tooling)

Conclusion

You don’t need to learn all of GCP to be productive. Pick a small core:
Cloud Run + Cloud SQL + Cloud Storage + IAM + Logging, and you can ship real services quickly.

Getting Started with gRPC in Go (Golang): A Practical Guide

Kamal Rhrabla — Thu, 26 Mar 2026 21:25:26 +0000

Modern applications are moving toward microservices and high-performance communication. If you're still using REST for everything, it might be time to explore a faster and more efficient alternative: gRPC.

In this article, we’ll break down what gRPC is, why it’s powerful, and how to build your first service using Golang.

What is gRPC?

gRPC (Google Remote Procedure Call) is a high-performance RPC framework developed by Google. It allows services to communicate directly using function calls instead of traditional HTTP/JSON APIs.

Instead of:

GET /users/1

You do:

userService.GetUser(ctx, &UserRequest{Id: 1})

Why Use gRPC?

1. High Performance

Uses HTTP/2
Binary serialization with Protocol Buffers (Protobuf)
Faster and more efficient than REST/JSON

2. Strongly Typed APIs

Contracts are defined using .proto files
No ambiguity between services

3. Streaming Support

Client streaming
Server streaming
Bidirectional streaming

Perfect for real-time systems (chat apps, live data, etc.)

4. Multi-language Support

Works with Go, JavaScript, Python, Java, etc.

Key Concepts

1. Protocol Buffers (Protobuf)

This is where you define your API structure.

Example:

syntax = "proto3";

package user;

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  int32 id = 1;
}

message UserResponse {
  int32 id = 1;
  string name = 2;
}

2. Code Generation

From the .proto file, you generate Go code:

protoc --go_out=. --go-grpc_out=. user.proto

Building a gRPC Server in Go

Step 1: Install Dependencies

go mod init grpc-demo
go get google.golang.org/grpc
go get google.golang.org/protobuf

Step 2: Implement the Server

package main

import (
    "context"
    "log"
    "net"

    pb "grpc-demo/user"
    "google.golang.org/grpc"
)

type server struct {
    pb.UnimplementedUserServiceServer
}

func (s *server) GetUser(ctx context.Context, req *pb.UserRequest) (*pb.UserResponse, error) {
    return &pb.UserResponse{
        Id:   req.Id,
        Name: "Kamal",
    }, nil
}

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatal(err)
    }

    grpcServer := grpc.NewServer()
    pb.RegisterUserServiceServer(grpcServer, &server{})

    log.Println("gRPC server running on port 50051...")
    if err := grpcServer.Serve(lis); err != nil {
        log.Fatal(err)
    }
}

Building a gRPC Client in Go

package main

import (
    "context"
    "log"
    "time"

    pb "grpc-demo/user"
    "google.golang.org/grpc"
)

func main() {
    conn, err := grpc.Dial("localhost:50051", grpc.WithInsecure())
    if err != nil {
        log.Fatal(err)
    }
    defer conn.Close()

    client := pb.NewUserServiceClient(conn)

    ctx, cancel := context.WithTimeout(context.Background(), time.Second)
    defer cancel()

    res, err := client.GetUser(ctx, &pb.UserRequest{Id: 1})
    if err != nil {
        log.Fatal(err)
    }

    log.Println("User:", res.Name)
}

gRPC vs REST

Feature	gRPC	REST
Protocol	HTTP/2	HTTP/1.1
Data Format	Binary (Protobuf)	JSON
Performance	Faster	Slower
Streaming	Native support	Limited
Browser Support	Limited	Excellent

When NOT to Use gRPC

Public APIs consumed by browsers
Simple CRUD services
When debugging via browser is important

gRPC shines in internal microservices communication

Pro Tips

Use gRPC Gateway if you need REST + gRPC
Add interceptors for logging/authentication
Combine with Docker for microservices
Use TLS in production

Final Thoughts

gRPC with Go is a powerful combination for building fast, scalable, and modern backend systems. If you're targeting microservices or high-performance systems, it's a must-learn tool.

Understanding Goroutines and Channels in Go

Kamal Rhrabla — Tue, 10 Mar 2026 22:53:57 +0000

Concurrency is one of the biggest reasons developers choose Go. While many languages require complex threading models or external libraries, Go provides a simple and powerful way to handle concurrent tasks using goroutines and channels.

In this article, we’ll explore what goroutines and channels are, how they work, and how you can use them to build efficient concurrent programs.

What is a Goroutine?

A goroutine is a lightweight thread managed by the Go runtime. Unlike operating system threads, goroutines are extremely cheap to create and can scale to thousands or even millions running at the same time.

Creating a goroutine is simple: you just add the go keyword before a function call.

package main

import (
    "fmt"
    "time"
)

func sayHello() {
    fmt.Println("Hello from goroutine")
}

func main() {
    go sayHello()
    time.Sleep(time.Second)
    fmt.Println("Main function finished")
}

What happens here?

The go keyword starts sayHello() in a separate goroutine.

The main function continues executing without waiting.

We add time.Sleep so the program doesn’t exit before the goroutine runs.

In real applications, we typically use synchronization mechanisms instead of sleep.

Why Goroutines Are Powerful

Traditional threads can be heavy and expensive. Goroutines solve this problem by being:

Lightweight, very small memory footprint
Fast to create
Managed by the Go scheduler
Perfect for I/O-heavy tasks

Examples of where goroutines shine:

Web servers handling many requests
Background jobs
API calls to multiple services
Concurrent data processing

The Problem: Sharing Data Between Goroutines

If multiple goroutines run at the same time, how do they communicate safely?

In many languages you would use:

Locks
Mutexes
Shared memory

Go promotes a different philosophy:

“Do not communicate by sharing memory; share memory by communicating.”

This is where channels come in.

What Are Channels?

A channel is a typed conduit that allows goroutines to communicate and synchronize.

You can send values into a channel and receive values from it.

Creating a channel

ch := make(chan int)

This creates a channel that can transmit integers.

Sending and Receiving Data

package main

import "fmt"

func main() {
    ch := make(chan int)

    go func() {
        ch <- 42
    }()

    value := <-ch
    fmt.Println(value)
}

What’s happening?

We create a channel.

A goroutine sends the value 42 into the channel.

The main goroutine receives the value and prints it.

Output:

Channels block by default, meaning:

Sending waits until another goroutine receives
Receiving waits until another goroutine sends
This makes synchronization simple.
Buffered Channels Sometimes you don’t want the sender to block immediately. For that, Go provides buffered channels.

ch := make(chan int, 2)

Example:

package main

import "fmt"

func main() {
    ch := make(chan int, 2)

    ch <- 1
    ch <- 2

    fmt.Println(<-ch)
    fmt.Println(<-ch)
}

Here the channel can store 2 values before blocking.

Using Goroutines with Channels (Real Example)

Let’s run multiple tasks concurrently and collect their results.

package main

import (
    "fmt"
    "time"
)

func worker(id int, ch chan string) {
    time.Sleep(2 * time.Second)
    ch <- fmt.Sprintf("Worker %d finished", id)
}

func main() {
    ch := make(chan string)

    for i := 1; i <= 3; i++ {
        go worker(i, ch)
    }

    for i := 1; i <= 3; i++ {
        fmt.Println(<-ch)
    }
}

Output (order may vary):

Worker 2 finished
Worker 1 finished
Worker 3 finished

Here we:

Start 3 goroutines
Each performs work
Each sends a result back through the channel
The main goroutine collects the results
This pattern is very common in Go.
Closing Channels

Sometimes we want to signal that no more values will be sent.

close(ch)

Example:

for value := range ch {
    fmt.Println(value)
}

The loop automatically stops when the channel is closed.

When to Use Goroutines and Channels

You should consider them when:

Running multiple independent tasks
Making parallel API requests
Processing jobs in background workers
Building high-performance servers
Streaming data between components

Common Beginner Mistakes:

1. Forgetting that goroutines are asynchronous

Your program might exit before goroutines finish.

2. Deadlocks

Example:

fatal error: all goroutines are asleep - deadlock!

This happens when goroutines are waiting on each other with no progress.

3. Overusing goroutines

Just because goroutines are cheap doesn’t mean everything should be concurrent.

Final Thoughts

Goroutines and channels are core features that make Go a powerful language for building scalable and concurrent systems.

Instead of complex thread management, Go gives developers a clean and expressive model for concurrency.

Once you master these two concepts, you'll unlock one of Go’s greatest strengths.

If you're learning Go for backend development, mastering goroutines, channels, and concurrency patterns will significantly improve your ability to build fast and scalable services.

Why Go (Golang) Is Becoming a Favorite Language for Backend Developers

Kamal Rhrabla — Thu, 05 Mar 2026 21:40:11 +0000

In recent years, Go (commonly called Golang) has rapidly gained popularity among backend developers. Originally created at Google in 2009, Go was designed to solve real problems engineers faced when building scalable systems.

Today, Go powers infrastructure and backend systems at companies like Uber, Dropbox, and Netflix.

But what makes Go so attractive for modern backend development?

Let’s explore.

1. Simplicity and Readability

One of the biggest strengths of Go is its minimalist design.

Unlike many modern languages that continuously add complex features, Go intentionally keeps the language simple.

For example:

package main

import "fmt"

func main() {
fmt.Println("Hello, Go!")
}

There are no unnecessary abstractions or complicated syntax rules.

This simplicity allows developers to:

Learn the language quickly
Maintain large codebases more easily
Reduce bugs caused by complex logic

2. Built for Performance

Go is a compiled language, similar to C and C++.

That means Go programs are compiled into native machine code, which makes them significantly faster than interpreted languages.

Compared to languages like:

Python
JavaScript

Go applications often provide much better performance, especially for CPU-intensive backend services.

3. Powerful Concurrency with Goroutines

One of Go’s most famous features is goroutines.

A goroutine is a lightweight thread managed by the Go runtime.

Creating thousands of concurrent tasks is incredibly easy:

go processRequest()

Behind the scenes, Go manages scheduling and execution efficiently.

This makes Go particularly powerful for building:

APIs
Real-time systems
Microservices
Distributed systems

Technologies like Docker and Kubernetes are actually written in Go because of these capabilities.

4. Fast Compilation

Another underrated advantage of Go is extremely fast compilation.

Large Go projects compile in seconds, which significantly improves developer productivity compared to languages with slower build processes.

This fast feedback loop makes Go ideal for modern development environments.

5. Excellent Standard Library

Go ships with a very powerful standard library, which covers many common tasks:

HTTP servers
JSON processing
File handling
Cryptography
Networking

For example, building a simple web server takes just a few lines:

package main

import (
"fmt"
"net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello from Go server!")
}

func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil)
}

With this minimal code, you already have a working web server.

6. Ideal for Microservices

Go has become a top choice for microservice architectures.

Its advantages include:

lightweight binaries
fast startup times
low memory usage
strong concurrency support

These characteristics make Go perfect for cloud-native systems.

This is why many modern cloud tools, including Terraform and Prometheus, are written in Go.

When Should You Use Go?

Go is particularly well suited for:

✔ Backend APIs

✔ Cloud services

✔ DevOps tools

✔ Distributed systems

✔ High-performance network services

However, it may not be ideal for:

complex front-end applications
heavy machine learning workloads

Final Thoughts

Go proves that simplicity can scale.

By focusing on performance, readability, and concurrency, Go has become one of the most powerful languages for building modern backend systems.

Whether you're building APIs, infrastructure tools, or distributed platforms, Go offers a productive and efficient development experience.

If you haven't tried Go yet, it might be the perfect language to add to your backend toolkit.

DEV Community: Kamal Rhrabla

How Traveling Shaped My Mind and Helped Me Respect Other Cultures

Traveling and psychological growth

Learning respect through culture

My experience with external traveling

Thailand

Malaysia

Saudi Arabia

My experience with internal traveling in Morocco

Merzouga

Marrakech

Chefchaouen

Essaouira

Rabat

Tangier

Food, nature, and the human connection

Conclusion

How Some Books Shaped My Way of Thinking

1. Atomic Habits taught me that small actions shape identity

2. Deep Work taught me that focus is a skill, not just a mood

3. The Mountain Is You taught me that the real challenge is often internal

4. How these books work together

5. How they changed my mindset in everyday life

Discipline

Progress

Self-awareness

Personal responsibility

Conclusion

How Space Made Me Love Technology

Using Google Cloud Storage as an S3 Alternative (AWS S3 --> GCS Guide)

1) Quick mapping: S3 concepts → GCS concepts

2) Why choose GCS over S3?

3) Create a bucket (the GCS way)

Pick a naming + location strategy

Create a bucket with gcloud

4) Upload, download, list objects

Upload a file

List objects

Download the object

5) Access control: IAM vs ACLs (S3 users pay attention here)

The recommended approach: IAM + Uniform bucket-level access

Example: grant read-only access to a user for a bucket

6) Public buckets: how to do it (and how to avoid accidents)

Make objects publicly readable (example)

7) Signed URLs: the “pre-signed URL” equivalent

Generate a signed URL (example)

8) Lifecycle rules: manage cost like S3 lifecycle policies

Example lifecycle JSON (delete after 30 days)

9) Versioning: protect against accidental overwrites

10) Encryption: default vs customer-managed keys (CMEK)

11) Logging and auditing (don’t skip this)

12) Common pitfalls for S3 users moving to GCS

Wrap-up

Terraform Modules for Reusable GCP Infrastructure (With a Real VPC Module Example)

What is a Terraform module?

Recommended repository structure

Module example: a reusable GCP VPC module

modules/vpc/versions.tf

modules/vpc/variables.tf

modules/vpc/main.tf

modules/vpc/outputs.tf

Using the module: dev environment example

envs/dev/main.tf

envs/dev/variables.tf

Module tips (this is what saves you later)

1) Keep modules “dumb” and input-driven

2) Prefer composable small modules

3) Be careful with IAM resources

4) Version your modules

Wrap-up

Getting Started with Google Cloud Platform (GCP): A Practical Guide for Developers

Why use GCP?

The mental model: how GCP is organized

Core GCP services developers should know

1) Compute (where your code runs)

2) Storage (files and blobs)

3) Databases (store application data)

4) Messaging + async workloads

5) IAM (permissions)

A practical starter architecture (small, modern, scalable)

Create a bucket with `gcloud`

`modules/vpc/versions.tf`

`modules/vpc/variables.tf`

`modules/vpc/main.tf`

`modules/vpc/outputs.tf`

`envs/dev/main.tf`

`envs/dev/variables.tf`