rohitmungre | RSS Feed

Orchestration using Kubernetes

hi@rohitmungre.com — Sat, 14 Dec 2024 00:00:00 GMT

Kubernetes (abbreviated as K8s) is a portable, extensible, open-source platform for managing containerized applications at scale. Kubernetes abstracts infrastructure away from application logic and provides powerful primitives for deploying, scaling, and maintaining containerized workloads. It provides high availability, scalability, resilience for the application. Kuberenetes was originally developed at Google as Bord task scheduler, it's origin story and the journey to getting open sourced is quite fascinating!

This guide walks through Kubernetes by demonstrating foundational concepts using kubectl to advanced architecture and operational strategies.

Core concepts with Kubectl

Before running commands below, make sure to:

Install kubectl on using the official installation guide.
Install docker desktop and enable Kubernetes in settings for starting a local kubernetes server. Other options include k3d (fast, lightweight), kind (quick local testing), MicroK8s (full k8s experience with low resource usage) and minikube (full VM style k8s experience).

Cluster

A Kubernetes deployment consists of multiple nodes managed by a centralized control plane.

Copy

kubectl cluster-info

Nodes

Worker machines (VMs or physical) where pods are scheduled and run. Nodes are managed by the Kubernetes control plane.

Copy

kubectl get nodes

Pods

The smallest deployable unit in Kubernetes. A pod encapsulates one or more containers with shared networking and storage. Pods are ephemeral – they can die and be replaced.

Copy

kubectl run my-nginx --image=nginx   # Creates a pod using nginx
kubectl get pods                     # See your pod
kubectl describe pod my-nginx        # Get detailed info

Deployments

Provide declarative updates for pods and replica sets. They manage rollout, rollback, and scaling of applications.

ReplicaSets ensure a specified number of pod replicas are running at any given time.
Deployment strategies include
- Rolling updates: Gradually replace pods with new ones
- Blue/Green deployments: Maintain two environments and switch traffic
- Canary releases: Release to a subset of users to test changes safely

Copy

kubectl create deployment my-nginx-deploy --image=nginx
kubectl get deployments
kubectl scale deployment my-nginx-deploy --replicas=3
kubectl get pods

Services

A Service exposes your Pods to the network – internally or externally - providing stable DNS names and load balancing. Service types: ClusterIP (internal), NodePort (access via node IP:port), LoadBalancer (cloud load balancer).

Copy

kubectl expose deployment my-nginx-deploy --port=80 --type=LoadBalancer
kubectl get services

Namespaces

A Namespace separates resources logically, useful when you have multiple teams, apps, or environments.

Copy

kubectl create namespace my-namespace
kubectl run test-pod --image=nginx --namespace=my-namespace
kubectl get pods -n my-namespace

ConfigMaps and Secrets

ConfigMaps store non-sensitive configuration. Secrets store sensitive data like passwords.

Copy

kubectl create configmap my-config --from-literal=APP_MODE=production
kubectl create secret generic my-secret --from-literal=DB_PASSWORD=secret123
kubectl get configmaps
kubectl get secrets

Configuring a basic pod yaml

Instead of using commands, you can define Pods declaratively with YAML. YAML is how real-world Kubernetes works. Example pod.yaml:

Copy

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx
    ports:
    - containerPort: 80

Apply it to create the pod and delete once done

Copy

kubectl apply -f pod.yaml
kubectl delete -f pod.yaml

Kubernetes Architecture

Control Plane Components

API Server: Frontend for the Kubernetes control plane
Scheduler: Assigns pods to nodes based on resource availability
Controller Manager: Runs background reconciliation loops
etcd: Consistent and highly available key-value store used as Kubernetes' backing store

Node Components

Kubelet: Agent running on each node that manages pod lifecycles
Kube-proxy: Maintains network rules for pod communication
Container runtime: Software responsible for running containers (e.g., containerd, CRI-O)

Advanced Features

Horizontal Pod Autoscaler (HPA): Auto-scales Pods up or down based on CPU, memory, or custom metrics. Helps optimize resources during traffic spikes or low-load periods.
Persistent Volumes (PV) and Storage Classes: Persistent Volumes (PV) are pre-provisioned or dynamically created storage. Persistent Volume Claims (PVC) requests for storage by applications. Storage Classes define different types of storage (e.g., SSDs vs. HDDs) dynamically.
Network Policies: Set rules for which Pods or Namespaces can communicate with each other. Crucial for zero-trust networking and cluster security hardening.
Ingress and Traffic Management: Ingress Controllers (NGINX, Traefik) expose Services externally via HTTP(S). It supports path-based and host-based routing, SSL/TLS termination, load balancing, authentication, rate-limiting, and WAF (Web Application Firewall) features.
Security and RBAC (Role-Based Access Control): RBAC provides fine-grained permissions for users, groups, and services. Service Accounts secure identities for Pods accessing APIs. Pod Security Admission control security settings like running as non-root & preventing privilege escalation. Network Policies further reinforce communication restrictions.

Observability

Monitoring and logging are critical in production Kubernetes environments.

Popular tools include:

Prometheus and Grafana for metrics
Fluentd, Logstash, Loki for logging
Jaeger, OpenTelemetry for tracing

Helm and Operators

Helm: Kubernetes package manager that simplifies deployment of complex applications using charts.
Operators: Custom controllers that extend Kubernetes to manage application lifecycles, especially for stateful apps like databases.

Best Practices

Use readiness and liveness probes for better pod health checks
Implement resource requests and limits to manage cluster resources
Avoid anti-patterns like monolithic pods or tight coupling
Organize workloads using namespaces, labels, and annotations
Regularly audit RBAC roles and permissions

Kafkaesque Streaming

hi@rohitmungre.com — Wed, 20 Nov 2024 00:00:00 GMT

What is Kafka?

Apache Kafka is a distributed streaming platform used for building real-time data pipelines and streaming applications. You can think of it as a distributed log system. Instead of sending data from point A to point B, Kafka acts as a durable, high-performance, fault-tolerant log where data is written once and consumed many times. It’s fast, scalable, and fault-tolerant.

Glossary

Producer: Sends (produces) messages to Kafka topics.
Consumer: Reads (consumes) messages from Kafka topics.
Topic: A category/feed name to which messages are sent and from which consumers receive messages.
Partition: Topics are split into partitions to allow scalability.
Broker: A Kafka server that stores data and serves clients.
Zookeeper: Manages Kafka’s metadata and cluster state (Kafka 3.x can run without it, but many setups still use it).
Consumer Group: A group of consumers that coordinate to read data in parallel.

This article walks through Kafka from the ground up using kafka cli via docker, progressing into its more advanced capabilities and architectural nuances.

Kafka using docker

Start Kafka with Docker

A basic docker-compose.yml for Kafka + Zookeeper below:

Copy

