标签：#Cloud

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 (

If you've used other browser-based code editors, you've probably noticed that the terminal feels off. You can run a script. You can print to stdout. But the moment you try to install a package and then actually use it in the next command, something breaks. The environment doesn't carry over. It feels like every command starts from scratch in a vacuum. That was the problem I wanted to solve when building the terminal for Cloudpen. Not just a place to run isolated snippets, but a proper environment where you can install dependencies, run build tools, and have everything you did in one command still be there for the next one. What most cloud terminals get wrong The core issue is that running code in the browser is hard to do without cheating somewhere. A lot of tools use sandboxed environments that look like a terminal but don't behave like one. They're good enough for demos. They fall apart in real work. The thing developers actually need is simple: if I install something, it should be there when I run the next command. That's it. That's the whole requirement. Surprisingly few cloud tools actually deliver it. How Cloudpen handles it Without going into the full technical detail, the short version is this: every command runs in a completely isolated environment, but all commands within your session share the same filesystem. So when you run npm install, those files are written somewhere. When you run your next command, that somewhere is exactly where it looks. Package installs work. Build tools work. Multi-step workflows work. And because each command runs in a clean, isolated environment, there's no bleed between users or sessions. The current terminal is optimized for commands that run to completion, while live application previews are handled through Cloudpen's deployment system. On the free plan, you can run any file in your project and see the output directly in the terminal. The live coding environment where you type commands yourself is on the Pro plan. Both use

Learn strategies for building interrupt-resilient AI workloads on Google Kubernetes Engine (GKE).

Introduction Managed Kubernetes platforms such as Amazon EKS, Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS) abstract away much of the operational complexity involved in running Kubernetes clusters. While this significantly improves developer productivity, it also hides many of the internal systems responsible for cluster orchestration, networking, node registration, and workload scheduling. As a result, many engineers interact with Kubernetes daily without fully understanding the components that keep a cluster operational behind the scenes. To better understand Kubernetes from an operational perspective, I set out to build and operate a self-managed Kubernetes platform on AWS using kubeadm. Unlike lightweight local environments such as Minikube or kind, kubeadm bootstraps Kubernetes in a way that closely resembles how real-world self-managed clusters are provisioned and operated. The objective of this project was not simply to install Kubernetes, but to explore: How the control plane components interact. How worker nodes register with the cluster. How Kubernetes networking behaves. How cloud integrations work. How traffic reaches workloads running inside the cluster. How operational failures surface during deployment and runtime. How production-style systems behave beneath managed abstractions. This article documents the architecture, implementation process, engineering decisions, operational lessons, and troubleshooting insights encountered during the effort to bring the platform to a healthy operational state. Project Objectives The primary objectives of this project were to: Provision infrastructure on AWS using Terraform. Bootstrap a self-managed Kubernetes cluster using kubeadm. Configure Kubernetes networking using Calico. Integrate Gateway API with AWS Load Balancer Controller. Expose workloads externally using AWS Application Load Balancers. Validate cluster functionality through application deployment. Understand the operational mechani

Keeping up with trending technical topics and new tools on developer forums can be time-consuming. To save time, I wanted to automate the process of finding popular articles, reading the comments to understand community sentiment, and drafting a summary. While I could write a standard Python script to scrape the dev.to API, simple scripts tend to be brittle. If an article doesn't have comments yet, a basic script will likely crash unless you write extensive error-handling logic. Instead of a rigid script, I built an Agent —a program that can dynamically reason about errors and adjust its approach. If one task fails, it can figure out the next best step. In this tutorial, I'll show you how to build a Trend-Spotting Agent using Python, the Google Agent Development Kit (ADK) , and Gemini 2.5 Flash. What We're Building We are going to write a Python application that acts as an autonomous agent. We'll give it three abilities: Search the dev.to API for rising technical articles based on specific tags. Dynamically fetch the top comments of those articles to read real community sentiment. Automatically draft a newsletter-style article on your DEV.to account summarizing its findings. Prerequisites Python 3.9+ installed on your machine. Google ADK . (Check out the Google ADK Docs if you need help installing). A DEV API Key . Grab this from your DEV.to account settings under "Extensions" and throw it in a .env file. Step 1: Giving the Agent its "Hands" (API Tools) Large Language Models (LLMs) are incredibly smart, but out of the box, they can't actually do anything on your computer. The coolest part about Google ADK is that we can write standard Python functions, hand them to the LLM as "tools", and let the AI decide how and when to use them. Let's write our API functions. Tool 1: Finding Rising Articles Here is our function to fetch rising articles. Pay close attention to the docstring ( """Fetches the top...""" ). We aren't writing this for other developers; the ADK actually

Switching focus from Frontend development to Data Engineering means shifting from building user interfaces to architecting robust data pipelines. It’s a completely different mindset, and the learning curve is exciting! As I dive deeper into the world of Data, these are the 4 essential tools and concepts that have become the absolute backbone of my daily learning roadmap: 1️⃣ Python (The Swiss Army Knife): Coming from JavaScript/TypeScript, picking up Python has been a breath of fresh air. From writing custom ETL scripts to data manipulation with Pandas, it's the ultimate language for data manipulation. 2️⃣ Advanced SQL (The Core): It's not just about simple SELECT statements anymore. Mastering Window Functions, CTEs (Common Table Expressions), and query optimization is where the real magic happens when interacting with Data Warehouses. 3️⃣ ETL/ELT Pipelines: Understanding how to efficiently Extract, Transform, and Load data without breaking downstream analytics. Moving from UI state management to Data state management is a game-changer. 4️⃣ Cloud Ecosystems & Modern Stack: Exploring how data flows through modern cloud environments and learning how big data tools manage scale. The transition requires patience, but applying my previous engineering background to these new tools makes the journey incredibly rewarding. 💡 To the Data Engineers in my network: What is the one tool or concept you believe is a "must-have" for someone transitioning into the field today? Drop your advice below!

At Twio we picked pg-boss for our job queue, ran into trouble when we went serverless, looked at Pub/Sub, and ended up on Google Cloud Tasks. This is what each queue got right, what it got wrong for our workload, and the rule we landed on for choosing between them. The workload Twio is an AI SaaS for loan brokers. The piece that needs a job queue is email processing: download an email, parse the body and attachments, OCR, classify with an LLM, write structured data, and index for RAG. One email with five attachments easily becomes 30+ background jobs. A batch upload becomes hundreds. Why pg-boss worked — until it didn't Our database was Postgres on Neon, so pg-boss was the obvious starting point. No extra infrastructure, and one feature we genuinely loved: transactional enqueue . Because jobs live in the same database as business data, you can create a job in the same transaction as the row that triggered it. No dual-write problem, no "DB succeeded but the queue API failed" inconsistency. It also gave us retries, delayed jobs, dead-letter queues, dedup keys, and full SQL visibility into stuck or failed jobs. For a Postgres-first app on always-on infra, it's an excellent tool. Then we moved heavy processing to Cloud Run, and the cracks showed up. pg-boss polls. Neon suspends. They want opposite things. pg-boss runs a query roughly every 1–2 seconds to look for the next job, plus maintenance queries. Neon autosuspends compute when nothing touches the database. If the queue is polling every second, Neon's idle timer never expires — you pay for always-on compute even when the queue is empty. Worse, when Neon did manage to suspend, the next poll had to wake it. That wake-up takes hundreds of ms to a few seconds, and queries that triggered it would fail with Connection terminated , ECONNRESET , or timeouts. Pooled connections made it worse: the pool kept sockets that the server had already closed during suspend, and the next polling cycle picked one up and broke. This isn