标签：#DevOps

If you are just getting started with Azure CLI and Bash scripting, this post is for you. I will walk you through how I automated the creation of Azure resource groups for multiple environments using a single Bash script — something that was taking a cloud admin several manual steps every week. This is Project 2 in my TechRush Cloud Engineering bootcamp series. If you want to see where this journey started, you can read my previous post where I tackled deploying a web app across two Azure regions for the first time . That project involved real blockers — quota limits, CLI version mismatches, and a deep dive into Azure Resource Providers. This one went smoother, and I think that is because the previous project was the hard school. The Problem Imagine a cloud administrator who has to create five resource groups every single week, one for each active project: Project-A-RG Project-B-RG Project-C-RG Project-D-RG Project-E-RG Every week. By hand. Management's response was simple: automate it. But here is where the task gets more interesting. Instead of creating one flat resource group per project, the better approach is to create four resource groups per project — one for each environment: Dev Test UAT Production This matters because each environment needs its own access controls, cost tracking, and lifecycle rules. You do not want your Development environment sharing a resource group with Production. Keeping them separate is a real-world cloud best practice, not just a bootcamp exercise. What You Will Need Before running this script, make sure you have the following set up: Azure CLI installed on your local machine. You can follow the official installation guide . An active Azure account . A free account works fine for this. A terminal that runs Bash — Linux, macOS, or WSL on Windows. Understanding the Design The core idea behind this script is parameterization . Instead of hardcoding project names, the script accepts a project name as input and uses it as a prefix for ev

Amazon Web Services has recently announced the general availability of the next generation of Amazon OpenSearch Serverless, with a redesigned architecture that enables 20 times faster resource provisioning than the previous serverless architecture, true scale-to-zero capability, and up to 60% lower cost than a provisioned cluster for peak loads. By Gianmarco Nalin

In the summer of 2016, Pokémon GO launched to a user base roughly fifty times larger than its capacity planning had anticipated. The engineering team had done load testing. They had throughput thresholds. They had autoscaling configured. Within hours of launch, the service was degraded globally — not because the infrastructure could not scale, but because it scaled too slowly against an arrival rate that exceeded every modelled scenario, and because the metric that was driving scaling decisions (CPU utilisation) lagged behind the actual saturation signal by several minutes. By the time CPU registered critical, the request queue had already grown to the point where p99 latency had crossed into the range where users were abandoning sessions faster than new sessions were being created. The engineering post-mortem identified the same root cause that appears in the post-mortems of most capacity-related incidents: the organisation's operational metrics were measuring how hard the infrastructure was working, not how much work the service could safely accept. CPU percentage is a resource utilisation metric. Memory percentage is a resource utilisation metric. IOPS is a resource utilisation metric. None of them is a service throughput metric. None of them tells you, with precision, at what arrival rate your SLO begins to degrade. Safe Operating Throughput is that metric. It is not a new concept in queueing theory or systems engineering — the idea of a safe operating ceiling predates modern distributed systems. What is new is its treatment as a first-class SRE metric: formally derived from load test data and SLO targets, continuously monitored for drift, and operationally enforced as a constraint in autoscaling configuration, capacity planning decisions, and deployment pipeline gates. Why Existing Capacity Metrics Are Insufficient The canonical capacity management approach in most organisations works like this: observe CPU or memory utilisation, set an autoscaling threshold (t

