标签：#DevOps

Stack Overflow has announced Stack Overflow for Agents, a beta API-first knowledge exchange aimed at AI coding agents rather than human developers. The service is presented as a way to close what the company calls the Ephemeral Intelligence Gap, where agents repeatedly rediscover the same fixes and patterns in isolation instead of sharing them through a common memory. By Matt Saunders

The problem IAM wildcards and public S3 buckets keep slipping through Terraform code review. Tools like Checkov and tfsec exist but they live in CI, require config files, and developers ignore the output because it's not where they're working. What I built TerraWatch is a GitHub App that scans every pull request that touches .tf files automatically. If it finds a security issue it blocks the merge and posts the exact code fix as a PR comment. The developer sees something like this in their PR: ⚠️ PUBLIC_S3_BUCKET - main.tf (Line 6) Severity: HIGH Risk: S3 bucket allows public read access. Fix: acl = "public-read" acl = "private" block_public_acls = true restrict_public_buckets = true They copy the fix, push, and the merge unblocks automatically. How it's different No YAML, no CI config - installs in 2 minutes via GitHub App Fixes are hardcoded diffs, not AI generated Nothing auto-applied - you review every fix No Checkov dependency - own lightweight rules engine Only reads changed .tf files in the PR, never your full codebase 29 rules covering S3 public access, IAM wildcards, open ports (SSH/RDP/MySQL/Postgres), unencrypted EBS/RDS, public databases, hardcoded secrets, EKS public endpoints, CloudTrail disabled, IMDSv1, and more. Try it Free during beta - terrawatch.dev Also launching on Product Hunt today if you want to show some support!

Agentic QA Pipelines: Why Your Test Scripts Are Already Obsolete You wrote the test. You maintained the test. The app changed. You rewrote the test. If that loop sounds familiar, you're not alone — and in 2026, you're also not competitive. Agentic QA pipelines are replacing script-based test automation not because AI is smarter than your QA engineers, but because describing goals is faster than maintaining instructions. Here's what's actually changing, why it matters, and how forward-thinking teams are shipping without the script debt. The Script Maintenance Tax Is Killing Velocity Traditional test automation follows a simple premise: write explicit instructions, run them, check results. It worked when applications changed slowly and test environments were stable. In 2026, neither is true. AI-generated code ships faster. Features change in days. UI components regenerate. And every change breaks a percentage of your carefully maintained test scripts — creating a maintenance tax that grows proportionally with your automation coverage. Quash's 2026 State of QA Automation Report found that teams spending more than 30% of QA bandwidth on script maintenance are shipping 2.4x slower than teams that have automated that maintenance layer away. The irony: the more test coverage you write, the more you're paying the tax. What Agentic QA Actually Means (Without the Buzzwords) An agentic QA system doesn't follow a script. It follows a goal. Instead of: Click the login button Enter " testuser@example.com " in the email field Enter "password123" in the password field Assert redirect to /dashboard An agentic QA agent receives: Goal: Verify that a registered user can successfully authenticate and access their dashboard. Context: Auth flow supports email/password and OAuth. Dashboard loads user-specific data. The agent then: Explores the auth flow autonomously Generates test scenarios, including edge cases it infers from the UI Executes tests, reads failures, and adapts to UI changes

