DEV Community: Pratik Mahalle

Ephemeral Environments for Developers: The Missing Layer in Your DevEx Stack

Pratik Mahalle — Sat, 28 Feb 2026 02:34:29 +0000

If your team is still sharing a handful of long‑lived “dev”, “staging”, and “QA” environments, you’re leaving a lot of speed and reliability on the table.

Modern teams are quietly switching to ephemeral environments—short‑lived, on‑demand environments spun up per feature, per branch, or even per pull request. They disappear when you’re done, but the impact on quality, collaboration, and delivery speed is very real.

This article breaks down what ephemeral environments are, why they matter, and how to think about adopting them in your org.

What Are Ephemeral Environments?

An ephemeral environment is:

On-demand: created automatically (or via a simple self-service action) when you need it
Isolated: scoped to a branch, feature, ticket, or pull request
Short‑lived: destroyed when the work is merged, abandoned, or after a TTL
Prod-like: runs the same stack (or a close approximation) as production

Concretely, this is often:

A full stack (frontend, backend services, DBs, queues) spun up per PR
A partial stack (only the service under change + its dependencies) with smart routing
Provisioned via Kubernetes namespaces, separate clusters, or cloud resources tied to a unique ID (e.g., feature-1234)

Instead of five teams fighting over staging, each PR gets its own “mini-staging” that matches production closely enough for serious testing and stakeholder review.

Why Ephemeral Environments Matter Now

Monolith-era release cycles could survive with shared environments. Today’s reality is different:

Microservices and distributed systems
Multiple teams shipping concurrently
CI/CD pipelines pushing to production multiple times a day
Product and design demanding faster iteration and feedback

In this world, environment contention and configuration drift become silent killers of velocity.

Ephemeral environments address several pain points:

1. They Remove the “Who Broke Staging?” Problem
Shared long‑lived envs suffer from:

Random breakages because someone else deployed their half-finished change
Dirty data and hard‑to‑reproduce bugs
“Works on my machine, not on staging” conflicts

With ephemeral envs:

Your environment is yours alone
You test your changes in isolation
When it’s broken, you know exactly where to look

This drastically reduces the cognitive load and finger‑pointing around shared staging.

2. They Shift Quality Left – For Real
We love to say “shift left,” but if the only realistic prod-like environment is staging, you’re not really shifting much.

Ephemeral envs bring prod‑like validation to the PR level:

Run integration and end‑to‑end tests against a realistic environment per change
Reproduce tricky issues using the exact code and configuration of the PR
Validate infrastructure changes (Helm charts, Terraform modules, feature flags) before they touch shared infra This reduces late surprises and production hotfixes—quality improves without slowing down delivery.

3. They Unlock True “Preview” Workflows for Stakeholders
Non‑developers struggle to review work on Git diffs:

Product wants to click through the new flow
Design wants to see how the UI looks on different devices
Sales wants to demo a feature to a specific customer segment

With ephemeral environments:

Every PR can have a preview URL
Stakeholders can play with the feature before it merges
Feedback loops tighten: “Try this PR link” beats “Wait for staging” or “I’ll send you a video”

This is a massive dev‑to‑business bridge: features become tangible earlier.

4. They Reduce Long‑Lived Staging/QA Maintenance Tax
Maintaining a couple of static environments sounds cheap—until you add up:

Time spent cleaning test data
Manual config tweaks that drift from prod over time
Fixing broken staging pipelines because ten teams rely on it

Ephemeral envs flip the model:

You codify environment creation (IaC, Helm, Kustomize, etc.)
Environments become cattle, not pets
Staging can be simplified (or even retired) in some orgs You trade ongoing manual babysitting for upfront automation—a better investment for scaling teams.

5. They Make Platform Engineering and DevEx Tangible
Ephemeral environments naturally sit inside an internal developer platform:

Self‑service UI or CLI to spin up an environment per branch
Guardrails via templates, policies, quotas, and TTLs
Integrated observability, logs, and metrics per environment

For platform teams, ephemeral envs are a high‑leverage way to:

Standardize how services run
Encapsulate best practices (health checks, security, resource limits)
Offer something developers feel immediately (“I get my own prod-like environment in minutes”)

When Are Ephemeral Environments a Good Fit?

They shine in certain scenarios:

Microservices / polyrepo / monorepo with many teams **- **High release frequency (multiple deployments per day/week)
Complex integrations (multiple backends, APIs, 3rd‑party systems)
Heavy UI/UX iteration, where visual review is key
Regulated environments, where you want strong separation between pre‑prod and prod

They are less critical—but still helpful—if:

You have a small monolith with rare releases
Your “staging” is truly simple and reliable
Most changes are trivial and low‑risk In practice, once teams get used to branch/PR‑scoped environments, it is hard to go back.

Common Challenges and Trade‑Offs

It’s not all magic. You need to be realistic about:

1. Infrastructure Cost
Spinning up full stacks per PR can be expensive if:

Resource limits are not set properly
Environments live forever because there is no TTL or cleanup
Every environment runs heavyweight databases or external services

Mitigations:

Use quotas and automatic TTLs
Right‑size resources for pre‑prod (smaller instances, fewer replicas)
Use shared backing services where it makes sense (read-only data, mocks)

2. Data Management
Prod‑like environments need prod‑like data patterns:

You often cannot copy full production databases
You may need anonymized or synthetic data
Tests may rely on certain data shapes and volumes

Mitigations:

Automated DB seeding/migration scripts per environment
Subset/snapshot of prod data with anonymization
Clear strategy for stateful vs. stateless services

3. Complexity of Orchestration
Ephemeral envs require:

Reliable IaC templates (Terraform, Pulumi, CloudFormation)
Kubernetes manifests/Helm charts that can be parameterized per env
Routing, DNS, and SSL automation

This is where platform engineering and internal tools pay off. It’s not a free feature; it’s a capability to build incrementally.

How to Start: A Pragmatic Adoption Path

You don’t need a fully automated, company‑wide system on day one. A sensible path:

Start with one product or team
Automate environment creation for PRs
Simplify data and dependencies early
Add TTLs and cost controls from day one
Observe usage and iterate

Over time, ephemeral envs evolve from an experiment into a core part of your delivery workflow.

The “Why Now” for Leaders

For engineering and platform leaders, ephemeral environments are not just a technical choice—they’re a DevEx and business decision:

Faster feedback → faster shipping → higher feature throughput
Lower change risk → fewer incidents → more stable roadmap
Better collaboration → less friction between dev, QA, product, and sales
Stronger platform foundation → easier to scale teams and services

In a market where developer productivity and time to value are increasingly strategic, ephemeral environments are a practical, observable lever you can pull.

If you’re still relying on a couple of long‑lived staging environments, this is a good time to ask:

What would it look like if every meaningful change had its own safe, isolated, prod‑like sandbox?
That answer is, essentially, your roadmap to ephemeral environments.

Follow us: Exemplar Dev to know more about upcoming developer platform which will enable you to create ephemeral environment.

Kubernetes Monitoring with Grafana

Pratik Mahalle — Tue, 20 Jan 2026 02:38:35 +0000

As a DevOps engineer working extensively with Kubernetes, I've learned that effective monitoring isn't just about collecting metrics - it's about gaining actionable insights that help you maintain cluster health and quickly troubleshoot issues. In this post, I'll share my experience using Grafana to monitor Kubernetes environments and some practical tips I've picked up along the way.

Why Grafana for Kubernetes?

Kubernetes generates an overwhelming amount of metrics. Without proper visualization, you're essentially flying blind. Grafana has become my go-to tool because it provides:

Beautiful, customizable dashboards that make complex data digestible
Seamless integration with Prometheus and other data sources
Powerful alerting capabilities
A strong community with pre-built dashboards

The Essential Stack

My monitoring stack(These are not also mine:) typically includes:

Prometheus - for metrics collection and storage
Grafana - for visualization and dashboards
kube-state-metrics - for Kubernetes-specific metrics
node-exporter - for node-level system metrics
Loki - (optional) for log aggregation

This combination gives you comprehensive visibility into your cluster's health and performance.

Key Metrics I Monitor

After managing multiple Kubernetes clusters, I've identified the metrics that matter most:

Cluster-Level Metrics:

Node resource utilization (CPU, memory, disk)
Pod count and status across namespaces
Cluster capacity and resource requests vs limits
API server latency and error rates

Application-Level Metrics:

Pod resource consumption
Container restart counts
Application-specific metrics (request rates, error rates, latency)
Persistent volume usage

Network Metrics:

Network traffic between pods and services
Ingress/egress bandwidth
Service endpoint availability

Dashboard Setup Tips(These are actually not mine)

Over time, I've developed some best practices for Grafana dashboards:

Start with community dashboards. The Grafana dashboard repository has excellent Kubernetes dashboards. My favorites include the Kubernetes Cluster Monitoring dashboard and the Node Exporter Full dashboard. Don't reinvent the wheel—start with these and customize as needed.

Organize by concern. I maintain separate dashboards for different audiences. A high-level cluster overview for leadership, detailed node metrics for infrastructure teams, and application-specific dashboards for developers.

Use variables effectively. Dashboard variables for namespace, pod, and container allow you to create reusable dashboards that work across your entire infrastructure. This saves tremendous time.

Set up meaningful alerts. Alerts should be actionable. I've learned to avoid alert fatigue by focusing on conditions that genuinely require intervention, like sustained high CPU usage, pod crash loops, or disk space approaching capacity.

