标签：#infra

AWS released Blocks in public preview, an open-source TypeScript framework where each Block bundles application code, local mocks, and AWS infrastructure. Designed for AI agents to write correct backends from the start, it runs locally without an AWS account and deploys the same code to Lambda, DynamoDB, Aurora, and Bedrock with zero changes. By Steef-Jan Wiggers

GitOps policy drift is what happens when a control plane keeps a policy perfectly reconciled long after the reason for that policy has stopped being true. Every commit is applied. Every pull request is merged cleanly. Every dashboard reads green. And the rule being enforced no longer reflects anything anyone would choose to enforce today — it just hasn't been told to stop. That gap is the subject of this post. Not configuration drift — the thing GitOps was built to kill — but a second, quieter failure mode that lives one layer above it: the policy is right by every technical measure and wrong by every practical one, and nothing in the reconciliation loop is capable of telling the difference. The Promise GitOps Actually Kept GitOps earned its place in the infrastructure as code architecture stack by solving a real and expensive problem: state drift. Before declarative reconciliation, infrastructure diverged from its source of truth constantly — a console change here, an emergency hotfix there, a manual override nobody logged. The git repository said one thing. Production said another. Reconciling the two was a forensic exercise. GitOps closed that gap with a simple, durable mechanism: a controller that continuously compares declared state to actual state and corrects the difference without waiting for a human to notice. That's not a small win. It's the reason platform teams can run infrastructure at a scale that would have been operationally unmanageable a decade ago, and it's why GitOps controllers sit at the center of nearly every modern infrastructure as code architecture built since. This post isn't an argument against that mechanism. It's an argument that the mechanism's success created a blind spot nobody designed for. What GitOps Never Promised to Solve Here's the boundary GitOps was never built to cross: reconciliation proves that declared state and actual state match. It says nothing about whether the declared state should still exist in its current form. A

