DEV Community: sanjay yadav

How Much Do You Trust the Dependencies Your Applications Install?

sanjay yadav — Wed, 05 Aug 2026 03:44:20 +0000

Software supply chain security has become one of the biggest concerns in modern application development.

Most of us run commands like pip install, npm install, or go get without thinking twice. We trust package registries, open-source maintainers, and our existing workflows because that's how software gets built every day.

But recent supply chain incidents have shown that a single compromised dependency can become an entry point into CI/CD pipelines, cloud environments, and Kubernetes clusters.

It made me think about how different teams are approaching dependency security today.

Do you scan dependencies before they reach production?
Are you generating SBOMs or verifying package integrity as part of your build process?
Has your team changed its software supply chain practices after the recent attacks?

I came across a technical breakdown of the recent LiteLLM supply chain incident. It explains how the compromise happened, how it could affect containerized and Kubernetes-based environments, and the practical steps teams can take to reduce similar risks.

https://www.kubeblogs.com/your-pip-install-backdoored-kubernetes-cluster/

I'd be interested to hear how your team approaches dependency management and software supply chain security. Have recent incidents changed the way you build, scan, or deploy applications?

Is the Cheapest Cloud Instance Really the Cheapest?

sanjay yadav — Tue, 04 Aug 2026 01:18:20 +0000

When comparing cloud providers, it's easy to focus on the monthly cost of an instance.

But that's rarely the full picture.

Storage performance, IOPS, throughput, and the overall infrastructure design can have just as much impact on performance and long-term costs as the instance itself.

I'm curious how other teams approach this.

Do you benchmark infrastructure before choosing a cloud provider?
Has a benchmark ever changed your decision?
How much weight do you give to storage performance compared to instance pricing?

While looking into this topic, I found a benchmark comparing AWS and Civo using the same workload. It looks at CPU performance, storage performance, and overall cost instead of relying on feature comparisons.

https://www.kubeblogs.com/aws-charges-extra-for-storage-performance-that-civo-ships-by-default/

I'd be interested to hear how your team evaluates cloud infrastructure before committing to a platform.

Race Conditions Don't Show Up Until Your App Has Real Users

sanjay yadav — Thu, 09 Jul 2026 04:13:08 +0000

Race conditions are one of those bugs that can make you question everything.

The application works during development. Testing passes. Even staging looks fine.

Then production traffic arrives.

Two requests update the same record at almost the same time.

One change silently overwrites another.

A transaction gets stuck waiting on a lock.

Now you're chasing a bug that only appears under very specific conditions.

The frustrating part is that these issues aren't easy to reproduce. They only show up when multiple requests interact with the same data at just the wrong moment.

My first instinct is usually to look for a bug in the application code. More often than not, the real problem is how concurrent requests interact with the database.

Understanding transactions, row-level locking, and when to use tools like transaction.atomic() or select_for_update() can make a huge difference once your application starts handling real traffic.

I came across this article while reading about concurrency issues in Django. It explains race conditions and deadlocks with practical examples and walks through a few approaches to avoid them.

https://www.kubeblogs.com/avoid-race-conditions-and-deadlocks-in-django-step-by-step-guide/

I Used to Think Database Search Was Good Enough Until Our Project Started Growing

sanjay yadav — Mon, 06 Jul 2026 05:25:15 +0000

I don't think many developers spend much time thinking about search when a project is new. I know I didn't.

At the beginning, a simple database query usually does the job. There isn't much content, searches are fast, and nobody complains.

That changes over time.

As more pages, blog posts, or products get added, people expect search to be fast, forgiving, and accurate. They don't care how it's implemented—they just expect to find what they're looking for in a few seconds.

That's when I realized that adding a search box isn't the same as building a good search experience.

Features like typo tolerance, relevance ranking, autocomplete, and fast indexing suddenly become much more important than they seemed on day one.

I came across this article while looking into better search options for Django projects. It walks through integrating Algolia with Django and explains why dedicated search starts making sense once your application outgrows basic database queries.

https://www.kubeblogs.com/add-blazing-fast-search-algolia/

Container Debugging Gets Much Harder Once SSH Stops Being an Option

sanjay yadav — Mon, 08 Jun 2026 04:55:46 +0000

Introduction

Is it even possible to exec into a running container in ECS? It definitely is - but it’s not straightforward to setup.

ECS Exec lets you connect to your containers on demand using the AWS CLI, giving you a way to inspect, debug, and fix issues inside your running services—without exposing them to external access.

In this guide, we’ll walk through setting up ECS Exec, checking configurations, handling common issues, and automating the whole process using Terraform. Whether you're troubleshooting a failed task or looking to simplify access for future deployments, this will help you get there.

Prerequisites

Install Required Tools

AWS CLI

aws --version
The AWS CLI version should be 2.1.33 or later.

Session Manager Plugin

(Required for ECS Exec)

session-manager-plugin --version
If it is not installed, download it from AWS Documentation.

IAM Permissions

The ECS Task Execution Role must have these permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession",
                "ssm:DescribeSessions",
                "ssm:TerminateSession",
                "ecs:ExecuteCommand",
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        }
    ]
}

Checking if ECS Exec is Enabled for a Service

Run the following command to check if ECS Exec is enabled:

aws ecs describe-services \
  --cluster <your-cluster> \
  --services <your-service> \
  --query 'services[*].enableExecuteCommand' \
  --region <your-region>

If the output is true, ECS Exec is enabled. If false, it must be enabled as shown below.

Checking ECS Exec via AWS Console

You can also check this in the AWS Console:

Open the Amazon ECS Console.
Navigate to Clusters and select your cluster.
Click on the Services tab and select your service.
Under the Networking section, look for the ECS Exec status.
If ECS Exec is not enabled, follow the next steps to enable it.

If ECS Exec is not enabled, follow the next steps to enable it.

Step-by-Step: Enabling and Using ECS Exec in AWS Fargate

Step 1: Enable ECS Exec for the Service

Run the following command to enable ECS Exec on your ECS service:

aws ecs update-service \
  --cluster <your-cluster> \
  --service <your-service> \
  --enable-execute-command \
  --region <your-region>

Step 2: Verify ECS Exec is Enabled at the Service Level

After running the command, check if ECS Exec is enabled by running:
Go to your service check networking you can see ecs exec service level as well

aws ecs describe-services \
  --cluster <your-cluster> \
  --services <your-service> \
  --query 'services[*].enableExecuteCommand' \
  --region <your-region>

If the output is true, ECS Exec is enabled at the service level.

Alternative: Check in the AWS Console (UI)

Open the Amazon ECS Console.
Go to Clusters and select your cluster.
Click on the Services tab and select your service.
Under Networking, look for the ECS Exec status.

Step 3: Verify ECS Exec at the Task Level

Now, check if ECS Exec is enabled at the task level:

Open the Amazon ECS Console.
Go to Clusters and select your cluster.
Click on the Tasks tab and choose a running task.
Look for the Execute Command option to confirm ECS Exec is enabled.

Alternatively, use the AWS CLI:

aws ecs describe-tasks \
  --cluster <your-cluster> \
  --tasks <your-task-id> \
  --query 'tasks[].enableExecuteCommand' \
  --region <your-region>

Step 4: Verify if the ECS Exec Agent is Running

To confirm that the ECS Exec agent is running inside the task, run:

aws ecs describe-tasks \
  --cluster <your-cluster> \
  --tasks <your-task-id> \
  --query 'tasks[].containers[].managedAgents'

If the agent is running, you will see an output like:

[
    {
        "name": "ExecuteCommandAgent",
        "status": "RUNNING"
    }
]

If it is not running, restart the ECS task to apply changes:


aws ecs update-service \
  --cluster <your-cluster> \
  --service <your-service> \
  --desired-count 1 \
  --region <your-region>

Step 5: Access the Container Using ECS Exec

Once ECS Exec is enabled and the agent is running, you can connect to the container using:

aws ecs execute-command \
  --cluster <your-cluster> \
  --task <your-task-id> \
  --container <your-container-name> \
  --command "/bin/sh" \
  --interactive \
  --region <your-region>

If everything is set up correctly, you should now have access to the container.

If ECS Exec is still not working, use the Amazon ECS Exec Checker tool to diagnose the issue.

Step 6: Troubleshooting ECS Exec Issues

Clone the ECS Exec Checker Repository

git clone https://github.com/aws-containers/amazon-ecs-exec-checker.git
cd amazon-ecs-exec-checker

Run the ECS Exec Checker Script

chmod +x check-ecs-exec.sh
./check-ecs-exec.sh <your-cluster> <your-task-arn>

Example:

./check-ecs-exec.sh architect-ecs-qa arn:aws:ecs:us-east-1:98700009786565:task/architect-ecs-qa/9f309986767jhhjghcgcjgjhb424ae

This script checks IAM permissions, ECS service configurations, and required dependencies. If any issue is found, the output will indicate what needs to be fixed.

From the screenshot, we can clearly see that the missing permissions are causing the issue.

The ECS task role (architect-miniapps-ecs-qa) does not have the required permissions for ssmmessages, specifically:

ssmmessages:CreateControlChannel
ssmmessages:CreateDataChannel
ssmmessages:OpenControlChannel
ssmmessages:OpenDataChannel

These permissions are currently implicitly denied, which means the ECS task is unable to establish a session using AWS Systems Manager (SSM).

Additionally, since this task is running in a private subnet, it requires a VPC endpoint for SSM Messages (ssmmessages) to communicate with AWS services. However, as seen in the output, the required com.amazonaws.us-east-1.ssmmessages VPC endpoint is missing.

To fix this:

Attach the necessary permissions to the ECS task role.

Add the missing VPC endpoint (com.amazonaws.us-east-1.ssmmessages) in the AWS VPC settings.

3. Update Security Group Rules for VPC Endpoints

The security group attached to the VPC endpoints must allow HTTPS (port 443) inbound from the ECS tasks' security group and all outbound traffic to the ECS tasks' security group.

Step 8: Automate Everything with Terraform

If you want to skip all the manual steps and set everything up in one go, you can use our Terraform configuration. It includes all the necessary IAM permissions, VPC endpoints, and ECS Exec-enabled services.

Here’s a demo terraform code that runs a service in a private subnet, and the required endpoints are added automatically. With this Terraform setup, you can apply the same configuration for all your future services without repeating these steps. If you already have a VPC in place you can easily understand what changes you might have to make in your own infra manually.

provider "aws" {
  region = "us-east-1"
}

terraform {
  required_version = "~> 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

data "aws_availability_zones" "available" {}

locals {
  region = "us-east-1"
  name   = "kubenine-${basename(path.cwd)}"

  vpc_cidr = "10.0.0.0/16"
  azs      = slice(data.aws_availability_zones.available.names, 0, 3)

  container_name = "kubenine-container"
  container_port = 80

  vpc_cidr_block = var.vpc_id != "" ? data.aws_vpc.vpc.cidr_block : module.vpc[0].vpc_cidr_block
  tags = {
    Repository = "https://github.com/terraform-aws-modules/terraform-aws-ecs"
  }
}

# Create a VPC with public and private subnets 
# Private subnets do not have any internet access since NAT gateway is disabled
module "vpc" {
  count   = var.vpc_id == "" ? 1 : 0
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = local.name
  cidr = local.vpc_cidr

  azs             = local.azs
  private_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 4, k)]
  public_subnets  = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 48)]

  public_subnet_tags = { "Tier" = "Public" }
  private_subnet_tags = { "Tier" = "Private" }
  private_route_table_tags = { "Tier" = "Private-route" }
  public_route_table_tags = { "Tier" = "Public-route" }

  enable_nat_gateway = false
  single_nat_gateway = false
  enable_dns_hostnames = true
  tags = local.tags

}


data "aws_vpc" "vpc" {
  # If the VPC ID is not provided, a new VPC will be created
  id = var.vpc_id != "" ? var.vpc_id : module.vpc[0].vpc_id
}

# Get private subnets in the vpc 
data "aws_subnets" "private" {
  # Add a filter to get only private subnets
  filter {
    name   = "tag:Tier"
    values = ["Private"]
  }

  # Add a filter to get only subnets in the VPC
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.vpc.id]
  }

  depends_on = [ module.vpc ]
}

data "aws_subnets" "public" {

  filter {
    name   = "tag:Tier"
    values = ["Public"]
  }

  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.vpc.id]
  }
}


data "aws_route_tables" "private" {
  vpc_id = data.aws_vpc.vpc.id

  filter {
    name   = "tag:Tier"
    values = ["Private-route"]
  }

  depends_on = [ module.vpc ]

}

output "private_route_tables" {
  value = data.aws_route_tables.private
}



module "ecs" {
  source       = "terraform-aws-modules/ecs/aws"
  cluster_name = "kubeops-ecs"
  cluster_configuration = {
    execute_command_configuration = {
      logging = "OVERRIDE"
      log_configuration = {
        cloud_watch_log_group_name = "/aws/ecs/aws-ec2"
      }
    }
  }

  fargate_capacity_providers = {
    FARGATE = {
      # The default_capacity_provider_strategy is used to determine how tasks are placed
      default_capacity_provider_strategy = {
        weight = 50
      }
    }

    # spot capacity provider is used to run tasks on Spot Instances
    FARGATE_SPOT = {
      default_capacity_provider_strategy = {
        weight = 50
      }
    }
  }
}


module "ecs_service" {
  source                 = "terraform-aws-modules/ecs/aws//modules/service"
  name                   = local.name
  cluster_arn            = module.ecs.cluster_arn
  cpu                    = 512
  memory                 = 1024
  enable_execute_command = true
  desired_count          = 1

  container_definitions = {
    (local.container_name) = {
      cpu       = 512
      memory    = 1024
      essential = true
      readonly_root_filesystem = false
      image     = "905418054480.dkr.ecr.us-east-1.amazonaws.com/dummy-log-generator"
      port_mappings = [
        {
          name          = local.container_name
          containerPort = local.container_port
          hostPort      = local.container_port
          protocol      = "tcp"
        }
      ]
    }
  }

  task_exec_iam_statements= [
        {
          actions   = [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel",
                "ecs:ExecuteCommand",
                "ssm:StartSession",
                "ssm:GetConnectionStatus",
                "ssm:DescribeSessions",
                "logs:DescribeLogGroups",
                "logs:CreateLogStream",
                "logs:DescribeLogStreams",
                "logs:PutLogEvents"

          ]
          resources = ["*"]
        }
      ]

  tasks_iam_role_statements = [
        {
          actions   = [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel",
                "ecs:ExecuteCommand",
                "ssm:StartSession",
                "ssm:GetConnectionStatus",
                "ssm:DescribeSessions",
                "logs:DescribeLogGroups",
                "logs:CreateLogStream",
                "logs:DescribeLogStreams",
                "logs:PutLogEvents"

          ]
          resources = ["*"]
        }
      ]