Most teams I talk to have "evals." I ask them where the evals run. The answer is almost always the same: a notebook, a dashboard, a spreadsheet someone updates after a bad week. That is not an eval suite. That is a museum. Here is the opinion I will defend for the rest of this post: if your agent's quality checks cannot block a merge, they are decorative. The entire value of an eval is that it stops a regression before it reaches a user. A score you read on Monday about a deploy you shipped Friday is a postmortem, not a gate. We gate code with unit tests. We gate APIs with contract tests. We gate infra with terraform plan . Then we take the single most non-deterministic component in the stack — an LLM agent that can silently change behavior when a vendor ships a new checkpoint — and we let it through on vibes. That asymmetry is the actual bug. Why "run it locally and eyeball it" rots The failure isn't that engineers are lazy. It's that manual eval runs degrade under exactly the conditions where you need them most: Prompt edits look harmless. You reword one line of a system prompt to fix a tone complaint and tank tool-selection accuracy on three unrelated tasks. Nobody re-ran the full set because it's a 40-minute slog. The model moves under you. You pinned gpt-4o , but gpt-4o is not a constant — providers roll checkpoints. Your prompt is identical and your behavior shifted anyway. Dependencies leak. A retrieval index gets re-embedded, a tool's API changes a field name, and the agent starts confidently citing stale data. None of that shows up in a code diff. Every one of these passes code review. Every one of these is caught by a regression suite that runs on the PR. The fix is boring and it works: treat agent behavior like any other thing you'd protect with CI. The two halves you actually need A CI gate for agents needs two things, and people consistently build only one. The first is a scorer : something that takes the agent's output for a fixed set of inputs and ret

Here's a thing that catches almost everyone the first week they run a model locally. You paste a 600-line file into your shiny new local assistant, ask it to find the bug, and it confidently rewrites a function that isn't even in the part it read. No error. No warning. It just... silently dropped most of your file on the floor before the model ever saw it. That's not the model being dumb. That's Ollama doing exactly what it was told. By default it gives every model a context window of 2048 tokens and quietly truncates anything past that. It's one of a handful of small surprises that separate "I installed Ollama" from "I actually understand what's running on my machine." Let's go through the ones that matter: how the thing works under the hood, what hardware you really need, the gotchas, and the honest answer to "should I even bother instead of just calling an API?" What Ollama actually is Ollama gets described as "Docker for LLMs," and that's a decent first approximation. You pull a model, you run it, there's a registry. But it hides what's doing the heavy lifting. Underneath, Ollama is a friendly wrapper around llama.cpp , the C/C++ inference engine that made running these models on consumer hardware practical in the first place. When you type ollama run , you're really booting a llama.cpp runtime with a sane default config and a tidy HTTP server bolted on. The models it runs are in a format called GGUF (GPT-Generated Unified Format). A GGUF file isn't just weights. It's a self-contained package that bundles the tensors, the tokenizer config, the architecture details, and hyperparameters like the trained context length, all in one file. That's why ollama pull llama3.1 gives you something that just works: everything the runtime needs to reconstruct the model is in the box. Ollama itself is young. The project shipped its first release in early July 2023 , and it rode the wave of open-weight models (Llama 2 landed that same month) that suddenly made "run a real LLM on

Series Final. The four mechanisms covered across this series — knowledge graph, Auto Review, Self-Healing, Recurrence Prevention — plus the non-engineer-PR application that sits on top of them, all hang off a single conviction: AI isn't something to trust; it's something to design. The 'I don't trust AI to fill in the blanks for me' framing this lives inside isn't doubt about generation quality, but the clear-eyed acceptance that AI has no idea what context wasn't handed to it, and that 'ideal behavior with no spec given' is a fantasy. The starting point goes back to 2025, when I was trying to figure out how to make AI actually understand a large codebase — and ran into walls on both context window scaling (lost in the middle, attention dilution) and learning-based approaches (machine unlearning, destructive interference). GraphRAG + MCP became the way out: hand AI only the facts it needs, when it needs them, so it doesn't have to infer. From code-graph (which I burned two months on and threw away) to the current product-graph (cpg). This piece is the philosophy and the trial-and-error behind the whole series: harnesses confine where hallucinations are allowed to happen, design is translating principles into your own use cases, and Coverage 90% as a solo target breaks the implementation.