Per-request attribution starts with five fields on every call: provider, model, input tokens, output tokens, and ownership tags such as team, feature, and customer. A monthly vendor bill cannot explain why one feature, one tenant, or one prompt template suddenly became expensive. Request-level math can. As of June 8, 2026, OpenAI lists GPT-5.4 mini at $0.75 per 1M input tokens and $4.50 per 1M output tokens, while Anthropic lists Claude Sonnet 4 at $3 and $15 respectively. Gateway logs are useful, but they rarely solve AI cost tracking per feature unless you enrich them with business context and retry metadata. The practical operating model is simple: calculate cost on every request, attach ownership dimensions, then roll the data up into team, feature, and customer views. If you are searching for "LLM cost attribution per request," you are usually already past the basic billing problem. You can see your OpenAI or Anthropic invoice, but you cannot answer the questions finance and engineering actually care about: which feature drove the spike, which team owns it, which customers are unprofitable, and which prompt or model change caused the jump. That is why per-request attribution matters. It turns AI spend from a monthly surprise into an operational metric you can act on in the same day. Why LLM cost attribution per request matters now According to the FinOps Foundation's 2025 State of FinOps report, 63% of respondents now manage AI spending, up from 31% the year before. That jump is the real signal. AI cost is no longer a side bucket inside cloud spend. It is becoming a first-class FinOps workload. For teams spending $5,000 to $50,000 per month on LLM APIs, averages break down quickly. A support assistant, an internal coding copilot, and a customer-facing generation feature can all hit the same vendor account while having completely different margins, latency targets, and prompt shapes. If you only look at total spend by provider, you lose the unit economics. Per-r

Short answer first: use Supabase if you want Postgres plus auth, realtime, storage, and a dashboard as one managed bundle. Self-host Postgres – or use a managed Postgres – if you mostly need a database and your app already handles its own auth and logic. The choice is not really "Postgres vs Supabase". It's whether you need the extra layers Supabase puts on top of Postgres. Supabase is not a database Supabase runs on PostgreSQL, but it's a stack of services around it: Postgres – the actual database Auth – user signup, login, JWT tokens Realtime – live updates over websockets Storage – an S3-style file store Edge Functions – serverless functions Studio – dashboard + auto-generated REST/GraphQL API So "self-host Postgres or use Supabase" compares a plain database to a full backend. The honest question: do you need those extra layers, or just the database underneath them? A quick test: You use Supabase Auth, Storage, and Realtime → Supabase earns its place. You use one of them → it's replaceable. You use none and treat it as "Postgres with a nice dashboard" → you want plain Postgres. Side-by-side comparison Factor Supabase (managed) Self-hosted Supabase Plain Postgres (managed or self-hosted) Database engine PostgreSQL PostgreSQL PostgreSQL Built-in auth Yes Yes No (bring your own) Realtime / websockets Yes Yes No File storage Yes Yes No Dashboard + auto API Yes Yes No (use any SQL client) Backups Managed (limits by plan) You manage Managed or you manage Cost shape Metered, grows with usage Server cost + your time Database only Self-host effort None High (many containers) Low–medium Lock-in Medium–high Medium Very low The lock-in point decides it for many teams. Your data is standard Postgres in every option ( pg_dump portable). The lock-in is everything else: Auth tokens, Storage paths, Supabase-specific RLS policies, Edge Function code. The more Supabase-specific features you adopt, the harder the exit. When each option wins Pick managed Supabase when: You're startin

Ten weeks ago I did the thing every "grow your open source project" guide tells you to do. I carved a few small, self-contained tasks out of my backlog, labeled them good first issue , wrote crisp descriptions, and waited for contributors to roll in. They didn't roll in. The issues just sat there. This morning, one of them finally got picked up. A first-time contributor opened a clean PR against my MCP server: a smoke-test suite, no new dependencies, green across the whole Node CI matrix. Exactly the contribution the label was advertising for. And then my own repository spent the next twenty minutes trying to stop it from getting merged. Not with anything dramatic. With three quiet, individually-reasonable "best practice" gates that, stacked together, form a gauntlet aimed squarely at the one person you spent ten weeks trying to attract. I want to walk through each gate, because almost everything written about contributors is about attracting them, and almost nothing is about the last hundred feet — the silent friction between a willing PR and a merged commit. The advice is only half the story "Add good first issues and contributors will come" is true in the same way "build it and they will come" is true: technically, eventually, for a small subset, with survivorship bias baked in. My good first issue opened on March 31. The PR that closed it merged on June 8. That's sixty-nine days of a clearly-labeled, beginner-friendly task sitting untouched. I'm not complaining about the wait — that part is normal. I'm pointing out that the advice stops exactly where the interesting problem starts. Because the bottleneck was never finding someone willing. When someone willing finally showed up, the friction was entirely on my side of the fence. Gate 1: the CI that silently refuses to run GitHub Actions does not run workflows on pull requests from first-time contributors until a maintainer approves the run. This is a sane anti-abuse measure — fork PRs can run arbitrary code in yo