  subnet_ids = data.aws_subnets.private.ids


  service_tags = {
    "ServiceTag" = "Tag on service level"

  }

  tags = local.tags

}

# VPC Endpoints are needed because the the private subnet doesn't have internet connectivity
module "vpc_endpoints" {
  source = "terraform-aws-modules/vpc/aws//modules/vpc-endpoints"

  vpc_id = data.aws_vpc.vpc.id

  create_security_group      = true
  security_group_name_prefix = "${local.name}-vpc-endpoints-"
  security_group_description = "VPC endpoint security group"
  security_group_rules = {
    ingress_https = {
      description = "HTTPS from VPC"
      cidr_blocks = [data.aws_vpc.vpc.cidr_block]
    }
    egress_all ={
      description = "all traffic"
      cidr_blocks = [data.aws_vpc.vpc.cidr_block]
    }

  }

  endpoints = {
    s3 = {
      service             = "s3"
      service_type        = "Gateway"
      route_table_ids     = data.aws_route_tables.private.ids
      policy              = data.aws_iam_policy_document.generic_endpoint_policy.json
       tags = { Name = "s3-api-vpc-endpoint" }
    },
    ecs_telemetry = {
      service             = "ecs-telemetry"
      private_dns_enabled = true
      subnet_ids          = data.aws_subnets.private.ids
      policy              = data.aws_iam_policy_document.generic_endpoint_policy.json
      tags = { Name = "ecs-telemetry-vpc-endpoint" }
    },
    ecr_api = {
      service             = "ecr.api"
      private_dns_enabled = true
      subnet_ids          = data.aws_subnets.private.ids
      policy              = data.aws_iam_policy_document.generic_endpoint_policy.json
      tags = { Name = "ecr-api-vpc-endpoint" }
    },
    ecr_dkr = {
      service             = "ecr.dkr"
      private_dns_enabled = true
      subnet_ids          = data.aws_subnets.private.ids
      policy              = data.aws_iam_policy_document.generic_endpoint_policy.json
      tags = { Name = "ecr-dkr-vpc-endpoint" }
    },
    logs = {
      service             = "logs"
      private_dns_enabled = true
      subnet_ids          = data.aws_subnets.private.ids
      policy              = data.aws_iam_policy_document.generic_endpoint_policy.json
      tags = { Name = "logs-vpc-endpoint" }
    },
    ssmmessages={
      service             = "ssmmessages"
      private_dns_enabled = true
      subnet_ids          = data.aws_subnets.private.ids
      policy              = data.aws_iam_policy_document.generic_endpoint_policy.json
      tags = { Name = "ssmmessages-vpc-endpoint" }
    }

  }

  tags = merge(local.tags, {
    Project  = "Secret"
    Endpoint = "true"
  })
}

data "aws_iam_policy_document" "generic_endpoint_policy" {
  statement {
    effect    = "Allow"
    actions   = ["*"]
    resources = ["*"]

    principals {
      type        = "*"
      identifiers = ["*"]
    }

  }
}

Add to the "Common Issues and Fixes" Table

At the end of the troubleshooting steps, add a small reminder:

If ECS Exec is still not working,
An error occurred (InvalidParameterException) when calling the ExecuteCommand operation: The execute command failed because execute command was not enabled when the task was run or the execute command agent isn’t running.
check your ECS task definition. By default, readonlyRootFilesystem is set to true, which prevents write operations inside the container.
To fix this, update your task definition and change:
"readonlyRootFilesystem": true
to:

"readonlyRootFilesystem": false

Then redeploy the task and retry ECS Exec.

Conclusion
By setting up the necessary IAM permissions, VPC endpoints, and security group rules, ECS Exec can work without issues.

If you run into any errors, check the Common Issues and Fixes section for quick solutions. With this setup, you can easily access and debug your ECS containers!

Time Zones Usually Don't Become a Problem Until Your Application Goes Global

sanjay yadav — Wed, 03 Jun 2026 05:09:21 +0000

Managing user time zones is a critical challenge in modern web applications and Django development. When your Django application serves users across different time zones globally, displaying dates and times in their local time zone becomes essential for optimal user experience and application usability. This comprehensive guide shows you practical methods to detect, handle, and implement client timezone management in Django applications, covering timezone detection, conversion, and best practices for international web development.

Why Time Zone Detection Matters

Users expect to see dates and times in their local timezone. Without proper time zone handling, a user in Tokyo might see meeting times in UTC, causing confusion and missed appointments. Django provides robust timezone support, but detecting the client's timezone requires combining frontend detection with backend implementation.

Common Time Zone Challenges

Data Inconsistency: Storing timestamps without timezone information leads to ambiguous data. A timestamp of "2024-01-15 14:30:00" could be interpreted differently depending on the user's location.

User Experience Issues: Displaying times in UTC or server timezone creates friction. Users must mentally convert times, leading to missed deadlines and poor user experience.

Business Logic Errors: Scheduling applications, booking systems, and time-sensitive operations fail when timezone handling is incorrect. A meeting scheduled for 2 PM EST might appear as 7 PM UTC to a European user.
**
Compliance Requirements: **Many industries require accurate time zone handling for audit trails, financial transactions, and regulatory compliance.

Step-by-Step Implementation

Method 1: JavaScript Detection with Session Storage

The most reliable approach combines JavaScript's built-in timezone detection with Django's session framework. This method works across all browsers and doesn't require external services.

Frontend Implementation

Add this JavaScript to your base template:

<script>
const timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
fetch('/set-timezone/', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-CSRFToken': document.querySelector('[name=csrfmiddlewaretoken]').value,
    },
    body: JSON.stringify({'timezone': timezone})
});
</script>

Backend View Implementation

import json
import pytz
from django.http import JsonResponse

def set_timezone(request):
    try:
        data = json.loads(request.body)
        user_timezone = data.get('timezone')
        pytz.timezone(user_timezone)  # Validate
        request.session['timezone'] = user_timezone
        return JsonResponse({'status': 'success'})
    except:
        return JsonResponse({'status': 'error'})

**Key Benefits: **This method provides 99% accuracy since it uses the browser's native timezone detection. The Intl API is supported in all modern browsers and returns the exact timezone configured on the user's system.

Method 2: Timezone Middleware

Middleware automatically activates the user's timezone for every request, eliminating the need to manually handle timezone activation in each view.

# middleware.py
import pytz
from django.utils import timezone

class TimezoneMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        user_timezone = request.session.get('timezone')
        if user_timezone:
            try:
                timezone.activate(pytz.timezone(user_timezone))
            except pytz.UnknownTimeZoneError:
                timezone.deactivate()
        else:
            timezone.deactivate()

        response = self.get_response(request)
        timezone.deactivate()
        return response

Performance Impact: Middleware adds minimal overhead (~1-2 ms per request). For high-traffic applications, consider caching timezone objects or using a more efficient timezone library like zoneinfo (Python 3.9+).

Method 3: User Profile Integration

For authenticated users, store timezone preferences in their profile for persistence across sessions.

# models.py
class UserProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    timezone = models.CharField(max_length=50, default='UTC')

    def __str__(self):
        return f"{self.user.username} - {self.timezone}"

Database Considerations:Store timezone as a string rather than a foreign key. This approach is more flexible and doesn't require maintaining a separate timezone table. The pytz.common_timezones list contains 435 time zones, which is manageable for validation.

**Migration Strategy: **For existing applications, create a data migration to populate timezone fields based on user location or default to UTC.

Method 4: Template Context Processor

Make timezone information available in all templates without passing it explicitly from views.