Modern software delivery pipelines can deploy code dozens or even hundreds of times per day. Traditional penetration testing models, where security teams perform assessments quarterly or before major releases, simply cannot keep pace. Attackers do not wait for the next security review. Every pull request, dependency update, infrastructure change, or container image introduces potential risk. Integrating penetration testing into CI/CD enables organizations to identify vulnerabilities before they reach production. The goal is not replacing human penetration testers. The goal is automating everything that can be automated so security experts can focus on complex attack paths and business logic flaws. Understanding Security Testing Layers in CI/CD Security testing is often misunderstood because multiple categories overlap. Testing Type Purpose SAST Analyze source code SCA Detect vulnerable dependencies DAST Test running applications IAST Runtime security analysis Penetration Testing Simulate attacker behavior Penetration testing combines elements of all these approaches. A mature CI/CD pipeline continuously performs automated penetration testing while reserving manual testing for sophisticated attack scenarios. Designing a Security-First CI/CD Architecture A security-centric pipeline typically looks like: Developer Commit ↓ Pre-Commit Security Checks ↓ Pull Request Validation ↓ Build Stage ↓ Container Security Scan ↓ Infrastructure Validation ↓ Deploy to Staging ↓ Automated Penetration Testing ↓ Security Gate ↓ Production Deployment Each stage eliminates vulnerabilities before they become more expensive to fix. Stage 1: Pre-Commit Security Controls The cheapest vulnerability is the one that never reaches Git. Secret Detection Install TruffleHog or Gitleaks before code reaches the repository. repos : - repo : https://github.com/gitleaks/gitleaks rev : v8.20.0 hooks : - id : gitleaks Developer installation: pip install pre-commit pre-commit install Now every commit is aut

DevOps has always evolved with technology. Cloud changed how teams manage infrastructure. Containers changed how applications are deployed. CI/CD changed how software is released. Observability changed how teams monitor systems. Now AI is starting to change DevOps again. The next stage of DevOps is not only automation. It is intelligence. * DevOps Was Built on Automation * Automation is one of the strongest foundations of DevOps. DevOps teams automate: • Builds • Tests • Deployments • Infrastructure provisioning • Monitoring alerts • Rollbacks • Scaling • Security checks This has helped teams deliver software faster and more reliably. But most automation still works through fixed rules. For example: if CPU crosses a threshold, send an alert. If a build passes, deploy to staging. If a container fails, restart it. This works well for known situations. But modern systems are more complex. Microservices, cloud platforms, Kubernetes, APIs, databases, queues, and third-party dependencies create huge amounts of operational data. When something goes wrong, fixed rules are not always enough. * Why Intelligence Matters * Modern DevOps teams do not just need more automation. They need better understanding. AI can help teams identify patterns, detect unusual behavior, summarize logs, group related alerts, and suggest possible causes during incidents. This is where AIOps becomes important. AIOps means using AI for IT operations. It helps DevOps and SRE teams move from reactive operations to smarter operations. Instead of only asking, “What alert fired?” teams can start asking: • What changed recently? • Which services are aff ected? • Are these alerts connected? • Is this behavior unusual? • Has this happened before? • What is the likely root cause? This does not mean AI will replace DevOps engineers. It means AI can support engineers with faster insights. * What This Means for DevOps Engineers * DevOps engineers should pay attention to AI because their role is evolving. Traditi

