标签：#infra

The 10-Minute Tax For many years, as a CDK developer, I'd run cdk synth , then cdk deploy , and then cross my fingers — either it deployed cleanly, or it failed somewhere in the middle of a CloudFormation run that had already been going for ten minutes: ❌ MyStack failed: UPDATE_ROLLBACK_COMPLETE Resource handler returned message: "The runtime parameter of nodejs16.x is no longer supported" (HandlerErrorCode: InvalidRequest) Ten minutes. For something CDK could have told you before it ever talked to CloudFormation. These days I let AI agents write a good chunk of my CDK code, which made this even worse — an agent can't iterate when every failed attempt costs it ten minutes. 🤖 AI Agent development loop: Attempt 1: cdk deploy → ⏱️ 10 min → ❌ deprecated runtime Attempt 2: cdk deploy → ⏱️ 10 min → ❌ invalid memory size Attempt 3: cdk deploy → ⏱️ 10 min → ❌ security group rule conflict Attempt 4: cdk deploy → ⏱️ 10 min → ✅ finally works Total time wasted: 30 minutes on things that were knowable at synth time. And if you're deploying something heavy like an Amazon EKS cluster, the penalty stretches to 25-30 minutes per failed attempt. What if the CDK could catch all of those on cdk synth — in seconds? The CDK Lifecycle: Where Validation Fits Before I show off the new validation, it helps to see where it plugs into the lifecycle every cdk deploy goes through: Stage What Happens Executed By 1. Construction Execute main.ts , call new Stack() , build the construct tree in memory CDK App (local) 2. Synth app.synth() traverses the tree, produces CloudFormation template to cdk.out/ CDK App (local) 3. Template Validation 🆕 Post-synth offline validation — default rule set + registered policy plugins CDK App (aws-cdk-lib, local) 4. Create Change Set 🆕 CloudFormation pre-deployment validation — 6 types of online checks against real account state CloudFormation (AWS) 5. Execute Change Set CloudFormation provisions/updates/deletes actual AWS resources CloudFormation (AWS) The gap was a

The Other Half of Compute xAI stood up its first 100,000 GPUs in Memphis in 122 days. It doubled that in another 92. By early 2026 the site, Colossus, held around 555,000 of them, building toward two gigawatts of power, for a reported 18 billion dollars. 1 Two sophisticated people can look at that number and reach opposite conclusions. Jensen Huang’s view is that the only real risk is underspending. He puts the buildout at a trillion dollars and counting, and argues the company that holds back capacity loses the decade. 2 Dario Amodei and Ray Dalio sit on the other side. Amodei has said it can be rational not to buy unlimited compute, because the revenue to justify it may arrive on a timeline that bankrupts whoever guessed wrong. Dalio keeps making a narrower point: a technology can succeed completely and still ruin the people who financed it. 3 Same buildout. Same dollar figure. One camp calls it the obvious move of the decade and the other calls it the setup for a wipeout. They are not disagreeing about the facts. They are reading the same number and the number is the problem. What 18 billion dollars buys Every token a model produces runs down a physical path. Electricity has to be generated, moved across a grid, and stepped down through transformers to a voltage a data centre can use. Chips have to be fabricated at advanced nodes, which in practice means TSMC and a single supplier of the lithography machines that make the process possible. The chips have to be wired together with optical interconnect, assembled into racks, and kept cold. None of those layers move at the same speed, and the slowest one always sets the schedule. For four years the slowest layer kept changing. In 2022 the constraint was GPUs themselves. In 2023 it was the high-bandwidth memory stacked next to them. In 2024 it was the advanced packaging that bonds the two together. By 2025 it was photonics, the lasers and transceivers that move data between racks. By 2026 it had reached power and the