Mistake to Avoid

Over-monitoring. You don't need to visualize every single metric. Focus on what helps you make decisions and troubleshoot issues.

Ignoring resource limits. Make sure your Prometheus and Grafana deployments have appropriate resource limits. I've seen monitoring systems become the problem when they consume too many cluster resources.

Static thresholds. CPU usage that's normal for one application might be critical for another. Context matters when setting alert thresholds.

Real-World Impact

Implementing proper Grafana monitoring has transformed how my team operates. We can now:

Identify performance bottlenecks before they impact users
Make data-driven decisions about scaling and resource allocation
Reduce mean time to resolution (MTTR) for incidents
Demonstrate infrastructure health to stakeholders

One specific example: we identified a memory leak in a microservice by noticing a steady upward trend in container memory usage over several days. Without Grafana's visualization, this would have been much harder to spot in raw metrics.

Getting Started

If you're new to Grafana and Kubernetes monitoring, here's my recommended path:

Deploy Prometheus using the kube-prometheus-stack Helm chart (it includes Grafana, Prometheus, and common exporters)
Import community dashboards for Kubernetes cluster monitoring
Explore the dashboards and understand what each panel shows
Customize dashboards based on your specific needs
Set up basic alerts for critical conditions
Iterate and improve based on real incidents and questions your team asks

Conclusion

Grafana has become an indispensable tool in my Kubernetes toolkit. The visibility it provides into cluster health, resource utilization, and application performance makes it easier to maintain reliable systems and quickly resolve issues when they arise.

The key is to start simple, use community resources, and gradually build more sophisticated monitoring as you understand your specific needs.

What's your experience with Grafana and Kubernetes? I'd love to hear about your monitoring setup and any tips you've discovered along the way.

Are you using Grafana for Kubernetes monitoring? Share your experiences in the comments below, or connect with me to discuss observability practices.

From DevOps to Platform Engineering in the AI Era

Pratik Mahalle — Mon, 05 Jan 2026 13:55:24 +0000

I've been talking to a lot of DevOps engineers lately, and the same question keeps coming up: "Is platform engineering just another hype, or should I actually care about this?"

Here's what I've learned: Platform engineers are earning up to 27% more than DevOps roles. But that's not really why this matters.

What Changed

Six months ago, every company was scrambling to add AI tools. Give developers Copilot, throw in some AI agents, problem solved, right?

Wrong.

Rickey Zachary from Thoughtworks spent 200 days on the road in 2025, and he kept seeing the same pattern: AI doesn't fix broken systems. It just breaks them faster.

Your documentation is scattered across Confluence, Notion, and somebody's Google Drive? AI can't help. Your deployment process has seven manual approval steps? AI agents will just fail at step three instead of step seven. Technical debt you've been working around for years? AI trips over it immediately.

The uncomfortable truth is that AI amplifies whatever you already have. Good systems get better. Messy systems get messier.

Why Platform Engineering

This is where platform engineering comes in, and why it's not just DevOps with a new name.

DevOps taught us to automate and collaborate. Platform engineering asks a different question: What if we built infrastructure as an actual product that developers want to use?

You think about the last time a developer asked you to provision something. You probably:

Got a Slack message or ticket
Did the thing manually (or ran your script)
Maybe documented it somewhere
Repeated this next week with a different developer

Platform engineering means building a self-service portal where developers do it themselves. You spend time building the product once, not doing the same task repeatedly.

The mindset shift is huge. You're not just automating tasks - you're designing experiences.

The AI Connection

Here's why timing matters: AI needs platforms to work.

Organizations are figuring out that giving developers AI tools without fixing the underlying infrastructure is pointless. Research shows that 86% of organizations now believe platform engineering is essential for getting real value from AI.

And there's a dual opportunity here:

Building AI-powered platforms means using AI to make your platforms smarter. Imagine documentation that answers questions, systems that predict issues before they happen, or troubleshooting that actually helps.

Building platforms for AI means creating infrastructure that ML teams need. They're struggling with model deployment, GPU management, and data pipelines. If you can solve these problems, you're suddenly very valuable.

What Actually Changes

The skills you need aren't completely different. You already know:

Infrastructure as code
CI/CD pipelines
Kubernetes and containers
Cloud platforms
Monitoring and security

Add to that:

Thinking about users (yes, developers are users)
Designing APIs people want to use
Writing documentation that doesn't suck
Measuring developer experience, not just uptime
Building things people choose to use, not have to use

That last point is crucial. Platform engineering fails when you build something and force people to use it. It succeeds when developers actively choose your platform because it makes their lives easier. And now here is the bigger problem!

How to Start

You don't need permission to start thinking like a platform engineer.

Pick the most annoying repetitive request you get. Build self-service for it. Make it so good that people stop asking you.

Document it like you're explaining to a friend, not writing a technical manual.

Measure the impact. How much time did you save? How many tickets disappeared?

Then do it again with something bigger.

I've seen people transition by:

Building an internal portal that cut provisioning time from 3 days to 10 minutes
Creating golden paths for deployments that reduced incidents by 60%
Specializing in MLOps infrastructure when their company started AI initiatives

None of them waited for a platform engineering job posting. They created platform engineering within their DevOps roles, proved the value, and the career followed.

The Real Question

Look, AI isn't replacing platform engineers. If anything, it's making the role more critical.

But the DevOps engineer who just keeps doing what they've been doing? That might be a harder position in two years.

The difference isn't about learning every new technology. It's about shifting from "I automate things" to "I build products that enable people."

That's the transition. That's why it matters.

Where I'd Start

If this resonates and you want to explore it:

This week: Talk to three developers. Ask them what's annoying about your infrastructure. Really listen.

This month: Fix one of those problems with self-service. Document it well. Measure the impact.

This quarter: Find platform engineering community. Join their Slack and see what others are building.

The career path isn't mysterious. Build things that make developers' lives better. Measure the impact. Share what you learn. Repeat.

Platform engineering isn't gatekept behind certifications or special knowledge. It's a mindset you can adopt starting today.

The question is whether you will.

Thank you for reading. See you soon!

How ventoy help me to install Window

Pratik Mahalle — Tue, 30 Dec 2025 17:01:17 +0000

After Four Years Using Arch Linux, I Finally Decided to Switch Back to Windows

After four years of using Arch Linux, I finally decided to switch back to Windows. I know that was quite a strange decision, as I was never a fan of Windows. I was always committed to Linux and its security. But time changes, and so do we.

I always used Balena Etcher for flashing ISOs, as I really love that product. Huge shoutout to them for making our lives easier.

After almost getting my pendrive ready to boot, I finally started to boot Windows, but one issue occurred saying, "Required media driver not found." I was like, "Did I make a mistake while flashing the ISO?" I even tried to reinstall the ISO, but the same issue persisted. After doing some research, I got to know that the media driver issue happens because Windows Setup can't detect the internal storage usually due to missing storage controller drivers or USB compatibility problems.

How Ventoy Solved This Issue

This is where Ventoy became my lifesaver.

Traditional tools like Balena Etcher work by extracting the ISO contents and writing them to the USB drive with a bootloader. This process can sometimes mess with the driver structure or how Windows Setup accesses the installation media and internal storage.

Ventoy works completely differently. It creates a bootable environment on your USB drive where ISO files are kept as - is - no extraction, no modification. You literally just copy the ISO file onto the USB like a regular file. When you boot, Ventoy loads the ISO directly from the file, maintaining its original structure and all embedded drivers.

Why this fixed my problem:

The "media driver not found" error happens because Windows Setup loses access to either the USB installation media or can't detect the internal storage (HDD/SSD/NVMe). With traditional flashing methods, the USB controller drivers or storage drivers don't always work properly during setup.

Ventoy bypasses this entirely because it boots the ISO in its virgin state, Windows gets all its drivers exactly as Microsoft packaged them, without any modifications from the flashing process.

What I did:

Downloaded Ventoy and installed it on my USB drive (one - time setup)
Simply copied my Windows ISO file directly onto the USB
Booted from the USB and selected the Windows ISO from Ventoy's menu
Windows installation went smooth, internal storage detected, no driver errors

For me the best thing will be of this tool is, I can keep multiple ISOs on the same USB - Windows, Linux distros, recovery tools i.e. all on one drive. No more reformatting every time and you dont even need extra USB because I don't have that, that is why I find this way :)

So sometimes the simplest solution is the best one and ventoy proved that by just not messing with the original ISO structure, everything works as it should.

If you’ve been through a similar switch or hit an unexpected installer issue, I’d be genuinely interested in hearing how your experience went.

Thank you for reading!

How can we integrate Bolna AI With Google Sheets?

Pratik Mahalle — Mon, 17 Nov 2025 08:10:57 +0000

You know that feeling when you have a list of 50 people to call for reminders, confirmations, or surveys, and you're sitting there thinking "there has to be a better way than dialing each number manually"? Well, I just discovered something that's going to completely change how you think about phone outreach, and I had to share it with you right away.

Picture this: You have a spreadsheet with phone numbers. You hit a button. AI agents start making those calls automatically. The conversations happen naturally. Results get written back to your spreadsheet. All without you lifting a finger. Sounds too good to be true? That's exactly what Bolna + Google Sheets makes possible, and honestly, it's brilliant.

The Problem Everyone Faces (But Nobody Talks About)