Simple Intro Your company gets one big cloud bill. It says $30,000. But which team spent it? Which app? Nobody knows. Kubernetes makes this worse because 100 small apps share the same computers. It’s like 10 families sharing one electricity bill. Let’s fix this in 5 easy steps Step 1: Put Nametags on Everything In Kubernetes, you can add "labels" to your apps. Example: team=sales , app=website , owner=pooja If you don’t add name tags, you can never track who spent what. It’s the most important step. Step 2: Check the Big Cost - Computers 70% of your bill is for CPU and RAM. That’s the “brain” and “memory” your apps use. The problem: Most people book a big computer but only use 20% of it. You pay for 100%, use 20%. You waste 80% money. Easy fix: Every month, check “How much did I book vs How much did I use?” Then book smaller next time. Step 3: Don’t Forget Hidden Costs Two things people forget: Storage: Like a hard disk. You deleted the app but forgot to delete the disk. It still charges you every month. Network: Moving data between countries or zones costs money. Check for old disks and big data transfers once a month Step 4: Share the Common Bill Fairly Some costs are for everyone. Like the main Kubernetes system or empty computers waiting for work. How to split it? Easy. If Team A uses 60% of the total computer power, they pay 60% of the common bill. Fair for everyone. Step 5: Use a Tool, Not Excel Doing all this in Excel will make you cry. It’s too much data. Use a tool that does it automatically. It connects to your Kubernetes, reads all the name tags, and tells each team: “You spent $2,340 this week.” Final Tip You can’t save money if you don’t know where it’s going. First, make the costs clear to everyone. Then the savings happen automatically. FAQ - In Simple Words Q1. Why can’t I just see costs in AWS bill? Because AWS only tells you “EC2 cost $10k”. It doesn’t tell you which of your 50 apps used that EC2. Kubernetes hides the details. Q2. What is the first

TL;DR OOMKill is a reporting artifact, not a root cause. By the time the kernel logs the kill event and your alerting pipeline fires, the service already degraded for every user who hit The Alert You See Is Not the Problem You Have OOMKill is a reporting artifact, not a root cause. By the time the kernel logs the kill event and your alerting pipeline fires, the service already degraded for every user who hit it in the preceding minutes. Operators page on the kill. The latency damage is already done. Aspect What Operators Observe What Actually Happens OOMKill event Alert fires; pod is restarted Kill is the kernel's final action after degradation is already complete Silent pressure window No alert fires; no dashboard turns red p99 latency climbs as allocator contention serializes parallel work Incident attribution Logged as "OOM, increased limit"; latency spike blamed on network or dependency Root cause (limit headroom erosion) goes unaddressed; pattern repeats Limit headroom over time No automated signal warns of erosion Gap between working set and limit shrinks as traffic grows or data shapes shift Recommended alert threshold Triggered at kill event Trigger at 80% headroom consumption before kernel involvement The mechanism works like this. Kubernetes memory limits define a hard ceiling enforced by the Linux kernel's cgroup subsystem. When a container's resident set size approaches that ceiling, the kernel does not wait. It begins refusing new memory allocations. Silent pressure window The application's allocator blocks, retries, or falls back to slower paths. Garbage collectors in JVM and Go runtimes trigger earlier and more aggressively because the heap has no room to grow. Each of these responses adds latency to in-flight requests before a single OOMKill event appears in your logs. The kill is the kernel's final action after the application has already been running degraded. Silent pressure window. The interval between first memory pressure and pod termination is

Docker is a game-changer for developers—making it easier to package, ship, and run applications. But with great power comes great responsibility. Whether you're running containers in development or production, security should never be an afterthought . In this post, I'll walk you through beginner-friendly Docker security practices that will help you build safer containers from the start. No enterprise jargon—just practical, actionable tips. Why Care About Docker Security? Containers may feel isolated, but they share the host OS kernel. This means: A compromised container could lead to host compromise. Vulnerabilities in container images can be exploited. Misconfigured containers can unintentionally expose sensitive data or ports. Docker Security Best Practices for Beginners This post is a follow-up to my previous article, Docker Like a Pro: Essential Commands and Tips , where we explored fundamental Docker commands and tips. Building upon that foundation, this guide focuses on essential security practices to help you build safer containers from the start. Docker has revolutionized the way developers build, ship, and run applications. However, with great power comes great responsibility. Whether you're running containers in development or production, security should never be an afterthought. In this post, I'll walk you through beginner-friendly Docker security practices that will help you build safer containers from the start. No enterprise jargon—just practical, actionable tips. Why Care About Docker Security? Containers may feel isolated, but they share the host OS kernel. This means: A compromised container could lead to host compromise. Vulnerabilities in container images can be exploited. Misconfigured containers can unintentionally expose sensitive data or ports. 1. Use Official Images When Possible Start by pulling images from Docker Hub’s verified publishers or official repositories. Use this: docker pull node:18 Not this (could be outdated or malicious): doc

