Skip to content
CloudKops logo CloudKops

Available for backend & infrastructure work

Building Reliable Backend Systems & Cloud Infrastructure

Backend & DevOps engineer specializing in Go, Kubernetes, cloud infrastructure, and automation — designing systems that stay up, scale predictably, and fail safely.

Experience
4+ yrs
Focus
Go & K8s
Clouds
AWS/GCP
cluster: healthy
control-plane api · etcd · scheduler node-a us-east-1a pod / api pod / worker cpu 34% · mem 51% node-b us-east-1b pod / api pod / worker cpu 34% · mem 51% node-c us-east-1c pod / api pod / worker cpu 34% · mem 51% 3/3 nodes ready reconciled 2s ago
Jahir Raihan, Backend & DevOps Engineer

Jahir Raihan

Backend & DevOps Engineer · CloudKops

About

Engineering problems first, technology second.

I'm a backend engineer who spends most of my time in the layer users never see — the services, queues, and clusters that decide whether an application stays up under load or falls over quietly at 2 a.m. Over the past four years that's meant designing APIs in Go and Spring Boot, containerizing them, and running them on Kubernetes across AWS, GCP, and OCI.

What actually holds my attention isn't a specific framework — it's the failure modes: a service that can't recover from a dependency timeout, a deployment pipeline that can't roll back safely, an autoscaler tuned for the wrong signal. I care about tracing those problems back to root cause, then automating the fix so it doesn't recur.

That mindset shows up in how I build: infrastructure defined as code with Terraform, delivery pipelines that fail loudly instead of silently, and dashboards that tell you something is wrong before a customer does. Less about shipping more code, more about shipping systems that keep working.

Experience
4+ years in backend engineering
Languages
Go, Java (Spring Boot)
Platforms
Docker, Kubernetes
Infrastructure
Cloud infra & Terraform
Delivery
CI/CD automation
Observability
Monitoring, logging, alerting

Core Expertise

What I build, end to end.

From the API layer down to the cluster it runs on — I work across the full stack of a production backend, not just the parts that are easy to demo.

Backend Engineering

Services and APIs designed for correctness under concurrency and load.

  • Go
  • Spring Boot
  • REST APIs
  • gRPC
  • Microservices
  • MongoDB
  • PostgreSQL

Cloud & Infrastructure

Infrastructure as code, provisioned and reproducible across providers.

  • Kubernetes
  • Docker
  • AWS
  • GCP
  • Terraform
  • Ansible

DevOps

Pipelines and observability that catch problems before customers do.

  • GitHub Actions
  • Jenkins
  • Linux
  • Monitoring
  • Prometheus
  • Grafana
  • Loki

Architecture

System design decisions that hold up as traffic and teams grow.

  • Distributed Systems
  • Scalability
  • High Availability
  • Performance
  • System Design

Featured Projects

Systems I've designed and shipped.

A mix of open-source tooling and production backends — each one built to solve a specific operational problem, not to fill out a portfolio.

Active development
Featured

GCP Compute Pricing & Monitoring Service

Redis-cached pricing API for GCP Compute Engine costs

A Go/Echo service that estimates Google Cloud Compute Engine costs — CPU, RAM, GPU, persistent disks/Local SSD, OS/license surcharges, and network egress — against the official Cloud Billing Catalog API, across on-demand, spot, and 1yr/3yr committed-use pricing. A scheduled sync job pulls the full catalog from GCP daily, detects real price changes via content hashing, and atomically swaps MongoDB plus pre-warms a versioned Redis cache, so the request-serving API never calls the GCP API directly and stays fully stateless and horizontally scalable.

GoEchoMongoDBRedisGCP Billing Catalog APIKubernetes

Highlights

  • Single & batch cost estimation API (POST /api/v1/calculate)
  • Redis-cached read path — ~2 round trips per fully-loaded request, near-zero DB calls
  • Versioned cache cutover for atomic, fleet-wide price updates with no stale window
  • Daily catalog sync with content-hash change detection (skips no-op writes)
  • Sustained use discount & spot/committed-use pricing modes
  • Redis Cluster support for HA, with pipelined batching around the CROSSSLOT constraint
  • Startup schema-version check to prevent serving against a stale derived-field cache
  • Docker + Kubernetes deployment (CronJob sync, HPA-scaled API tier)
Active development

GCP Pricing Grafana Data Source Plugin

Monitor GCP resource pricing directly inside Grafana

A Grafana data source plugin that surfaces real-time and historical GCP resource pricing as queryable panels, letting infra teams track cost trends alongside their existing observability dashboards.

GoTypeScriptGrafana Plugin SDKGCP Billing API

Highlights

  • Custom Grafana data source plugin
  • Real-time GCP pricing queries
  • Cost trend panels & alerting
  • Per-project and per-service breakdowns
  • Dashboard templates for common GCP services
Active development

InfraSight

Open-source Kubernetes security scanner

A CLI tool written in Go that scans Kubernetes clusters for misconfigurations, RBAC risks, and drift from security baselines — built for teams that want CIS-style checks without a heavyweight platform.

GoKubernetes APICobra CLIDocker
View on GitHub

Highlights

  • Kubernetes security scanner
  • Misconfiguration detection
  • RBAC analysis
  • CLI-first workflow
  • JSON output for CI pipelines
  • Docker support
Active development

Cloud Automation Platform

Provision infrastructure across AWS, GCP, and OCI

A unified provisioning layer that wraps Terraform modules behind a single API, letting teams request compute, networking, and storage across three cloud providers without hand-writing HCL for each one.

GoTerraformKubernetesPostgreSQL

Highlights

  • Multi-cloud provisioning (AWS, GCP, OCI)
  • Terraform module orchestration
  • Policy-based approval workflow
  • Drift detection & reconciliation
  • Audit-logged infrastructure changes
