标签：#net

Microsoft is placing greater emphasis on controlling disruption in Azure Kubernetes Service (AKS) Node Auto-Provisioning (NAP), publishing new guidance to help platform teams balance the efficiency benefits of automated node consolidation with application availability. By Craig Risi

Kasia Trapszo discusses how Netflix evolved its commerce platform from a U.S. DVD service into global infrastructure. She explains navigating international payment realities, adapting to strict regulatory mandates, decomposing monolithic architectures along domain boundaries, and re-architecting systems for massive live-event demand - proving great systems survive by continually evolving. By Kasia Trapszo

Meta has detailed MTIA 300, its first in-house accelerator optimized for training ranking and recommendation models. By Matt Foster

If you've provisioned a VPC from a Terraform module without fully internalising what each piece is doing, that's fine — right up until something breaks. An instance that should be reachable isn't. A private instance can't pull a package update. And you're left checking five different resources with no clear mental model of how they connect. This post builds that mental model from the ground up. Not just definitions — the why behind each piece, so troubleshooting becomes deduction instead of guesswork. CIDR math you actually need A CIDR block is IP address / prefix length . The prefix length fixes the network portion; the remaining bits are your host space. Formula: 2^(32 - prefix) = total addresses . AWS reserves 5 per subnet (network address, VPC router, DNS, reserved, broadcast). CIDR Total addresses Usable /16 65,536 65,531 /20 4,096 4,091 /24 256 251 /28 16 11 To reverse-engineer a prefix from a required host count: round up to the next power of two, subtract the exponent from 32. Need 300 hosts? Next power of two is 512 (2⁹), so prefix = 32 - 9 = /23 . Run this before sizing any subnet that will host an autoscaling group or EKS node group. Start with /16 for the VPC itself. VPC CIDR is difficult to resize after the fact — once you have subnets, peering connections, or Transit Gateway attachments built against it, renumbering becomes a migration project. /16 costs nothing up front and avoids that corner. Subnet allocation: carving up the VPC A practical three-AZ production layout from 10.0.0.0/16 : Tier AZ-a AZ-b AZ-c Size Typical use Public 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24 /24 ALB, NAT gateway, bastion Private/app 10.0.16.0/20 10.0.32.0/20 10.0.48.0/20 /20 EKS nodes, ECS, EC2 Data 10.0.64.0/24 10.0.65.0/24 10.0.66.0/24 /24 RDS, ElastiCache Reserved 10.0.128.0/17 /17 Future tiers, Transit Gateway, VPN The jump from /24 in the public tier to /20 in the app tier is intentional. ALBs and NAT gateways consume very few IPs; the app tier is where consumption scales

Netflix and Rockstar Games finally debuted their "extended look" at Grand Theft Auto VI. It showed that the new game looks to keep much of the spirit of GTA - exploration, driving, crimes, shooting, and cinematic story scenes. But everything just looks much better than previous entries, with impressive graphics, densely-packed rooms, and detailed environments. […]

A retry answers a narrow question: might the same operation succeed if I attempt it again? Recovery has a harder job. It must bring the original business operation to a known, valid outcome after something went wrong. Getting there may require another attempt, a status lookup, resuming from persisted state, or compensation. If the system cannot resolve the operation safely, it must hand it to a person. This difference matters as soon as an AI workflow does more than return text. If it retrieves data, calls tools, writes state, or continues after the HTTP request ends, adding three retries around the workflow is not a recovery design. It is three more chances to spend money, repeat a side effect, or lose track of what already happened. A retry repeats an attempt Suppose a support feature performs this workflow: load the ticket and approved policy -> generate a reply -> validate the reply -> save it as a draft The policy read returns 503 Service Unavailable with an applicable Retry-After response, and the dependency contract classifies it as transient. No application business state changed, and the request still has time left. A delayed retry may be reasonable. Now suppose the draft save times out after the request reached the database. The caller cannot tell whether the write committed. Repeating the complete workflow creates a new model response and may save a second draft. Retrying only the write is safe when the write is naturally idempotent, or when the boundary can recognize the retry as the same logical operation. Otherwise, the second attempt may create another draft. Both failures may appear as a timeout or dependency exception in application code. They do not have the same effect. What happened What is known Suitable response A transient policy read failed before returning data No application business state changed Retry the read within its budget The model endpoint rejected an invalid request The same request will fail again Stop and fix the request or cont