Lessons from building a small VPN service around standard WireGuard clients instead of a proprietary app When you look at a commercial VPN product, the app seems to be the product: a polished interface, a country list, and a large Connect button. I chose the opposite approach. Instead of building another VPN client, I decided to give users a standard WireGuard configuration that they could import into an existing client. That decision removed a lot of client-side work — but it also exposed where the real complexity of a VPN service actually lives. Why build another app if WireGuard already has one? The usual commercial VPN flow is straightforward: install the vendor's app, sign in, choose a location, and connect. A proprietary client can manage server selection, subscriptions, kill switches, automatic reconnects, diagnostics, updates, and support in one place. But for a small service with one or a few locations, I had to ask a more basic question: do I really need to build and maintain a separate Windows, macOS, Android, and iOS client just to establish a WireGuard tunnel? WireGuard already has mature clients across the major desktop and mobile platforms. A user can import a configuration file or scan a QR code and get a normal VPN toggle. On paper, that looked like a very attractive tradeoff: less client code, fewer update mechanisms, fewer installers, and a smaller attack surface to maintain. What I underestimated was that the app was never going to be the hardest part. A .conf file is not just a settings file The first architectural lesson was simple but important: a WireGuard configuration is effectively a credential. It contains the client's private key. A QR code that represents the same configuration contains the same sensitive material in another form. That immediately creates product problems that have nothing to do with the tunnel itself. How do you show the configuration safely? What happens if the user loses it? Can you issue a replacement without leavin

Originally published at vinpatel.com What is actually inside the Department of Energy's new Genesis Open Models Initiative? Right now, the honest answer is: a name, a URL, and a lab crest. The claim, as DOE has made it by putting the initiative live at genesisopenmodels.anl.gov, is that the federal government is now in the open-model business — training or releasing AI systems the way Meta releases Llama or Mistral releases its weights, except under a federal national lab's letterhead instead of a Silicon Valley one. The .anl.gov domain ties it directly to Argonne National Laboratory, a DOE lab that runs some of the country's largest public research compute. Here is what is measurable today: a hostname registered under a DOE national laboratory's domain, and a title. That is the entirety of what's publicly documented about this launch right now. No model card. No parameter count. No benchmark table. No license terms. No dataset provenance. If you went looking for the thing the name promises — an open model you can download, fine-tune, or audit — you'd come away with a URL and nothing to point a training run or a procurement memo at yet. That gap is not evidence of a bluff. It's what federal AI launches look like structurally. National labs run compute clusters under export-control review, multi-agency sign-off, and clearance processes that have nothing to do with how fast a model can actually train. A private lab ships a checkpoint the day it clears internal review. A DOE initiative clears communications, legal, and interagency review before it clears a single line of a model card — and the announcement is often the artifact that exists first, because it's the cheapest one to produce. The site can go live in an afternoon. The weights cannot. What would actually close this gap is specific and checkable: a published model card with parameter counts and training data provenance, an open license attached to real downloadable weights, and benchmark numbers outside resear

Introduction: Cloud computing has transformed the way individuals, businesses, educational institutions, and governments store, manage, and access data and applications. Rather than relying solely on physical servers and local infrastructure, cloud computing allows users to access computing resources over the internet on demand. Popular cloud service providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform offer scalable, secure, and cost-effective solutions that support everything from email services to artificial intelligence and big data analytics. Although cloud computing offers numerous benefits, it also presents certain challenges that organizations should consider before adopting cloud-based solutions. Understanding both the advantages and disadvantages helps businesses make informed decisions that align with their operational and strategic goals. What is Cloud Computing? Cloud computing is the delivery of computing services—including servers, storage, databases, networking, software, analytics, and artificial intelligence—over the internet ("the cloud"). Instead of purchasing and maintaining expensive hardware, users pay only for the resources they consume, making cloud computing flexible and cost-efficient. Advantages of Cloud Computing: Cost Savings One of the greatest advantages of cloud computing is its ability to reduce IT costs. Organizations no longer need to invest heavily in purchasing servers, networking equipment, and data centers. Cloud providers also handle hardware maintenance and software updates, reducing operational expenses. Scalability and Flexibility Cloud computing enables organizations to scale resources up or down depending on demand. Businesses experiencing seasonal spikes can quickly allocate additional computing resources without purchasing new hardware. High Availability and Reliability Leading cloud providers maintain multiple geographically distributed data centers. This redundancy ensures high avai

Taking vibe-coding a step further, Naïve claims its infra can automate most of the work in setting up and running a business.