When to choose ansible roles over playbooks depends on the need for reusable structure, clear separation of concerns, and scalable maintenance across many environments. In a deployment that touches 1,200 servers, the early design decision determines whether the codebase remains maintainable or devolves into ad‑hoc tasks that require weeks of debugging. 📑 Table of Contents 📦 Modularity — Why Structure Matters 🧩 Reusability — When Scaling Demands Roles 🔧 Example: Deploying a Database Across Multiple Environments ⚙️ Dependency Management — How Requirements Influence Choice 🔗 Role Dependency Example 📁 File Layout — Organizing Artifacts for Maintenance 📊 Performance & Execution — Impact on Runtime 🔍 Comparison – Roles vs. Playbooks 🟩 Final Thoughts ❓ Frequently Asked Questions When should I still use a flat playbook? Can I mix roles and tasks in the same playbook? How do I test a role without affecting production? 📚 References & Further Reading 📦 Modularity — Why Structure Matters Roles enforce a predictable directory hierarchy that isolates tasks, variables, handlers, and files. What this does: # roles/webserver/tasks/main.yml - name: Install Nginx apt: name: nginx state: present - name: Deploy configuration template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf mode: '0644' notify: Restart Nginx # roles/webserver/handlers/main.yml - name: Restart Nginx service: name: nginx state: restarted tasks/main.yml: defines the ordered steps the role performs. handlers/main.yml: runs only when notified, preventing unnecessary restarts. The directory roles/webserver groups all related artifacts, making the role portable. Because the role encapsulates its logic, a playbook can invoke webserver without repeating internal steps. This eliminates duplication and aligns with the DRY principle. Key point: Enforced structure turns a loose collection of tasks into a self‑contained unit that can be shared across multiple playbooks. 🧩 Reusability — When Scaling Demands Roles Roles enable r

Why This Matters: The 2 AM Problem It's 2 AM. Your phone rings. Your production database is down. Customers can't log in. Revenue is dropping by the second. You call the Ops team. They restart the server. Downtime: 45 minutes. Cost: $100K in lost sales. Root cause? Unknown. This happens thousands of times a week at companies worldwide. The question isn't "Will your system break?" It's " When it breaks, are you ready? " That's where SRE comes in. What is SRE? (The Real Definition) SRE (Site Reliability Engineering) = Applying software engineering principles to build reliable, scalable infrastructure and systems. It's not just about keeping servers running. It's about: Reliability : Systems that don't break unexpectedly Scalability : Systems that handle growth without collapsing Infrastructure : Automating how systems are built, deployed, and monitored Measurability : Knowing exactly how your system is performing at any moment Traditional operations manages infrastructure reactively — when something breaks, you fix it. SRE manages infrastructure proactively — you engineer it so it rarely breaks, and when it does, it heals itself. The Key Insight: Reliability is Engineered, Not Hoped For Here's the critical shift in thinking: Old mindset : "Let's build this system and hope it doesn't break." SRE mindset : "Let's measure what 'reliable' means, design the system to achieve that, and automate the monitoring and recovery." But reliability isn't just uptime. It includes: Uptime : Is the system available? Latency : How fast does it respond? (A slow system is effectively broken) Error rate : What percentage of requests fail? Throughput : Can it handle the traffic? User experience : Does the system meet user expectations? All of these are engineered and measured. A Simple Analogy: The Bridge Imagine you're managing a bridge. Traditional approach : Engineers patrol daily, react to problems, work around the clock fixing issues SRE approach : Engineers design monitoring that aler