Coates said in a LinkedIn post that the company is not trying to recreate Twitter.

Langfuse with Microsoft.Extensions.AI has an appealing story: update prompts without redeploying. A prompt fetches its config blob—model, tokens, temperature—which the code passes straight to the LLM. It works. But it puts a boundary in what I'd suggest might be better placed elsewhere — and moving it is a small enough change to be worth exploring. This post is about where to move that line in a .NET codebase using Microsoft.Extensions.AI against OpenAI or Azure OpenAI, with Langfuse as the source of prompts. What the current setup buys you Let me be fair to it first, because the coupling is a deliberate design, not an accident. Langfuse's prompt config is an optional JSON object versioned alongside the prompt. That means someone can open the Langfuse UI, change the model or a parameter, and ship it — no code change, no redeploy. Combined with labels (pointers to specific versions that your code references), a rollback is just moving the production label back to an earlier version. For prompt content iteration, that story is genuinely good, and there is a real audience of people who want model config coupled to prompt versions more tightly so each version is fully self-describing and reproducible. So this is a trade-off, not a bug. The question is whether the thing you are optimizing for — non-engineers tuning prompts without a deploy — is worth what the coupling costs. Why I think this deserves consideration Three points stand out. It is an untyped blob feeding provider selection. The Langfuse config is arbitrary JSON without schema enforcement. On the other end, whatever LLM plumbing you use will treat that model string as authoritative. A missing key, a stray max_tokens , or a gpt4o typo might not fail at build time or deploy time — it could fail on a live request, or silently do something unintended. You have a loosely-typed value driving an infrastructure decision, and the mistake may not surface until traffic hits it. It conflates two change lifecycles with di

Scalable Guardrail Service ASP.NET Core Kubernetes: Architecture, Code, and Ops Quick Answer Scalable Guardrail Service ASP.NET Core Kubernetes: A dedicated ASP.NET Core guardrail microservice on Kubernetes validates LLM requests, enables instant policy updates via Redis, and scales with custom HPA for high‑throughput. Scalable Guardrail Service ASP.NET Core Kubernetes: Why a Dedicated Guardrail Microservice Matters When you expose an LLM‑powered API to the world, every request is a potential compliance risk. A single malformed prompt can surface PII, trigger a policy violation, or even cause a brand‑damaging output. In my experience, the first version of such a system is a set of ad‑hoc filters sprinkled across controllers. Under load, those filters become latency bottlenecks, policy updates race, and audit trails vanish. The root cause is a missing architectural layer that treats guardrails as a first‑class microservice that can scale horizontally, be updated live, and be observed independently. Guardrail Layer Requirements We need a guardrail layer that: Validates every request before it hits the LLM engine. Can be updated without redeploying the entire API surface. Provides per‑tenant isolation and versioning. Logs every decision for compliance and red‑team analysis. Runs at the same scale as the LLM inference service. When This Fails in Production Policy updates are applied via a shared ConfigMap and the pods do not reload, so new rules are never enforced. The guardrail service is single‑instance; a spike in requests triggers a queue that exceeds the LLM engine’s rate limit, causing a cascading failure. Audit logs are written to local disk; a pod crash loses events. Latency spikes because each request performs a synchronous Redis lookup for every policy. Common Mistakes Engineers Make Embedding guardrail logic inside the API controller rather than a dedicated middleware. Using in‑memory policy caches without a TTL, leading to stale rules. Ignoring the fact that