version: '3'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000

  kafka:
    image: confluentinc/cp-kafka:latest
    ports:
      - "9092:9092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

Start it:

Copy

docker-compose up -d

Verify that confluentinc/cp-kafka:latest is up using below and copy the container id (to be used in the commands going forward)

Copy

docker ps

Cli commands

List topics

Copy

docker exec -it <container_id> kafka-topics --bootstrap-server localhost:9092 --list

Create a Topic

Copy

docker exec -it <container_id> kafka-topics \
  --bootstrap-server localhost:9092 \
  --create --topic my-topic \
  --partitions 1 --replication-factor 1

Describe a Topic

Copy

docker exec -it <container_id> kafka-topics \
  --bootstrap-server localhost:9092 \
  --describe --topic my-topic

Produce (Send) Messages

Copy

docker exec -it <container_id> kafka-console-producer \
  --broker-list localhost:9092 --topic my-topic

Type your messages, press Enter to send each one.

Consume Messages

Copy

docker exec -it <container_id> kafka-console-consumer \
  --bootstrap-server localhost:9092 \
  --topic my-topic --from-beginning

Delete a Topic

Copy

docker exec -it <container_id> kafka-topics \
  --bootstrap-server localhost:9092 \
  --delete --topic my-topic

Start Consumer Group

Copy

docker exec -it <container_id> kafka-console-consumer \
  --bootstrap-server localhost:9092 \
  --topic my-topic --group my-group

List Consumer Groups

Copy

docker exec -it <container_id> kafka-consumer-groups \
  --bootstrap-server localhost:9092 --list

Describe Consumer Group

Copy

docker exec -it <container_id> kafka-consumer-groups \
  --bootstrap-server localhost:9092 \
  --describe --group my-group

Cleanup

Copy

docker-compose down
docker volume prune  # if you want to wipe all Kafka data

Kafka Architecture

Kafka is designed around a pull-based model, where consumers pull data from brokers at their own pace. Messages are stored durably on disk and replicated across brokers for fault tolerance.

Key architectural traits:

Immutable commit log
Offset tracking for exactly-once or at-least-once semantics
Replication for durability and high availability
Horizontal scalability by adding more brokers/partitions

Advanced Topics

Kafka Internals

Kafka uses a log-structured storage system, where data is appended to a log file. This enables:

Fast disk I/O (sequential writes)
Efficient compaction and retention policies

Delivery Semantics

Kafka supports:

At-most-once (no retry)
At-least-once (with retries)
Exactly-once (via idempotent producers and transactions)

Kafka Connect

A framework for scalable and fault-tolerant integration with external systems like databases, cloud storage, etc.

Kafka Streams

Kafka’s native stream processing library for building real-time applications. It supports windowed joins, aggregations, and stateful transformations.

KSQL (ksqldb)

SQL-like interface to process and query Kafka topics in real-time. Great for monitoring, alerting, and ad hoc analytics.

Schema Registry

Used to enforce schema evolution and validation of messages (usually with Avro, Protobuf, or JSON Schema).

Security & Reliability

Kafka supports:

TLS encryption (for data in transit)
SASL authentication
ACLs for fine-grained authorization

Reliability features:

Leader election for partitions
ISR (In-Sync Replicas) for high availability
Durable storage with configurable retention

Design Patterns

Event Sourcing: Storing state changes as a sequence of events.
CQRS: Using Kafka to separate reads and writes with materialized views.
Log Compaction: Retaining only the last message per key, ideal for changelog streams.

Best Practices

Use idempotent producers for exactly-once delivery.
Design partitioning strategy carefully (by key, round-robin, custom).
Monitor with tools like Prometheus, Grafana, Confluent Control Center.
Use Kafka Connect with dead letter queues for fault-tolerant ingestion.
Leverage Kafka Streams or Flink for advanced real-time processing.

When to Use Kafka

Kafka excels when:

You need to handle high-throughput, real-time data
You're building event-driven or microservices architectures
You want durable, replayable, fault-tolerant logs

It’s not ideal for:

Short-lived messages (use Redis or RabbitMQ)
Direct request-response communication
Heavy transformations (use Kafka Streams or an external processor)

Caching with Redis

hi@rohitmungre.com — Sun, 13 Oct 2024 00:00:00 GMT

What is Redis?

Redis (REmote DIctionary Server) is an in-memory data store, often used as a cache, message broker, or even a NoSQL database.

It’s:

Super fast (sub millisecond latency) (everything is in-memory)
Key-value based, like a giant hash table
Used in systems that need low-latency access to frequently used data

In this article, we explore caching with Redis from the ground up using redis-cli, and then dive into its advanced capabilities and architectural considerations.

Install Redis cli

Copy

sudo apt update
sudo apt install redis-server -y

Start Redis Server and check status

Copy

sudo service redis-server start
sudo service redis-server status

Open the Redis command line interface and test ping:

Copy

redis-cli

Stop Redis server when done

Copy

sudo service redis-server stop

Core Concepts of Redis Caching

Key-Value Storage

Redis operates as a high-speed key-value store. The value can be a simple string or a complex data structure like a hash or list. List of data types for Redis.

Copy

# Strings
SET name "Redis"
GET name
SET city "London"
INCR counter
DECR counter
APPEND city " Bridge"

# Lists
LPUSH tasks "learn redis"
LPUSH tasks "build app"
RPUSH tasks "deploy app"
LRANGE tasks 0 -1

# Hashes
HSET user:100 name "Alice" age "30"
HGET user:100 name
HGETALL user:100

# Sets (Unordered)
SADD tags "fast" "nosql" "cache"
SADD tags "fast"    # won’t duplicate
SMEMBERS tags
SISMEMBER tags "cache"

# Sorted sets
ZADD leaderboard 100 "Alice" 200 "Bob"
ZRANGE leaderboard 0 -1 WITHSCORES
ZREVRANGE leaderboard 0 0 WITHSCORES

Time-To-Live (TTL)

Redis supports automatic key expiration using TTL. This is essential for caching.

Copy

SET temp "this is temporary" EX 10
TTL temp

# You can also use
EXPIRE name 60
PERSIST name       # remove expiry

Atomic operations

All Redis commands are atomic — they finish completely or not at all. No race conditions — great for counters, locks, etc.

Copy

INCR score
DECR stock

Used for messaging between parts of your system — chat apps, real-time updates, etc.

Copy

# Terminal 1:
SUBSCRIBE news

# Terminal 2:
PUBLISH news "Redis 7 released!"

Transactions (MULTI/EXEC)

Group commands together, all run as one atomic batch.

Copy

MULTI
SET balance 100
INCR balance
EXEC

Persistence Modes (RDB and AOF)

Although Redis is often used as a cache, it supports persistence. Redis can save data to disk:

RDB (Snapshotting): Saves the dataset at specified intervals. Good for backups.
AOF (Append-Only File): Logs every write operation. Safer but slower.
Hybrid (RDB + AOF): Combine both for balance between safety and performance.

You don’t do this via CLI often, but you can trigger a save manually:

Copy

SAVE
BGSAVE

Monitoring / Inspection

Copy

KEYS *             # List all keys (use with caution)
SCAN 0             # Safer alternative to KEYS for large DBs
TTL key            # Time to live
TYPE key           # Get the type of a key
INFO               # Redis server stats

Deleting Data

Copy

DEL name
FLUSHDB           # Deletes all keys in current DB
FLUSHALL          # Deletes all keys in all DBs

Eviction Policies

Redis can evict keys when memory is full, using policies such as:

volatile-lru: Least Recently Used for keys with TTL
allkeys-lru: LRU across all keys
volatile-ttl: Evict keys with nearest expiry
noeviction: Return errors when memory is full
allkeys-random: Evict random keys

Configured via maxmemory-policy.

Copy

CONFIG SET maxmemory 1mb                 # Set a low memory limit
CONFIG SET maxmemory-policy allkeys-lru

CONFIG GET maxmemory
CONFIG GET maxmemory-policy

# Reset to default
CONFIG SET maxmemory 0
CONFIG SET maxmemory-policy noeviction

Advanced Concepts

Redis Cluster

Redis Cluster allows you to shard (partition) your data across multiple Redis nodes, enabling horizontal scaling and automatic failover.

Data is automatically distributed across nodes (no manual sharding)
The Redis keyspace is split into 16,384 hash slots (0–16383). Each key maps to a slot, and each slot is handled by a node
Each master node can have one or more replicas; if a master goes down, a replica can be promoted automatically
Can survive failures of some nodes, as long as a majority of masters are reachable
If a key is on a different node, Redis tells the client to retry on the correct one (MOVED response)

Redis Sentinel

Redis Sentinel is a system to monitor Redis master-replica setups and provide automatic failover if the master fails.

Monitors master-slave setups, watches Redis masters and replicas for failures
Alerts admins (or systems) if something goes wrong
Provides automatic failover - promotes a replica to master if the master goes down
Clients can ask Sentinel which node is the current master
Good for high availability when clustering is not needed

Advanced Caching Patterns

Read-Through Caching

The application checks Redis before hitting the database. On cache miss, it loads from the DB and updates Redis.

Copy

def get_user(id):
    user = redis.get(f"user:{id}")
    if user is None:
        user = db.get_user(id)
        redis.setex(f"user:{id}", 3600, user)
    return user

Write-Through Caching

Writes go to both Redis and the database simultaneously. Ensures consistency but increases write latency.

Cache Aside / Lazy Caching

The app fetches from Redis, and on miss, loads from the DB and stores the result. Most common and flexible.

Negative Caching

Cache null or "not found" responses to avoid repeated DB hits.

Best Practices

Use pipelines for batching commands
Leverage sharding via Redis Cluster for horizontal scaling
Tune maxmemory, maxclients, and eviction policy for optimal memory use
Monitor using tools like redis-cli, MONITOR, or RedisInsight
Use requirepass to set authentication
Bind only to internal interfaces (bind 127.0.0.1)
Enable tls for secure in-transit data
Use ACLs (Redis 6+) to control access

Use Cases Beyond Caching

Apart from caching, Redis supports:

Pub/Sub messaging for real-time communication
Streams for data pipelines and log ingestion
Geospatial indexing for location-based queries
HyperLogLog, bitmaps for analytics and counting

Websockets & Rest APIs

hi@rohitmungre.com — Wed, 12 Jun 2024 00:00:00 GMT

Modern applications often require real-time communication, seamless data transfer, and responsive interfaces. Two of the most common technologies that power client-server communication are WebSockets and REST APIs. While both are essential, they are designed for different use cases and offer distinct advantages and trade-offs.

WebSockets

WebSocket is a communication protocol that provides full-duplex, real-time communication channels over a single, long-lived connection between a client (such as a web browser) and a server. Unlike the traditional HTTP request-response model, WebSocket allows the server to send data to the client without being prompted. WebSocket provides full-duplex (i.e., bidirectional) communication channels to enable client-server interaction over a single, persistent Transmission Control Protocol (TCP) connection.

Architecture

Python implementation

A simple websocket server that accepts a token and symbol for subscribing and sends a price (random) to the client every 3 seconds

Copy

# server.py
import asyncio
import websockets
import random
import json

VALID_TOKEN = "MY_TOKEN"

async def price_stream(websocket):
    try:
        # Receive the initial subscription message
        message = await websocket.recv()
        data = json.loads(message)

        token = data.get("token")
        symbol = data.get("symbol")

        if token != VALID_TOKEN or not symbol:
            await websocket.send(json.dumps({"error": "Invalid token or missing symbol"}))
            await websocket.close()
            return

        print(f"Client subscribed to {symbol} with token {token}")

        # Send random price updates every 3 seconds
        while True:
            price = round(random.uniform(95, 105), 2)
            response = {
                "symbol": symbol,
                "price": price
            }
            await websocket.send(json.dumps(response))
            await asyncio.sleep(3)

    except websockets.ConnectionClosed:
        print("Client disconnected.")

async def main():
    async with websockets.serve(price_stream, "localhost", 8765):
        print("WebSocket server running at ws://localhost:8765")
        await asyncio.Future()  # run forever

if __name__ == "__main__":
    asyncio.run(main())

Simple python client to subscribe to and consume data from the above websocket

Copy

# client.py
import asyncio
import websockets
import json

async def subscribe():
    uri = "ws://localhost:8765"
    async with websockets.connect(uri) as websocket:
        # Send token and symbol to server
        token = "MY_TOKEN"
        symbol = input("Enter symbol to subscribe: ").strip()

        subscription_request = {
            "token": token,
            "symbol": symbol
        }
        await websocket.send(json.dumps(subscription_request))

        # Listen for price updates
        while True:
            message = await websocket.recv()
            data = json.loads(message)

            if "error" in data:
                print(f"Error from server: {data['error']}")
                break

            print(f"Price Update - {data['symbol']}: ${data['price']}")

if __name__ == "__main__":
    asyncio.run(subscribe())

Use cases

Real-time messaging apps, online gaming, live dashboards, IoT device communication, and collaborative tools.

Performance

Low latency, efficient for high-frequency data transfer, but scaling requires managing persistent connections with sticky sessions or brokers.

Security

Uses WSS (WebSocket Secure) for encryption, requires manual authentication and careful handling to prevent spoofing and session hijacking.

Best practices

Authenticate at connection start, use structured message formats like JSON/Protobuf, handle reconnections, and implement routing by rooms/topics.

Challenges