Claude is genuinely useful for production Linux troubleshooting — when you use it right. Here's the workflow that works, after a year of using it on real incidents across Ubuntu, RHEL, and Rocky. The mental model: Claude is a senior pair, not an oracle The mistake most engineers make on day one: they paste a 5-line error message and expect a fix. Claude can do better than that — but only if you give it the same context you'd give a senior engineer joining your incident bridge. A senior engineer would want: What OS and version? What does this server do? What changed recently? What's the actual symptom? What command output have you already gathered? Give Claude that, and the quality of analysis changes completely. The workflow Step 1: Establish context with a system prompt Use our Linux Server Troubleshooting Prompt as your system prompt, or paraphrase: "You are a senior Linux sysadmin. Rank root-cause hypotheses by probability. Recommend safe diagnostics first. Label destructive commands as DANGEROUS." Step 2: Paste structured context, not noise Good: OS: Ubuntu 22.04, kernel 5.15 Role: production MySQL replica, 64GB RAM, 16 cores Recent changes: kernel upgrade 6 hours ago Symptom: server load average 40+, MySQL replication lag growing, queries timing out $ uptime 14:22:01 up 6:02, 4 users, load average: 41.23, 38.51, 35.04 $ free -h total used free shared buff/cache available Mem: 62Gi 58Gi 1.2Gi 128Mi 3.1Gi 1.8Gi $ iostat -xz 2 3 [...] Bad: my server is slow can you help Step 3: Let it ask follow-up questions The good prompts in our library tell Claude to ask for missing data before guessing. When it asks "can you share dmesg | tail -50 and vmstat 1 5 ?" — that's a feature, not a flaw. Give it the data. Step 4: Validate suggested commands before running Claude will sometimes suggest a command with subtly wrong syntax, a destructive flag, or a path that doesn't exist on your distro. Read every suggestion before running. Never paste straight into a root shell. Step 5

🚀 CKA Exam Overview: What Every Kubernetes Engineer Should Know Before Starting If you're working in DevOps, Cloud Engineering, Platform Engineering, or SRE, chances are you've heard about the Certified Kubernetes Administrator (CKA) certification. But here's what surprises most people: ⚠️ There are no multiple-choice questions. You get a real Kubernetes environment and must perform actual administrative tasks within a limited time. That makes the CKA one of the most practical certifications in the cloud-native ecosystem. 📋 CKA Exam Pattern Category Details Exam Type Performance-Based Duration 2 Hours Environment Live Kubernetes Cluster Passing Score ~66% Proctoring Online Remote Proctored Difficulty Intermediate to Advanced 🎯 Core Domains 1️⃣ Cluster Architecture, Installation & Configuration Cluster setup Control Plane components Certificate management Cluster upgrades 2️⃣ Workloads & Scheduling Deployments StatefulSets DaemonSets Jobs & CronJobs 3️⃣ Services & Networking Services Ingress DNS Network Policies 4️⃣ Storage Persistent Volumes Persistent Volume Claims Storage Classes 5️⃣ Troubleshooting Node failures Pod failures Control Plane issues Network troubleshooting Why CKA Matters in 2026 Modern organizations running workloads on AWS, Azure, and GCP increasingly rely on Kubernetes. A certified administrator demonstrates the ability to: ✅ Manage production clusters ✅ Troubleshoot incidents efficiently ✅ Maintain reliability and scalability ✅ Support cloud-native application deployments These skills directly align with DevOps and SRE responsibilities. My 90-Day CKA Challenge I'm beginning a structured 90-day CKA preparation journey. Over the next few months, I'll share: Study notes Lab exercises Troubleshooting scenarios Exam strategies Kubernetes tips & tricks Real-world DevOps and SRE learnings Discussion Time 👇 If you've already taken the CKA: 👉 What was the hardest section for you? If you're preparing: 👉 What's your biggest challenge right now? Let's learn