Active development

goqueue

Interface-driven background job queue for Go

A lightweight, strongly-typed background job queue for Go, built on generics so job payloads are defined without manual JSON marshaling. Jobs persist across pluggable storage backends — PostgreSQL, MySQL, Redis, or MongoDB — with built-in retry policies, dead-letter handling, and graceful shutdown.

GoPostgreSQLMySQLRedisMongoDB
View on GitHub

Highlights

  • Generic, strongly-typed job payloads (no manual JSON marshaling)
  • Pluggable storage backends: PostgreSQL, MySQL, Redis, MongoDB
  • Simple API: New(), Enqueue(), Register()
  • Built-in retry policies with exponential backoff, plus custom policies
  • Dead-letter job support
  • Delayed job scheduling & per-job configuration overrides
  • Graceful shutdown
Active development

VPN Node Infra

Terraform + Ansible WireGuard VPN node with Prometheus metrics

Provisions a single-region WireGuard VPN node on AWS with Terraform and configures it with Ansible — WireGuard interface, NAT/forwarding, and a small Go agent that exposes per-peer traffic counters for Prometheus. New client peers can be hot-added to the live interface without restarting the tunnel.

TerraformAnsibleWireGuardGoAWSPrometheus

Highlights

  • Terraform-provisioned VPC/EC2/EIP/security group, auto-writes Ansible inventory
  • Idempotent WireGuard setup: keypair generation, wg0.conf, IPv4 forwarding, NAT rules
  • Hot-add client peers via wg set, persisted to survive reboot
  • Go node agent polling wg show, exposing per-peer byte counters at /metrics
  • systemd-managed WireGuard interface and agent, both start on boot

Engineering Philosophy

Reliability is a practice, not a feature.

Engineering isn't about writing code — it's about building systems you can trust at 3 a.m. Every project I take on runs through the same loop: understand the real behavior of the system, ship something small enough to verify, measure what actually happens in production, and use that evidence to decide what to fix next. Automation exists to make the good outcome the default one, not to remove judgment — just the need to repeat it manually. The loop never really finishes; it just resets at a more reliable baseline each time.

  1. 01

    Learn

    Understand the system as it actually behaves — not as the diagram claims.

  2. 02

    Build

    Ship the smallest version that proves the design under real conditions.

  3. 03

    Measure

    Instrument it. An unmeasured system is a guess wearing a uniform.

  4. 04

    Optimize

    Fix the bottleneck the data points to, not the one that's easiest to fix.

  5. 05

    Automate

    Turn the fix into a pipeline, a policy, or an alert — so a human isn't the safeguard.

  6. 06

    Repeat

    Systems drift. The loop doesn't close — it just starts again at a higher baseline.

Writing

Notes from production.

Long-form write-ups on the infrastructure and backend problems I run into most — published as they're ready, not on a schedule.

Kubernetes

What actually happens during a pod eviction

Tracing the kubelet's decision path from resource pressure to eviction, and what that means for how you set requests and limits.

Draft · in progress
Go

Context cancellation is not error handling

Why treating ctx.Done() as your error strategy leads to goroutine leaks, and a pattern for separating the two concerns.

Draft · in progress
Docker

Multi-stage builds beyond smaller images

Using build stages to isolate secrets, speed up CI caching, and produce reproducible artifacts across environments.

Draft · in progress
System Design

Idempotency keys are a contract, not a header

What it actually takes to make retried requests safe end-to-end — storage, TTLs, and the failure modes people miss.

Draft · in progress
DevOps

Rollbacks should be a pipeline stage, not a plan

Designing CI/CD so a rollback is a tested, one-command action instead of an improvised response during an incident.

Draft · in progress
Observability

Why your metrics are lying to you

How to avoid the common pitfalls of metrics collection, aggregation, and visualization that lead to misleading dashboards.

Draft · in progress
Flagship Project

One pricing engine. Two ways to see it.

A GCP cost-monitoring system built as a backend service and a Grafana data source plugin — the same live pricing data, once as an API teams can query before they provision, and once as panels teams already watch after they do.

~31.6k

SKUs synced per catalog pull

2

Redis round trips per priced request

>99%

Cache hit rate (steady state)

Daily

Catalog sync cadence

  1. 01

    The problem

    Teams provisioning GCP Compute Engine had no fast way to see the real cost of a config before spinning it up, and no way to notice when GCP's own prices drifted underneath them.

  2. 02

    The pricing engine

    A Go/Echo service prices CPU, RAM, GPU, disks, and egress against the live Cloud Billing Catalog API. A daily sync job pulls the full catalog, hashes it to detect real price changes, and atomically swaps a versioned Redis cache — so every request is served from Redis in ~2 round trips, never blocked on a live GCP call.

  3. 03

    The Grafana lens

    A companion Grafana data source plugin surfaces that same pricing data as native panels, so cost sits alongside the CPU, memory, and network dashboards infra teams already watch — turning a one-off estimate into an ongoing signal.

  4. 04

    The outcome

    Expensive configurations get caught on a dashboard before they hit the bill, not after — and a price change in GCP's own catalog shows up as a trend line, not a surprise invoice.

Tech Stack

Tools I reach for by default.

Not an exhaustive list — the languages, runtimes, and infrastructure I use often enough to trust deeply.

  • Go
  • Java
  • Docker
  • Kubernetes
  • Terraform
  • Ansible
  • AWS
  • GCP
  • GitHub Actions
  • Jenkins
  • PostgreSQL
  • Redis
  • Kafka
  • Grafana
  • Prometheus

Contact

Let's build something reliable.

Open to backend engineering and cloud infrastructure roles, contract work, and conversations about distributed systems. I usually reply within a day.