Three weeks ago, one of the teams we work with had a checkout outage. The root cause a malformed...

HashiCorp has released Terraform 1.15, introducing dynamic module sources, a formal deprecation mechanism for variables and outputs, a new inline type conversion function, type constraints for output blocks, and native Windows ARM64 support. The release addresses several long-standing requests from the Terraform community. By Matt Saunders

CSV files are one of the most common formats for storing and exchanging data. Whether you’re working with logs, analytics data, application exports, or reports, there will likely come a time when you need to load CSV data into ClickHouse®. The good news is that ClickHouse® makes CSV ingestion straightforward and efficient. In this guide, you’ll learn how to create a table, prepare a CSV file, load CSV data into ClickHouse®, and verify that the data has been imported successfully. Why Use CSV Files with ClickHouse®? CSV (Comma-Separated Values) files are simple, portable, and supported by virtually every data platform. Common use cases include: Importing exported application data Loading historical datasets Migrating data from other databases Testing analytics workloads Sharing data between systems Because ClickHouse® is designed for high-performance analytics, it can efficiently process and query large CSV datasets once they are loaded into a table. Sample CSV File Let’s assume we have a file named employees.csv with the following contents: id,name,department,salary 1,Alice,Engineering,75000 2,Bob,Marketing,60000 3,Charlie,Finance,70000 This simple dataset will help demonstrate how to load CSV data into ClickHouse®. Step 1: Create a Table in ClickHouse® Before importing data, create a table that matches the structure of the CSV file. CREATE TABLE employees ( id UInt32, name String, department String, salary UInt32 ) ENGINE = MergeTree() ORDER BY id; This table contains four columns that correspond directly to the columns in our CSV file. Step 2: Load CSV Data into ClickHouse® There are several ways to import CSV data, but one of the most common methods is using the ClickHouse® client. Run the following command: clickhouse-client --query=" INSERT INTO employees FORMAT CSVWithNames" < employees.csv The CSVWithNames format tells ClickHouse® that the first row contains column headers. After executing the command, ClickHouse® will read the CSV file and insert the records

In Modern Time applications are no longer simple monolithic systems. Today organizations run: Microservices Kubernetes Containers Serverless Functions Multi-Cloud Platforms Distributed Systems As infrastructure becomes more distributed, troubleshooting becomes significantly harder. A single user request may travel through: Frontend ↓ API Gateway ↓ Microservice A ↓ Microservice B ↓ Database When something breaks, the biggest challenge becomes: "What exactly happened?" This is where Observability becomes critical. 🔗 Resources ** Support the Journey on GitHub: If you're following along, consider starring and forking the repo:** https://github.com/17J/30-Days-Cloud-DevSecOps-Journey What is Observability? Observability is the ability to understand the internal state of a system by analyzing the data it produces. In simple words: Can we understand what is happening inside our systems? Observability helps engineers answer: Why is the application slow? Which service is failing? Which request caused the issue? What changed recently? Where is latency occurring? Without observability: Problem Exists ↓ Guessing Begins With observability: Problem Exists ↓ Evidence Available ↓ Faster Resolution Why Observability Matters Modern cloud-native systems generate enormous amounts of data. Example: 100 Microservices ↓ Millions of Requests ↓ Thousands of Containers Traditional monitoring alone is no longer sufficient. Organizations need: Visibility Insights Correlation Root Cause Analysis Observability provides all of them. Monitoring vs Observability Many people confuse monitoring and observability. Monitoring asks: What is wrong? Observability asks: Why is it wrong? Example: Monitoring: CPU Usage = 95% Observability: Which service? Which request? Which dependency? Which deployment caused it? Observability provides context. The Three Pillars of Observability Modern observability is built on three primary pillars. Metrics Logs Traces Or: Monitoring Logging Tracing Together they provide a

