标签：#Cloud

The era of passive data analytics is over. Today, the most forward-thinking data teams aren't just...

Martin Kleppmann discusses the urgent need for technological sovereignty in modern infrastructure. Exploring the shifting landscape of global tech dependencies, he shares how engineering leaders can leverage multi-cloud architecture, de facto API standardization, the AT Protocol, and local-first development paradigms to reclaim user agency and build highly resilient systems. By Martin Kleppmann

Microsoft announced the general availability of Microsoft Discovery, its Azure-based platform for deploying autonomous AI agent teams in scientific R&D. The platform powered the development of Majorana 2, a topological quantum chip with 1,000x reliability improvement and 20-second qubit lifetimes. Microsoft now targets a scalable quantum computer by 2029, halving its original timeline. By Steef-Jan Wiggers

Today, June 8th, InfoQ celebrates 20 years. This is not a comprehensive history, but a deliberately selective look at the technologies and practices InfoQ identified early, where they sit on the adoption curve in 2026, and how that curve may evolve over the next five to ten years. By InfoQ

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

Quiet Defaults, DNSSEC Cracks, and Agents in the Data Plane I read the AWS Nitro V6 TCP timeout change twice before I believed it. Default went from 432,000 seconds to 350 seconds. Five days to six minutes. On the newest instance family. Quietly, in release notes most people won't read until something breaks. That sort of set the tone for May. No flagship launch to anchor the month around. What there was a lot of: defaults moving in places vendor press releases don't celebrate. Post-quantum crypto pushing into campus boot chains. Every cloud vendor shipping some flavor of agentic-networking pattern. The .de TLD briefly breaking because of DNSSEC. None of it announced loudly. All of it the kind of thing that breaks production at 2am if you weren't paying attention. What Moved This Month Three things, fast. Post-quantum crypto left the VPN tunnel. Cisco's full-stack PQC for campus and branch is the next chapter after April's PQ IPsec story — boot, firmware signing, supply chain attestation, and transport-layer crypto all moving together. If your campus has mixed-vintage gear (which is basically everyone), this is multi-year partial coverage with no clean switchover. Agentic networking became a real category. Cloudflare's Town Lake / Skipper writeup and Claude Managed Agents , Palo Alto's Portkey-based unified AI Gateway , and AWS's Bedrock AgentCore connectivity patterns all dropped this month. The right question stopped being "can my agent reach the model" and became "what IAM blast radius does this agent have if it gets prompt-injected." DNSSEC had a rough month. The .de TLD broke briefly, the DNSSEC root key was rolled, and Cloudflare also debugged a QUIC CUBIC death spiral that was hiding in plain sight. The Internet's core had a louder month than usual, and not in a good way. 1. Agentic AI Is Now Actually A Networking Problem An agent in production isn't a fancy chatbot. It's a thing that calls APIs, reads logs, accesses SaaS data, and sometimes writes back to sy

If you run Aviatrix on Azure, there is a slow-moving infrastructure change happening underneath your gateways right now that is worth paying attention to. Microsoft started rolling out a new generation of network hardware on May 26, 2026, called MANA (Microsoft Azure Network Adapter). For most Azure workloads, the change is invisible. For network virtual appliances (NVAs) like Aviatrix gateways, it is not, and Aviatrix has issued a field notice ( FN-2026-AZ-001 ) telling customers to take action. What is MANA and Why is Microsoft Rolling it Out? For roughly a decade, Azure VMs with Accelerated Networking enabled have used Mellanox-based NICs exposed to the guest as mlx4/5 SR-IOV adapters . SR-IOV (Single Root I/O Virtualization) lets the VM talk to the network card hardware directly, bypassing the hypervisor's virtual switch. This is what gives Accelerated Networking its low-latency, high-throughput characteristics. Microsoft has been quietly building its own in-house networking silicon. MANA is the result: a Microsoft-designed network adapter that replaces the Mellanox hardware Azure has been using on the host side. From an Azure customer's perspective, MANA preserves Accelerated Networking semantics, but the device the guest OS sees is different. The driver is different. The interface name is different. And that is where Aviatrix gateways run into trouble. Why Aviatrix Gateways Are Affected Aviatrix gateways are not generic VMs. They run a custom data plane that binds tightly to the underlying NIC for performance reasons. Specifically, the gateway image expects the Mellanox driver to be present and operational. On MANA hardware, that driver is no longer in play, and the gateway image does not yet include a MANA-aware driver. Per the field notice, the symptom is intermittent performance degradation rather than an outright outage. That makes it harder to detect: throughput drops, latency spikes, or session resets that look like noise can be the early signs of a gate