TL;DR: Grafana Agent reached End-of-Life on November 1, 2025 and has been replaced by Grafana Alloy. Alloy consolidates Agent's Static mode, Flow mode, and Kubernetes Operator into a single collector built on the OpenTelemetry Collector while maintaining native support for Prometheus and Loki. If you're using Flow mode, migration is relatively straightforward. If you're using Static mode, the migration process will involve reviewing and testing the converted configuration. Before switching over, verify relabeling rules, recheck resource usage, and confirm that Prometheus and Loki are receiving the same data and labels as before. If you're still running Promtail, it's worth migrating both to Alloy at the same time since Promtail is also End-of-Life. If you deployed Grafana Agent a couple of years ago, there's a good chance you haven't thought about it since. It quietly collects metrics, ships logs, and generally stays out of the way. What you may not realize is that Grafana Agent reached End-of-Life on November 1, 2025. That includes Static mode, Flow mode, and the Kubernetes Operator. Grafana Labs has stopped creating bug fixes, security patches, and official support. If you're still running it, your collection layer is probably still performing normally, but is now unsupported. That doesn't necessarily mean it will stop working tomorrow, plenty of unsupported software continues running for years. It does mean you're taking on the risk yourself, especially as the rest of your monitoring stack continues to evolve. This article covers why Grafana Labs replaced Agent with Alloy, what actually changes during the migration, and where people tend to run into problems. Why Grafana Agent was deprecated One of the biggest issues with Grafana Agent is that it was essentially three agents, not one product: Static mode, which used YAML and looked similar to Prometheus. Flow mode, which introduced a component-based configuration using River. The Kubernetes Operator, which manage

Your AI bill tripled last quarter. Your CTO forwarded you an article about companies saving 70% by switching to open models. Now someone is asking you to figure out what that would actually look like. I spent the last few weeks digging into this. The numbers, the hardware, the real trade-offs. Here's what I found, with enough specifics that you can actually make a decision rather than just nodding along to another "open source is the future" think piece. What "Open Models" Actually Means When someone says "open model" they mean an AI model where the weights (the learned parameters that make the model work) are publicly downloadable. You grab the file, run it on your hardware, and you don't pay anyone per request. The big names right now: Meta's Llama 4, DeepSeek V4, Zhipu's GLM-5.2, Moonshot's Kimi K3, Alibaba's Qwen 3.5, and Google's Gemma 4. These aren't toys. Some of them genuinely compete with the frontier models on real benchmarks. Chinese open models now handle over 30% of enterprise traffic on OpenRouter, up from 4.5% in early 2025. That's a massive shift in barely a year. The Architecture: What You Actually Need You want your team to use an open model. Here's the stack, from bottom to top. Hardware (The Expensive Part) A model is a giant file. We're talking anywhere from 4 GB (a small 7B model, quantized) to 1.5 TB (Kimi K3, full weights). That entire file needs to sit in GPU memory to run fast. Why GPU memory specifically? Because generating each word in a response requires billions of multiply-and-add operations. GPUs do thousands of these in parallel. A CPU does them one at a time. The practical difference: a 7B model on a CPU generates 2-5 tokens per second (painfully slow for interactive use). The same model on a GPU generates 30-80 tokens per second (feels instant). For one person on a CPU, it might be tolerable. For a team of 10 all hitting the same endpoint? Unusable. Requests queue up and everyone waits 30-60 seconds for responses. Think of it like

Governor who touted Texas as AI “epicenter” pauses data center grid connections.

Attribution is preliminary , and so far it seems no real damage. And it seems like this is a campaign that has targeted at least seven states . And, because this is where the US is right now, Trump doesn’t believe it’s Iran and that Minnesota…I guess…hacked itself. “I think I blame it on Minnesota because they’re grossly incompetent,” Trump said. “I would blame it on Minnesota and the governor, the corrupt governor of Minnesota. They like to say, ‘Oh, it’s Iran.’ Iran should be so lucky. Iran’s got bigger problems than worrying about Minnesota.”...

Last week I was doing a routine check on a CyberPanel server and noticed something that didn't add...