Backstage won the developer portal war and most teams running it still failed. Spotify's open-source framework, now a CNCF project, holds about 89% of the IDP market, runs at more than 3,400 organizations, and serves over two million developers outside Spotify. That is a decisive victory by any market-share metric. Then you find the number nobody puts on a keynote slide: the average internal adoption rate of a self-hosted Backstage instance sits around 10%. Most teams stand up a portal, demo it to leadership, and watch it quietly fail to become the thing engineers open every morning. So the slogan making the rounds in platform circles this year, "DIY is dead," is aimed at the exact tool that dominates the category. That sounds like a contradiction. It isn't. It's a math problem about where a small platform team's hours actually go. The 89% that doesn't mean what you think Framework market share and developer adoption are two different scoreboards, and Backstage is winning one while losing the other. Winning the framework war means a lot of organizations chose Backstage as the thing to build on. It says nothing about whether developers inside those organizations use the resulting portal. The honest read of the data is grim: teams "burn out on maintenance before delivering features developers actually want," and 56% of Backstage adopters name upgrades as their single biggest pain point. Not catalog design, not plugin gaps. Upgrades. The treadmill of keeping a fast-moving framework current is the thing that eats the year. I've watched this pattern up close on infra teams that had every reason to succeed. The portal goes live, gets a round of applause, and then the catalog data goes stale because nobody owns the integrations, the scorecards never get wired to real ownership data, and three months later the platform engineers are spending their sprints chasing a plugin that broke on the latest bump. The portal became the project instead of the platform. That is the failu

One of the first cloud concepts many people encounter while learning AWS is EC2 . The name sounds technical. The documentation is extensive. And the number of configuration options can make it feel like something fundamentally different from a regular computer. But while trying to understand cloud computing, I found myself repeatedly coming back to a simple thought: At the end of the day, an EC2 instance is just another computer. That realization helped me understand cloud infrastructure much more clearly. The Intimidation Factor When people first open the AWS console, they encounter terms such as: EC2 VPC Security Groups Elastic IPs Auto Scaling It is easy to feel that cloud computing is an entirely different world. But before diving into those concepts, it helps to ask a simpler question: What is an EC2 instance actually providing? Starting with the Name EC2 stands for: Elastic Compute Cloud The important word here is: Compute AWS is essentially renting computing resources. When you launch an EC2 instance, AWS allocates: CPU Memory (RAM) Storage Networking to a virtual machine that you can access. In other words: You are renting a computer that lives inside AWS's infrastructure. Comparing It to a Personal Computer Consider a typical laptop. It contains: A processor RAM Storage An operating system Network connectivity Now consider an EC2 instance. It also contains: Virtual CPUs RAM Storage An operating system Network connectivity The location is different. The concepts are the same. The Main Difference: Ownership The biggest difference is not technical. It is operational. With a personal computer: You own the hardware. The machine sits near you. You maintain it. With EC2: AWS owns the hardware. The machine runs in a data center. AWS manages the physical infrastructure. You only manage the virtual machine running on top of it. Why Linux Knowledge Transfers This was one of the most interesting observations during my learning. If an EC2 instance runs Linux, many of th