# context_processors.py
def timezone_context(request):
    user_timezone = 'UTC'
    if request.user.is_authenticated:
        try:
            user_timezone = request.user.userprofile.timezone
        except:
            user_timezone = request.session.get('timezone', 'UTC')

    return {'user_timezone': user_timezone}

Template Usage: Access timezone information in any template using {{ user_timezone }}. This eliminates the need to pass timezone data from every view.

Caching Strategy: Consider caching timezone objects in Redis or Memcached for high-traffic applications to reduce database queries.

Implementation Flow

Advanced Implementation Strategies

Database Storage Best Practices

**
Always Store in UTC:** Store all timestamps in UTC in your database. Convert to user timezone only for display purposes. This prevents data corruption and makes your application timezone-agnostic.

# Good: Store in UTC
created_at = timezone.now()  # Always UTC

# Bad: Store in local timezone
created_at = datetime.now()  # Ambiguous timezone

Timezone-Aware Models:Use Django's timezone-aware datetime fields:

class Event(models.Model):
    name = models.CharField(max_length=100)
    start_time = models.DateTimeField()  # Timezone-aware
    end_time = models.DateTimeField()    # Timezone-aware

Performance Optimization

Timezone Object Caching: Cache timezone objects to avoid repeated

pytz. timezone() calls:
from django.core.cache import cache

def get_timezone_object(tz_string):
    cache_key = f"timezone_{tz_string}"
    tz_obj = cache.get(cache_key)
    if not tz_obj:
        tz_obj = pytz.timezone(tz_string)
        cache.set(cache_key, tz_obj, 3600)  # Cache for 1 hour
    return tz_obj

**Database Query Optimization: **Use select_related() when fetching user profiles with timezone information:
users = User.objects.select_related('userprofile').filter(is_active=True)

Security Considerations

Input Validation: Always validate timezone strings to prevent injection attacks.

ALLOWED_TIMEZONES = set(pytz.common_timezones)

def validate_timezone(tz_string):
    return tz_string in ALLOWED_TIMEZONES

Privacy Compliance: Time Timezone detection reveals approximate user location. Implement proper consent mechanisms and consider GDPR/privacy implications.

Testing Strategies

**Timezone Testing: **Test your application across different timezones.

from django.test import TestCase
from django.utils import timezone
import pytz

class TimezoneTestCase(TestCase):
    def test_timezone_conversion(self):
        # Test with different timezones
        test_timezones = ['UTC', 'America/New_York', 'Asia/Tokyo', 'Europe/London']

        for tz in test_timezones:
            with timezone.override(pytz.timezone(tz)):
                # Your timezone-dependent tests here
                pass

Mock Timezone Detection: Mock JavaScript timezone detection in tests:

def mock_timezone_detection():
    return 'America/New_York'

Alternative: GeoIP Detection

For applications where JavaScript isn't available, you can use GeoIP detection, though it's less accurate:

def get_timezone_from_ip(request):
    try:
        g = GeoIP2()
        ip = request.META.get('REMOTE_ADDR')
        if ip:
            country = g.country(ip)
            timezone_map = {
                'US': 'America/New_York', 'GB': 'Europe/London',
                'IN': 'Asia/Kolkata', 'AU': 'Australia/Sydney',
                'JP': 'Asia/Tokyo'
            }
            return timezone_map.get(country['country_code'], 'UTC')
    except:
        pass
    return 'UTC'

Accuracy Limitations: GeoIP detection is only 60-70% accurate for timezone detection. Countries like the US and Russia span multiple time zones, making this method unreliable for precise time zone detection.

Common Pitfalls and Solutions

Pitfall 1: Daylight Saving Time Issues

Problem: DST transitions can cause timezone conversion errors.

**Solution: **Always use timezone-aware datetime objects and let Django handle DST automatically:

# Good: Django handles DST automatically
user_time = timezone.now().astimezone(user_timezone)

# Bad: Manual DST handling (error-prone)
user_time = naive_datetime + timedelta(hours=offset)

Pitfall 2: Session Timeout Issues

Problem: Time Timezone information is lost when sessions expire.

**Solution: **Implement a fallback mechanism that re-detects timezone on session loss:

def get_user_timezone(request):
    # Try session first
    tz = request.session.get('timezone')
    if not tz:
        # Fallback to GeoIP or default
        tz = get_timezone_from_ip(request) or 'UTC'
        request.session['timezone'] = tz
    return tz

Pitfall 3: Mobile App Considerations

Problem: Mobile apps may not have access to browser timezone detection.

Solution: Use device-specific timezone detection APIs:

# For React Native
import { NativeModules } from 'react-native';
const timezone = NativeModules.RNDeviceInfo.getTimezone();

# For Flutter
import 'package:timezone/timezone.dart' as tz;
final timezone = tz.local.name;

Conclusion
The JavaScript detection method combined with Django middleware provides the most reliable timezone handling. It directly queries the user's system timezone and integrates seamlessly with Django's timezone framework.

Start with the JavaScript + session approach for immediate results. Add user profile storage for authenticated users, and implement middleware for automatic timezone activation across your application.

This approach ensures your users see dates and times in their local time zone while maintaining clean, maintainable code that follows Django best practices.

How to Create a Custom Healthy Backend Count Metric in GCP

GCP Permissions and Scopes for Compute Engine VMs Explained
How to Securely Expose Your Applications Using Cloudflare Tunnel

Most Prometheus Problems Start Long Before Dashboards Break

sanjay yadav — Tue, 02 Jun 2026 04:51:20 +0000

Prometheus is an incredibly powerful tool for monitoring your systems. Its flexible data model and expressive query language, PromQL, make it one of the most popular choices in the observability world.

But — that flexibility comes at a cost.

When you're just starting out with Prometheus, it's easy to fall into certain traps that can cause performance issues, data overload, or alerts that don’t do what you expect. These issues can be subtle, and they often don't show up until you're deep into building your dashboards or alert rules.

In this post, I’ll walk you through six of the most common mistakes developers make with Prometheus, explain why they’re problematic, and show you exactly how to avoid them.

Let’s start with a classic one

Mistake 1: Cardinality Bombs

One of the most common and painful mistakes people make when starting out with Prometheus is accidentally creating what's known as a cardinality bomb. This happens when a metric is broken down by too many unique label values, which causes an explosion in the number of time series Prometheus needs to track.

In Prometheus, a time series is defined by the combination of a metric name and its label values. Each unique combination creates a new time series, which Prometheus has to store, index, and process. This is normally a great feature—it lets you filter and aggregate your metrics in powerful ways. But it becomes a problem when you start using labels that take on a large or even unbounded set of values.

Let’s look at an example. Say you're counting HTTP requests in your service using this metric:

http_requests_total
This gives you a single time series. Now you decide to split this metric by the HTTP method, like GET or POST:
http_requests_total{method="GET"} http_requests_total{method="POST"}
This creates two time series, one for each method. Still totally manageable.

Then you decide to also track which user sent each request. You add the user_id label:

http_requests_total{method="GET", user_id="123456"}
This is where the problem starts. Now, every single unique user_id value creates a separate time series. If you have 1,000 users, that's 1,000 new time series. If you have a million users, Prometheus now needs to store and track a million individual time series for just this one metric.

And remember: this doesn’t scale linearly. Each additional label multiplies the number of possible combinations, and suddenly you’re hitting Prometheus' limits or exhausting your server’s memory.

This kind of explosion in time series count is one of the most common reasons Prometheus servers become unstable, slow, or completely unresponsive. It leads to high memory usage, long query times, and brittle alerting.