Por que usar o Cloudflare em vez do DNS padrão do seu registrador Escrevi esse texto depois de um perrengue aqui na empresa onde trabalho. Precisei registrar uns subdomínios, entrei no painel da Cloudflare esperando achar os registros lá e não tinha nada, fui atrás do time para entender onde aquilo estava apontando e a resposta foi que tudo passava direto pelo provedor de domínio. Quando você registra um domínio na GoDaddy, Namecheap, Registro.br ou qualquer outro provedor de domínio, ele já vem com um par de nameservers configurados por padrão. Funciona, mas "funcionar" e "ser a melhor opção para produção" são coisas diferentes, e trocar esses nameservers pelos da Cloudflare é uma das mudanças de maior custo-benefício que dá para fazer em um projeto. O que muda ao trocar os nameservers Um provedor de domínio só precisa resolver DNS: publicar seus registros A, CNAME, MX e afins, e responder consultas. A infraestrutura por trás disso varia muito de provedor para provedor e raramente é otimizada para latência global ou resiliência a ataques, porque não é o produto principal deles. A Cloudflare constrói a rede em torno de DNS, CDN e mitigação de DDoS como núcleo do negócio, e isso aparece em números concretos: a rede anycast cobre mais de 330 cidades, então uma consulta DNS ou uma requisição HTTP é respondida pelo ponto de presença fisicamente mais próximo do usuário, não por um servidor central do outro lado do mundo. Hoje a Cloudflare responde por algo em torno de 23% de todos os sites da internet. Vantagens técnicas O anycast é a base de tudo. Não existe "o servidor DNS" que pode cair: se um ponto de presença fica indisponível, o tráfego é roteado automaticamente para o mais próximo, o que reduz latência de resolução e risco de indisponibilidade. A mesma arquitetura, combinada a TTLs baixos, também acelera a propagação de mudanças: um registro DNS alterado costuma valer em minutos, enquanto em boa parte dos provedores de domínio tradicionais não é incomum esperar ho

HashiCorp has introduced tfpolicy, a new HCL-based policy-as-code framework for Terraform, now available in public beta within HCP Terraform. It is designed to simplify and modernize infrastructure governance by integrating policy creation and enforcement directly into Terraform workflows, eliminating the need for separate tools and languages. By Sergio De Simone

Wavelength and intensity in the infrared are translated into colors in the visible.

Kubernetes makes it easy to define CPU and memory requests for our applications. But there is a problem: How do we know whether those resource requests are actually correct? If an application requests: yaml resources: requests: cpu: "1000m" memory: "1Gi" but normally consumes only a few millicores of CPU and a few megabytes of memory, we may be reserving significantly more cluster capacity than the workload actually needs. I wanted to understand how Kubernetes cost optimization platforms detect this situation, so I built a small hands-on lab using: Google Kubernetes Engine (GKE) CAST AI Kubernetes Docker FastAPI Google Artifact Registry The goal wasn't simply to install CAST AI. I wanted to observe the complete process: Deploy workload ↓ Observe resource usage ↓ Compare requests vs usage ↓ Identify over-provisioning ↓ Generate recommendation ↓ Apply rightsizing ↓ Verify from Kubernetes Architecture The lab architecture was intentionally simple. FastAPI Coffee API | v Docker Image | v Google Artifact Registry | v GKE Cluster | v Kubernetes Deployment | +----------------+ | | v v Pod #1 Pod #2 | | +-------+--------+ | v ClusterIP Service + | v CAST AI | +-------+-------+ | | v v Cost Monitoring Workload Optimization 1. Building a Small Test Application I created a very small FastAPI application for the experiment. from fastapi import FastAPI import socket import os import time app = FastAPI() @app.get("/") def home(): return { "message": "Coffee Shop API", "hostname": socket.gethostname(), "pod": os.getenv("HOSTNAME"), "time": time.time() } @app.get("/coffee") def coffee(): return { "coffee": "Cappuccino", "price": 120 } The hostname in the response was useful later because I could see which Kubernetes Pod handled each request. 2. Containerizing the API The application was packaged using Docker. FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 8000 CMD ["uvicorn", "app:app", "--host", "0

British AI neocloud Nscale is buying software startup Anyscale, which helps companies scale their AI workloads across data centers and servers.

The Series A was led by Khosla Ventures, with participation from Allianz, Rebel Fund, Brick and Mortar Ventures’ Darren Bechtel, and Y Combinator’s Garry Tan.