Your agent nailed every test case. You shipped it. Within 48 hours, users report hallucinated outputs, silently dropped tool calls, and responses that bear zero resemblance to what worked on your machine. You reload the same prompt locally. It works perfectly. Welcome to the most predictable failure mode in AI engineering: the dev-to-prod gap. This is Crucible C01. We dissect the five failure modes that kill agents in production and give you the tools to catch them before your users do. The Idea (60 Seconds) Developers test agents in idealized conditions: deterministic inputs, warm context windows, generous API latency budgets, and sequential tool calls. Production exposes the opposite environment: cold starts strip context, rate limits compress timing, and parallel calls introduce race conditions. The agent that performed flawlessly at temperature 0 on a 2k-token context window collapses at temperature 0.7 on an 8k-token window. The five failure modes are temperature drift and context window overflow first; silent API errors and prompt drift follow; race conditions complete the set. Each one has a detection pattern and a fix, and this article delivers both plus the CLI tool to automate the detection. Why This Matters AI agent failures differ from traditional software failures in one critical way: they are stochastic. A web API either returns 200 or 500. An AI agent returns something that looks plausible 90% of the time and is catastrophically wrong 10% of the time. That 10% is invisible in manual testing and devastating in production. The economics compound fast because every failed agent interaction wastes tokens, and wasted tokens cost money. At scale, a subtly broken agent burns budget faster than a working one because it retries, loops, and rephrases instead of succeeding. A single temperature drift bug can double your API spend. Reliability is the differentiator. The market is flooding with AI wrappers. The ones that survive will be the ones that work consiste

Three years ago we had our first real outage. Six hours of downtime. Thousands of angry users. Multiple executives on the call. Here's what we did right, what we did wrong, and what we'd do differently. What we did right 1. Communicated immediately. The moment we knew we had a problem, we updated the status page and emailed our biggest customers personally. Not when we had answers. When we had a question. 2. Had a single incident commander. One person making calls. Not a committee. When the CEO tried to direct technical work, the IC politely rerouted and told her where her help was actually needed (talking to customers). 3. Took care of our people. During hour 4, I ordered food. During hour 5, I forced the primary engineer off the call for 20 minutes to walk outside. Long incidents destroy people. You have to feed them and force them to rest. 4. Wrote it down as we went. We had a shared doc with a live timeline. When the post-mortem came, we had every decision captured. What we did wrong 1. Tried to fix the root cause during the incident. For the first 2 hours, we were digging into why the database was struggling. We should have been mitigating (rolling back) first. 2. Let too many people 'help.' By hour 3, we had 12 engineers in the call. Half of them were useless. The IC should have kicked people out sooner. 3. Gave optimistic estimates. 'We'll be back in 30 minutes.' We were not back in 30 minutes. That miscommunication was worse than saying 'unknown.' 4. Didn't prepare the executive communication. The CEO had to answer customer questions in real time with no script. We should have drafted talking points for her after hour 1. What we'd do differently Mitigate first, investigate second. Always. Cap the number of active engineers at 4 during an incident. Others go on standby. Default to 'unknown' for estimates. Only give a number when we're sure. Assign someone explicitly to 'executive liaison.' Their job is to keep the C-suite informed without interrupting the tec

If you’ve been following my previous posts, you know I’m a big advocate for Trunk-Based Development and shrinking your pull requests until they almost feel too small. In a perfect world, developers merge code directly into the main branch multiple times a day, everything flows smoothly, and production remains rock solid. But let’s be honest. When you actually try to pitch this to a backend team working on a core system, you almost always hit the exact same wall of resistance. Someone in the back of the room will inevitably raise their hand and ask: “That sounds great in theory, but I’m currently refactoring our legacy checkout service. It’s going to take me four days of deep architectural changes. Are you seriously telling me I should merge half-baked, broken code into the main trunk and push it straight to production where real customers are buying our products?” It’s a completely valid objection. If your only tool for hiding uncompleted work is holding onto a massive, long-lived feature branch, then trunk-based development breaks down immediately. You end up with the exact nightmare we talked about earlier: huge code reviews, painful merge conflicts, and code that rots before it ever sees a live environment. To make continuous delivery actually work without causing catastrophic production outages every single afternoon, you need to decouple two concepts that most engineering teams mistakenly treat as the exact same thing: Deployment and Release . Last article in this category is focused on Trunk-Based Development: https://codecraftdiary.com/2026/05/18/trunk-based-development-roadmap/ The Core Concept: Shifting Left by Decoupling In traditional development setups, deploying code and releasing a feature happen simultaneously. You merge your giant feature branch, the CI/CD pipeline runs, the code hits the live servers, and boom—your users immediately see the new functionality. This model is incredibly high-stakes. If something goes wrong, your only options are rollin