Hermes Agent already has memory, and that matters. It keeps local context, it improves over time, and it works without forcing you into a cloud service. It also supports several external memory providers. I still built hermes-mempalace , because none of the existing options fit my setup quite right. I wanted something: local-first isolated by Hermes profile verbatim, not just extracted facts easy to inspect on disk simple enough to trust over time That last part is the important one. I did not want a memory layer that turns conversations into an opaque pile of embeddings or summaries you cannot really audit. I wanted actual transcripts, mined into a readable structure, with no hidden server in the middle. Why the existing options were not enough Hermes already gives you a few paths: built-in memory and session context external providers for different use cases enough flexibility to adapt, if you are willing to bend your workflow around them And to be clear, some of those options are good. But ... I run Hermes on a headless machine at home. And I use separate profiles for different contexts. And I do not want conversation content depending on a cloud API or a separate service unless there is a very good reason. So, the best fit had to check a few boxes: [x] no API key [x] no external server [x] no extra runtime I did not already want/install [x] storage isolated by HERMES_HOME [x] memory we can actually read later That let to MemPalace , or https://mempalaceofficial.com/ (hopefully, that's the right one!) What hermes-mempalace does hermes-mempalace wires MemPalace into the Hermes memory provider interface. It follows the same lifecycle as the rest of Hermes memory providers: system_prompt_block() adds a short memory reminder to the prompt. prefetch() can run a MemPalace search before the first model call. sync_turn() buffers completed turns without slowing the chat loop. on_session_end() writes buffered turns to markdown and mines them into the palace. shutdown() flu

Six months ago I moved my RAG pipeline from Pinecone to self-hosted Qdrant. My vector search bill went from $210/month to $6.50/month. Same latency. Same recall. Here's exactly how. The Setup My app does document Q&A for legal contracts. The numbers: 5.2 million vectors (1536-dim, OpenAI embeddings) ~800K queries/month P99 latency requirement: < 50ms On Pinecone Serverless, this cost me roughly $210/month — storage plus read units plus write units for daily ingestion of new documents. What I Moved To A single Hetzner CX32 server: 4 vCPU, 8 GB RAM, 80 GB SSD €8.50/month (about $9.20) Qdrant running in Docker Automated daily backups to S3-compatible storage ($0.50/month) Total: ~$10/month. That's a 95% cost reduction. The Migration Was Easier Than Expected bash# Export from Pinecone (I used their scroll API) python export_pinecone.py --index legal-docs --output vectors.jsonl Start Qdrant docker run -d -p 6333:6333 -v ./storage:/qdrant/storage qdrant/qdrant Import python import_qdrant.py --input vectors.jsonl --collection legal-docs The whole migration took an afternoon. The Qdrant Python client is straightforward, and the API is surprisingly similar to Pinecone's. Performance Comparison I ran the same 10,000 test queries against both setups: MetricPinecone ServerlessQdrant Self-HostedP50 latency23ms4msP99 latency89ms12msRecall@100.970.97Monthly cost$210$10 The self-hosted Qdrant is actually faster because the data sits in memory on the same machine. Pinecone Serverless loads data from object storage on demand, which adds cold-start latency. When Self-Hosting Is a Bad Idea I want to be honest about the trade-offs: Don't self-host if: You have zero DevOps experience and no one on the team does You need 99.99% uptime SLA for enterprise customers Your vector count is growing unpredictably (10M one month, 100M the next) You're a team of 1-2 and every hour on infra is an hour not building product Do self-host if: Your scale is predictable (you know roughly how many vectors

The test passed. The restore completed inside the window. The workload came online. The team signed off, closed the ticket, and filed the results. DR test: successful. And then, somewhere between the test environment and the next real incident, the recovery plan drifted out of alignment with the infrastructure it was written to protect. Not dramatically. Not all at once. Gradually — through a cloud migration, an IdP consolidation, a new SaaS dependency, a network redesign that didn't make it into the runbook. DR plan failure rarely happens where you tested. It happens at the assumptions the exercise never reached. The Test Has a Boundary. The Incident Doesn't. A DR exercise begins with a defined scope. A specific workload. A known starting state. A target environment that has been prepared in advance. The team is available, credentialed, and not managing anything else. The blast radius is controlled before the test starts. A real incident does none of that. Scope expands from the first alert. Authentication problems surface because the IdP that wasn't in exercise scope is now unreachable. Networking issues appear because the failover path assumes a routing table that was updated three months ago. A vendor the plan never named is unavailable, and the recovery sequence stalls waiting for a dependency that was never documented as a dependency. The plan was written for the conditions of the test. The incident arrives in conditions the plan never anticipated. That gap is where DR plan failure actually lives — not in the restore mechanism, but in everything the restore mechanism was assumed to be able to reach. Most DR Plans Depend on Things They Never Recover The recovery exercise validates a workload. What it rarely validates is the recovery infrastructure itself. Consider what a typical enterprise DR plan silently depends on: Assumed — Not Tested: Identity provider, backup management console, cloud account access, ticketing and incident management systems, third-party