The key to avoiding this issue is to be intentional about which labels you use. Avoid labels with high cardinality—meaning labels that can have a large number of unique values. These often include things like user_id, email, UUID, full_url, or anything dynamic or user-generated.

Instead, use labels with a small, well-defined set of values. Good examples are method, status_code, region, or job. These labels typically don’t grow unbounded over time and are much safer to use.

Here’s a quick comparison:

Bad (high-cardinality):

sum(rate(http_requests_total[1m])) by (user_id)
Good (low-cardinality):

sum(rate(http_requests_total[1m])) by (method, status)
By avoiding high-cardinality labels and being mindful of how many unique combinations you're generating, you can prevent runaway time series growth and keep your Prometheus setup healthy and fast.

Mistake 2: Aggregating Away Too Many Labels

In Prometheus, aggregating metrics is a common and powerful technique — especially when writing alerts or building dashboards. But it’s easy to accidentally drop important labels during aggregation, and that can make your alerts harder to manage and understand.

Let’s say you’re tracking error rates across multiple services using this metric:

http_requests_total{status="500"}
To create an overall error rate, you might write something like this:

sum(rate(http_requests_total{status="500"}[5m]))
This works — it gives you the total error rate. But there’s a catch: when you use plain sum(), you lose all the labels from the underlying time series. That includes labels like job, service, or instance — things that can help you trace the source of the problem.

Now imagine that alert fires. Without preserved labels, you won't know where the errors are coming from. You’ll see a number, but no context.

That’s why it's important to use the by() modifier with your aggregations — to keep specific labels you want to preserve. For example:

sum by(job)(rate(http_requests_total{status="500"}[5m]))
Now your result still gives you error rates, but broken down by job. You get both the number and the context — making your alerts actionable.

If you want to drop all labels except specific ones, you can also use without(), but the idea is the same: don’t accidentally throw away useful information when you aggregate.

Label preservation becomes even more critical in alerts, because tools like Alertmanager rely on labels for routing, grouping, silencing, and notifications. Losing them early in the pipeline means less flexibility and control later on.

In short: sum() without by() can silently remove valuable signal from your data. Always be intentional about what you keep — and what you drop.

Mistake 3: Unscoped Metric Selectors

One of the lesser-known but sneaky issues in Prometheus is using unscoped metric selectors. When you're writing a PromQL query, it's tempting to just write something like:

http_requests_total

This seems fine at first — you're pulling all data for that metric. But here's the problem: in larger environments, multiple services might expose the same metric name. And they might not even mean the same thing.

You could be unintentionally selecting data from several completely unrelated jobs or services — even ones you didn’t intend to include. Worse, a new service might start exposing a conflicting metric in the future, and your alerting rules or dashboards will suddenly break or behave strangely.

Let’s say you’re building a dashboard for your frontend service, and you’re calculating the error rate like this:

rate(http_requests_total{status=~"5.."}[5m])If you didn’t filter this by job or service name, you might be seeing error rates from backend, frontend, auth, or anything else using the same metric — even if they’re unrelated.

To prevent this, always scope your queries to the specific job or service you care about. Like this:

rate(http_requests_total{job="frontend", status=~"5.."}[5m])Now you're only selecting metrics coming from your frontend job, and you’re protected from conflicts in the future.

It’s a small habit that makes your queries and alerts more reliable and easier to understand — especially as your Prometheus setup grows.

Mistake 4: Missing "for" Durations in Alerting Rules

When writing alerting rules in Prometheus, it’s common to forget or skip the for duration — the field that defines how long a condition must be true before an alert actually fires. But this small detail plays a big role in the reliability of your alerts.

Let’s take a simple example:

You want to alert when a target goes down, so you write:

alert: InstanceDown expr: up == 0
At first, this seems fine. But without a for: duration, the alert will fire immediately — even if the failure was just a temporary blip. A single scrape failure or a momentary network issue could trigger alerts that aren’t actionable.

That’s where the for: field comes in. It adds tolerance for short-lived issues.

For example:

alert: InstanceDown expr: up == 0 for: 2m
Now Prometheus will only fire the alert if the instance has been down for two full minutes. This makes alerts more meaningful and reduces noise.

Even if your query already includes a time-averaged function like rate() or avg_over_time(), it’s still important to include a for: duration. Why? Because when the Prometheus server starts up or loses data, there may not be enough data points to truly represent that time window — and you might still get false positives.

Adding a for: value makes your alerting system more robust, but you should still find a balance. Too short, and you get noise. Too long, and you might miss important signals.

In general, use a for duration of at least 1–5 minutes for most alerting conditions, unless there's a strong reason to alert immediately.

Mistake 5: Using Too Short Rate Windows

In Prometheus, functions like rate(), irate(), and increase() are commonly used to calculate how fast counters are increasing. But they all require a window of data — and if that window is too small, you can run into problems.

Let’s say your Prometheus server scrapes metrics every 15 seconds. Now imagine writing a query like this:

rate(http_requests_total[20s])
That seems fine on the surface — you're asking for a rate over the past 20 seconds. But because your scrape interval is 15 seconds, there might only be one data point in that 20-second window. And rate() needs at least two points to work. If there aren't two, the function returns nothing at all.

The result? Gaps in your graphs. Inconsistent alert behavior. Empty dashboards.

This gets even worse if a scrape fails or arrives late. Now your 20-second window might contain zero points, and rate() just disappears entirely from the output.

The fix is simple: choose a window that's wide enough to reliably include at least two data points — even with occasional failures.

A good rule of thumb: set your rate window to at least 4–5x your scrape interval.

If you scrape every 15 seconds, use a window of at least 1 minute:

rate(http_requests_total[1m])This adds consistent output and makes your graphs and alerts more reliable.

Mistake 6: Using Functions With Incorrect Metric Types

PromQL has a variety of functions — like rate(), irate(), increase(), deriv(), and predict_linear() — each designed for specific kinds of metrics. The issue comes when you apply one of these functions to the wrong type of metric.

For example, rate() is built for counters — metrics that only increase over time (like total requests). It assumes any drop in value is a counter reset, and it compensates for that. So if you use rate() on a gauge (which can go up and down naturally), it will misinterpret a normal decrease as a reset, and the result will be wrong.

Let’s say you apply rate() to memory usage:

rate(memory_usage_bytes[5m])
If memory usage drops — which is totally normal — rate() will treat that drop as a reset and return an inflated or inaccurate result.

Similarly, deriv() and predict_linear() are meant for gauges. If you apply those to counters, they won't know how to handle resets and will return nonsense or misleading output.

Prometheus won’t stop you from doing this — it doesn’t know the intent of your metric. So you need to be careful and understand what kind of data you're working with.

Quick guideline:

Use rate(), irate(), and increase() with counters
Use deriv(), delta(), and predict_linear() with gauges
Always make sure you understand the metric you're querying — whether it’s a counter or a gauge — before choosing a function.

Conclusion

Prometheus is a powerful tool — but only if you use it wisely. The mistakes covered here are incredibly common, even among experienced teams. By avoiding them, you can build more reliable monitoring systems, write more meaningful alerts, and scale Prometheus confidently.

Let’s recap:

Avoid high-cardinality labels like user_id
Preserve important labels during aggregations
Scope your queries to the right jobs or services
Always use for durations to reduce alert noise
Choose appropriate rate windows based on your scrape interval
Use PromQL functions that match your metric type
Getting these fundamentals right helps your monitoring stay efficient, accurate, and maintainable — especially at scale.