Most organizations still think of the hypervisor as a resource abstraction layer. CPU. Memory. Storage. The platform that decides where workloads run. That mental model is increasingly incomplete. Every major virtualization platform — vSphere, AHV, Proxmox — has been steadily accumulating policy enforcement responsibilities. The hypervisor isn't just deciding where workloads run. It's increasingly deciding what they're allowed to do. The Speed of the Shift Is the Real Story Virtualization practitioners already know security controls have moved downward through the stack. What's less appreciated is how compressed the most recent phase has been. For years, hypervisors enforced resource allocation. Within a single platform generation cycle, that same layer accumulated encryption policy enforcement, workload trust validation, microsegmentation, secure boot enforcement, host attestation, and workload isolation boundaries — not as optional add-ons, but as core platform capabilities. The perimeter-to-OS transition took decades. The hypervisor accumulated a comparable policy enforcement surface in the time between one major vSphere release and the next. That compressed timeline is what creates the ownership lag — the governance model adequate for a resource scheduler has not caught up to a platform that enforces organizational policy. The Hypervisor Now Makes Binding Decisions The distinction that matters: a platform that observes policy versus a platform that enforces it. The hypervisor is no longer observing. It is enforcing. VM fails attestation → workload does not start. Encryption policy mismatch → workload cannot migrate. Segmentation policy violation → communication blocked at the platform layer. Trust validation failure → host removed from workload eligibility. Those are not scheduling decisions. Those are governance outcomes. The workload doesn't get a vote. This is what makes the hypervisor governance infrastructure : infrastructure that directly enforces organiza

A lot of teams start their LLM stack with one model string in application code. That is fine for prototypes. It becomes painful once multiple products, customers, background jobs, and fallback paths all share the same AI budget. At that point, an OpenAI-compatible gateway should not just be a convenience proxy. It should become a control plane: the place where routing, quotas, cost attribution, keys, and failover are managed consistently. Here is the checklist I use when evaluating whether a gateway setup is production-ready. 1. Keep the SDK surface stable Your application should not need to know every provider-specific header, endpoint, or auth detail. A simple OpenAI-compatible client shape keeps provider changes out of the main code path: from openai import OpenAI import os client = OpenAI ( api_key = os . environ [ " AI_GATEWAY_API_KEY " ], base_url = os . environ . get ( " AI_GATEWAY_BASE_URL " ), ) The app should usually call a logical model or route. Provider-specific decisions should live in gateway configuration where they can be reviewed and changed safely. 2. Route by feature, not by vibes A global default model is easy to start with, but it hides important differences between workloads. A better routing table looks like this: Feature Default tier Fallback tier Budget sensitivity Classification low-cost fast model second low-cost model high Support summary low/mid model mid model high Customer chat mid/frontier model safe fallback medium Coding/analysis strongest reliable model reasoning model low/medium Background enrichment batch/cheap model skip/defer very high The goal is not always to use the cheapest model. The goal is to use the cheapest model that reliably clears the quality bar for that feature. 3. Enforce limits at the gateway boundary Do not rely only on scattered application code for cost control. A shared gateway should enforce: per-API-key quotas per-project or per-customer spend caps per-feature token limits provider and model allow-lists e