Whether you're running a small business, managing events, or handling customer support, phone calls are still the most effective way to reach people. But they're also the most time-consuming. Manual dialing, repeating the same script, logging results—it's exhausting and kills productivity.

Email? Often ignored. SMS? Great, but limited. Phone calls? Personal, direct, and impossible to ignore. But who has time to make 50 calls a day?

That's where the magic of Bolna's AI calling platform combined with the simplicity of Google Sheets comes in. You get the power of AI-driven voice calls without writing a single line of backend code.

What Makes Bolna + Google Sheets Special?

Here's what got me genuinely excited about this integration:

No Infrastructure Required
You don't need servers, databases, or complex DevOps. Just a Google Sheet and a Bolna account. That's it. Set it up once, and you're done.
Real-Time Updates
As calls happen, your spreadsheet updates automatically. You can see who's been called, who answered, and what was discussed—all in one place.
AI That Actually Sounds Human
Bolna's AI agents don't sound like robots. They handle conversations naturally, respond to questions, and even adapt to different situations. It's not just playing a recording—it's having real conversations.

How It Actually Works (The Simple Version)

Think of it like this: your Google Sheet becomes a command center. Each row is a person to call. Mark a row as "pending," and Bolna's AI takes over. It makes the call, has the conversation, and writes back the result. You just check the sheet to see what happened.

The best part? You can test it with your own number first. Call yourself, see how the AI sounds, and once you're comfortable, scale it to hundreds of calls.

Alright, let's build this thing from scratch. Grab a coffee, and let's do this together. I'll walk you through every single step.

Step 1: Set Up Your Bolna Account (5 minutes)

1.1 Create Your Account

Go to platform.bolna.ai
Sign up with your email
You'll get $5 in free credits automatically—enough for 50-100 test calls

1.2 Verify Your Phone Number
This is crucial. Bolna requires verified numbers to prevent spam.

Click on Settings in the left sidebar
Navigate to Verified Phone Numbers
Click Add Number
Enter your phone number in international format (e.g., +919876543210 or +12025551234)
You'll receive an OTP—enter it
Your number is now verified and ready to receive test calls

1.3 Generate Your API Key
This key is how your Google Sheet will talk to Bolna.

Go to Settings → API Keys
Click Create New API Key
Give it a name like "Google Sheets Integration"
Copy the key and save it somewhere safe—you won't see it again
It looks something like: bolna_live_abc123xyz456...

Step 2: Create Your AI Agent (3 minutes)

2.1 Navigate to Agents

Click Agents in the left menu
Click Create New Agent

2.2 Choose a Template
Bolna gives you pre-built templates. Pick one that matches your use case:

Appointment Reminder - For reminding customers about bookings
Survey Agent - For collecting feedback
Lead Qualification - For sales outreach
General Support - For customer service calls

For this tutorial, let's pick Appointment Reminder.

2.3 Customize Your Agent (Optional)

You can edit the first message the agent says
Example: "Hi, this is an automated reminder from [Your Company]. I'm calling to confirm your appointment scheduled for tomorrow at 3 PM. Can you confirm if you'll be able to make it?"
Keep it short and natural

2.4 Save and Copy Agent ID

Click Save
You'll see an Agent ID (looks like agent_abc123xyz)
Copy this—you'll need it in your script

Step 3: Set Up Your Google Sheet (5 minutes)

3.1 Create a New Google Sheet

Go to sheets.google.com
Create a new spreadsheet
Name it something like "Bolna Call Automation"

3.2 Set Up Your Columns
Create these exact column headers in Row 1:

A	B	C	D
Phone Number	Status	Call ID	Result

3.3 Add Your Test Data
Fill in a few rows like this:

Phone Number	Status	Call ID	Result
+919876543210	pending
+12025551234	pending

Important formatting tip:

Make sure phone numbers are in E.164 format (+CountryCodePhoneNumber)
Format Column A as Plain Text (Format → Number → Plain Text) so Google Sheets doesn't remove the "+"

Step 4: Write the Google Apps Script (10 minutes)

This is where the magic happens. Don't worry—I'll walk you through every line.

4.1 Open Apps Script Editor

In your Google Sheet, click Extensions → Apps Script
You'll see a code editor with some default code
Delete everything in there

4.2 Paste This Complete Script


const BOLNA_API_KEY = "YOUR_API_KEY_HERE";  // Paste your Bolna API key
const AGENT_ID = "YOUR_AGENT_ID_HERE";      // Paste your agent ID

function triggerCalls() {
  const sheet = SpreadsheetApp.getActiveSheet();
  const lastRow = sheet.getLastRow();

  // Skip if only header row exists
  if (lastRow < 2) {
    Logger.log("No data rows found");
    return;
  }

  // Get all data rows (starting from row 2)
  const rows = sheet.getRange(2, 1, lastRow - 1, 4).getValues();

  rows.forEach((row, index) => {
    const phoneNumber = row[0];
    const status = row[1];
    const rowNumber = index + 2; // +2 because arrays start at 0 and we skip header

    // Only process rows marked as "pending"
    if (phoneNumber && status === "pending") {
      try {
        Logger.log(`Processing row ${rowNumber}: ${phoneNumber}`);

        // Make the API call to Bolna
        const callId = makeBolnaCall(phoneNumber);

        // Update the sheet with new status and call ID
        sheet.getRange(rowNumber, 2).setValue("initiated"); // Status column
        sheet.getRange(rowNumber, 3).setValue(callId);      // Call ID column

        Logger.log(`Call initiated successfully: ${callId}`);

      } catch (error) {
        Logger.log(`Error for row ${rowNumber}: ${error.message}`);
        sheet.getRange(rowNumber, 2).setValue("error");
        sheet.getRange(rowNumber, 4).setValue(error.message);
      }
    }
  });
}

function makeBolnaCall(phoneNumber) {
  const url = "https://api.bolna.dev/call";

  const payload = {
    agent_id: AGENT_ID,
    recipient_phone_number: phoneNumber,
    // You can add more options here:
    // user_data: { customer_name: "John Doe" }
  };

  const options = {
    method: "post",
    contentType: "application/json",
    headers: {
      "Authorization": `Bearer ${BOLNA_API_KEY}`
    },
    payload: JSON.stringify(payload),
    muteHttpExceptions: true
  };

  const response = UrlFetchApp.fetch(url, options);
  const statusCode = response.getResponseCode();
  const responseBody = response.getContentText();

  Logger.log(`API Response Code: ${statusCode}`);
  Logger.log(`API Response Body: ${responseBody}`);

  // Check if the call was successful
  if (statusCode !== 200 && statusCode !== 201) {
    throw new Error(`Bolna API error (${statusCode}): ${responseBody}`);
  }

  const data = JSON.parse(responseBody);

  // Return the call ID from the response
  return data.call_id || data.id;
}

function updateCallStatuses() {
  const sheet = SpreadsheetApp.getActiveSheet();
  const lastRow = sheet.getLastRow();

  if (lastRow < 2) return;

  const rows = sheet.getRange(2, 1, lastRow - 1, 4).getValues();

  rows.forEach((row, index) => {
    const callId = row[2];      // Call ID column
    const status = row[1];      // Status column
    const rowNumber = index + 2;

    // Only check calls that are not yet completed
    if (callId && status !== "completed" && status !== "failed" && status !== "error") {
      try {
        const callData = getCallStatus(callId);

        // Update status
        sheet.getRange(rowNumber, 2).setValue(callData.status);

        // If call is completed, add the result/summary
        if (callData.status === "completed") {
          const result = callData.summary || callData.transcript_summary || "Call completed successfully";
          sheet.getRange(rowNumber, 4).setValue(result);
        }

        // If call failed, log the reason
        if (callData.status === "failed") {
          const reason = callData.failure_reason || "Call failed";
          sheet.getRange(rowNumber, 4).setValue(reason);
        }

      } catch (error) {
        Logger.log(`Error checking status for row ${rowNumber}: ${error.message}`);
      }
    }
  });
}

function getCallStatus(callId) {
  const url = `https://api.bolna.dev/call/${callId}`;

  const options = {
    method: "get",
    headers: {
      "Authorization": `Bearer ${BOLNA_API_KEY}`
    },
    muteHttpExceptions: true
  };

  const response = UrlFetchApp.fetch(url, options);
  const statusCode = response.getResponseCode();
  const responseBody = response.getContentText();

  if (statusCode !== 200) {
    throw new Error(`Failed to get call status (${statusCode}): ${responseBody}`);
  }

  return JSON.parse(responseBody);
}

function resetAllToPending() {
  const sheet = SpreadsheetApp.getActiveSheet();
  const lastRow = sheet.getLastRow();

  if (lastRow < 2) return;

  // Clear status, call ID, and result columns
  sheet.getRange(2, 2, lastRow - 1, 3).clearContent();

  // Set all to pending
  for (let i = 2; i <= lastRow; i++) {
    sheet.getRange(i, 2).setValue("pending");
  }

  Logger.log("All rows reset to pending");
}

4.3 Update Your Configuration
At the top of the script, replace:

YOUR_API_KEY_HERE with your actual Bolna API key
YOUR_AGENT_ID_HERE with your actual agent ID

4.4 Save the Script

Click the Save icon (💾)
Give your project a name like "Bolna Integration"

Step 5: Test Your First Call (5 minutes)

5.1 Run the Script Manually