Scaling complexity, debugging difficulty, state management overhead, and increased infrastructure requirements for high availability.

REST APIs

REST stands for REpresentational State Transfer. A REST API is a way for different systems (like a browser, mobile app, a backend server) to communicate over the internet using HTTP. It is not a protocol or a standard — it's an architectural style that defines a set of rules and principles on how to structure APIs.

Key rules being:

Stateless: Each request from a client to a server must contain all the info needed to understand and process it. No client session is stored on the server side
Resource-based: Everything is considered a resource — like a user, an image, a file, etc. Resources are represented by URLs (URIs).
Uses HTTP Methods: Standard methods like GET, POST, PUT, DELETE, PATCH for interacting with resources.
Uniform Interface: The format of requests and responses must follow consistent rules (like JSON responses).
Representation-driven: Resources can be sent in various formats (JSON, XML), but JSON is the most common today.
Cacheable: Responses should declare if they are cacheable to optimize network efficiency

Architecture

Python Implementation

FastAPI based python server:

Copy

# server.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import Dict

app = FastAPI()

# Sample in-memory database
todos: Dict[int, Dict[str, str]] = {
    1: {"task": "Learn Python", "status": "Pending"},
    2: {"task": "Learn APIs", "status": "Pending"}
}

# Request body model
class TodoItem(BaseModel):
    task: str
    status: str = "Pending"

# GET all todos
@app.get("/todos")
def get_todos():
    return todos

# GET a specific todo
@app.get("/todos/{todo_id}")
def get_todo(todo_id: int):
    todo = todos.get(todo_id)
    if todo:
        return todo
    raise HTTPException(status_code=404, detail="Todo not found")

# POST a new todo
@app.post("/todos", status_code=201)
def create_todo(item: TodoItem):
    new_id = max(todos.keys(), default=0) + 1
    todos[new_id] = item.dict()
    return {"message": "Todo created", "id": new_id}

# PUT update a todo
@app.put("/todos/{todo_id}")
def update_todo(todo_id: int, item: TodoItem):
    if todo_id in todos:
        todos[todo_id] = item.dict()
        return {"message": "Todo updated"}
    raise HTTPException(status_code=404, detail="Todo not found")

# DELETE a todo
@app.delete("/todos/{todo_id}")
def delete_todo(todo_id: int):
    if todo_id in todos:
        del todos[todo_id]
        return {"message": "Todo deleted"}
    raise HTTPException(status_code=404, detail="Todo not found")

if __name__ == "__main__":
    import uvicorn
    uvicorn.run("server:app", host="127.0.0.1", port=5000, reload=True)

Client to fetch data from API:

Copy

# client.py
import requests

BASE_URL = "http://localhost:5000"

def list_todos():
    response = requests.get(f"{BASE_URL}/todos")
    print(response.json())

def get_todo(todo_id):
    response = requests.get(f"{BASE_URL}/todos/{todo_id}")
    print(response.json())

def create_todo(task):
    payload = {"task": task}
    response = requests.post(f"{BASE_URL}/todos", json=payload)
    print(response.json())

def update_todo(todo_id, task, status):
    payload = {"task": task, "status": status}
    response = requests.put(f"{BASE_URL}/todos/{todo_id}", json=payload)
    print(response.json())

def delete_todo(todo_id):
    response = requests.delete(f"{BASE_URL}/todos/{todo_id}")
    print(response.json())

if __name__ == "__main__":
    print("Creating a new Todo...")
    create_todo("Build a REST API!")

    print("\nListing all Todos...")
    list_todos()

    print("\nGetting Todo with ID 1...")
    get_todo(1)

    print("\nUpdating Todo ID 2...")
    update_todo(2, "Learn APIs better", "Completed")

    print("\nDeleting Todo ID 1...")
    delete_todo(1)

    print("\nFinal Todo List:")
    list_todos()

Use cases

CRUD operations, public APIs, traditional web applications, and services requiring simple, scalable, stateless communication.

Performance

Higher latency compared to WebSockets due to repeated handshakes and headers, but horizontally scalable and simple to cache.

Security

Uses HTTPS for secure transmission, supports OAuth, JWT token-based authentication, and benefits from the stateless security model.

Best practices

Use nouns for resources, proper HTTP methods for operations, error handling with standard codes, version APIs, and apply rate limiting and pagination.

Challenges

Less efficient for real-time updates (requires polling), overhead with repeated TCP handshakes, and stateless nature limiting persistent interaction.

Combining REST and WebSockets

In many real-world applications, REST and WebSockets complement each other. A common pattern is:

Use REST for authentication, initial data fetching, and CRUD operations
Use WebSockets for real-time updates and push notifications

This hybrid model allows developers to balance simplicity and performance.

Hosting on GCP

hi@rohitmungre.com — Thu, 18 Apr 2024 00:00:00 GMT

I recently decided to revive my personal website after a long time and decided to go with GoDaddy for domain & Google Cloud Platform (GCP) for hosting - mostly for learning purposes.

Below are the steps I followed to host my static personal website on GCP

Create a Google Cloud Account

Go to https://cloud.google.com/
Sign up (you’ll get $300 free credits for 90 days)

Install `gcloud` and `gsutil` cli

Copy

curl https://sdk.cloud.google.com | bash
exec -l $SHELL
gcloud init

It will ask to log into your Google account. You can also authorize explicitly by gcloud auth login.
This should install both gcloud and gsutil

Create and set your project

Copy

gcloud projects create YOUR_NEW_PROJECT_ID
gcloud config set project YOUR_NEW_PROJECT_ID

Make sure billing is enabled too (free tier is typically enough)

Enable required services

Copy

gcloud services enable storage.googleapis.com

One time setup required per project

Create a Storage Bucket

Copy

gcloud storage buckets create YOUR_BUCKET_NAME --location=YOUR_REGION --uniform-bucket-level-access

# Using gsutil mb (make bucket)
gsutil mb -l YOUR_REGION gs://YOUR_BUCKET_NAME/

--uniform-bucket-level-access ensures simplified permission management.

Upload Your Website Files

Suppose your files are in a folder ./website (must contain at least index.html).

Copy