Kubernetes networking is one of the most misunderstood parts of running containerized workloads. A pod can reach another pod by IP — but why does that stop working after a deployment? A service exists and resolves in DNS — but traffic isn't arriving at the application. An Ingress resource is configured — but requests return 502. These puzzles are common and they stem from the same root: Kubernetes networking has several distinct layers, each solving a different problem, and it's easy to conflate them. This article walks through how Kubernetes networking actually works at each layer — from pod networking to services to Ingress to network policy — so the next time something breaks, you have a mental model to reason from. The fundamental promise: flat pod networking Kubernetes makes one core promise about networking: every pod can communicate directly with every other pod in the cluster without NAT. Every pod gets a real IP address from the cluster's pod CIDR range, and those IPs are routable between pods regardless of which node they're running on. This is not something Kubernetes itself implements. It's a contract that every Kubernetes-conformant CNI (Container Network Interface) plugin must fulfill. When you install Calico, Cilium, Flannel, Weave, or any other CNI, you're installing the component that actually creates this flat network. The mechanism varies — Flannel uses VXLAN overlays, Calico can use BGP for direct routing, Cilium uses eBPF — but the result is the same: pod-to-pod communication without NAT. Here's what a pod's network namespace looks like: $ kubectl exec -it my-pod -- ip addr 1: lo: ... 3: eth0@if12: ... inet 10.244.1.15/24 brd 10.244.1.255 scope global eth0 $ kubectl exec -it my-pod -- ip route default via 10.244.1.1 dev eth0 10.244.0.0/16 via 10.244.1.1 dev eth0 The pod has an IP ( 10.244.1.15 ) on a /24 subnet. The node this pod runs on has an IP from the same range — or a different /24 within the same /16. Traffic from this pod to 10.244.2.8 (

The IaC landscape split into two philosophies about a decade ago and hasn't fully resolved the argument since. On one side: declarative configuration languages designed specifically for infrastructure (Terraform HCL, CloudFormation YAML, Bicep). On the other: general-purpose programming languages brought to infrastructure (AWS CDK, Pulumi). Both approaches have won in production at major organizations. Neither is clearly superior. This comparison covers Terraform, AWS CDK, and Pulumi in depth — how they work, where they excel, where they struggle, and which makes sense for different team situations. It isn't a beginner introduction to any of these tools; if you're choosing between them for a real project, this assumes you've at least skimmed each one. The core philosophical difference Terraform's HCL is a purpose-built configuration language. It's not Turing-complete (no arbitrary loops, no recursion, limited conditionals). This is by design: HashiCorp's position is that infrastructure definitions should be readable, predictable, and safe to generate tooling around. When you read a .tf file, you can understand what it creates without executing anything. CDK and Pulumi take the opposite position: the limitations of configuration languages are a tax on productive engineers. Why invent a domain-specific language when TypeScript already exists? Real programming languages have proper abstractions, test frameworks, package managers, IDE support, and a billion engineers who already know them. Infrastructure should be no different from application code. Both positions have merit. The choice between them often comes down to who's writing the infrastructure more than which approach is technically superior. Terraform Terraform is the default choice for infrastructure-as-code in 2026. It works with every major cloud provider and hundreds of minor ones. The Terraform Registry has thousands of modules — reusable packages for common patterns like VPCs, EKS clusters, and RDS databa

This field test was against Kubernetes. The issue was Kubernetes #138728: https://github.com/kubernetes/kubernetes/pull/139545 The issue involved the watch cache path around initial events. The useful diagnostic boundary was: watch cache consistency work → read lock hold time → initial event delivery That matters because cache paths in Kubernetes are not just storage details. They sit between stored state and the clients watching that state. If too much work happens while a cache lock is held, the system may still be logically correct, but the operational path can become more expensive, more blocking, or harder to scale than it needs to be. The local repair candidate is intentionally narrow. It does not redesign the watch cache. It does not change the broader storage model. It does not rewrite WatchList behavior. The patch focuses on reducing how much work happens while the watch-cache read lock is held. For ordered stores, the repair keeps the cheap snapshot boundary during interval construction, but defers full ordered list materialization until the interval is consumed by the watcher path. In plain terms: Take the necessary cache boundary under lock. Do not do heavier list materialization there if it can be safely deferred. The local patch touched only the watch-cache interval implementation and its focused tests. Local validation passed for the relevant cacher tests, store tests, full cacher package tests, and diff hygiene. Status: draft PR opened for maintainer review Field Test #013 Project: Kubernetes Issue type: watch-cache / initial-events behavior Boundary: cache consistency work under lock vs bounded watcher consumption Result: narrow local repair candidate and focused test coverage Status: local proof prepared; no public PR or comment opened yet This field test matters because it shows Scarab operating inside a major distributed systems platform. The bug shape was not a simple crash. It was not a UI issue. It was not a configuration mismatch. It was a me