Upgrading Kubernetes clusters across a large enterprise fleet is often a balancing act between staying current with security patches and avoiding outages. By default, Google Kubernetes Engine (GKE) rolls out automatic upgrades progressively according to Google Cloud regional timelines. While regional rollout works well for standalone clusters, it does not understand your organization's business topology. If you run staging clusters in us-central1 and critical production clusters in us-east1 , a standard regional rollout could upgrade your production environment before your pre-production validation completes. The General Availability (GA) release of GKE rollout sequencing with custom stages solves this challenge. It provides platform teams with declarative control to sequence cluster upgrades across fleets, environments, and even distinct Google Cloud organizations according to business criticality rather than cloud geography. How rollout sequencing works Rollout sequencing builds on GKE fleet management. Fleets serve as logical boundaries for environments such as development, staging, and production. With rollout sequencing, you define an ordered pipeline of upgrade stages managed by a central resource called RolloutSequence . When GKE publishes a new automatic upgrade target for a release channel, or when you explicitly trigger a target version, the system creates a Rollout object. This rollout progresses through your defined stages sequentially: Control plane upgrades start in the first stage. Once all control planes in that stage reach the target version, a stage soak timer begins. Node upgrades run in parallel with control plane upgrades, respecting node pool upgrade strategies such as surge or blue-green. When both control planes and nodes complete their upgrade and satisfy the configured soak duration, the rollout advances to the next stage in the sequence. If an individual stage contains clusters that take longer than 30 days to finish upgrading—due to restr

Your datacenter needs to talk to Azure. You can send that traffic through an encrypted tunnel over the public internet, or over a private circuit that never touches it. That single choice — shared road or private rail — decides cost, speed, and reliability. Almost every organization moving to Azure keeps something on-premises, and those two worlds have to connect privately. Azure gives you two hybrid-connectivity options, and they take opposite routes to the same destination: VPN Gateway and ExpressRoute . Understanding them is really understanding one question — does your traffic ride the public internet, protected by encryption, or a dedicated line that bypasses it entirely? VPN Gateway: an encrypted tunnel over the internet Microsoft's description is exact: Azure VPN Gateway "can be used to send encrypted traffic between an Azure virtual network and on-premises locations over the public Internet." Your traffic still travels the ordinary internet, but inside an IPsec/IKE tunnel, so it is private even though the road is shared. It comes in a few shapes: site-to-site (your datacenter's VPN device to Azure), point-to-site (an individual remote worker to the VNet), and VNet-to-VNet . It is quick to stand up, needs no third party, and is inexpensive — the pragmatic default for dev/test and small-to-medium production links. ExpressRoute: a private, dedicated circuit ExpressRoute takes the other road entirely. It "lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider." The defining fact: because ExpressRoute connections do not go over the public internet , they offer "more reliability, faster speeds, consistent latencies, and higher security than typical connections over the internet." You are not tunnelling through shared roads; you have a private rail line into Microsoft's network, arranged through a connectivity provider. That extra reliability and consistency costs more and takes longer t

The FBI has seized domains associated with a botnet that allowed Chinese-backed hackers to breach several U.S. government departments.

System Design: Payment Processing System A capstone system design walkthrough — designing a payment processing system end to end — covering the core domain model, the ledger as the system's source of truth, idempotency and exactly-once-effect guarantees, integrating with external payment gateways and card networks, handling asynchronous webhooks, reconciliation, fraud and risk checks, and the specific correctness and compliance demands that make payments a uniquely unforgiving system design problem. Table of Contents Introduction Why Payment Systems Are a Different Kind of Hard The Core Domain Model The Ledger: Double-Entry Bookkeeping as the Source of Truth Idempotency: The Single Most Important Property Integrating with Payment Gateways and Card Networks The Payment State Machine Webhooks: Handling Asynchronous Gateway Callbacks The Saga: Coordinating Payment Across Multiple Services Reconciliation Fraud and Risk Checks Data Security and Compliance Consistency, Availability, and the CAP Trade-off for Money Scaling the System Observability for a Payment System Common Pitfalls Quick Reference Table Conclusion Introduction A payment processing system takes the general system design vocabulary covered in this series' System Design guide — databases, caching, queues, load balancing — and applies it to a domain where the ordinary consequences of a bug are dramatically higher: a double-charged customer, a lost payment, or a corrupted ledger isn't a degraded user experience, it's real money moved incorrectly, sometimes irreversibly. This guide walks through designing such a system end to end, drawing directly on this series' DDD, Event-Driven Architecture, Database Migrations, and Secret Management guides, each of which turns out to be load-bearing infrastructure for getting payments right rather than optional architectural polish. Client → Payment API → [validate, risk-check] → Payment Gateway (Stripe/Adyen/etc.) → Card Network → Bank ↓ ↓ (async webhook) Ledger (source o