At Kubenine, we help teams set up infrastructure, cloud environments, and production-grade monitoring so that you can focus on building your product — not managing systems and alerts.

Most Teams Don't Move to Amazon RDS for Performance

sanjay yadav — Fri, 29 May 2026 05:19:50 +0000

You’ve decided to move your applications from on-premises to AWS and are looking at the cloud services that best meet your needs. When moving an application with a relational database like Oracle, MySQL, or SQL Server to the cloud, you'll face the choice between Amazon RDS and AWS EC2.

You need to decide whether to:

Use AWS’s Relational Database Service (RDS)
Host a database server on an AWS EC2 (Elastic Compute) instance

What is AWS RDS?

Amazon Relational Database Service (Amazon RDS) is a managed Database-as-a-Service (DBaaS) that helps IT administrators easily set up, run, and scale relational databases in the cloud. RDS supports popular database engines like MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server.

When moving to the cloud, most applications using these databases can switch to Amazon RDS without much hassle. You can choose different database instance types based on your needs for CPU, memory, storage, and networking. With Amazon RDS, Amazon takes care of tasks like provisioning, setup, patching, backup, recovery, and failure repair, saving your team from these time-consuming tasks.

Amazon RDS automatically backs up your databases every 24 hours, ensuring that in the worst case, you can recover data for up to 24 hours. With a multi-region active-active strategy, you can achieve near-zero data loss and minimal recovery time. Routine patching is also automated with set maintenance windows for security. On top of this it also supports PITR recovery so you can get back your database to any particular timestamp in last 7 days.

RDS allows you to have read replicas in zones closer to your users, which increases read capacity and reduces the load on production servers by routing read queries to the replicas. You can also send heavy queries to read replicas to lessen the burden on your main servers.

What is Amazon EC2?

Amazon Elastic Compute Cloud (EC2) is a web service that gives you secure access to server instances when you need them. It's easy to get and set up capacity – just use the Amazon EC2 web service interface to add capacity as needed.

You have full control over your computing resources and can scale up or down based on your needs. To provide database services for your application, you can set up EC2 instances and install the necessary database engines yourself.

Next, let’s look at the pros and cons of choosing between Amazon RDS and EC2 for your database.

Administration

When it comes to administration, Amazon RDS is easy to set up because AWS automates the entire process of management, maintenance, and security, allowing you to focus on essential tasks instead of routine maintenance. You can access its capabilities through the AWS Management Console, AWS RDS command-line interface, or simple REST API calls.

AWS EC2 gives you full control over the OS, database version, configuration, and other software components, but you are responsible for all routine maintenance activities, including patches, upgrades, backups, replication, and clustering.

High Availability

Amazon RDS has built-in high availability. It automatically creates a primary database instance and replicates the data to a standby instance in a different Amazon Availability Zone. This ensures that if there is an outage in one zone, you can recover your database from the other zone.

On the other hand, with AWS EC2, you are responsible for configuring the database server in a highly available cluster.

Backups

With Amazon RDS, you can set up automated backups. AWS CloudWatch can notify you about backup failures, completions, and more. You can also get database snapshots on-demand and keep them as long as you need.

With AWS EC2, you have to enable backups yourself and set up separate monitoring to ensure regular backups. You cannot use AWS CloudWatch for this.

Scalability

Amazon RDS easily integrates with Amazon’s scaling tools for both vertical and horizontal scaling. You can scale up to a larger instance in a few clicks, and you can automate the creation of additional read replicas to handle increased read-only workloads.

With AWS EC2, you have to set up a scalable architecture manually, which includes setting up multiple EC2 instances, load balancing, configuring Availability Groups, and Sharding.

Performance

With Amazon RDS, you can configure your instance with a specific number of provisioned IOPS for fast and consistent performance, though it can be expensive. RDS integrates with Amazon CloudWatch for monitoring database performance.

With AWS EC2, you need to choose the right storage volume for the IOPS and latency you need. Since the database server is not AWS-managed, you cannot use AWS CloudWatch for performance monitoring and need to use third-party tools instead.

Storage

With Amazon RDS, you have three storage options:

General-purpose SSD: Cost-effective, delivers single-digit millisecond latencies, and handles up to 3,000 IOPS.
Provisioned IOPS: Ideal for database-intensive workloads needing low latency and very high IOPS throughput.
Magnetic: Supports magnetic storage for backward compatibility.
With AWS EC2, the IOPS and latency depend on the instance type. You can get up to 16,000 IOPS and 2,000 Mbps with the right EBS-optimized instance.

Support and Control

With Amazon RDS, you are limited to the database engines and versions supported by Amazon. Amazon manages upgrades and patches, so you don't handle the database server directly. You have access to database administration tools for necessary tasks.

With AWS EC2, you can install any database engine and version you want, without being limited by AWS's RDS support. You have full control over the operating system and the database server. You can apply updates and patches, set maintenance windows, run multiple instances on the same EC2 instance, and control the ports used.

Security

Amazon RDS offers encryption both at rest and in transit. This means the storage for database instances, read replicas, automated backups, and snapshots are all encrypted while stored.

In AWS EC2, encryption is handled at the EBS volume level, and you can also configure encryption at the database level.

Licensing

Amazon RDS offers both “License Included” and “Bring-Your-Own-License (BYOL)” models, depending on the database engine.

For example, Oracle RDS allows you to bring your license, but Amazon RDS for SQL Server only supports the “License Included” model. You cannot bring your SQL licenses to RDS, as SQL Server is licensed through AWS.

With AWS EC2, you can bring your database licenses regardless of the database engine.

Cost

Spending depends on the instance type, and you can use the AWS Cost Calculator to get detailed costs.

Amazon RDS:

Usually more expensive because Amazon handles routine management tasks for you.

AWS EC2:

Generally cheaper since you manage the database server yourself.
You are responsible for tasks like backup, recovery, patching, and load management.

How to Choose Between AWS RDS and Amazon EC2

Choosing between a database on an EC2 instance and RDS means deciding between managing everything yourself and using a managed service where AWS handles routine tasks. With RDS, a simple API call gives you control over deployment, backups, snapshots, restores, sizing, high availability, and replicas.

In contrast, using EC2 means you need to manually set up, configure, manage, and tune components like EC2 instances, storage, scalability, networking, and security.

Using RDS reduces management overhead and increases flexibility and automation. You can use automated CI/CD systems with AWS CLI, CDK, and CloudFormation to deploy the database with minimal manual work. Managed services let you control the infrastructure and design services that are easy to deploy, replicate, and have auto-healing features.

However, cost is a key factor. Amazon RDS can be slightly more expensive than EC2 for the same configuration. If you have a tight budget or need a database engine or version not supported by RDS, you might have to use an EC2-hosted database.

At KuebOps Consulting, we highly recommend using RDS instances over EC2 for database to our clients. The additional cost that you pay almost always saves a lot more money than what you would spend on managing and scaling the database yourself on an EC2 instance.

Route 53 DNS Firewall: Block Malware Across Your VPC
Fix 504 Errors in GKE Load Balancer (BackendConfig Guide)
How We Use Airflow to Optimize Our DevOps Workflow

Database Performance Discussions Usually Change Once Infrastructure Costs Start Scaling

sanjay yadav — Thu, 28 May 2026 04:47:03 +0000

At smaller scale, managed databases usually feel interchangeable.

The application works.
Queries run.
Everything seems fine.

But once workloads grow and infrastructure costs start increasing, database discussions become much more operational than people initially expect.

Storage performance.
IOPS limits.
Latency.
Cost scaling.