gcloud storage cp ./website/* gs://YOUR_BUCKET_NAME/ --recursive

# Using gsutil cp
gsutil cp -r ./website/* gs://YOUR_BUCKET_NAME/

# Using gsutil sync
# Only syncs the file additions/deletes/updates
# Preferable if large number of files 
gsutil -m rsync -r -c -d website gs://YOUR_BUCKET_NAME

Make your files public

Copy

gcloud storage buckets add-iam-policy-binding YOUR_BUCKET_NAME \
  --member=allUsers \
  --role=roles/storage.objectViewer

# Using gsutil ch 
gsutil iam ch allUsers:objectViewer gs://YOUR_BUCKET_NAME

This allows the public to access your files.

Configure the Bucket for Website Hosting

Set your index.html and (optional) 404.html

Copy

gcloud storage buckets update YOUR_BUCKET_NAME --website-main-page-suffix=index.html --website-not-found-page=404.html

# Using gsutil web set 
gsutil web set -m index.html -e 404.html gs://YOUR_BUCKET_NAME

Access your website

Your website should now be visible at https://YOUR_BUCKET_NAME.storage.googleapis.com

Linking godaddy domain to GCP

Name Your Bucket Correctly (Important!)

For domain mapping to work - your bucket name MUST match your domain exactly. (www.yourdomain.com)

If you didn’t create the bucket with this exact name, you’ll need to create a new bucket.
When you create a bucket with the domain name, google will try to authorize if you are the rightful owner of the website

Add a CNAME Record in GoDaddy

Go to your GoDaddy dashboard > Select your domain (e.g., yourdomain.com) > Go to DNS Management > Add Record. Add this CNAME record:

Type: CNAME
Name: www
Value: c.storage.googleapis.com
TTL: 1 hour (default is fine)

Forward root domain (naked domain) (Optional)

GoDaddy can't CNAME a root domain (yourdomain.com) directly — that’s a DNS limitation. But you can set up a Domain Forwarding rule in GoDaddy:

Forward yourdomain.com ➔ https://www.yourdomain.com
Enable Permanent 301 Redirect and Forward with masking (optional).

Now both yourdomain.com and www.yourdomain.com will work.

Google Cloud Load Balancer + HTTPS (Optional)

Create a backend bucket

Copy

gcloud compute backend-buckets create STATIC_BACKEND_NAME \
  --gcs-bucket-name=YOUR_BUCKET_NAME \
  --enable-cdn

This tells GCP "this backend is tied to my GCS bucket."

Reserve a global static IP

Copy

gcloud compute addresses create LB_STATIC_IP \
  --global

Name it LB_STATIC_IP appropriately.

Get the reserved IP and save it as you'll use it soon in GoDaddy

Copy

gcloud compute addresses describe LB_STATIC_IP --global --format="get(address)"

Create SSL Certificate (Managed)

Copy

gcloud compute ssl-certificates create SSL_CERT_NAME \
  --domains=www.yourdomain.com

GCP will auto-provision a Let’s Encrypt-like cert for you.

Create URL Map and Target Proxy

Copy

gcloud compute url-maps create URL_MAP_NAME \
  --default-backend-bucket=STATIC_BACKEND_NAME


gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME \
  --url-map=URL_MAP_NAME

Create Forwarding Rule

Now, tie the static IP to HTTPS frontend

Copy

gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE \
  --address=LB_STATIC_IP \
  --global \
  --target-https-proxy=HTTPS_PROXY_NAME \
  --ports=443

Load Balancer is READY now!

It will automatically serve your static website via HTTPS.
URL: https://www.yourdomain.com. Once the SSL cert is active — takes a little time.

Update DNS at GoDaddy

Go back to GoDaddy DNS settings:

Add A record:
- Type: A
- Host: @
- Points to: STATIC IP ADDRESS
(Optional) Add another A record:
- Host: www
- Points to: STATIC IP ADDRESS
TTL: 1 hour (default is fine)

Final Flow diagram

Copy

User Browser (HTTPS) 
     ↓
Google Load Balancer (Static IP, HTTPS cert)
     ↓
Backend Bucket → GCS Static Website

PS

SSL Certificate may take 10–30 minutes to provision.
The domain MUST point to the Load Balancer IP for certs to validate.
You pay a small fee for the static IP and Load Balancer (~$5/month depending on use).

WSL 2 setup for devs

hi@rohitmungre.com — Tue, 05 Dec 2023 00:00:00 GMT

Last updated: Dec 15, 2024

After having used a Mac environment/Linux VMs previously at my work, Windows Subsystem for Linux (WSL) has been a game changer for me to develop on Windows. It allows me to run a full Linux environment natively on Windows, without using a virtual machine or a dual boot. It provides the best of both worlds, where one can run windows apps (VSCode, Chrome etc.) alongside Linux CLI tools (bash, git, vim etc.). It's fast and lightweight, shares resources/filesystem with Windows - allowing you to work seamlessly without having to fiddle with compatibility layers.

In this guide, I'm sharing how I set up my WSL V2 with Ubuntu and development environment for Python, Rust, Node, React, etc.

Install Ubuntu using WSL 2

Enable WSL V2

I use Windows 11, where I can use WSL out of the box.

Check your windows version using below in the Terminal/PowerShell

Copy

winver

Install WSL manually if lower than 10.

Open Terminal/PowerShell and ensure WSL version is V2.

Copy

wsl --status

This should return the default version as 2.

Install Ubuntu

Install Ubuntu using following commands in Terminal/PowerShell, you will be asked to input a username and password for your linux account, input those accordingly:

Copy

wsl --install -d Ubuntu-24.04

This installs WSL 2 with Ubuntu 24.04 (Replace with the latest/desired Ubuntu version). If not, you can manually install it from the Microsoft Store.

Confirm Installation

Copy

wsl --list --verbose

Make sure Ubuntu is listed and running under WSL 2. If installed successfully, you should also see Ubuntu 24.04.01 LTS option in terminal (click on dropdown box on right of the tab names). You can go to terminal > settings & set the default profile to Ubuntu 24.04.01 LTS - which will open the ubuntu by default on terminal.

Install zsh, ohmyzsh

zsh

Install zsh using package manager

Copy

sudo apt update && sudo apt upgrade -y
sudo apt install zsh

Verify installation

Copy

zsh --version

Make it your default shell

Copy

chsh -s $(which zsh)

ohmyzsh

Install ohmyzsh using curl

Copy

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)

Plugins

Fetch autosuggesions, zsh-syntax-highlighting, zsh-fast-syntax-highlighting, zsh-autocomplete plugins

Copy

git clone https://github.com/zsh-users/zsh-autosuggestions.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/zsh-autosuggestions && \
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting && \
git clone https://github.com/zdharma-continuum/fast-syntax-highlighting.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/fast-syntax-highlighting && \
git clone --depth 1 https://github.com/marlonrichert/zsh-autocomplete.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/zsh-autocomplete

Add plugins to .zshrc

Copy

plugins=(
git
zsh-autosuggestions
zsh-syntax-highlighting
fast-syntax-highlighting
zsh-autocomplete
)

Reload your environment to make changes work

Copy

source ~/.zshrc

Update & setup Ubuntu Packages

Copy

sudo apt update && sudo apt upgrade -y

Install common tools, including dependencies for pyenv, protobuf etc.:

Copy

sudo apt install \
  keychain \
  build-essential \
  protobuf-compiler \
  libssl-dev \
  zlib1g-dev \
  libbz2-dev \
  libreadline-dev \
  libsqlite3-dev \
  curl \
  file \
  git \
  libncursesw5-dev \
  xz-utils \
  tk-dev \
  libxml2-dev \
  libxmlsec1-dev \
  libffi-dev \
  liblzma-dev \
  just

Install Python

Ubuntu usually comes with Python pre-installed. Verify version:

Copy

python3 --version

For Python version management, install pyenv:

Clone pyenv in the ~/.pyenv directory
Install the python versions you need, for example

Copy

pyenv install 3.13.1

Install Rust

Use the official Rust installer:

Copy

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env

Check installation:

Copy

rustc --version
cargo --version

Install Node.js, npm, yarn

Use Node Version Manager (nvm) for flexibility:

Copy

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts

Verify the versions:

Copy

node -v
npm -v

Install Yarn

Using the official Yarn APT repo:

Copy

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt update && sudo apt install yarn -y

Check version:

Copy

yarn -v

Post Script

My home setup

Databases Demystified

hi@rohitmungre.com — Sat, 18 Nov 2023 00:00:00 GMT

Databases are foundational to nearly all software systems, from small web apps to large-scale enterprise platforms. Modern development offers a variety of database types—each suited to different kinds of data, workloads, and application needs.

Below is an architect-level overview of databases, aimed at guiding technology choices in designing robust and scalable systems.

Types of Databases

Relational Databases (RDBMS)

Structured data stored in rows and columns, strong schema and ACID transactions. Use when you need strong data consistency and structured schemas (e.g., banking).

Pros: Mature, reliable, strong consistency, Standardized query language (SQL)
Cons: Scaling horizontally is harder, rigid schema can slow development

Examples: MySQL, PostgreSQL, Oracle, SQL Server

NoSQL Databases

Flexible schema, designed for unstructured or semi-structured data, scalable. Use when you need to handle varied and changing data structures or scale horizontally.

Pros: Highly scalable, flexible data models, good for big data
Cons: Eventual consistency, lack of standardization between NoSQL DBs

Examples: MongoDB, Cassandra, Redis, Couchbase

NewSQL Databases

Hybrid of RDBMS and NoSQL: scalability with ACID properties. Use when you want scalability without giving up strong consistency (e.g., financial apps).

Pros: Best of both worlds: scalability + strong consistency, SQL support
Cons: Still maturing compared to traditional RDBMS, fewer available products

Examples: CockroachDB, Google Spanner

In-Memory Databases

Data stored in RAM for extremely fast access. Use when extremely low latency and high throughput are critical (e.g., caching).

Pros: Blazing fast reads/writes, simple to set up
Cons: Data loss risk if not persisted properly, RAM limitations

Examples: Redis, Memcached

Time-Series Databases

Optimized for storing and querying time-stamped or sequential data. Use when dealing with IoT data, logs, or any event-driven systems.

Pros: Efficient at handling huge amounts of chronological data
Cons: Not suitable for general-purpose database use

Examples: InfluxDB, TimescaleDB, Prometheus

Graph Databases

Data modeled as nodes and edges representing relationships. Use when relationships between entities are complex and deeply interconnected (e.g., social networks).

Pros: Natural modeling of connected data, efficient traversal queries
Cons: Steeper learning curve, specialized query languages

Examples: Neo4j, ArangoDB

Key-Value Stores

Simple (key, value) pairs for high-speed lookups. Use when you need fast simple lookups or session management.

Pros: Lightning fast for simple operations, extremely scalable
Cons: Not ideal for complex queries, data relationships not managed well

Examples: Redis, DynamoDB, Riak

Document Databases

Data stored as JSON-like documents with flexible schemas. Use when your data is semi-structured and schema may evolve over time.

Pros: Flexible, easy to store complex nested data
Cons: Lack of complex query capabilities compared to RDBMS

Examples: MongoDB, CouchDB, Firestore

Columnar Databases

Stores data by columns rather than rows; efficient for analytics. Use when you perform heavy read analytics on large datasets (e.g., big data warehouses).

Pros: Great compression, high performance for OLAP workloads
Cons: Poor for transactional systems (frequent small updates)

Examples: Apache Cassandra, ClickHouse, BigQuery

Object-Oriented Databases

Stores data as objects, similar to object-oriented programming concepts. Use when you want seamless persistence of complex data structures (e.g., CAD apps).

Pros: Natural mapping to OOP languages, good for complex hierarchies
Cons: Niche use case, limited support and adoption

Examples: db4o, ObjectDB

Scaling Databases

Scaling i.e. handling more load — more users, more reads, more writes, or bigger datasets — can be a crucial factor in selecting the database. Below are the types of scaling one need to consider:

Vertical Scaling (Scale Up)

Add more CPU, RAM, or storage to a single server.

Its simple to implement & needs no changes in application code.
Easier but has upper limits (hardware limitations) & can get expensive quickly.

Horizontal Scaling (Scale Out)

Distribute data across multiple servers (sharding/partitioning).

Almost infinite scaling (theoretically), better fault tolerance
Requires more architecture planning due to more complexity (replication, partitioning, consistency issues), needs redesigning applications sometimes.

Sharding (Data Partitioning)

Splitting the database into pieces and storing them on different servers based on some rule (e.g., user_id).

Reduces load on each server, enables horizontal scaling
Complex to implement, hard to rebalance shards later if one shard becomes "hot" (too much traffic)

Replication

Copying data across multiple servers (often one master, multiple replicas), use master-replica setups for high availability and read scaling

Improves read scalability, provides backup/failover if a node crashes
Write bottleneck still at the master (unless multi-master, which adds complexity), potential for replication lag

Caching Layer

Store frequent queries or data in a fast, temporary storage (like Redis, Memcached).

Reduces database load dramatically, improves response times.
Cache invalidation is tricky, data in cache might be slightly stale

Choosing the Right Database

Requirement	Recommendation
Strong consistency & transactions	PostgreSQL, MySQL
Schema flexibility	MongoDB, Couchbase
High throughput read/write	Redis, Cassandra
Complex relationships	Neo4j, Postgres with CTEs
Geospatial data	PostGIS (PostgreSQL)
Cache layer	Redis
Real-time analytics	ClickHouse, Elasticsearch

Modern Database Tools and Ecosystem

Tool/Concept	Purpose
PgAdmin, DBeaver	GUI for managing SQL databases
Prisma, SQLAlchemy	ORM libraries for app integration
Alembic, Flyway	Database migrations
RedisInsight	GUI for Redis
Kafka Connect	Streaming data into/out of databases
Supabase	Postgres-based backend-as-a-service

Courage Amidst the Storm

hi@rohitmungre.com — Thu, 14 Sep 2017 00:00:00 GMT

A beautiful Marathi poem, penned by Ravindra Ghanshyam Deshpande, featured in the critically acclaimed Marathi movie 'Killa' (2014).

सागराने नाविका मनी
संकट मोठे पेरले
वादळाने होडीस एका
दशदिशांनी घेरले...

शीळ तुटले, खेळ तुटले,
कथा काय या वलयाची
नाविकासही फिकीर नव्हती
पुढे राहिल्या पल्ल्याची...

नशिब नक्कते पाठीशी,
नक्कता अनुभव गाठीशी
उभा ठाकला एकटाच
युद्ध होते वादळाच्या
वय वर्षे साठीशी...

स्वबली विश्वास मोठा
त्यास तोड कर्तुत्वही
रौद्र वादळ शांत झाले
पाघळले श्रुत्वधीही...

एकवटला धीर हा
काढून येतो तत्क्षणी
शतबाहुंचे बळ येते
जो मातृत्व तरेल मनी...

— Ravindra Ghanshyam Deshpande

English Translation

The sea bore an array of perils…
A mighty storm ambushed the lone sailor…

The sail snapped, the nails unhooked…..
The sailor persisted, unfazed by what lay ahead

Luckless, the knots of skill turned loose.
He stood there alone, the storm slapped its noose

A life lived in benevolence will not let the faith wither
He overcame fear and the storm fulled into slither

Courage of the universe, regathers in single moment
A hundred arms’ strength regains, as the memory of mother returns.

Starting up v/s PhD

hi@rohitmungre.com — Tue, 30 Jun 2015 00:00:00 GMT

Here are some of the points why I feel startups are similar to doing a PhD in many aspects

You not only have to find solution to an existing problem - you have to find and define the problem itself

PhD starts with making yourself familiar with the field in general by doing relevant courses, then gradually a problem statement is sketched, is made more and more concrete over many iterations. Similarly founders in startups not only have to solve a customer problem/necessity, they have to find what the problem/necessity is first. They spend doing market research, surveys , ground level work by interacting with customers first to arrive at the Value Proposition.

The cycle of Idea -> build -> measure -> validate -> learn

After defining the problem statement comes the stage of ideation and experimentation. Both in PhD and startups, hypothesis are created, tools and mechanisms are built to test those hypothesis (a minimal viable product in startup) - data points are measured from that experimentation and learning is made whether that idea was validated or not.

Strong feedback mechanism

Both in startups and PhD, feedback is available from time to time which makes you question the direction you are working on and whether you need to evolve or pivot. In PhD feedback is given by professors, your data points and your own speculations in that direction, in startups its given by customers, products performance , VCs etc.

Both are strong test of one's character

I read recently that PhD is more of a test of a person's attitude and his character rather than his intellect. Because of the sheer nature of PhD - which is finding something that is not known to anyone else in the world - even the brightest minds start to question themselves. Similarly for Startups the one has to solve an undefined problem, find markets, make a product and survive in a highly competitive environment - which tests the emotional integrity of the toughest persons as well. High amounts of personal pressures,speculations and introspections are involved through out the journey. In both PhDs and startups the highs as well the lows are very extreme.

At the end of a PhD/Startup you are one of the best persons in the world, who knows about that field

Most people get drenched into personal, emotional, financial, social pressures in the process and are not able to cope up with it. The ones who survive are the ones who have made a dent in the world - by adding to that was already existing.

Both have funding problems! (:p)

Raising money for an idea that you believe in but have no proven record that your hypothesis is true is not an easy task. Whether raising funding for research projects or pitching your idea to the VCs - both require good communication skills and structured thinking to convince someone else to put their money on you.

Must need v/s nice to have

hi@rohitmungre.com — Sun, 07 Jun 2015 00:00:00 GMT

Building a Product

I notice that majority of the startups that I come across are either B2C or B2B. B2C make a product whose end user will be a human customer where as B2B serve another business(es).

Building B2B or C2B requires domain knowledge of particular businesses which most of recent grads like myself don't have. On the other hand, imagining yourself as a customer of any e-commerce or internet service comes intuitive to us, as we have been consuming different products our entire life.

It especially helps being in mid-twenties right now in India, as its demographic is skewed highly towards young people. That means most of the people using your service—if you open an internet-based startup in India—will be under 30. This gives a lot of edge to young entrepreneurs in terms of tapping the nerves of their audience.

Idea Exploration

I came up with some B2C ideas in the last couple of months. These ideas were good on their own and were not blatant copies of something already done in the western world. But a big barrier I found was that these were “nice-to-have” products, not “must-haves.”

But then I thought—is that really a barrier?

When I think about tech giant companies like Google, Facebook, Paypal, etc., and how they started, I find that most of them were not must-haves in their early days. This made me think: when you're ideating a new product, do you imagine it to be a must-have or a nice-to-have?

Defining Must-Haves and Nice-to-Haves

There are certain products that have become necessities of our lives, without which we cannot imagine living (e.g., vehicles, electricity, buildings). Then there are “nice-to-have” products like a Tag Heuer watch or a Mercedes-Benz—you can do without them.

But this classification also depends on several variables:

Time: Mobile phones were once “nice-to-have”; now they are essential.
Place: Living standards vary drastically across regions.

Therefore, these attributes (must-have vs. nice-to-have) apply to specific segments of society and must be evaluated based on context.

Start by imagining your product for one demographic of the society at a time and then scale it up.
Ask: Is it a must-have for that group now? Could it become one in the future?

Peter Thiel once said:

Start small and monopolize small markets. But small doesn't mean non-existent.

Creating a Market

Creating a market for oneself is not new. A friend once explained this beautifully with an example:

We had only one night canteen in our university campus. We had to walk half a kilometer for snacks, so most students went only when truly hungry.
Then, night canteens were introduced in each hostel. Suddenly, more people went, some who never went before, and those who went rarely became regulars.
A midnight catering market was created.
We never knew we were hungry every night until the option existed.

Examples from Big Tech

This holds true for many breakthrough companies:

Ford: When automated cars launched, there was no proven market.

"If I had asked my customers what they wanted, they would have said a faster horse." – Henry Ford
Google & Facebook: Cool to have at first; now social connection is a digital necessity.

These companies didn’t just serve a market—they created one by tapping into the human nature of their users.

Peter Thiel again:

"The future will always be different, but it will always be rooted in the present world."

So, How to Know If Your Idea is a Must-Have?

I believe most game-changing companies initially presented a solution to an existing problem that seemed nice-to-have, but they made it indispensable over time by being 10x better than existing alternatives.

Examples:

Ford: Replaced horses with more efficient transport
Google: Better search UX
Paypal: Secure, fast money transfer
Amazon: Brought shopping to your screen
Apple: Created a consumer tech market from scratch

They converted nice-to-haves into must-haves.

Sometimes, your users may not even know what they need—which is why building something visionary often means not always following customer feedback blindly.

Final Thoughts

Edward J. v. K. Menge said:

"Breeding homing pigeons that could cover a given space with ever-increasing rapidity did not give us the laws of telegraphy, nor did breeding faster horses bring us the steam locomotive."

Identifying a market is key. Many game-changer companies created monopolies by solving real problems in radically new ways. Even spotting such problems is a journey on its own.

Now that technology is reaching more people than ever, and the internet has made phenomena like virality and data-sharing commonplace, the tech world’s potential is enormous—and evolving fast.

Technology is, after all, about blurring the lines between must-haves and nice-to-haves—creating things that never existed before.

📝 Edit (2015/06/08)

Found out that there's a course on Udacity — How to Build a Startup — where the concept of creating new markets is elaborated.

Zero to one

hi@rohitmungre.com — Wed, 27 May 2015 00:00:00 GMT

Zero to One is one of the most informative business books I have read.

Peter Thiel models the world and explains concepts in a very intuitive and logical way. It's especially useful for people looking to start a business. It has an excellent blend of theoretical knowledge with practical real world examples, and is quite information dense. The experience of actually starting up and scaling companies gives a unique perspective onto things.

Summarizing my key takeaways from the book below.

Key takeaways

The Act of Singularity
When you create something new (going from zero to one), it is fundamentally different from when you extend what already exists (going from one to n). There is a fundamental difference between these two acts.
No Single Formula
There is no single formula for building a company. Each company is different, each customer is different. There are many roads that lead to many destinations. Identifying opportunities is essential.
Rooted Innovation
The future will always be different from the present, but it will also be rooted in today's world. You can have an idea which might be drastically different from whatever has been done up till now, but it has to be grounded in reality somehow.
Incremental vs. Bold Moves
Make incremental advances, stay lean and flexible, improve on the competition and focus on products not sales. Although some exactly opposite principles would also be equally true.
The Power of Sales
Sales is often underrated by geeks and engineers. Although ultimately having a well-built product with value underlying beneath it is important, sales is necessary for visibility, distribution, and bridging the gap between customers and the product. Superior sales and distribution by itself can create a monopoly with no product differentiation. Although the converse is not true.
Definite vs. Indefinite Future
If you treat the future as something definite, it makes sense to understand it, work it, and shape it. But if you expect an indefinite future ruled by randomness, you will give up on trying to master it.
Durability Over Growth Alone
The value of a business today is the sum of all the money it will make in the future. Therefore an important criterion to check apart from growth is durability. For a company to be valuable, it must grow and endure. Try not to forget about the long-term implications, focusing on short-term growth only. An important question to ask: Will this business still be there after ten years?
Start Small, Think Big
Every startup must start with a small market. But small doesn't mean non-existent. Try not to be a small fish in a big pond, rather choose a small pond itself. Start small and monopolize, don't disrupt. Get the last mover’s advantage.
Follow the Power Law
Try to monopolize and follow the power law. That seems to hold true in more situations than people realize. The biggest secret in venture capital is that the best investment in a successful fund equals or outperforms the entire rest of the fund combined.
Culture Is the Company
No company has a culture — every company is a culture. A startup is a team of people on a mission, and a good culture is just what that looks like on the inside.

The Road Not Taken

hi@rohitmungre.com — Wed, 25 Feb 2015 00:00:00 GMT

One of my favourite poems by Robert Frost:

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;

Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.

— Robert Frost

Zen of Python

hi@rohitmungre.com — Sat, 17 Jan 2015 00:00:00 GMT

One of the most influential and elegantly written guidelines in the world of programming. A reminder that programming is not just about getting things to work, it's also about doing so in a way that is clean, logical, and elegant.

Quite philosophical and applicable to other areas in life at times.

Beautiful is better than ugly.
Explicit is better than implicit.

Simple is better than complex.
Complex is better than complicated.

Flat is better than nested.
Sparse is better than dense.

Readability counts.
Special cases aren't special enough to break the rules.

Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

Now is better than never.
Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those.

— Tim Peters

City of Hope

hi@rohitmungre.com — Wed, 12 Nov 2014 00:00:00 GMT

A city covered in its own dust
with people filled with hunger and lust

Skyscrapers meet scraps of the slum
noise takes over the birds' hum

Chaos, mayhem - there is a wild rush
Daring ocean is the land's crush

The crowd is running, searching for its soul
Waiting for the destiny's dices to roll

Beneath this bedlam, there exists hard work
Workings of night and day, making this circus berserk

Emotions run high here, aspirations even higher
A very few do make it, but everyone's a trier

All are visitors, lost are its own
Beside the ocean - winds of liberty are blown

But also comes along a saffron-green thunder
The turn of events sometimes makes one wonder

Is it the crowd or the Arabian sea,
Who is staring at the ocean of people?

The day is running, night is dope
Still it is called the city of hope

— Rohit Mungre

Blue

hi@rohitmungre.com — Sat, 19 Oct 2013 00:00:00 GMT

She had blue skin,
And so did he.
He kept it hid
And so did she.
They searched for blue
Their whole life through,
Then passed right by -
And never knew.

— Shel Silverstein, Every Thing on It

rohitmungre | RSS Feed

Orchestration using Kubernetes

Core concepts with Kubectl

Cluster

Nodes

Pods

Deployments

Services

Namespaces

ConfigMaps and Secrets

Configuring a basic pod yaml

Kubernetes Architecture

Control Plane Components

Node Components

Advanced Features

Observability

Helm and Operators

Best Practices

Kafkaesque Streaming

What is Kafka?

Glossary

Kafka using docker

Start Kafka with Docker

Cli commands

List topics

Create a Topic

Describe a Topic

Produce (Send) Messages

Consume Messages

Delete a Topic

Start Consumer Group

List Consumer Groups

Describe Consumer Group

Kafka Architecture

Advanced Topics

Kafka Internals

Delivery Semantics

Kafka Connect

Kafka Streams

KSQL (ksqldb)

Schema Registry

Security & Reliability

Design Patterns

Best Practices

When to Use Kafka

Caching with Redis

What is Redis?

Install Redis cli

Core Concepts of Redis Caching

Key-Value Storage

Time-To-Live (TTL)

Atomic operations

Publish / Subscribe (Pub/Sub)

Transactions (MULTI/EXEC)

Persistence Modes (RDB and AOF)

Monitoring / Inspection

Deleting Data

Eviction Policies

Advanced Concepts

Redis Cluster

Redis Sentinel

Advanced Caching Patterns

Read-Through Caching

Write-Through Caching

Cache Aside / Lazy Caching

Negative Caching

Best Practices

Use Cases Beyond Caching

Websockets & Rest APIs

WebSockets

Architecture

Python implementation

Use cases

Performance

Security

Best practices

Challenges

REST APIs

Architecture

Python Implementation

Install `gcloud` and `gsutil` cli