Cloudflare recently described how a slowdown in its billing pipeline was traced to contention inside the query planning stage of ClickHouse. The team profiled the bottleneck and patched ClickHouse to replace an exclusive lock with a shared lock, drop the per-query copy of the parts list, and improve part filtering. By Renato Losio

Cloud gaming on macOS has improved a lot over the last few years, but I kept running into the same issues: random ping spikes, micro-stutters, Bluetooth latency, and network interruptions caused by background system services. Instead of tweaking settings manually every time I launched a gaming session, I decided to build a small native macOS utility to automate the process. The result is CloudBoost. The Problem When troubleshooting cloud gaming performance on macOS, I noticed that many issues weren't caused by internet speed. Even with a fast fiber connection, there were occasional interruptions caused by: Background wireless discovery services Network interface transitions Power management behaviors Input device acceleration Memory pressure during long gaming sessions These issues were small individually, but together they created a noticeably less consistent experience. The Approach Rather than creating another "system cleaner" application, I wanted something that would: Apply temporary optimizations only during gaming sessions Avoid permanent system modifications Use native macOS technologies Restore original settings when disabled The application focuses on automation instead of aggressive tuning. Building It CloudBoost was developed using: Swift SwiftUI Native macOS APIs UNIX system utilities already available on macOS The biggest challenge wasn't writing code. It was understanding which system behaviors actually affected cloud gaming and identifying changes that could safely improve consistency without creating side effects. Features Current functionality includes: Network optimization routines Temporary wireless service management Mouse acceleration controls Session-based optimization profiles Automatic restoration of original settings Native menu bar integration Automatic update checking through GitHub releases What I Learned One interesting lesson from this project is that performance optimization is often more about engineering decisions than programming c

Introduction Website hosting has been greatly improved through the use of cloud computing. This has made it easier for individuals as well as businesses to access, scale, and use hosting services at a reasonable price. One of the easiest and most efficient methods that developers may use to host a static site on Microsoft Azure is the Static Website Hosting option offered by Azure Blob Storage, which allows developers to upload their static files without the need for a traditional web or virtual server (i.e., HTML, CSS, JavaScript, and media files). In this project, I will download a free static website template from Tooplate, customize the downloaded version using Visual Studio Code (VS Code), and then deploy the new version to Azure Blob Storage for public viewing. This will involve editing all content, images, styles, and branding so that the template reflects how I want it to look when it is completed. To develop my own static website using Azure Blob Storage, I will first navigate to Tooplate and browse the templates available for modification (or further development). After deciding which template is most suitable, I will download the ZIP package of the template and extract it onto my local computer's disk drive. Then, I will open the ZIP file's contents using VS Code to customize all aspects of the website prior to publishing. After customizing the template, we will create an Azure storage account, enable Static Website Hosting, upload the customized/static website files to the Azure Blob Storage $web container, and then publish the created static website into the cloud. Project Objectives .Download a free static website template from Tooplate. .Go to VS code and edit the downloaded template from there .Create a Resources Group .Create an Azure Storage Account. .Enable Azure Static Website Hosting. .Upload website files to Azure Blob Storage. .Deploy and access the website through Azure's public endpoint. .Document the deployment process. Prerequisites Before