That’s usually where infrastructure tradeoffs start becoming impossible to ignore.

The pricing usually looks straightforward until higher performance tiers start becoming unavoidable.

In practice, performance discussions usually turn into infrastructure efficiency discussions pretty quickly.

I found this benchmark useful because it compares AWS RDS and Civo Postgres from both the performance and operational cost perspective instead of only comparing monthly cost numbers:

https://www.kubeblogs.com/aws-rds-vs-civo-postgres-benchmark/

Kubernetes Observability Usually Gets More Complicated Before It Gets Better

sanjay yadav — Mon, 25 May 2026 05:08:11 +0000

Logs are easy at the beginning.

Production observability usually isn’t.

One pattern that shows up often in Kubernetes environments is teams adding more monitoring components over time and slowly ending up with more complexity than expected.

More agents.
More pipelines.
More moving parts.

Collecting telemetry is usually not the hard part.

Keeping observability systems manageable as infrastructure grows is where things get difficult.

That’s why tooling discussions usually become much more operational than feature comparisons.

Especially once infrastructure starts growing and operational overhead becomes harder to ignore.

I found this breakdown useful because it compares Fluent Bit and Grafana Alloy from a Kubernetes observability perspective instead of treating it as only a tooling comparison:

https://www.kubeblogs.com/fluent-bit-vs-grafana-alloy-kubernetes-observability-2026/

Terraform with AI: Build AWS Infra (Cursor + MCP)

sanjay yadav — Sat, 23 May 2026 05:21:24 +0000

Why Terraform with AI Matters in Modern DevOps

Writing Terraform for anything beyond a small setup quickly becomes tedious.
Once you start dealing with multiple modules, cross-resource dependencies, and AWS-specific quirks, the workflow slows down. Most of the time isn’t spent writing code — it’s spent checking documentation, fixing edge cases, and rerunning terraform apply.
Many teams are now experimenting with Terraform with AI to speed this up.
In practice, that only works partially — unless the AI has proper context.

Build Complete AWS Infrastructure with Terraform MCP Server and Cursor AI - Full Tutorial

How Terraform workflows traditionally worked

A typical workflow looks like this:
Read Terraform docs
Write modules and resources manually
Run terraform plan
Fix errors
Repeat
For small setups, this is manageable.
For production infrastructure, it becomes repetitive and slow. Most engineers end up switching between Terraform registry docs, AWS docs, and their codebase constantly.

Limitations of Using Terraform with AI Without Context

The obvious idea is to use AI to generate Terraform.
In most cases, it starts like this:

“Generate Terraform for a VPC with public and private subnets”
You do get output. But:

It may use outdated arguments
It ignores your module structure
Dependencies are incomplete
It often fails during terraform apply
👉 The core issue: AI does not understand your infrastructure context

Our First Attempt (RAG Failure) (Late 2024 - before advent of modern agents)

To solve this, we built an internal tool using:

Vector database
RAG (Retrieval-Augmented Generation)
The idea was to fetch Terraform documentation and index it in a vector database and provide it to an agent
It helped slightly — but failed in practice:

Iteration was difficult - terraform plan and apply loop - fix errors
Context size limitations
No awareness of project structure
Could not refine outputs
It generated code, but only for simple infrastructure. For complex ones it used to fail after a few iterations.

We didn't try to optimise it further because while we were in middle of it - cursor agents became extremely powerful and they pretty much solved this iteration problem.

What changed with MCP Server + Cursor

The behavior changed once we introduced Terraform MCP Server and used it with Cursor.
Instead of generating code blindly, the system now had access to:

Terraform module documentation
Input/output structures
Resource relationships
The difference was noticeable.
The output was not perfect — but much closer to something usable.

How MCP actually changes the workflow

At a high level, MCP acts as a bridge between the editor (Cursor) and Terraform context.
Instead of guessing, the AI can:

Look up module definitions
Understand required inputs
Follow dependencies across resources

This is the key difference from standard AI usage.

⚙️ What MCP Server Actually Does Internally

The improvement with MCP is not just better prompting — it’s access to structured Terraform knowledge.
The MCP server exposes tools that allow the AI to query real Terraform data:

Key MCP Capabilities:

Provider Documentation Lookup

Fetches full documentation for resources, data sources, and functions

Module Discovery

Finds Terraform modules from the registry with usage examples

Module Details

Retrieves inputs, outputs, and configuration patterns

Policy Search

Helps identify best practices and security policies
👉 In simple terms:
Instead of guessing, the AI can look things up like an engineer would.

Terraform with AI vs Manual vs MCP (Comparison)

In practice, most teams try AI first, then realize that without context, results are unreliable. MCP fixes that gap.

A practical example: building AWS infrastructure

Let’s take a realistic setup:

VPC with public and private subnets
NAT Gateway and Internet Gateway
Application Load Balancer
Auto Scaling group (EC2)
CloudFront distribution
Cloudflare DNS
Jump box for access
This is a typical production-style setup.
Writing this manually takes time — especially when wiring dependencies correctly.

How we approached it

Instead of writing everything manually, we broke the problem into smaller steps and guided the AI.

🧠 Full Prompt Used for Infrastructure Generation

Instead of vague prompts, we used a structured, step-by-step approach to guide the AI.

Start code generation. Do it step by step. Move to next step only after the current step is complete.

Step: Create VPC and Network Infrastructure - use vpc module
- Create VPC with appropriate CIDR block
- Create public and private subnets across 2 AZs
- Set up Internet Gateway
- Configure NAT Gateways in public subnets
- Configure route tables for public/private subnets

Step: Create Security Groups
- ALB security group (allow HTTP/HTTPS inbound)
- EC2 security group 
    - allow traffic from ALB
    - allow ssh from the vpc
- Allow all outbound traffic

Step: Create Auto Scaling Group - use autoscaling module
- Create launch template for EC2 instances
- Use ubuntu ami for the instances
- Configure ASG across private subnets
- Use keypair named "vikas-aws"
- Add a user data script to install nginx and create a simple html page

Step: Create a jumpbox
- Create a jumpbox in the public subnet
- Ensure it has a public IP
- Allow SSH from internet

Step: Create Application Load Balancer - use alb module
- Create ALB in public subnets
- Configure HTTP listener
- Attach to autoscaling group

Step: CloudFront Distribution
- Configure CloudFront with ALB as origin
- Set caching TTL to 0

Step: DNS Configuration
- DNS handled via Cloudflare (no route53)

In practice, breaking the problem into steps like this improves output quality significantly compared to single prompts.

What the generated Terraform looked like

A simplified example:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "demo-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.3.0/24", "10.0.4.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

This wasn’t perfect out of the box, but:

Structure was correct
Inputs were mostly valid
Dependencies were aligned
That already saves a significant amount of time.

What actually improved (based on usage)

From real usage:

Before:

2–4 hours to assemble infra
Multiple documentation lookups
Several failed applies

After:

Initial setup generated in minutes
Fewer structural errors
Faster iteration
In most teams, the biggest gain is reduced context switching.

Operational considerations

This approach still requires discipline:

Always run terraform plan
Review changes carefully
Do not trust generated code blindly
IAM policies and security configurations must always be reviewed manually.

When Terraform with AI Works Best

In most teams, this approach works well when:

You are building new infrastructure
You need to scaffold modules quickly
You want to reduce repetitive work
It is less effective when used blindly or without validation.

When not to use this approach

Avoid relying on it when:

Infrastructure requires strict compliance
You don’t understand the generated code
You need deterministic, audited configurations
This is not a replacement for Terraform expertise.