AI Agents Are the Best Thing to Happen to Network Administration Since SDN A single API key, an AI agent, and a router behind a double-NAT in Southeast Asia. What happened next changed how I think about network management. I manage UniFi routers spread throughout the ASEAN region — some for friends, some for relatives, one for a charity. They're in different cities, different ISPs, different levels of network hostility. Most sit behind carrier-grade NAT. A few are in places where the government firewall blocks VPN protocols at the transport layer. UniFi's own management interface has always been good. The web dashboard, accessible through Ubiquiti's cloud, gives me visibility into every site: device health, client lists, traffic stats, WiFi experience scores. It's one of the reasons I chose UniFi in the first place — the centralized GUI just works. But the GUI is still a GUI. It's clicks and menus and dropdowns. It's fast for one site, manageable for three, and tedious at ten. For anything beyond what Ubiquiti built into the interface, you'd need to write your own tooling. I never bothered, because I'm not a developer, and the built-in dashboard was good enough. Then AI agents arrived, and suddenly the calculation changed. The Discovery I knew UniFi had an API. I'd heard about it in passing — some REST endpoints for the controller, vaguely documented, probably read-only. I never looked into it seriously because what was I going to do with it? Write a Python script to poll client counts? Build a custom dashboard? Without a team of developers, an API is just a locked door. But when I started working with an AI agent, I gave it my UniFi cloud API key on a whim. I figured it could pull basic stats — the stuff from the Site Manager API at api.ui.com/v1 . Read-only. Dashboard-level. Useful as context for answering questions. Then the agent discovered something I'd completely missed: the Cloud Connector API . I owe this discovery in large part to the Art of WiFi PHP client

Microsoft Agent Framework is built for production multi-agent systems, which is exactly why its LLM bill can grow faster than expected. If you are running workflows with retries, handoffs, tools, and checkpoints, the easiest savings do not come from prompting harder — they come from adding a gateway layer under the framework. I built Lynkr, so obvious founder disclosure: this article uses Lynkr as the gateway example. I’ll keep it practical and focus on where the cost actually shows up in Microsoft Agent Framework workloads. Why this is a real Microsoft Agent Framework problem The current Microsoft Agent Framework README positions it as a production-grade framework for Python and .NET, with: multi-agent workflows sequential, concurrent, handoff, and group collaboration patterns middleware observability provider flexibility checkpointing and human-in-the-loop flows That is exactly the kind of stack where token usage grows quietly. A single prompt-response app is easy to reason about. A production workflow is not. Once you add routing, retries, multiple agents, MCP tools, and long-lived execution state, the same context starts getting resent over and over. That creates four predictable cost leaks. Where the spend comes from in Microsoft Agent Framework workloads 1. Repeated shared context across agents Multi-agent systems reuse a lot of the same context: task instructions tool definitions previous messages workflow state grounding context Even when the framework orchestrates cleanly, the model provider still sees repeated input tokens. 2. Tool-heavy steps explode prompt size Once agents start using tools, responses stop looking like simple chat. You get: search results file reads JSON blobs browser outputs execution traces Those payloads are often much larger than the user’s actual request. 3. Every task does not need the same model A workflow step that says “classify this,” “summarize these logs,” or “extract the next action” does not need the same model as “resolve