I recently rebuilt my homelab from scratch. The goal was simple: one machine, everything containerised, zero exposed ports, GPU-accelerated local AI, and a fully automated backup setup. No cloud subscriptions for the tools I use every day. This is the full technical breakdown — what I'm running, how it's wired together, and the hard-won fixes that cost me hours so you don't have to repeat them. What I'm Running Eight services, 26 containers, one machine: Service Purpose Portainer Docker management UI Uptime Kuma Service monitoring (7 monitors) NocoDB Self-hosted Airtable — CRM & leads n8n Workflow automation Open WebUI Local AI chat interface Ollama Local LLM inference (GPU) AFF!NE Collaborative docs & whiteboards Plane Project management (roadmaps, sprints) Duplicati Encrypted daily backups Cloudflare Tunnel Zero Trust secure access — no open router ports All external-facing services sit behind Cloudflare Zero Trust with email OTP. No passwords to manage, no VPN clients — Cloudflare handles authentication at the edge. Architecture ┌──────────────────────────────────┐ │ Cloudflare Edge (Zero Trust) │ │ *.yourdomain.com — email OTP │ └──────────────┬───────────────────┘ │ HTTPS ┌──────────────▼───────────────────┐ │ Ubuntu Machine │ │ │ │ cloudflared (outbound tunnel) │ │ │ │ │ ┌─────▼────────────────────┐ │ │ │ homelab-net (bridge) │ │ │ │ │ │ │ │ portainer uptime-kuma │ │ │ │ nocodb n8n │ │ │ │ open-webui affine │ │ │ │ plane-* duplicati │ │ │ │ ollama (GPU passthrough) │ │ │ └───────────────────────────┘ │ └───────────────────────────────────┘ Everything runs on a shared Docker bridge network ( homelab-net ). The cloudflared container maintains an outbound-only encrypted tunnel — no inbound ports open on the router at all. Ollama runs in Docker with NVIDIA GPU passthrough. The AI model inference happens on the GPU, leaving CPU headroom for all other services. Prerequisites Ubuntu 24.04 LTS Docker Engine + Compose v2 NVIDIA GPU with driver 535+ NVIDIA Container Too

To provide SRE as a service, a team built a center of excellence, introducing Federated SREs and roles like production manager and technical tribe lead. They created a culture of data-driven conversations where SLOs and SLAs were democratised. Surviving growing cognitive load meant continuously simplifying architecture and embedding sovereignty and resilience into platform design decisions. By Ben Linders

AWS disclosed that Resilient Network Graphs, a flat network architecture based on quasi-random graph theory, is now the default for most new data center builds. The design replaces fat-tree hierarchies with direct ToR-to-ToR mesh connections using passive optical ShuffleBoxes, cutting routers by 69%, boosting throughput by 33%, and reducing network power consumption by 40%. By Steef-Jan Wiggers

Kubernetes is the industry standard for scaling cloud-native workloads While it offers tremendous scalability and flexibility, securing Kubernetes environments remains a significant challenge. Organizations often rely on a collection of disconnected security tools to handle vulnerability scanning, runtime monitoring, compliance validation, and incident response. As clusters grow in complexity, security teams face increasing alert fatigue, delayed response times, and difficulties correlating security events across multiple layers of the platform. Recent advancements in Agentic AI present an opportunity to rethink Kubernetes security. Instead of relying solely on static rules and isolated security products, organizations can deploy a collaborative network of AI-powered security agents that continuously monitor, investigate, and remediate threats. This blog explores how a Multi-Agent Security Framework can transform Kubernetes security operations through autonomous detection, investigation, and remediation. The Problem with Traditional Kubernetes Security Modern Kubernetes environments generate security signals from multiple sources: Runtime security tools Container vulnerability scanners Admission controllers Network monitoring systems Compliance platforms Cloud security posture management tools Each system produces valuable information, but most operate independently. Consider a common scenario: A container begins executing suspicious commands. A runtime security platform detects the behavior and raises an alert. However, determining whether the threat is critical requires additional context: Is the pod exposed externally? Does the workload have excessive privileges? Can it access sensitive namespaces? Is lateral movement possible? Does it violate organizational policies? Answering these questions often requires multiple tools and human intervention. This is where multi-agent systems become valuable. What is a Multi-Agent Security Framework? A Multi-Agent Security Fr