Messing with the genetic code might have gotten a bit easier to do.

Bluesky's new 10-minute video support includes faster upload speeds, too.

I maintain gumdrop , an async, non-blocking Java server framework. Last year I wanted to add HTTP/3 support, and ran into a wall: the Java ecosystem essentially doesn't have QUIC. The JDK's own experimental support (JEP 517) is client-only. Netty gets HTTP/3 by shelling out to quiche + BoringSSL over JNI — which works, but you're back to native builds, platform-specific binaries, and a C library sitting underneath your "pure Java" framework. I used that approach first. It was clumsy enough that I went looking for a pure-Java alternative. There's exactly one: Kwik. But Kwik is blocking per connection — one thread per QUIC connection. That's a non-starter for a framework built around single-threaded selector loops handling tens of thousands of concurrent connections. So I wrote a QUIC implementation from scratch: packet protection, loss detection and NewReno congestion control, connection migration, 0-RTT, QPACK, an HTTP/3 client and server — all driven by the same non-blocking event loop as everything else in gumdrop. Collaboration note: TLS 1.3 comes from Agent15 — also from Kwik's author, Peter Doornbosch, but just the handshake layer, not the connection model. We're currently working together on making PQC — hybrid key exchange and signatures — the default there. Why the thread model matters The reason this mattered beyond HTTP/3: gumdrop isn't a web framework with QUIC bolted on, it's a general async I/O framework, and QUIC is just a transport. One thread per connection is exactly the model gumdrop exists to avoid — it caps concurrency at your thread pool, not your file descriptors, and it's the reason a "just use Kwik" fix was never really on the table. The same QUIC stack backs DNS-over-QUIC (DoQ) as a first-class DNS transport alongside DoT, DoH, UDP, and TCP — and the DNS resolver itself is fully async, with no blocking InetAddress.getByName() anywhere in the I/O path, which is its own small miracle in Java. HTTP, SMTP, IMAP, POP3, FTP, MQTT, SOCKS — it's the

Your backend framework will outlive your current team. Choose one that the next team can still navigate — here's why .NET has been that framework for Netflix, GitHub, and Stack Overflow for over two decades. Summary Twenty-three years. That's how long .NET has been running in production. Most frameworks from that era got abandoned, forked beyond recognition, or replaced entirely — .NET kept showing up. Netflix still uses it. GitHub uses it. Stack Overflow, which has probably saved more developer careers than any single resource on the internet, runs on ASP.NET. None of these teams are using it out of inertia. They're using it because it works under conditions that expose every weakness in a poorly designed system. This article gets into how .NET actually works, what it gives teams day-to-day, and whether it makes sense for what you're building now. Key Takeaways: One codebase, five platforms — Windows, macOS, Linux, Android, iOS. No rewrites, no platform-specific forks. Three languages, one project — C#, F#, and Visual Basic coexist without forcing a rewrite. The performance tooling ships with it — JIT compiler, AOT compiler, CLR memory management, Garbage Collector. All out of the box. Why Is .NET Still Around? Honestly, this question is worth sitting with for a second — because in software, most things don't survive twenty years. They solve the problem of the moment, get widely adopted before anyone finds the sharp edges, and then get quietly replaced when something newer comes along and the migration pain seems worth it. .NET didn't go that way. Some of that is Microsoft backing — resources, long-term support commitments, a developer community that doesn't dissolve when priorities shift. But backing alone doesn't explain it. Plenty of well-resourced frameworks have died. What actually kept .NET alive is that the foundational architecture held up. The cross-platform capability wasn't duct-taped on in 2020 because everyone suddenly cared about Linux. It was in the