Where this fits in a DevOps workflow

This approach integrates naturally with:

Git-based workflows
CI/CD pipelines
Infrastructure reviews
The deployment process does not change — only the way code is written.

FAQ

What is Terraform with AI?

Terraform with AI refers to using AI tools to generate and manage infrastructure code more efficiently.

What is Terraform MCP Server?

It provides AI tools with Terraform context, including modules and documentation.

Is AI-generated Terraform safe for production?

Yes, but only after proper validation and review.

Conclusion

Terraform itself hasn’t changed.
What’s changing is how engineers interact with it.
Using Terraform with AI + MCP Server reduces friction in writing infrastructure — especially for repetitive setups.
It doesn’t replace engineering judgment, but it does make the workflow more efficient.

K3s vs Kubernetes (K8s): Performance, Architecture, Use Cases and When to Choose Each

sanjay yadav — Fri, 22 May 2026 04:50:47 +0000

K3s and Kubernetes (K8s) are often compared, but they are not direct competitors. They solve different infrastructure problems.
K3s can run in under 200MB of RAM, while a standard Kubernetes cluster can exceed 800MB. This makes the choice highly dependent on your environment and workload.

This guide explains the key differences between K3s and Kubernetes, focusing on architecture, performance, and real-world DevOps use cases.

What is Kubernetes (K8s)

Kubernetes is a container orchestration platform designed to manage large-scale distributed systems.
It provides:

Automated deployment and scaling
Self-healing infrastructure
Service discovery and load balancing
Kubernetes is widely used in production environments where scalability and reliability are critical.

What is K3s

K3s is a lightweight Kubernetes distribution designed for environments with limited resources.

It simplifies Kubernetes by:

Packaging components into a single binary
Using lightweight storage (SQLite by default)
Reducing operational complexity
K3s is commonly used in edge computing, IoT, and development environments.

K3s vs Kubernetes: Key Differences

K3s vs Kubernetes Architecture Comparison

K3s vs Kubernetes Performance Comparison

From practical testing, K3s consistently performs better on small instances (1–2GB RAM), while Kubernetes starts showing its strength as workload complexity and scale increase.

Real-World Observation

In a test cluster:

K3s used approximately 200MB RAM
Kubernetes used more than 800MB RAM
K3s performs better in constrained environments, while Kubernetes handles high-scale workloads more effectively.

K3s vs Kubernetes Use Cases

When to Use K3s

Edge computing
IoT deployments
CI/CD environments
Local development

When to Use Kubernetes

Production systems
Microservices architecture
Multi-cloud deployments
High-traffic applications
A common mistake is adopting full Kubernetes too early. For many small projects or internal tools, K3s can handle the workload with significantly less operational overhead.

Decision Guide

Installation Examples

K3s Installation

curl -sfL https://get.k3s.io | sh -

Kubernetes Installation (kubeadm)

kubeadm init
Pros and Cons

K3s

Pros

Lightweight
Fast setup
Low resource usage

Cons

Limited scalability
Fewer enterprise features

Kubernetes

Pros

Highly scalable
Rich ecosystem
Production-grade

Cons

Complex setup
Higher resource usage

FAQ

Is K3s production ready

K3s is production ready for lightweight workloads, especially in edge and constrained environments.

Is K3s faster than Kubernetes

K3s has faster startup time and lower resource consumption compared to standard Kubernetes.

Can K3s replace Kubernetes

K3s is not a replacement for Kubernetes in enterprise environments. It is designed for specific use cases like edge and development.

Continue learning with these in-depth guides:
Kubernetes Architecture Deep Dive (Components Explained)
K8s vs Docker: Complete Comparison Guide
Best Kubernetes Monitoring Tools for DevOps

Conclusion

There is no one-size-fits-all choice here, but in most early-stage or resource-constrained setups, K3s is often the more practical starting point.
K3s and Kubernetes are designed for different types of environments, and choosing the right one depends on your specific use case.
K3s is ideal for lightweight workloads, edge computing, and development environments where simplicity and low resource usage are important.
Kubernetes, on the other hand, is built for large-scale, production-grade systems that require high availability, scalability, and a mature ecosystem.
In most modern DevOps workflows, both are used together:

K3s for development, testing, and edge deployments
Kubernetes for production and high-scale applications
Selecting the right platform is less about features and more about aligning with your infrastructure needs and long-term scalability goals.

DEV Community: sanjay yadav

How Much Do You Trust the Dependencies Your Applications Install?

Is the Cheapest Cloud Instance Really the Cheapest?

Race Conditions Don't Show Up Until Your App Has Real Users

I Used to Think Database Search Was Good Enough Until Our Project Started Growing

Container Debugging Gets Much Harder Once SSH Stops Being an Option

Introduction

Prerequisites

Install Required Tools

AWS CLI

Session Manager Plugin

IAM Permissions

Checking if ECS Exec is Enabled for a Service

Checking ECS Exec via AWS Console

Step-by-Step: Enabling and Using ECS Exec in AWS Fargate

Step 1: Enable ECS Exec for the Service

Step 2: Verify ECS Exec is Enabled at the Service Level

Alternative: Check in the AWS Console (UI)

Step 3: Verify ECS Exec at the Task Level

Step 4: Verify if the ECS Exec Agent is Running

Step 5: Access the Container Using ECS Exec

If ECS Exec is still not working, use the Amazon ECS Exec Checker tool to diagnose the issue.

Step 6: Troubleshooting ECS Exec Issues

Attach the necessary permissions to the ECS task role.

Add the missing VPC endpoint (com.amazonaws.us-east-1.ssmmessages) in the AWS VPC settings.

3. Update Security Group Rules for VPC Endpoints

Step 8: Automate Everything with Terraform

Add to the "Common Issues and Fixes" Table

Time Zones Usually Don't Become a Problem Until Your Application Goes Global

Why Time Zone Detection Matters

Common Time Zone Challenges

Step-by-Step Implementation

Method 1: JavaScript Detection with Session Storage

Frontend Implementation

Backend View Implementation

Method 2: Timezone Middleware

Method 3: User Profile Integration

Method 4: Template Context Processor

Implementation Flow

Advanced Implementation Strategies

Database Storage Best Practices

Performance Optimization

Security Considerations

Testing Strategies

Alternative: GeoIP Detection

Common Pitfalls and Solutions

Pitfall 1: Daylight Saving Time Issues

Pitfall 2: Session Timeout Issues

Pitfall 3: Mobile App Considerations

Read More

Most Prometheus Problems Start Long Before Dashboards Break

Mistake 1: Cardinality Bombs

Here’s a quick comparison:

Mistake 2: Aggregating Away Too Many Labels

Mistake 3: Unscoped Metric Selectors

Mistake 4: Missing "for" Durations in Alerting Rules

Mistake 5: Using Too Short Rate Windows

Mistake 6: Using Functions With Incorrect Metric Types

Conclusion

Most Teams Don't Move to Amazon RDS for Performance

What is AWS RDS?

What is Amazon EC2?

Administration

High Availability

Backups

Scalability

Performance

Storage

Support and Control

Security

Licensing

Cost

Amazon RDS:

AWS EC2:

How to Choose Between AWS RDS and Amazon EC2

Read More

Database Performance Discussions Usually Change Once Infrastructure Costs Start Scaling

Kubernetes Observability Usually Gets More Complicated Before It Gets Better

Terraform with AI: Build AWS Infra (Cursor + MCP)

Why Terraform with AI Matters in Modern DevOps