Let's Encrypt issues TLS certificates with a 90-day validity period by default. However, as the industry is gradually shortening TLS certificate lifetimes—with the maximum eventually expected to fall to 47 days—Let's Encrypt already offers certificates using the tlsserver profile with a validity period of 45 days. Compared with the current default classic profile, the tlsserver profile removes deprecated attributes such as the Common Name. Because it follows the latest recommended configuration, it also produces slightly smaller certificates. The differences between the profiles are documented on the following page. If you have already automated certificate issuance and renewal, it is worth considering an early move to the tlsserver profile. Certificate Profiles - Let's Encrypt Certificates issued with the classic profile are currently valid for 90 days. However, the validity period is scheduled to be shortened to 64 days in February 2027 and then to 45 days in February 2028. Certificate renewal automation is easy to leave untouched once it is working, and many monitoring systems also use fixed day-based thresholds. Both renewal automation and monitoring therefore require careful review. Decreasing Certificate Lifetimes to 45 Days - Let's Encrypt With only about six months remaining before the validity period is reduced to 64 days, now is a good time to begin validating your systems. Let's Encrypt also provides the shortlived profile for certificates that support IP addresses. These certificates are valid for only six days. With such a short lifetime, using them without automation is no longer practical. 6-Day and IP Address Certificates - Let's Encrypt To issue certificates using any of these profiles, you need an ACME client that supports ACME profile selection. Widely used clients such as Certbot should be able to issue them without difficulty. Issuing a certificate with the new tlsserver or shortlived profile is straightforward. The harder part is keeping it ren

When you open a website, send a message, or watch a YouTube video, many technologies work together in the background. As a beginner in DevOps, understanding these basic networking concepts will help you understand how applications communicate over the internet. **What Is a Protocol? A protocol is a set of rules that devices follow when communicating with each other. Think about two people having a conversation. For communication to be successful, both people must speak the same language and follow simple rules, like taking turns to talk and listening before responding. Computers work the same way. They use protocols to know how to send, receive, and understand information. Without protocols, computers would not be able to communicate with one another. **2. What Is Packet Switching? **Imagine you want to send a large book to a friend. Instead of sending the entire book in one huge package, you divide it into many smaller packages. Each package travels separately and, when they all arrive, your friend puts them back together in the correct order. This is exactly how the internet works. When you visit a website, your data is broken into small pieces called packets. Each packet travels across the internet and is reassembled when it reaches its destination. This process is called packet switching, and it makes internet communication faster and more reliable. **3. What Is an IP Address? **Every house has a unique address that helps delivery drivers know where to deliver packages. Similarly, every device connected to the internet has a unique Internet Protocol (IP) address. An IP address helps the internet know exactly where information should be sent. Without an IP address, websites, computers, and phones would not know where to send or receive data. **4. What Is TCP/IP? **Breaking data into packets is not enough. The packets must also arrive correctly. This is where TCP/IP (Transmission Control Protocol/Internet Protocol) comes in. IP finds the correct destination for ea

Github URL: https://github.com/SID-Technologies/Pilum In December 2025, I open-sourced Pilum , a multi-cloud deployment CLI that deploys to Cloud Run, Lambda, Azure, Cloudflare Pages, npm, Homebrew, and Docker Hub from a single pilum.yaml . The announcement post covered the architecture: recipes, ingredients, handlers, wave-based execution. That was the "it compiles and the tests pass" version. Three months and 40+ pull requests later, Pilum deploys all of SID Technologies , platform-core, Torch, Statio, every website, every npm package, and itself. This post is about everything that broke between "it works" and "it ships production software." ( Update: * there's now a seven-months-in addendum at the bottom. It's mostly about what stopped breaking.)* The Timeline Dec 2, 2025 : First commit. Baseline CLI with recipe system. (#1) Dec 4 : Homebrew release workflow. Pilum dogfoods its own deployment. (#2-#4) Dec 31 : Service graph, --only-changed , file embedding support. The "I need this for real" features. (#22-#24) Jan 3-12 : Documentation and bug fixes. The quiet "oh, this doesn't actually work" phase. (#25-#29) Feb 6-7 : The big feature sprint — 8 features in 48 hours. Wave deployments, npm recipe, Cloudflare Pages, Azure Container Apps, Cloud Run Jobs, environment variables, JSON output, history command. (#30-#38) Feb 8-12 : The big fix sprint — YAML parsing, package manager issues, build failures, error swallowing, GCP secrets, Cloudflare execution. Everything from the feature sprint broke something. (#42-#49) Feb 24 : Security hardening and npm publishing fixes. (#51-#53) Mar-Apr : Memory-based worker allocation, wave ordering bug, orchestrator rewrite. The "I thought this was done" phase. (#58-#62) The pattern is clear: features ship fast, fixes ship faster, and the real bugs show up a month later. Wave-Based Deployments Were Broken Wave-based deployment was the headline feature in #31. Services declare dependencies, Pilum builds a dependency graph, topological