Introduction One of the common tasks performed by DevOps Engineers is upgrade of their organization's Kubernetes Cluster at least once every 3 months as Kubernetes release newer version while maintaining on the last 3 released versions. For instance, if the newest version is v1.34, the supported versions would be v1.34, v1.33 & v1.32. Hence, the need to understand how this upgrade process can be achieved with zero downtime. Prerequisites: Cordon your Nodes: This simply means making your nodes unschedulable. No new deployments would be scheduled on the node. Review and understand the change logs in the release notes - Ensure that the change logs or updated components won't affect your production environment. Kubernetes upgrade are irreversible - You can't downgrade your cluster after an upgrade. A fresh installation would be required in the event of an issue with the upgraded version. Hence Lower Level Environment Test (Unit, Staging or Pre-Production) - Given that Kubernetes upgrades are irreversible, always test the newer version and allow monitoring for about 2-weeks before production cluster upgrade. Control Plane & Nodes should be on the same versions. Cluster Auto-Scaler: If you are using this feature within your Kubernetes environment, ensure that it is on the same or compatible version with your control plane to avoid issues during the cluster upgrade. IP Addresses: Make available at least 5 IP addresses within the cluster subnet. Kubelet: This component should also match the version of your control plane before the upgrade. What are the actual upgrade processes Control Plane Upgrade: If using the Managed Kubernetes Cluster (EKS, AKS, GKS), the Cloud Company will take care of managing the control plane. However, upgrade of the cluster doesn't happen automatically. Hence, you will be required to action this via the CLI, UI or EKSCLI etc. Node Group or Data Plane Upgrade: Managed Node Groups - This is easier because you can use the rollout deployment approach,

Lovable and Google signed an expanded multiyear deal that involves a 5x expansion of Lovable's footprint on Google Cloud, and expanded access to Anthropic Claude.

After migrating Spark pipelines to Azure Kubernetes Service, two infrastructure settings interacted destructively: spark.kubernetes.local.dirs.tmpfs=true backed shuffle spill with RAM instead of disk, and a hard podAffinity rule forced all executors onto one node. Together, they caused repeated OOM kills invisible to standard diagnostics. By Pranav Bhasker

If you've ever built a REST API with Express, you've probably felt it. Middleware registration, type definitions, body parser setup, connecting Joi or Zod... the structure is simple, but the boilerplate is excessive. When I first saw Hono, I was skeptical. "Another Express clone," I thought. That changed when I actually ran it. Bottom line: Hono v4 is more than just lightweight and fast. TypeScript type inference flows naturally all the way to route handlers. Zod validation connects via a single official package. On Bun, response times are noticeably faster than Express. Everything in this post is based on what I ran in a sandbox in June 2026. Why Hono — Compared to Express and Fastify Understanding where Hono fits means answering three questions. Bundle size : Hono v4 core is about 12KB. Express is 58KB, Fastify is 77KB. The gap might not sound dramatic, but in edge environments like Cloudflare Workers or Deno Deploy, bundle size directly affects cold start time. Edge functions sometimes initialize a new runtime per request — smaller means faster first response. Runtime compatibility : Express is Node.js-only. Fastify targets Node.js by default. Hono was designed from the start to "run anywhere." The same code deploys to Bun, Deno, Cloudflare Workers, Node.js, and AWS Lambda Edge. TypeScript support : Express requires @types/express as a separate install, and properties added to req via middleware don't get type inference. Hono is written in TypeScript from the ground up, and the Hono<{ Bindings: Env; Variables: Variables }> generic gives you type-safe access to environment variables and middleware state. I'm not saying Hono is the right choice for every situation. If your team is deeply invested in Express, or you need a mature plugin ecosystem, there's no compelling reason to switch. But if edge deployment is the goal, or you want type safety from day one, Hono is the most convincing TypeScript API framework right now. Installation and First Server — Response in