In the Apps Script editor, select triggerCalls from the function dropdown at the top
Click Run (▶️)

5.2 Authorize the Script
The first time you run it, Google will ask for permissions:

Click Review Permissions
Choose your Google account
Click Advanced → Go to Your Project Name
Click Allow

(Don't worry—this is safe. Google just shows this warning for custom scripts)

5.3 Check the Logs

Click Execution Log at the bottom
You should see: Call initiated successfully: call_xyz123

5.4 Your Phone Rings!
Within 10-20 seconds, your verified phone number should ring. Answer it and have a conversation with the AI agent.

5.5 Watch Your Sheet Update
Go back to your Google Sheet. You should see:

Status changed to "initiated"
Call ID appeared in Column C

Step 6: Set Up Automatic Status Updates (5 minutes)

Right now, you have to manually check call status. Let's automate that.

6.1 Create a Trigger

In Apps Script, click the clock icon (⏰) on the left sidebar (Triggers)
Click Add Trigger

6.2 Configure the Trigger
Set these values:

Choose which function to run: updateCallStatuses
Choose which deployment: Head
Select event source: Time-driven
Select type of time trigger: Minutes timer
Select minute interval: Every 1 minute

6.3 Save the Trigger

Click Save
Authorize again if prompted

Now, every minute, your sheet will automatically check if calls are completed and update the results!

Step 7: See the Results

After your call ends (usually 1-2 minutes), refresh your Google Sheet. You should see:

Phone Number	Status	Call ID	Result
+919876543210	completed	call_xyz123	Customer confirmed appointment for tomorrow at 3 PM

The Result column now contains a summary of what happened during the call!

What I Love About This Approach

It's Transparent
Everything happens in a spreadsheet you control. No black boxes. No hidden processes. Just rows of data you can see and manage.
It's Flexible
Want to add more fields? Just add columns. Need to change the script? Tweak it. It adapts to your workflow, not the other way around.
It's Scalable

Start with 5 calls. Scale to 500. The process is the same. You're not locked into any plan or paying per seat.
It's Accessible
Even non-developers can set this up. If you can create a Google Sheet (and you probably can), you can build this.

The Technical Bit (For Those Who Care)

Under the hood, you're using:

Bolna's REST API to trigger calls and fetch status
Google Apps Script (basically JavaScript) to connect your sheet to Bolna
Triggers to automate status updates every minute

The script does three things:

Reads rows marked "pending"
Calls Bolna's API to initiate calls
Polls call status and writes results back

It's event-driven, lightweight, and doesn't require any server hosting.

Why This Matters (The Big Picture)

AI phone calls aren't science fiction anymore. They're practical, affordable, and accessible to anyone. What used to require call centers and massive budgets now fits in a Google Sheet.

This isn't about replacing humans—it's about letting AI handle the repetitive, predictable parts so humans can focus on what matters: complex problems, empathy, and decision-making.

Whether you're a solo entrepreneur, a growing startup, or a team inside a larger company, this integration gives you superpowers. You can reach more people, faster, without sacrificing quality.

Final Thoughts

The best tools are the ones that just work. No unnecessary complexity. No vendor lock-in. No steep learning curve. Bolna + Google Sheets is exactly that—simple, powerful, and surprisingly fun to build.

If you've been looking for a way to automate phone calls without hiring developers or buying expensive software, this is your answer. Give it a shot. Test it with your own number. See what happens when AI handles your outreach.

Trust me, once you see your first automated call complete and the result appear in your spreadsheet, you'll wonder how you ever did it manually.

Now go build something cool. And when it works, share it. The community needs more builders who aren't afraid to experiment.

Ready to start? Head to platform.bolna.ai and create your account. You're literally 20 minutes away from automated AI phone calls.

Is DevRel Just About Events, or Something Deeper?

Pratik Mahalle — Fri, 10 Oct 2025 10:09:52 +0000

"So you just travel and go to conferences?"

That's usually what people say when I tell them I work as a Developer Relations or DevRel. And look, I honestly get it. From the outside, it probably looks like I'm just collecting conference badges, having good food, free stickers and t-shirts.

But after attending some big conference like KubeCon India, speaking at OpenSSF Community Day India, and hanging out at PyCon India, Bengaluru this year, I've got some thoughts to share with you all. Yeah, conferences are fun. But DevRel? It's way more interesting (and messier) than you'd think.

The Conference Life Looks Cooler Than It Actually Is

Let me paint you a picture. You're at KubeCon. There are thousands of people, companies booths everywhere, and someone's handing out yet another t-shirt you'll never wear. You're tired because you stayed up late debugging your demo that broke 10 minutes before your talk. Your phone's dying because you forgot your charger. And you're pretty sure you've had 6 cups of coffee today.

Glamorous? Not exactly.

But then something cool happens. You meet someone who's been stuck on a problem for weeks, and he actually know how to help. Or someone comes up after your talk and says "Hey, that thing you mentioned? That's exactly what I needed and can you help me in that?."

That's when it clicks. This isn't about the free food or the fancy venue. It's about actually being useful to people.

At OpenSSF Community Day India, I gave my first real conference talk. Was I nervous? Absolutely. Did I rehearse it like 20 times? You bet. But standing there, talking about something I care about, and seeing people actually paying attention (not checking their phones!), that felt pretty great.

The Real Conversations Happen in Random Places

Here's what nobody tells you about conferences: The best stuff doesn't happen during the scheduled talks.

At PyCon India, I had this conversation with a developer at the lunch table. We started talking about what he do in the Python community, and they shared their entire workflow, their pain points, why they chose certain tools over others in his work. I think, that 20-minute chat taught me more than any survey ever could.

At KubeCon, someone came to me during a coffee break and showed me his side projects about the communtiy. Right there, between sessions, we debugged an issue together, he has. No slides, no agenda, just two people trying to solve a problem.

These moments are gold. This is where you learn what developers actually struggle with, what they love, what makes them want to throw their laptop out the window(But can't).

Giving Talks Is Terrifying (But Worth It)

Let's be real about speaking at conferences. It's scary.

Before my OpenSSF talk, I was pacing backstage like I was about to take my final exam. What if nobody shows up? What if everyone shows up and I completely blank? What if my demo fails? (Spoiler: demos always fail. Plan accordingly, even my failed.)

But here's the thing about giving talks - it forces you to really know your stuff. You can't just go and understand something. You need to explain it clearly enough that someone who's never seen it or heard it before can follow along with that.

And when you're done? People come up with questions, ideas, their own experiences. Suddenly you're not just talking at people, you're having actual conversations about that topic. That's the fun part actually.

Plus, there's something weirdly satisfying about seeing your slides on a big screen. Not gonna lie, that's pretty cool.
This is my picture from my talk when my demo stop working!

DevRel Between Conferences (AKA The Actual Job)

Okay, so what happens when you're not at a conference? Because that's will be like 95% of the time.

Most of my days look like this:

Writing docs that don't suck. After hearing someone at PyCon say "I read your docs three times and still didn't get it," I learned that what makes sense to me might not make sense to everyone else. Now I try to write like I'm explaining it to a friend.

Hanging out in community channels. Someone's stuck at 2 AM trying to deploy something. You drop a quick tip that unblocks them. They're happy, you're happy, everyone's happy.

Making sample apps and demos. Because sometimes people just want to see "how do I actually use this thing?" Not theory. Not architecture diagrams. Just show me the code.

Being the bridge between users and product teams. When five different people tell you the same thing is confusing, that's feedback worth taking seriously.

None of this is exciting enough for Instagram. But it's what actually helps people.

The Unglamorous Truth

DevRel has this reputation of being all fun and games. Travel! Events! Swag! And sure, those things exist. But nobody talks about:

Answering the same question 47 times (and trying to sound enthusiastic on answer 47)
Writing the tutorial that took you 8 hours for someone to read in 5 minutes
Debugging someone else's setup over a spotty video call
Realizing your blog post has a typo after 500 people have already read it
Spending hours planning an event and having 3 people show up

It's not all highlight reels. Sometimes it's just showing up and doing the work, even when nobody's watching.

Why I Actually Like This Job

Despite everything I just said, I genuinely love this work. Here's why:

You're constantly learning. Every conversation teaches you something. Every question makes you think differently. You can't do DevRel and stay stagnant.

You meet genuinely interesting people. At KubeCon, I met someone building cloud infrastructure for rural schools. At PyCon, I talked to developers building tools for climate research. These people are doing cool stuff, and you get to be part of their journey.

You see real impact. When someone builds something because of a tutorial you wrote, or when a feature gets added because you advocated for it, that feels good. You're not just talking about technology, you're helping people use it.

The community becomes your community. You start recognizing faces at events. People remember you. You become part of something bigger than just your company or project.

What DevRel Actually Is

I was at Open Source Summit India, and there Aditya Oberoi gave a talk on DevRel and he mentioned a very good definition of DevRel. As you can see that in the image below.

After going to these conferences, and having countless conversations, here's my take:

I feel DevRel is a person who represents the company to the community and vice versa.

It's about:

Writing guides that actually make sense
Answering questions without being condescending
Building tools that solve real problems
Creating spaces where people feel comfortable asking for help
Being honest when something's broken instead of making excuses

Yes, events are part of it. Speaking at conferences is part of it. But those are just the visible parts. The real work is everything else, the daily grind of helping people, listening to feedback, and trying to make things better. And these are the some real work which goes hidden.

If You're Thinking About DevRel

My advice will be? Don't do it for the travel or the stage time or just for the fame. Those things are bonuses, not the job honestly.

But do it if you actually enjoy helping people. Do it if you get excited when someone finally understands something you explained. Do it if you care about making technology more accessible and less frustrating.

And if you do end up at a conference like KubeCon or PyCon? Don't just collect swag and business cards. Have real conversations with he people and make friends. These friends will really help you in future. Ask people what they're building. Learn about their challenges. That's where the actual interesting stuff happens.

Because at the end of the day, DevRel isn't about how many events you attended or how many talks you gave. It's about how many developers you actually helped. And honestly? That's a pretty good way to spend your time.

P.S. — If you see me at a future conference, say hi! I promise I'm friendlier than I look when I'm frantically trying to find a power outlet 10 minutes before my talk.

MemU: Memory that works everywhere

Pratik Mahalle — Sun, 17 Aug 2025 11:35:04 +0000

You know how we were talking about those chatbots and digital assistants that seem to forget everything the moment you close the app? Well, I just discovered something that's going to completely change that game, and I had to tell you about it right away.

The Problem We All Face

Picture this: You're having deep conversations with your favourite digital companion, sharing personal stories, preferences,and dreams, and gradually building what feels like a real relationship. Then you come back the next day, and... nothing. It's like talking to someone with amnesia who has to start from scratch every single time and I am kind of that person also.

Frustrating, right? That's exactly what got the folks at NevaMind thinking, and they came up with something called MemU that honestly sounds too good to be true.

What Makes MemU Different

Think of MemU as giving your digital companion a proper brain - not just the ability to chat, but genuine memory that works like yours and mine. Instead of forgetting everything after each conversation, it creates what they call an "intelligent memory folder" that actually learns and grows.

Here's what completely amazed me: this thing doesn't just store random bits of conversation. It has a memory agent (basically like having a personal librarian in your head) that automatically decides what's worth remembering, what needs updating, and what can be forgotten. No more manually organising or structured data input - it just handles everything naturally.

The Numbers That Made Me Do a Double-Take

Okay, so I'm usually doubtful about these tech claims, but check this out:

They're hitting 92% accuracy on memory benchmarks (that's insanely good)
It can cut costs by up to 90% compared to traditional approaches
Instead of processing tiny conversation fragments, it can handle hundreds of conversation turns at once

That last point is huge because it means developers don't have to constantly ping the system for every little memory operation. It's like the difference between having to consciously think about every step while walking versus just naturally walking to where you want to go.

How It Actually Works (The Cool Stuff)

The most brilliant part is how memories connect to each other. Remember how our brains don't just store isolated facts but create these web-like connections between related thoughts? MemU does exactly that. Your memories become this living network where finding one thing naturally leads you to related memories.

But here's the part that really got me excited - it keeps working even when you're offline. The memory agent analyzes existing memories, finds patterns, creates insights, and basically makes your knowledge base smarter over time. It's not just growing bigger; it's getting more intelligent.

And just like human memory, it knows what to prioritize. Recent stuff stays easily accessible, while less important things naturally fade into the background. Your digital companion develops its own personality and understanding that's uniquely shaped by your interactions.

Real-World Applications That Make Sense

The creators designed this specifically for companion applications, and you can see why:

Personal Companions: Finally, someone who actually remembers your favorite coffee order, that story about your childhood dog, and how you prefer to be comforted when you're stressed.

Educational Assistants: A tutor that remembers your learning style, what topics you struggle with, and builds on previous lessons naturally.

Creative Partners: Collaborators for writing, brainstorming, or projects who remember your creative preferences and can reference past ideas.

Therapy and Wellness: Digital support that understands your patterns, triggers, and what approaches work best for you personally.

Three Ways to Try It Out

What I love is that they've made this accessible regardless of your technical level:

Cloud Version: The easiest route - sign up at app.memu.so, get your API key, and you're literally three lines of code away from having persistent memory in your applications. They handle all the complex infrastructure stuff.

Self-Hosted: For people who want complete control over their data and prefer running everything locally. Perfect if privacy is your main concern or if you want to customize everything.

Enterprise: Full commercial licensing with dedicated support, custom development, and all the enterprise-grade features you'd expect.

Why This Matters More Than You Think

We're moving toward a world where our digital interactions become increasingly personal and meaningful. The difference between a forgettable chatbot experience and a genuinely helpful digital companion often comes down to memory.

MemU isn't just solving a technical problem - it's enabling real relationships between people and their digital tools. When your companion remembers not just what you said, but understands the context, your preferences, and how you've grown over time, everything changes.

The Open Source Thing

Here's something I really respect about the team: they're committed to open source development, otherwise I wouldn't be writing about this one here. The core framework is available on GitHub under Apache License 2.0, which means the community can contribute, modify, and improve it together.

They've got an active Discord community, regular updates on Twitter, and they're genuinely interested in feedback from developers and users alike.

Conclusion

Look, I've seen plenty of "revolutionary" memory solutions that turned out to be mostly hype. But MemU feels different. The combination of high accuracy, practical implementation, and genuine understanding of what companion applications need makes this feel like a real breakthrough.

The fact that they're achieving 92% accuracy while keeping costs low suggests they've solved some fundamental technical challenges that others haven't figured out yet. That is from this one. If you have to talk about this,let's connect on x.

Want to Try It?

If you're curious (and you should be), the easiest way is to check out their cloud version at app.memu.so otherwise try the community edition also. Even if you're not so called technical person, you can experiment with the API and see how persistent memory changes the conversation experience.

What do you think? Does this sound like something you'd want to experiment with? I'm definitely planning to play around with it this weekend and also creating a demo on this and see what kind of companion experiences I can build.

Want to explore MemU yourself? Check out memu.pro or dive straight into the code at their GitHub repository. Join their Discord community to connect with other developers who are building the future of intelligent digital companions.

Chaos Engineering for Security: Breaking Systems To Strengthen Defenses

Pratik Mahalle — Sun, 20 Jul 2025 12:45:03 +0000

I'm excited to be speaking about this topic at OpenSSF Community Day India, and wanted to share some insights on this fascinating intersection of chaos engineering and security.

When most people hear "chaos engineering," they immediately think of Netflix's famous Chaos Monkey randomly terminating servers to test system resilience. But what if we took that same philosophy and applied it to security? What if, instead of waiting for attackers to find our vulnerabilities, we intentionally broke our own systems to discover weaknesses first?

Welcome to Security Chaos Engineering – a practice that's transforming how we think about proactive security testing.

Security Testing Reality Check

Let's start with some uncomfortable truths about modern security:

277 days - that's the average time it takes to detect a security breach(according to the theories)
Security testing typically happens too late in the development cycle
Most assumptions about security controls go completely untested
Teams deploy defenses and hope they work, only discovering gaps during real incidents

I've witnessed this pattern repeatedly in organizations I've worked with. Teams spend months perfecting their security configurations, only to discover during a real incident that their assumptions were wrong. That firewall rule they thought was bulletproof? It fails under load. The network segmentation they relied on? It breaks when pods start communicating unexpectedly.

Here's the key question that changed how I think about security: What if we could break things safely and strengthen our defenses before attackers find our weaknesses?

Enter Security Chaos Engineering

This is where Security Chaos Engineering comes in - a proactive approach that flips the traditional security script:

Traditional Security Approach:
Wait for attacks → Respond to incidents → Fix what broke

Security Chaos Engineering Approach:
Inject controlled failures → Test security responses → Strengthen defenses proactively

Definition: Security Chaos Engineering is the practice of testing security controls and incident response procedures through controlled failure injection and attack simulation.

Goal: Find vulnerabilities and weaknesses before real attackers do, while building confidence in our defensive capabilities.

The core principle remains simple: If we can break it in a controlled environment, we can fix it before an attacker exploits it.

Tools of the Trade

Before we dive into practical examples, let's talk about the tools that make Security Chaos Engineering possible. Having the right toolkit is crucial for effective security chaos experiments.

Core Chaos Engineering Platforms

ChaosMesh: My go-to choice for Kubernetes-native environments. It offers excellent security experiment support with intuitive YAML configurations and a solid web UI for monitoring experiments.

LitmusChaos: Perfect for complex, multi-step chaos workflows. It has extensive experiment templates and integrates well with CI/CD pipelines. The community is active and constantly adding new security-focused experiments.

Security Monitoring and Detection

KubeArmor: Runtime security monitoring that integrates beautifully with chaos experiments. It can detect policy violations and unusual behavior patterns during your tests.

Falco: Essential for detecting suspicious activities during chaos experiments. Its rule-based detection engine helps identify when your experiments uncover real security issues.

Open Policy Agent (OPA): Useful for testing policy enforcement under various failure conditions.

Network and Infrastructure Tools

Istio Service Mesh: Provides detailed network observability during chaos experiments, helping you understand how security policies behave under stress.

Weave Scope: Excellent for visualizing network topology and understanding blast radius during security chaos experiments.

Why Tool Selection Matters

Each tool serves a specific purpose in the security chaos engineering workflow:

Chaos platforms inject the failures
Monitoring tools observe the impact
Security tools detect when defenses fail
Network tools help understand the scope of impact

The key is creating a cohesive toolchain where these components work together seamlessly.

Real-World Scenarios: Learning by Breaking

Now that we have our toolkit ready, let me walk you through some practical scenarios where Security Chaos Engineering has proven invaluable.

Scenario 1: Testing Kubernetes Pod Compromise

Imagine you have a Kubernetes cluster with what you believe is proper network segmentation. Your pods are isolated, your network policies are in place, and everything looks secure on paper.

Here's how we can test this assumption:

# Using ChaosMesh to simulate a compromised pod
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-compromise-test
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: web-frontend
  scheduler:
    cron: "@every 10m"

But that's just the beginning. What we really want to test is what happens after compromise:

Lateral Movement Testing: Once we simulate a pod compromise, can the "attacker" move laterally to other services?
Data Exfiltration Simulation: Can sensitive data be accessed from the compromised pod?
Privilege Escalation: Can the compromised pod gain higher privileges?

Scenario 2: Firewall Stress Testing

Your firewall rules work perfectly under normal conditions, but what happens when your system is under stress? Here's a test I regularly run:

# Using LitmusChaos for network chaos experiments
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: network-loss-test
spec:
  definition:
    scope: Namespaced
    permissions:
      - apiGroups: [""]
        resources: ["pods"]
        verbs: ["create","delete","get","list"]
    image: "litmuschaos/go-runner:latest"
    args:
      - -c
      - ./experiments -name network-loss
    command:
      - /bin/bash
    env:
      - name: NETWORK_PACKET_LOSS_PERCENTAGE
        value: '50'
      - name: TOTAL_CHAOS_DURATION
        value: '300'

This experiment simulates 50% packet loss for 5 minutes. During this chaos, we test:

Do firewall rules still apply correctly?
Are there any bypass opportunities when the network is degraded?
How does the system behave when connections are intermittent?

Demo: Setting Up Your First Security Chaos Experiment

Let me show you how to set up a basic security chaos engineering experiment using open-source tools.

Step 1: Environment Setup

First, let's set up a basic Kubernetes cluster with some security tools:

# Install ChaosMesh
curl -sSL https://mirrors.chaos-mesh.org/v2.6.2/install.sh | bash

# Install KubeArmor for runtime security
kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/deployments/kubearmor.yaml

# Verify installations
kubectl get pods -n chaos-mesh
kubectl get pods -n kubearmor

Step 2: Create a Vulnerable Application

Let's deploy a simple web application with intentional security gaps:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vulnerable-app
  labels:
    app: vulnerable-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: vulnerable-app
  template:
    metadata:
      labels:
        app: vulnerable-app
    spec:
      containers:
      - name: web
        image: nginx:latest
        ports:
        - containerPort: 80
        securityContext:
          runAsUser: 0  # Running as root - intentionally vulnerable
          capabilities:
            add: ["NET_ADMIN"]  # Excessive privileges

Step 3: Create Security Chaos Experiments

Now, let's create experiments to test our assumptions:

Experiment 1: Pod Failure Under Attack Simulation

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: ddos-simulation
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - default
    labelSelectors:
      app: vulnerable-app
  delay:
    latency: "10ms"
    correlation: "100"
    jitter: "0ms"
  duration: "5m"

Experiment 2: Testing Security Controls During Resource Exhaustion

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: memory-stress-security-test
spec:
  appinfo:
    appns: default
    applabel: 'app=vulnerable-app'
    appkind: 'deployment'
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-memory-hog
    spec:
      components:
        env:
        - name: MEMORY_CONSUMPTION
          value: '500'
        - name: TOTAL_CHAOS_DURATION
          value: '300'

Step 4: Monitor and Observe

While the chaos experiments run, we monitor several security metrics:

# Monitor KubeArmor alerts
kubectl logs -n kubearmor -l kubearmor-app=kubearmor --tail=100 -f

# Check for privilege escalation attempts
kubectl get events --field-selector reason=FailedMount,reason=SecurityContextDeny

# Monitor network policies
kubectl describe networkpolicies

What We Learn from Breaking Things

Running these experiments consistently reveals patterns that traditional security testing misses:

Discovery 1: Security Controls Fail Under Load

In one experiment, I discovered that our API rate limiting completely broke down when pods were under memory pressure. The security control was there, but it became ineffective when the system was stressed.

Discovery 2: Network Policies Have Edge Cases

During a network partition experiment, we found that certain pod-to-pod communications bypassed our network policies when DNS resolution was flaky. This created an unexpected attack vector.

Discovery 3: Monitoring Blind Spots

Chaos experiments revealed that our security monitoring had significant blind spots during high-CPU usage periods. Critical security events were being dropped or delayed.

Best Practices for Security Chaos Engineering

Based on my experience implementing this across different organizations, here are key practices that work:

Start Small: Begin with non-production environments and simple experiments. Don't try to simulate a full-scale attack on day one.

Hypothesis-Driven: Each experiment should test a specific security assumption. "What happens to our authentication system when the database is slow?" is better than "let's see what breaks."

Automate Everything: Manual chaos is not sustainable. Use tools like ChaosMesh and LitmusChaos to create repeatable, scheduled experiments.

Learn and Iterate: Each experiment should lead to concrete improvements in your security posture. If you're not fixing things you discover, you're not doing it right.

Build Observability First: You can't understand what breaks if you can't see it breaking. Ensure comprehensive monitoring and logging before running experiments.

Collaborate Across Teams: Security chaos engineering works best when security, development, and operations teams work together. Each brings unique perspectives on what might break.

Tools of the Trade

Here's my current toolkit for Security Chaos Engineering:

ChaosMesh: Excellent for Kubernetes-native chaos experiments with good security experiment support
LitmusChaos: Great for complex, multi-step chaos workflows
KubeArmor: Runtime security monitoring that integrates well with chaos experiments
Falco: For detecting unusual behavior during experiments
Gremlin: Commercial option with advanced security testing features

The Mindset Shift

The biggest challenge isn't technical – it's cultural. Organizations need to shift from "don't break production" to "break production safely and learn from it."

This means:

Embracing failure as a learning opportunity
Questioning assumptions about security controls regularly
Building systems that are resilient to both accidental and malicious failures
Investing time in proactive testing rather than just reactive incident response

Looking Forward

Security Chaos Engineering is still evolving, but I'm convinced it represents the future of proactive security. As systems become more complex and distributed, our security testing needs to evolve too.

The goal isn't to replace traditional security practices – it's to complement them. Penetration testing, vulnerability scanning, and compliance audits all have their place. But they're not enough anymore.

If you're curious to learn more about this approach, I'll be diving deeper into practical implementations and advanced scenarios at the OpenSSF Community Day India. We'll do live demos, explore real-world case studies, and hopefully convince a few more people that breaking things on purpose is actually a pretty good idea.

What's your experience with chaos engineering? Have you tried applying it to security? I'd love to hear your thoughts and experiences. Feel free to reach out – the security community gets stronger when we share our learnings, especially our failures.

Google's Gemini CLI: Open Source AI Agent

Pratik Mahalle — Fri, 04 Jul 2025 17:16:05 +0000

Hey everyone! So I just got my hands on Google's brand new Gemini CLI, and I'm honestly blown away. This isn't just another AI tool – it's a complete game-changer that brings the power of Gemini 2.5 Pro directly into your terminal. Let me tell you why this has me so excited.

What Makes This Different?

Google describes Gemini CLI as "an open-source AI agent that brings the power of Gemini directly into your terminal" – and that's exactly what it does. But here's what really caught my attention: it can handle over 1 million tokens in context, making it easy to analyze large projects.

Think about that for a second. Most AI tools struggle with large codebases, but this thing can literally understand your entire project at once. It's like having a senior developer who's read through every single file in your repo and can give you contextual advice about any part of it.

The Setup Is Surprisingly Smooth

I was expecting the usual developer tool setup nightmare, but Google actually made this dead simple. You've got two options:

Option 1: Try it instantly (no installation needed):

npx https://github.com/google-gemini/gemini-cli

Option 2: Install it globally (recommended):

sudo npm install -g @google/gemini-cli

That's it! Just make sure you have Node.js 18 or later, and you're good to go. Once installed, just type gemini in your terminal and boom – you're in.

The Free Tier Is Actually Insane

Here's where Google really surprised me. They're offering "the industry's largest allowance: 60 model requests per minute and 1,000 requests per day at no charge". Let me put that in perspective – that's more than most developers would ever need, and it's completely free if you just log in with your Google account.

Compare that to other AI tools where you hit limits after a few conversations. This is a legitimate free tier that you can actually rely on for real work.

The Multimodal Magic

Now here's where things get really interesting. Gemini CLI has "multimodal app prototyping" capabilities and can "quickly generate app prototypes from PDFs or sketches".

I tested this by uploading a rough sketch of a UI mockup, and it generated working HTML/CSS code that actually looked like what I drew. The AI can literally see your images, understand your drawings, and turn them into code. It's like having a designer and developer rolled into one.

Built-in Superpowers

The tool comes packed with features that make it feel like a proper AI assistant rather than just a chatbot:

Google Search Integration: It can "ground prompts with Google Search so you can fetch web pages and provide real-time, external context to the model". No more outdated information – it pulls fresh data from the web.

File Upload with @: Just type @ in the CLI and it opens a file picker. You can upload code, images, documents – whatever you need the AI to analyze.

DevOps Automation: It can "perform Git operations, fetch PRs, create migration plans, and more". I've already used it to generate complex git commands I always forget.

Creative Content Generation: It has "tool integration" that can "connect to media generation models like Imagen, Veo, and Lyria" for creating images and videos.

Real-World Testing Results

I've been using this for about a week now, and here are some scenarios where it absolutely shines:

Code Analysis: I uploaded a legacy Python project with 50+ files. Within seconds, it understood the entire codebase and could explain complex functions, suggest improvements, and even identify potential bugs.

Debugging: Instead of copying error messages to Google, I just paste them directly into the CLI. It not only explains what's wrong but provides contextual fixes based on my actual code.

Learning New Frameworks: I'm picking up React, and this thing has been like having a personal tutor. It explains concepts, shows examples, and even generates starter code that follows best practices.

Command Line Wizardry: Forgot that complex Docker command? Need a specific git workflow? The AI remembers everything and can generate exactly what you need.

The VSCode Integration Is Seamless

Here's something cool – Google has integrated Gemini CLI with their "Gemini Code Assist" so that "all developers — on free, Standard, and Enterprise Code Assist plans — get prompt-driven, AI-first coding in both VS Code and Gemini CLI".

You can literally run gemini right inside VSCode's integrated terminal and use the same @ command to select files from your current project. It's like having the best of both worlds – the power of the terminal with the convenience of your IDE.

Open Source Means Real Freedom

The entire project is "fully open source (Apache 2.0)", which means you can actually inspect the code, understand how it works, and contribute improvements. This isn't a black box – you can see exactly what's happening with your data.

Google is actively encouraging community contributions, and I expect we'll see some amazing extensions and improvements from the developer community soon.

Why This Feels Like the Future

Using Gemini CLI feels fundamentally different from other AI tools. It's not just about asking questions – it's about having an AI that truly understands your development context and can take action within your workflow.

The massive "1 million token context window" means it can keep track of complex conversations, understand large codebases, and maintain context across multiple interactions. It's like having a coding partner who never forgets anything.

The Enterprise Story

If you're working in a team or enterprise environment, you can use "a Google AI Studio or Vertex AI key for usage-based billing or get a Gemini Code Assist Standard or Enterprise license". This gives you higher rate limits and enterprise-grade features.

But honestly, for most individual developers, the free tier is more than enough to get started and see real productivity gains.

Should You Try It Right Now?

Absolutely. This tool has genuinely changed how I approach coding. The setup takes 5 minutes, it's completely free, and it might just revolutionize your development workflow.

What impressed me most is how natural the interaction feels. You're not fighting with a clunky web interface or waiting for pages to load. Everything happens instantly in your familiar terminal environment.

Getting Started Today

Ready to give it a shot? Here's what you need to do:

Make sure you have Node.js 18+ installed
Run sudo npm install -g @google/gemini-cli
Type gemini in your terminal
Choose your theme and sign in with Google
Start experimenting!

The first time you run it, it'll walk you through the setup process. Choose "Login with Google" for the best free experience, and you'll be up and running in under 5 minutes.

Final Thoughts

Google's Gemini CLI isn't just another AI tool – it's a fundamental shift in how we interact with AI while coding. It brings enterprise-grade AI capabilities directly into the environment where developers actually work, with generous free limits that make it accessible to everyone.

The combination of massive context windows, multimodal capabilities, web search integration, and seamless workflow integration makes this feel like the AI assistant we've all been waiting for.

If you're a developer, this is definitely worth your time. Your terminal is about to get a whole lot smarter, and your productivity is about to take a serious jump.

Trust me on this one – give it a try today. You'll wonder how you ever coded without it. That`s it for now, see you in another one. If you have to talk more about it, you can connect with me on x.

KEDA: Smarter Scaling for Kubernetes – Event-Driven and Effortless

Pratik Mahalle — Sun, 29 Jun 2025 09:47:54 +0000

I was just exploring some CNCF projects and then I got to know about Keda. So, in this article, we will be talking about Kubernetes Event-driven Autoscaling (KEDA).

Scaling applications in Kubernetes is pretty cool, right? But what if I told you there’s a smarter way to scale — not just based on CPU or memory, but based on real-world events like incoming messages, pending jobs, or HTTP requests?

Let me introduce you to KEDA — Kubernetes Event-Driven Autoscaler.

Whether you’re new to Kubernetes or someone who's been running clusters for a while, you’ll love how KEDA changes the way we think about autoscaling.

KEDA was accepted to CNCF on March 12, 2020, moved to the Incubating maturity level on August 18, 2021, and then moved to the Graduated maturity level on August 22, 2023.

The Challenge with Traditional Autoscaling

So, imagine this: you’ve set up your application to scale with HPA, which primarily focuses on CPU and memory usage. That’s great for CPU-heavy apps, but what about those applications that don’t rely solely on these metrics for performance?
Think of apps that process message queues, listen to streaming events (like Kafka), or handle background jobs based on database records. Often, these apps can have a large backlog of tasks while their CPU is barely hitting 10%. Frustrating, right?

In Kubernetes, we usually scale our apps with the Horizontal Pod Autoscaler (HPA).
But here’s the thing:

HPA mostly cares about CPU and memory usage.

That’s fine if your app is CPU-heavy. But what if your app:

Processes a message queue?
Listens for events from a streaming platform like Kafka?
Runs background jobs based on database records?

In these cases, CPU and memory aren’t always the right signals to decide whether to scale up or down.
You could have a huge backlog of work, but the CPU is chilling at 10%.

This is where KEDA comes in.

Enter KEDA

This is where KEDA comes to the rescue. It’s an open-source project that allows you to scale your Kubernetes applications based on the number of messages in a queue, the rate of events, or other custom metrics. It empowers us to scale our workloads dynamically and efficiently, depending on specific triggers and workloads rather than just CPU or memory.

How Does KEDA Work?

KEDA works by using a set of scalers—these are components that listen to various events and determine when and how much to scale your applications. It integrates seamlessly with existing tools like HPA, allowing it to use the scaling logic of Kubernetes, but with the added finesse of reacting to specific event-driven conditions.

Here’s how it typically functions:

Scaler Configuration: You define which event source (like a Kafka queue or Azure Queue Storage) KEDA should monitor and specify the scaling logic within a Custom Resource Definition (CRD).
Event Monitoring: KEDA continuously watches the specified external event sources. For instance, if you set it to monitor a message queue, it will check how many messages are in the queue.
Autoscaling: When the defined threshold is reached—say, the number of messages exceeds a certain value—KEDA triggers the HPA to scale up the pods. If the backlog decreases (or if the queue is empty), it will scale down accordingly.

Why KEDA is Worth Using

Flexibility: KEDA supports a wide range of event sources, from message queues to databases and custom metrics, making it adaptable for various use cases.
Cost-Efficiency: By scaling your application based on actual demand (number of events, messages, etc.), you’re only using the resources you need, potentially reducing costs.
Simplicity: The setup is relatively straightforward, especially if you're already familiar with Kubernetes. With KEDA's CRDs, you can quickly get started integrating advanced autoscaling capabilities.

Real-World Use Cases

Let’s take a look at how KEDA can shine in real-life situations:

Background Jobs: If you have a system that processes data in batches (think image processing), KEDA can scale your worker pods based on the number of images waiting to be processed in a queue.
Event Stream Processing: If you're capturing events from a data streaming platform like Kafka, KEDA can monitor the number of unprocessed events and scale your consumers up or down accordingly, ensuring that no event is left hanging.
Microservice Communication: In a microservices architecture, certain services may only need to scale based on specific triggers, such as the number of requests or messages from another service. KEDA can handle this beautifully.

Refer this for more

Conclusion

If you’re looking to optimize your Kubernetes applications and enhance their autoscaling capabilities, KEDA is definitely worth giving a try. It helps bridge the gap between traditional scaling methods and the dynamic workloads that today’s applications often require.

Let me know if you end up experimenting with KEDA. I’d love to hear about your experiences or any challenges you encounter along the way! If you have any suggestion, you can connect me on x!

Happy scaling! 🍻

🐣How to Save Money with AWS Spot Instances

Pratik Mahalle — Tue, 20 May 2025 05:53:55 +0000

What if I told you that you can reduce your cloud costs by up to 90%—without rewriting your application? Yes, that’s what Spot Instances are for.

What Exactly is a Spot Instance?.

To understand Spot Instances, Lets consider a scene, think of AWS like an airline. Sometimes, seats go unsold, and the airlines offer those seats at lower prices due to unsold capacity. Spot Instances are AWS’s unsold capacity sold at a discount.

Spot Instances are essentially the same as regular EC2 Instances, but they are significantly cheaper because you are using AWS's extra, unused servers. The probelm is that these instances can be taken away at any time. However, don’t worry; it’s not as scary as it sounds.

When Should You Use Spot Instances?

So, when should you use a Spot Instance for your application, Right?
Spot Instances are amazing, but they are not right for everyone. Here are some scenarios where using them makes sense:

Development and Test Environments: Use Spot Instances for developing and testing applications.
CI/CD Pipelines: Run build and test jobs cost-effectively, mainly for open-source.
Batch Jobs: Execute batch processing jobs at lower costs, particularly for open-source or internal applications.
Containers with Fargate or ECS: If you are using containers, Spot Instances can be a smart way to save costs.

👋 One Last Thing:

Using Spot Instances is not just about saving money; it also encourages to think about scalability, resilience, and automation—core skills for any solution architect or DevOps engineer. If you have time, try creating a Spot Instance to see how it work, and then imagine replacing ten of your servers with it.

If you want to know more, you can check the references below.

References:

Spot Instance Pricing Page
EC2 Spot vs. On-Demand Explained (AWS Docs)
YouTube: Spot Instances in Production – Good Idea?

That`s it for this now! I'm happy you made it to the end - thank you so much for your support. If you have any queries or opinions, you can connect with me on x.

A Beginner's Journey: Deploying Applications on Amazon EKS

Pratik Mahalle — Thu, 17 Apr 2025 10:17:36 +0000

In this blog post, I want to walk you through the step-by-step process of deploying a straightforward web application utilising Amazon EKS (Elastic Kubernetes Service).
Kubernetes has emerged as one of the most widely adopted tools in the DevOps industry. However, many individuals find themselves wrestling with the complexities of EKS and its integration with AWS. My objective is to demonstrate these concepts, making them more accessible and practical for implementation.

What Is Kubernetes?

Kubernetes is an innovative open-source platform designed for container orchestration. It automates critical processes such as deploying, scaling, and managing containerised applications.
Originally developed by Google, Kubernetes is now watched by the Cloud Native Computing Foundation. In essence, Kubernetes serves as a powerful framework for managing your applications, enabling seamless deployment and scalability tailored to your needs.

Why EKS?

When it comes to deploying and managing the containerised application, Elastic Kubernetes Service stand out exceptionally well. Here's why EKS can transform your deployment strategy.

Fully Managed: EKS simplifies Kubernetes management by handling tasks like deploying and scaling, allowing your team to focus on building exceptional applications.
Seamless AWS Integration: EKS works effortlessly with AWS services, improving your application's functionality while maintaining strong security through IAM and other tools.
Dynamic Scalability: It easily adjusts the number of nodes and pods to match traffic demands, ensuring efficient resource utilisation and potential cost savings.
High Availability: Leveraging multiple Availability Zones(AZ), EKS guarantees that your applications remain online and available, even during unexpected challenges.
Enhanced Security: With built-in security features like IAM integration and automatic data encryption, EKS safeguards your sensitive information.
Strong Support Community: EKS has among the strong community support concerning others as it gives you access to best practices and assistance whenever needed.

How Do We Deploy Cloud-Native Apps on EKS?

This tutorial's primary goal is to demonstrate how to deploy a containerised application onto an EKS cluster, leveraging Helm for efficient package management.

Prerequisites

Before diving into the deployment process, this is the deployment process we are going to use and ensure you have the following tools installed and configured on your system:

Python: A powerful programming language necessary for application development.
Docker: A platform for developing, shipping, and running applications in containers.
Kubernetes: The container orchestration system we'll be working with.
Helm: The package manager for Kubernetes that simplifies deployment.
AWS CLI: Command Line Interface for interacting with AWS services.
Amazon EKS: AWS's managed Kubernetes service.

To access the source code and additional resources, feel free to visit the GitHub repository here: [GitHub Repo Link: https://github.com/pratik-mahalle/Zero-to-Production].

Step 1: Dockerizing the Application

Let's picture you have a simple application written in Python. The first crucial step involves creating a Docker image of this application. Below is the Dockerfile that I used:

FROM python:3.9-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "app.py"]

In this Dockerfile:

We start from the official Python 3.9 image with a slim footprint to keep our container lightweight.
The WORKDIR instruction sets the working directory in the container to /app.
All application files are copied into this directory.
The command pip install -r requirements.txt installs all necessary dependencies.
The EXPOSE command tells Docker to expose port 5000 on the container for web traffic.
Finally, the CMD instruction specifies how to run the application.

Next, we will upload this Docker image to an Amazon ECR (Elastic Container Registry). Ensure that you create an ECR repository through the AWS Console and authenticate your Docker client for the process.

To obtain an authentication token and log in to your Docker registry, execute the following command in the AWS CLI:

aws ecr get-login-password - region ap-south-1 | docker login - username AWS - password-stdin [AWS_ACCOUNT_ID].dkr.ecr.ap-south-1.amazonaws.com

Important Note: If you encounter any issues when using the AWS CLI, check that you have the latest versions of both the AWS CLI and Docker installed. Make sure to replace the AWS_ACCOUNT_ID with your actual AWS account id.

Now, to build your Docker image, use the following command. If further information on building a Docker image from scratch is needed, please refer to this resource. You can skip this if your image is already built:

docker build -t demo .

Once the build is complete, it's crucial to tag the image to prepare it for pushing to your ECR repository:

docker tag demo:latest [AWS_ACCOUNT_ID].dkr.ecr.ap-south-1.amazonaws.com/demo:latest

Finally, push your Docker image to the AWS repository with this command:

docker push [AWS_ACCOUNT_ID].dkr.ecr.ap-south-1.amazonaws.com/demo:latest

Congratulations! Your application is now successfully dockerized and ready for deployment.

Step 2: Create an EKS Cluster

With your application dockerized, the next step is to create an EKS cluster. First, verify that you have the AWS CLI, kubectl, and eksctl installed and properly configured on your terminal.

To create an EKS cluster, execute the following command in the terminal:

eksctl create cluster - name demo-cluster - region ap-south-1 - nodes 1 - spot

(Note: I opted for a spot instance since I plan to use this cluster for an extended period, which can be more cost-effective.)

After the cluster is created, it's crucial to update your kubeconfig file to ensure you're working with the latest resource configurations:

aws eks update-kubeconfig - name demo-cluster

To enable your pods to securely access AWS services without the need to store long-term credentials, we will configure a service account with appropriate IAM roles.

1. Create an OIDC Provider for Your EKS Cluster(Optional but recommended)

Run the following command to set up an OpenID Connect (OIDC) provider:

eksctl utils associate-iam-oidc-provider - region ap-south-1 - cluster demo-cluster - approve

2. Create an IAM Policy for ECR Access

Creating an IAM policy can be done via the AWS Console. Below is an example policy you can use, which grants the necessary permissions for ECR:

{
 "Version": "2012–10–17",
 "Statement": [
 {
 "Sid": "VisualEditor0",
 "Effect": "Allow",
 "Action": [
 "ecr:DescribeImageScanFindings",
 "ecr:StartImageScan",
 "ecr:GetLifecyclePolicyPreview",
 "ecr:CreateRepository",
 "ecr:PutImageScanningConfiguration",
 "ecr:GetAuthorizationToken",
 "ecr:UpdateRepositoryCreationTemplate",
 "ecr:PutRegistryScanningConfiguration",
 "ecr:ListImages",
 "ecr:GetRegistryScanningConfiguration",
 "ecr:BatchGetImage",
 "ecr:ReplicateImage",
 "ecr:GetLifecyclePolicy"
 ],
 "Resource": "*"
 }
 ]
}

As a best practice, always attach the least privileged policy to enhance security measures.

3. Create the IAM Role with IRSA Binding

To create the IAM service account, execute the following command:

eksctl create iamserviceaccount \
 - name ecr-access-sa \
 - namespace default \
 - cluster demo-cluster \
 - attach-policy-arn arn:aws:iam::[AWS_ACCOUNT_ID]:policy/ECRReadAccess \
 - approve \
 - override-existing-serviceaccounts

Your EKS cluster is now adequately configured and ready for application deployment.

Step 3: Deploy Your Application

In the next section, we will delve into the details of registering our application with the EKS cluster and employing Kubernetes resources to manage and expose our application effectively.
Now, you're ready to deploy your app!

Here is the basic Helm structure of the app:

flask-app/
├── Chart.yaml
├── templates/
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml

Let's write the values.yaml file. This file will store all the configuration values.

replicaCount: 2
image:
 repository: _.dkr.ecr.ap-south-1.amazonaws.com/demo
 tag: latest
 pullPolicy: IfNotPresent
service:
 type: LoadBalancer
 port: 80
 targetPort: 5000

We are mapping the external port 80 to app`s internal port 5000 and exposing using thee LoadBalancer. Make sure to replace the repository.

Chart.yaml

apiVersion: v2 name: flask-app version: 0.1.0

Deployment.yaml

Here's your main deployment file which manages the replica set and the desired pods are running:

apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Chart.Name }} spec: serviceAccountName: ecr-access-sa replicas: {{ .Values.replicaCount }} selector: matchLabels: app: {{ .Chart.Name }} template: metadata: labels: app: {{ .Chart.Name }} spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" ports: - containerPort: {{ .Values.service.targetPort }}

It uses the values from the values.yaml.

Service.yaml

apiVersion: v1 kind: Service metadata: name: {{ .Chart.Name }} spec: type: {{ .Values.service.type }} selector: app: {{ .Chart.Name }} ports: - name: http protocol: TCP port: 80 targetPort: 5000

We are exposing the application on port 80 using a LoadBalancer.
Now we are done with the Helm configuration. To deploy our app using Helm, use the following command:

helm upgrade - install flask-app ./Zero-to-Production - namespace default

To access your application, run:

kubectl get svc flask-app

Then copy the external IP and paste it into your browser. And that`s it, you did it!

Additional Information

You can use horizontal pod autoscaling (hpa) to scale the app in case of increased traffic, or you can simply use the kubectl scale command to scale the application. you can check the github repo for the scaling the pods.

That`s it for this now! I'm happy you made it to the end - thank you so much for your support. If you have any queries or opinions, you can connect with me on x.