Seri: Proxmox VE Cluster ve Corosync | Hafta 5 Serinin adı "Cluster ve Corosync"; ama dört modüldür ağırlık HA Manager, resource affinity ve CRS'teydi, Corosync'in kendisine (redundant link'ler, izleme araçları) hiç dönmemiştim. Bu modülde iki konuyu birleştirip derinlemesine işledim: birden fazla corosync link'i tanımlayıp gerçekten birini kesip diğerinin devralmasını kanıtlamak, ve günlük operasyonda kullanılacak izleme araçlarını tek tek denemek. İkisi de planladığımdan çok daha fazla soru açtı; biri yanlış bir config anahtarı yüzünden saatler süren bir araştırmaya dönüştü, diğeri ise hiç beklemediğim bir kilitlenme keşfiyle bitti. Bölüm 1: Redundant Corosync Links Kurulum: İkinci Link'i Eklemek Şu ana kadar cluster'ımızda tek bir corosync link'i vardı ( link1 , izole corosync-net ağı). Management ağını ( 192.168.122.x ) link0 olarak ekleyip gerçek bir yedeklilik kurdum; /etc/pve/corosync.conf 'u kopyalayıp düzenleyip atomik olarak yerine taşıdım: cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new # nodelist'teki her node'a ring0_addr ekledim, totem'e ikinci bir interface bloğu ekledim mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf Doğrulama: corosync-cfgtool -s LINK ID 0 udp addr = 192.168.122.11 status: ... connected ... connected LINK ID 1 udp addr = 10.10.10.11 status: ... connected ... connected Teknik olarak başarılı; iki link de bağlı. Ama log'a dikkatlice bakınca, mimarimizin niyetini tersine çeviren bir şey oldu: [KNET ] rx: host: 3 link: 0 is up [KNET ] host: host: 3 (passive) best link: 0 (pri: 1) link_mode: passive modunda, öncelik eşitken düşük numaralı link kazanıyor . link0 'ı sonradan eklediğim için, o Corosync'in asıl trafiğini üstlenmiş; Modül 0'da özellikle izole ettiğimiz corosync-net ( link1 ) sessizce yedek konuma düşmüştü. Yanlış Anahtar, Saatler Süren Bir Araştırma Bunu düzeltmek için link1 'e daha yüksek öncelik vermeye çalıştım: interface { linknumber : 0 priority : 5 } interface { linknumber : 1 priority : 10 } İşe yaramadı. cor

The social app founded by Bonobos co-founder Andy Dunn is expanding beyond events with new digital homes for groups to connect, organize, and make plans.

The blunt tool is still in a lot of GRUB files: GRUB_CMDLINE_LINUX_DEFAULT = "isolcpus=0,1" Then update-grub (or grub2-mkconfig ) and reboot. Userspace tasks stop landing on CPU0/1. That is all most people verify — they fire a few busy loops and top looks empty on those cores. IRQs do not care. isolcpus is a scheduler isolation hint. Hardware interrupts can still fire on the "isolated" CPUs. I watched seven tight loops leave 0/1 idle for processes while /proc/interrupts still ticked on those cores. If you wanted a CPU for DPDK, a user-space NIC, or a cycle-accurate loop, scheduler isolation is necessary and not sufficient . Lab notes (English original is short; this write-up is the missing IRQ half): https://sunshout.tistory.com/1620 How to see what you actually isolated After reboot: cat /proc/cmdline # isolcpus=0,1 must be there grep PREEMPT /boot/config- $( uname -r ) || true taskset -cp 1 # pick a known userspace pid; it should not be 0,1 watch -n1 'grep "^ *[0-9]" /proc/interrupts | head' If IRQs still increment on CPU0/1, isolation is incomplete. That is expected with classic isolcpus= . On newer kernels the story split: isolcpus=domain / cpusets / cgroup cpuset — userspace isolcpus=managed_irq or manual irqaffinity / /proc/irq/*/smp_affinity — interrupts nohz_full= — tick reduction, another knob, not a substitute isolcpus is also marked deprecated in some trees in favor of cpusets. The IRQ caveat did not go away when the docs changed the preferred interface. Moving IRQs by hand Find the noisy ones ( eth0 , NVMe, GPU): grep -E 'eth|nvme|enp' /proc/interrupts # smp_affinity is a hex CPU mask. CPU2 only → 4 echo 4 > /proc/irq/IRQNUM/smp_affinity Or set the default affinity so new IRQs skip 0/1: irqaffinity=2-7 in the same GRUB line (adjust to your CPU count). Some devices ignore this (managed IRQs, VFIO). Then you isolate at the driver: bind the NIC to vfio-pci and poll from a pinned thread. When this shows up next to SR-IOV Passing a VF into KVM does not pin ho