You already have Playwright tests. They run in CI on every pull request, they assert that login works and checkout completes, and then they stop — because CI only runs them against a branch, at merge time. The moment the code is in production, those tests go silent. A third-party script breaks checkout at 3 AM and your perfectly good test suite says nothing, because nothing triggered it. Playwright monitoring closes that gap: you take the same browser tests and run them on a schedule against production, turning your end-to-end suite into a synthetic monitoring system that watches real user journeys continuously. Prerequisites Node.js 18+ and an existing project ( npm install -D @playwright/test , then npx playwright install chromium ). A deployed production (or staging) URL to run checks against. A dedicated synthetic test account — never a real customer's credentials. A secret store for that account's credentials (GitHub Actions secrets, or your platform's equivalent). Never hard-code them. Step 1 — Write a check that asserts on what the user sees A monitor-grade check is not "did the page load." It is "could a user complete the thing they came to do." Assert on the outcome, with a generous timeout for real-world latency: import { test , expect } from " @playwright/test " ; test ( " checkout reaches confirmation " , async ({ page }) => { await page . goto ( " https://shop.example.com " ); await page . getByRole ( " button " , { name : " Add to cart " }). click (); await page . getByRole ( " link " , { name : " Checkout " }). click (); await page . getByLabel ( " Email " ). fill ( process . env . SYNTHETIC_EMAIL ! ); await page . getByLabel ( " Card number " ). fill ( " 4242424242424242 " ); await page . getByRole ( " button " , { name : " Pay now " }). click (); // The assertion a 200 OK can never make for you: await expect ( page . getByText ( " Order confirmed " )). toBeVisible ({ timeout : 15000 , }); }); Credentials come from process.env , not the source. The t

One of the most common system design interview questions is: "How would you scale a web application from 100 users to 100 million users?" The answer is rarely a single technology. Instead, systems evolve through multiple stages, with each stage solving a specific bottleneck. This article walks through the typical evolution of a scalable system and explains why , how , and when each component is introduced. 1. Single Server Why Start Here? Every application starts simple. In the beginning: Traffic is low Development speed matters more than scalability Infrastructure costs should be minimal What Is It? A single machine handles everything: Frontend Backend Database Users | v Single Server ├── Application └── Database How Does It Work? User sends request. Application processes request. Database stores and retrieves data. Response is returned. Everything happens on one machine. Problem As traffic grows: CPU becomes overloaded Memory becomes insufficient Database competes with application for resources A single server becomes a bottleneck. Interview One-Liner A single server architecture is simple and cost-effective but becomes a bottleneck as traffic and resource usage increase. 2. Application and Database Separation Why Do We Need It? The application and database have different workloads. Application Server: Uses CPU Handles business logic Database Server: Uses memory and storage Handles queries Keeping them together causes resource contention. How Does It Work? Move the database to a separate machine. Users | v Application Server | v Database Server Benefits Independent scaling Better resource utilization Improved performance Example Suppose an e-commerce website receives thousands of requests. The application handles: Authentication Order processing API responses The database handles: Product data Orders User information Separating them prevents one workload from affecting the other. Interview One-Liner Separating the application and database allows each layer to scal

Dialogue management is the process of tracking conversational state and deciding what an agent should say or do next. Classical systems split this into isolated modules: natural language understanding, dialogue state tracking, a policy engine, and response generation. Large language models can collapse these boundaries into a single inference step, but doing so reliably requires careful architecture choices. This article examines practical patterns for using LLMs as dialogue managers, with a focus on structured reasoning, tool use, and cost-efficient inference. What Is LLM Dialogue Management? An LLM-based dialogue manager treats conversation as a partially observable decision process where the model itself reasons over history, user intent, and available actions. Instead of hand-written rules or separate slot taggers, the model receives the full transcript, a system prompt defining the task, and optionally a schema of tools it can invoke. The model then emits either natural language or structured JSON representing the next system action. This approach excels in open-domain or rapidly changing domains where maintaining a rigid ontology is impractical. Architecture Patterns for LLM-Based Dialogue Most production implementations fall into one of four patterns. The right choice depends on how much control you need over state transitions and how willing you are to trade complexity for flexibility. End-to-end generation. The LLM receives the full chat history and outputs the next response. It works well for unstructured chit-chat but can hallucinate state or ignore business rules without additional guardrails. Structured state extraction. The LLM is prompted to output a JSON object representing dialogue state, such as slots, user intent, and confirmed facts. A lightweight policy layer reads this state to decide whether to ask a question, call an API, or close the task. This separates reasoning from control and makes debugging easier. Tool-augmented manager. The LLM uses

Few-shot learning with large language models is one of the most practical ways to steer model behavior without updating weights. By embedding task-specific examples directly into the prompt, developers can turn a general-purpose foundation model into a domain-specific classifier, parser, or reasoning engine. The technique relies on in-context learning, where the model infers patterns from exemplars rather than from gradient updates. Because it requires no training pipeline, few-shot prompting is ideal for rapid prototyping and production tasks where data volumes are too small for fine-tuning or where model weights must remain frozen. The Mechanics of In-Context Learning In-context learning is an emergent capability of transformer-based language models. During inference, the model attends to the full context window, using the provided examples as a dynamic prior. Each example adjusts the hidden-state activations for subsequent tokens, effectively conditioning the output distribution without any parameter change. Research suggests that the model locates latent task representations within its pretrained weight space and uses the few-shot examples to activate the appropriate subspace. The result is a flexible interface: change the examples, and the model adapts its behavior immediately. Zero-Shot, One-Shot, and Few-Shot Prompting These three patterns describe how much guidance you provide before the actual task input. Zero-shot: You describe the task in natural language with no examples. This works best for simple, well-known tasks that the model has seen frequently during pretraining. One-shot: You prepend a single example. This is often enough to communicate output format or tone. Few-shot: You prepend three to ten examples, sometimes more for complex schema extraction or multi-label classification. The marginal gain from each additional example typically diminishes, but for tasks with rigid output schemas, a larger set of exemplars can substantially improve consisten

I run a hosting company. I'm also a BCA student. These two things coexist somehow. GigaNodes started in 2022 as a game server hosting brand — Minecraft, FiveM, ARK, the usual. Over time it grew into a proper VPS and dedicated server operation under GigaNode Technologies Private Limited, with AMD EPYC 7C13 hardware co-located at Yotta DC Noida. Earlier this year we did something I haven't seen any other Indian hosting provider do: we deployed Cloudflare Magic Transit across our entire network. What that actually means Magic Transit is not Cloudflare CDN. It is not a proxy. It is Cloudflare's enterprise network product where your IP prefixes get announced via BGP into Cloudflare's global backbone. All traffic destined for your servers enters Cloudflare's network first, gets scrubbed for attack traffic, and clean packets get forwarded to your data center via GRE tunnel. To deploy it, your infrastructure partner needs to have BGP-level integration with Cloudflare. Individual companies can't just sign up for it. We made it work through our partnership with Advika Datacenters Private Limited (AS135682) at Yotta DC Noida. The result: DDoS traffic never reaches our hardware. Our servers don't see the attack at all. Why no other Indian provider had done this Most Indian hosting providers use blackholing. When an attack comes in, they null-route your IP. Server goes offline. Attack stops eventually. Server comes back. That is the standard. That is what "DDoS protection included" usually means in India. The difference with Magic Transit is that legitimate traffic keeps flowing while attack traffic gets dropped. Your server stays online. Players stay connected. Trades don't get interrupted. We found out pretty quickly this actually works. We took a 1.7 Tbps attack after deployment. The servers didn't notice. A 1.7 Tbps volumetric attack hit our network in May 2026. Cloudflare absorbed it at the edge. No downtime. No support tickets from customers. We found out from the Cloudfla

Paul Klein discusses the distributed systems challenges of scaling cloud-hosted browser infra for AI agents. He explains how to manage bursty, stateful multi-tenancy and secure Chromium environments against remote code execution using Firecracker. He also shares how to leverage the Model Context Protocol (MCP) to turn complex websites into accessible agentic tools. By Paul Klein

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

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

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

HashiCorp has announced the general availability of the Terraform MCP Server, an open-source MCP server that enables agents to integrate with Terraform Registry APIs. The company says that it can improve infrastructure teams productivity by relieving engineers of rote tasks. By Sergio De Simone

I was thinking about some tests for a service that uses language models; there are several, even prompt injection. A question came to mind: is it possible to make multiple requests asking for any text like Lorem Ipsum, generating many unnecessary tokens and incurring costs? But creating a test where there are multiple accounts making the same request to generate 10,000 Lorem Ipsum tokens simultaneously, could that cause a service outage? Because most of the infrastructure I see doesn't use any queuing method when the chat is free of tasks involving an agent or even heavier functionalities. I didn't actually generate anything, I just wanted to start a discussion on this topic.

Published June 17, 2026 by gyorgy Infrastructure used to be something you wrote separately from your application. Lately that boundary has been dissolving, and the vocabulary has not kept up. Three distinct ideas are getting blurred together, partly because they all start from the same place: your code already implies what infrastructure it needs, so why state it twice. They diverge sharply on what they do about that. Here is the short version, then the longer one. The short version Infrastructure as Code (IaC). You describe the infrastructure explicitly, in its own files. The tool turns those files into real resources. Total control, total verbosity, and your infrastructure definition lives apart from your application code. Framework-defined Infrastructure (FdI). The framework infers the infrastructure from your application code, and a managed platform provisions it for you. Almost no configuration, no drift between app and infra, but the inference only covers what the framework exposes, and the resulting infrastructure runs on the platform's rails. Infrastructure as Framework (IaF). The framework reads your applications and generates infrastructure code that you own, deployed into your own cloud accounts. The framework does the inferring, you keep the output and the account. Who writes the infra Who owns the output Where it runs Scope IaC You, by hand You Any cloud Anything you can express FdI The framework The platform The platform What the framework exposes IaF The framework You Your cloud accounts What the framework covers The rest of this is just those three rows, explained. Infrastructure as Code IaC is the established answer. You write declarations, in HCL or a general-purpose language, that spell out the resources you want: this VPC, this load balancer, this database, these IAM bindings. A tool like Terraform or Pulumi reads the declarations and reconciles your cloud to match. The strength is that nothing is hidden. Every resource is something you chose and

AWS recently announced CDK Mixins, a new AWS CDK feature that lets developers add reusable capabilities like security, monitoring, and configuration to AWS resources. Mixins work across different construct types, making infrastructure code more flexible and reusable. By Renato Losio

The IPO market is back, and it’s not the same companies leading the charge. FAANG had a good run, but a new acronym is taking over: MANGOS — Meta (or Microsoft, depending on who you ask), Anthropic, Nvidia, Google, OpenAI, and SpaceX. Half of that bunch is heading to public markets in the same window, and it’s a stress test for investors, for valuations, and for […]

Your pods keep getting killed. Not crashing — killed. One moment they're running fine, the next they're gone and Kubernetes is spinning up replacements. You check the logs and there's nothing useful. The pod just… disappeared. Turns out Kubernetes killed it on purpose. And if you don't tell it how much memory your app actually needs, it'll keep doing it. Why Kubernetes evicts pods Kubernetes runs on nodes — physical or virtual machines that host your containers. Each node has a finite amount of CPU and memory. When a node runs low on resources, Kubernetes has to make a choice: which pods stay, and which ones get evicted to free up space. The decision comes down to QoS classes — Quality of Service tiers that Kubernetes assigns to every pod based on how you've configured resource requests and limits. There are three classes: BestEffort — no resource requests or limits defined. Kubernetes has no idea how much CPU or memory the pod needs. These get killed first. Burstable — requests and limits are defined, but they're different (e.g., requests: 256Mi , limits: 512Mi ). The pod is guaranteed the request amount, but can burst up to the limit. Killed second. Guaranteed — requests and limits are set to the same value. Kubernetes reserves exactly that amount of resources for the pod. Killed last. If your pods don't have resource configuration at all, they're running as BestEffort. And when the node hits memory pressure, BestEffort pods are the first to go — no questions asked. The Guaranteed class Setting your pod to the Guaranteed class is one line in your deployment config. Define requests and limits for both CPU and memory, and make them identical: resources : requests : memory : " 512Mi" cpu : " 500m" limits : memory : " 512Mi" cpu : " 500m" That's it. Kubernetes now knows this pod needs exactly 512 MiB of RAM and half a CPU core, and it reserves that capacity when scheduling the pod onto a node. If a node doesn't have 512 MiB available, the pod won't be placed there. An

In 2025 Google Cloud added G4 , powered by NVIDIA's RTX PRO 6000 Blackwell Server Edition GPUs to their offering, allowing them to offer hardware not only for AI applications, but also for other applications, such as rendering, simulations or gaming. A single G4 instance with one accelerator ( g4-standard-48 ) comes equipped with 48 CPU cores, 180 gigabytes of RAM and 96 gigabytes of GPU memory. This is a lot of resources for a single cloud workstation, that only the most demanding workstreams would utilize. Most professionals who require a graphics accelerator to do their job, don't really need this much compute power for day to day tasks. It wasn't financially reasonable to pay for a G4 instance, when you weren't utilizing all the resources you paid for. If only there were smaller machine types… If only you could share that one very powerful GPU between multiple virtual machines… Introducing fractional VMs! During Google Cloud Next 2026, Google announced GA for fractional G4 VMs and was the first provider to bring vGPU functionality to RTX PRO 6000 accelerators. vGPU stands for virtual graphical processing unit . Just like VMs (virtual machines) are a way to split one physical computer into smaller, independent systems, vGPU allows for a single physical accelerator to be split into 2, 4 or 8 virtual accelerators! The new fractional machine types ( g4-standard-24 , g4-standard-12 , g4-standard-6 ) now allow you to perfectly match the compute capabilities to your needs! Who is it for? The existence of those new machine types makes it much more cost-efficient to move many GPU-dependent tasks to the cloud. Replacing physical workstations in offices with cloud infrastructure is not a new thing , but till now, Google Cloud didn't offer a good platform for those who needed workstations to process images, post-process videos, simulate physics or render 3D graphics. Those users now can get exactly the hardware they need, allowing their companies to move away from maintaini

If you've ever spun up an EC2 instance for a side project, accessed a remote work desktop from your personal laptop, or stored files on Google Drive without thinking about the physical hard drive it lives on, you've used virtualization. As the foundational technology behind all modern cloud computing, virtualization transformed how we build, deploy, and manage IT infrastructure—cutting hardware costs significantly for enterprises and making on-demand scalability a reality for teams of all sizes. In this guide, we'll break down exactly what virtualization is, how it powers the cloud, the 6 core types of virtualization, and best practices to implement it safely and efficiently. Table of Contents What is Virtualization in Cloud Computing? Core Virtualization Concepts You Need to Know Role of Virtualization in Cloud Computing 6 Key Types of Virtualization (With Use Cases) Top Benefits of Virtualization for Teams of All Sizes Virtualization vs. Related Technologies Virtualization vs. Cloud Computing Virtualization vs. Containerization Common Virtualization Challenges and Mitigations Real-World Virtualization Use Cases Virtualization Best Practices Conclusion References What is Virtualization in Cloud Computing? Virtualization is a technology that creates virtual, software-based representations of physical hardware (servers, storage, networks, etc.) and abstracts these resources from the underlying physical machine. A software layer called a hypervisor separates operating systems and applications from physical hardware, allowing multiple isolated, self-contained systems called Virtual Machines (VMs) to run simultaneously on a single physical host. Each VM has its own virtual CPU, memory, storage, and network interface, and operates independently of other VMs on the same host. For cloud providers, this technology is the backbone of all on-demand infrastructure services, allowing them to share physical hardware across thousands of customers securely and efficiently. Core Vi

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