With shiftbloom studio. I build tools and projects about a variety of experimental approaches to real-world problems. The issue for such use-case often was how most small media systems start out: one big always-on recorder that keeps costing money even when nothing is happening. For live capture you obviously need to stay ready at all times — sometimes you can’t risk losing the first minutes. But for everything else it’s complete overkill. The Core Problem Backfills, VOD downloads, clip imports, repairs and re-encodes are queue work. They can wait a few seconds, run on burst capacity, or even on a regular VPS or laptop. They don’t need the same always-hot infrastructure as the live recorder. That’s why I split the system. Instead of one large monolith, I deployed: Observer cells — only for live streams (time-critical) Harvest cells — for all queue processing (can be delayed) The Three Roles 1. Mothership A small control-plane cron job. It checks queue sizes, currently live channels and running observer tasks, then decides: how many harvest cells should exist right now which channels need an observer cell It’s intentionally simple. The database remains the single source of truth. 2. Observer Cells Each observer cell records exactly one live channel. It receives its assignment through environment variables: +++env OBSERVER_VOD_ID OBSERVER_CHANNEL_ID OBSERVER_CHANNEL_LOGIN OBSERVER_CHANNEL_NAME +++ It starts recording immediately, writes HLS segments to object storage, sends heartbeats, and waits a short standby window after the stream goes offline. This window is important because streams sometimes drop and reconnect quickly. Without it you end up with many small broken VOD fragments. 3. Harvest Cells These handle all background work: downloading VODs, re-encoding, recovering broken files, etc. They can run anywhere Docker is available — AWS tasks, a small VPS, or even a spare laptop. They only need outbound access to Postgres and object storage. What Changed Previous

Exam Guide: Developer - Associate 🏗️ Domain 2: Security 📘 Task 2: Implement Encryption By Using AWS Services. Encryption shows up everywhere, especially on this exam. S3, DynamoDB, SQS, Lambda environment variables, RDS, and more. You need to know the difference between client-side and server-side encryption, how KMS works, and when to use each approach. 📘Concepts Encryption at Rest vs Encryption In Transit Encryption At Rest Data stored on disk: S3 Objects, DynamoDB tables, EBS volumes, RDS databases. Encryption In Transit Data moving between services or between client and server: HTTPS, TLS, VPN. Where At Rest In Transit S3 SSE-S3, SSE-KMS, SSE-C HTTPS (enforced via bucket policy) DynamoDB Encrypted by default (AWS owned or KMS) HTTPS (always) RDS KMS encryption SSL/TLS connections SQS SSE-KMS HTTPS Lambda env vars KMS (default + optional CMK) HTTPS KMS Key Types Type Managed By Cost Use Case AWS owned keys AWS Free Default encryption (DynamoDB, S3 SSE-S3 ) AWS managed keys AWS (in your account) Free (per-use charges) aws/s3 , aws/dynamodb (you can't manage them) Customer managed keys (CMK) You Monthly + per-use Full control: rotation, policies, cross-account Envelope Encryption KMS can only directly encrypt up to 4 KB . For larger data, it uses envelope encryption: 1. KMS generates a data key (plaintext + encrypted copy) 2. You encrypt your data with the plaintext data key 3. You store the encrypted data key alongside the encrypted data 4. You discard the plaintext data key from memory 5. To decrypt: KMS decrypts the data key → you decrypt the data The AWS Encryption SDK handles this automatically. Server-Side Encryption Options for S3 Option Key Management Use Case SSE-S3 AWS manages everything Simplest, no KMS costs SSE-KMS You control the KMS key Audit trail via CloudTrail, key policies SSE-C You provide the key with every request Full key control, AWS doesn't store the key Client-Side vs Server-Side Encryption Aspect Server-Side Client-Side Who encrypts AWS (