标签：#azure

How an unexpected regional constraint forced us to deeply understand Azure GPU VM families, naming conventions, and workload fit. Introduction As architects, we often assume that infrastructure decisions are straightforward: "The workload is already running successfully in Region A. Let's deploy the same Kubernetes workload in Region B." That's exactly what we thought. Our workload consisted of a Visual Element Detection (VED) service hosted on Kubernetes. The application uses a PyTorch model to analyze images and detect various visual elements in an image file. The service was already running successfully on a node pool backed by Azure's NVads_A10_v5 GPU VMs. Then we hit an unexpected challenge. The target region did not offer NVads_A10_v5 instances. What looked like a simple deployment exercise became a deep dive into Azure GPU virtual machine families, GPU architectures, VM naming conventions, and workload characteristics. This article shares what I learned in the hope that it helps others who find themselves evaluating Azure GPU SKUs for AI inference workloads. I am relatively new to the world of MLOps, Model deployments, GPU Workloads etc and equally interested and excited to learn more on this front. The Workload Before discussing VM selection, let's understand the workload characteristics: Model Type : PyTorch Model Size : less than 200 MB (.pth) Image Resolution : ~2000 x 2000 Expected Throughput : 5-7 requests/sec Platform : AKS (Kubernetes) Workload Type : Inference only This is important because GPU sizing should always start from the workload and not from the VM catalog. Step 1: Understanding Azure GPU VM Families Many engineers first encounter Azure GPU machines through names like: NV12s_v3 NV6ads_A10_v5 NC4as_T4_v3 ND96isr_H100_v5 The naming can be intimidating. The first breakthrough was understanding that Azure organizes GPU VMs into three primary families: N-Series ├── NV ├── NC └── ND NV Series – Visualization and Graphics NV-series VMs are designe

Two months ago I picked up a ticket that looked routine: a job that reads mailbox data from Microsoft 365 through EWS, running fine for over a year, started failing on a subset of mailboxes in one tenant. Same app registration, same code path, same service account. The error in the logs pointed at throttling, so that's where the admin had already spent three days looking. Wrong direction. The actual cause had nothing to do with throttling budgets. This mix-up happens constantly right now, and it's worth understanding why, because the fix for one problem does nothing for the other, and chasing the wrong one wastes days. TL;DR: if your EWS failures don't scale with request volume, stop tuning throttling and go check your Application Access Policy scope groups instead. What EWS throttling actually looks like Exchange Online throttles EWS the same way it always has: budget-based. Every account gets a policy (the default is EwsDefaultThrottlingPolicy , but plenty of tenants layer custom ones on top) that tracks a slowly-refilling budget rather than a simple call count. When you overspend it, you get back a 503 or 429 with an X-MS-Diagnostics header telling you which budget got exhausted, usually the connection count or the concurrent-request limit. The tell for real throttling is consistency. It scales with load, correlates with concurrency and batch size, and clears up within minutes once you back off. If you graph failure rate against request volume, you'll see a clean relationship. If you double your batch size, failures increase. If you throttle yourself proactively (respecting Retry-After , staying under EWSFindCountLimit for FindItem calls), it mostly goes away. That correlation is the whole diagnostic test. If your failures don't scale with volume, you're not looking at a throttling problem, no matter what the error message on the surface says. What actually changed Over the past year or so, Microsoft tightened enforcement in two places that both produce errors ea

Azure Storage SFTP is Microsoft's managed file transfer service on top of Azure Blob Storage, convenient, but billed continuously per endpoint (roughly $0.30/hour, ~$220/month) and tied to Azure AD. SFTPGo is an open-source file transfer server offering SFTP, FTP/S, and WebDAV with pluggable storage backends (local disk, Azure Blob, S3-compatible, GCS) and no per-endpoint charge. This guide deploys SFTPGo with Docker Compose and Traefik, sets up user auth (password + SSH key + 2FA), connects S3-compatible object storage, and covers the migration path from Azure Storage SFTP. By the end, you'll have a self-hosted file transfer server with the same capabilities at zero endpoint cost. Azure Storage SFTP → SFTPGo Mapping Azure Storage SFTP SFTPGo Equivalent Notes SFTP Endpoint SFTPGo SFTP Server Configurable port, default 2022 Azure Blob Storage Azure Blob backend Native support; point at the same container, no migration needed Azure AD Authentication LDAP/OIDC plugin External identity provider via plugin Local Users Web UI / REST API user management Hierarchical Namespace Virtual directories No HNS requirement Azure Monitor Built-in logging + webhooks/syslog Prerequisite: Linux server with Docker + Compose, a DNS A record for your domain, and (if migrating) an existing Azure Storage account with SFTP enabled plus the Azure CLI installed locally. Deploy with Docker Compose 1. Create the project directories: $ mkdir -p ~/sftpgo/ { data,config } $ cd ~/sftpgo 2. Create the environment file: $ nano .env DOMAIN = sftp.example.com LETSENCRYPT_EMAIL = admin@example.com 3. Create the Compose manifest: $ nano docker-compose.yml services : traefik : image : traefik:v3.6 container_name : traefik command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --certificatesresolvers.letsencrypt.acme.httpchallenge=tr

Parts 1 and 2 of this series ( Microsoft Entra extensibility is a gift. It is also Control Plane. and Securing the code that decides who Entra trusts ) made two static decisions. Where the code lives: a dedicated Control Plane subscription, directly under the root management group or under a dedicated Control Plane management group, never in the platform identity subscription or an application landing zone. What credential it uses to call out: a managed identity by default, federated identity credentials when the call must leave Azure, certificates as a tolerated middle step, and static symmetric keys never. Both decisions are one-time. You make them, you walk away, you do not touch them for months. The third decision is not like that. It is continuous, and it is the one most teams quietly skip: how do you know the deployed code on that Function App is still the code your reviewers approved? How do you know the Logic App workflow definition has not been rewritten since last Tuesday? How do you know nobody added a federated identity credential to the managed identity at 3 a.m. on a Saturday? The answer is monitoring. Not "we have Log Analytics turned on." Monitoring with a specific operating contract attached. The posture inversion For most Azure workloads, the default operating posture is reasonable trust. Engineers deploy. Pipelines run. Configuration drifts a little. The team reviews changes weekly. Anomalies are caught eventually. For a Microsoft Entra extension, that posture is wrong. The default has to be inverted. Once an Entra extension lands in production, every change to it is suspicious by default. Not "needs review." Not "let's check first." Suspicious. The default state of an alert firing on a Function App that hosts a custom claims provider is "the SOC is investigating, prove this was approved." If you cannot prove the change was approved within the team's response SLA, the change is treated as an incident and rolled back. That posture is harsh on purpo

Claude models reached GA on Microsoft Foundry with Azure-native billing and governance, but no European data zone exists. Anthropic's own documentation confirms data residency guarantees apply to Bedrock and Vertex AI but not Foundry. European practitioners from banking and healthcare report the offering is unapproved for production. By Steef-Jan Wiggers

While setting up a self-managed Kubernetes cluster on Azure VMs, I hit this error when running sudo kubeadm init on a Standard_B1s VM (1 vCPU / 1 GB RAM): [ERROR NumCPU]: the number of available CPUs 1 is less than the required 2 After checking Stack Overflow and the official Kubernetes documentation ("Before you begin"), I confirmed that kubeadm requires at least 2 CPUs to install the control plane. The fix: I stopped the VM and resized it from Standard_B1s to Standard_B2s (2 vCPU / 4 GB RAM) from the Azure portal, then ran kubeadm init again — the preflight checks passed and the control plane initialized successfully. Posting this in case it helps someone hitting the same issue on a low-tier cloud VM. Thanks to the community for the answers that pointed me in the right direction!

Durante más de cuatro décadas, hablar de servidores era prácticamente sinónimo de hablar de arquitectura x86 . Desde los primeros servidores empresariales hasta la mayoría de los centros de datos modernos, Intel y AMD han dominado la infraestructura sobre la que funcionan nuestras aplicaciones. Sin embargo, algo está cambiando. De forma silenciosa, los principales proveedores de nube como Microsoft Azure están incorporando cada vez más procesadores ARM para ejecutar cargas de trabajo modernas. ¿La razón? No es únicamente el rendimiento. Es la eficiencia energética. El problema de los centros de datos modernos Cada vez que desplegamos una máquina virtual o un clúster de Kubernetes en Azure, detrás existe un servidor físico consumiendo energía. Ahora imaginemos un centro de datos con cientos de miles de servidores. Incluso una pequeña reducción en el consumo eléctrico por servidor representa un ahorro enorme cuando se multiplica por toda la infraestructura. Y no solo hablamos de electricidad. Menos energía implica: menos calor generado menor necesidad de refrigeración menores costos operativos menor huella de carbono Por eso la eficiencia energética se ha convertido en un factor estratégico para los hyperscalers (gigantes tecnológicos que poseen y administran infraestructuras de centros de datos masivas a nivel global). ¿Qué diferencia a ARM de x86? A grandes rasgos: x86 utiliza una arquitectura CISC (Complex Instruction Set Computing) , con un conjunto amplio de instrucciones complejas. ARM utiliza una arquitectura RISC (Reduced Instruction Set Computing) , basada en instrucciones más simples y optimizadas. Esto no significa automáticamente que ARM sea “más rápido”. Lo que sí significa es que puede realizar muchas cargas de trabajo consumiendo considerablemente menos energía. En otras palabras: ARM no busca ganar por fuerza bruta. Busca hacer más con menos. ¿Por qué ahora? Hace unos años, ARM estaba asociado principalmente a teléfonos móviles. Hoy la situación es muy

This closes out the series' capstone: the multi-agent customer support system built across Parts 6-9, now hardened with evaluation, cost governance, and observability so it can actually run in production with an on-call rotation behind it, not just in a demo environment. Continuous evaluation pipeline Evaluation: measuring quality continuously, not just at launch A one-time eval before launch tells you nothing about drift once real traffic — and real edge cases — start hitting the system. Set up a continuous evaluation pipeline using a G-Eval-style approach, where a separate model scores production outputs against explicit criteria: eval_criteria = { " correctness " : " Does the response accurately reflect the order/refund status retrieved from the tools? " , " escalation_appropriateness " : " If the case was ambiguous or high-risk, did the agent escalate to a human rather than resolving it alone? " , " tone " : " Is the response professional and appropriately empathetic given the customer ' s stated frustration level? " , } def geval_score ( response , context , criterion_name , criterion_description , eval_model_client ): prompt = f """ Evaluate the following response against this criterion: { criterion_description } Context: { context } Response: { response } Score from 1-5 and give one sentence of reasoning. Return JSON: {{ " score " : int, " reasoning " : str}} """ result = eval_model_client . complete ( prompt ) return json . loads ( result ) def run_continuous_eval ( sample_of_production_traffic ): scores = { crit : [] for crit in eval_criteria } for interaction in sample_of_production_traffic : for crit_name , crit_desc in eval_criteria . items (): result = geval_score ( interaction . response , interaction . context , crit_name , crit_desc , eval_model_client ) scores [ crit_name ]. append ( result [ " score " ]) return { crit : sum ( vals ) / len ( vals ) for crit , vals in scores . items ()} Sample a percentage of real production traffic daily (not just s

Microsoft has announced the limited public preview of Copilot Autofix for GitHub Advanced Security for Azure DevOps, extending AI-powered vulnerability remediation to teams using Azure Repos. By Craig Risi

I recently built a multi-agent customer support system on Azure AI Foundry and NVIDIA NIM. First time doing anything like this. Made four predictions upfront about what would happen. Three of them were wrong. Here is what I actually learned. 1. "Tokens" is not a unit of cost It is a unit of work. The price per unit of work varies by 5-10x depending on which model did the work. I was tracking total token count across both the small 9B model and the large 49B model as if they cost the same. They do not. Total tokens went up in the optimized version. Cost in dollars probably went down. I was measuring the wrong thing the whole time. 2. A verbatim hash cache on natural language traffic deflects ~0% of queries I predicted 25-40% cache deflection. The actual number was 0%. Every query in my test set was a unique string, so the hash-based cache never had a single chance to fire. A verbatim cache is not a simpler version of a semantic cache. It is a different thing entirely. If your workload is natural language, build semantic similarity caching from day one, not as an upgrade later. 3. configure_azure_monitor() does not capture OpenAI SDK calls by default You need to install and initialize opentelemetry-instrumentation-httpx explicitly: pip install opentelemetry-instrumentation-httpx==0.61b0 from opentelemetry.instrumentation.httpx import HTTPXClientInstrumentor HTTPXClientInstrumentor().instrument() Without this, your App Insights Logs will show customMetric and performanceCounter entries (CPU, memory) but nothing about what your agent actually did. 4. Pin your OpenTelemetry versions or everything breaks Installing opentelemetry-instrumentation-httpx without version pinning pulled in opentelemetry-api 1.42.1. But azure-monitor-opentelemetry-exporter needs opentelemetry-api==1.40. The conflict is silent until things start misbehaving. Pin everything to the 0.61b0 / 1.40.0 line: pip install \ "opentelemetry-api==1.40.0" \ "opentelemetry-instrumentation==0.61b0" \ "opentelem

👋 Hi DEV Community! I'm the creator of Cloud Compass , a newsletter dedicated to making cloud computing easier to understand. If you've ever felt overwhelmed by the constant stream of cloud updates, new services, documentation, and buzzwords, you're definitely not alone. I originally published this as the welcome issue of my newsletter, and I'm sharing it here because I hope it helps developers, students, and anyone starting their cloud journey. ☁️ Welcome to Cloud Compass Cloud news, concepts, and insights without the overwhelm. The cloud is moving fast. Let's make sure you're not left behind. Welcome to Cloud Compass — your guide to staying current with cloud computing while building real cloud knowledge, without feeling overwhelmed. Let's be honest. Keeping up with cloud technology is exhausting. Cloud providers release new services, features, and updates almost every week. Between official documentation, blog posts, YouTube videos, LinkedIn posts, and countless tutorials, it's difficult to know: What actually matters? What should you learn first? Where do you even begin? That's exactly why I started Cloud Compass . This isn't a newsletter written by AI or filled with copied announcements. It's written by someone who genuinely enjoys learning cloud computing and wants to make it easier for everyone else—whether you're: A developer trying to stay current A student entering the cloud world for the first time A professional who wants to understand cloud technology without spending hours reading documentation The goal is simple: Show up regularly with something that's actually useful. "I want Cloud Compass to feel less like reading tech news and more like having a conversation with someone who already read everything and saved you the time." Here's what you can expect 📰 Cloud News Roundup The most important updates from across the cloud industry—not just AWS, Azure, and Google Cloud, but the wider cloud ecosystem. No endless lists of links. No unnecessary hype. Just

Rule of thumb : Secrets → Key Vault Configs → App Configuration Use both for secure + flexible configuration management. Azure Key Vault Purpose : Securely store sensitive information such as secrets, keys, and certificates. Use Cases : Store API keys, connection strings, tokens. Manage and rotate TLS/SSL certificates. Protect cryptographic keys used for encryption/decryption. Strengths : Built-in hardware security module (HSM) support. Access policies and RBAC for fine-grained control. Automatic secret rotation with some Azure services. Logging and monitoring via Azure Monitor. Limitations : Not designed for feature flags or configuration settings that change frequently. API calls can add latency if used excessively at runtime. Azure App Configuration Purpose : Centralized application configuration management . Use Cases : Store non-sensitive app settings (feature flags, UI options, app behavior). Versioned configurations and labels (per environment, per region). Enable dynamic configuration refresh in apps. Strengths : Feature flag management built-in. Supports key-value pairs with labels for environment separation. Integration with Azure Functions, App Service, AKS, and more. High availability and global distribution. Limitations : Not designed to store secrets or keys. Does not provide encryption key lifecycle management. When to Use Which Use Key Vault when : Handling secrets (DB passwords, API keys). Managing certificates and encryption keys. Need secure storage with strong access policies. Use App Configuration when : Handling app configs (feature flags, toggle dark mode, regional endpoints). Need dynamic refresh without redeployment. Want environment-based configuration with versioning. How They Work Together In most real-world solutions, you combine both : Use Azure App Configuration for general settings and feature management. Reference Azure Key Vault inside App Configuration for sensitive values. Example: AppConfig:DbConnectionString → points to Key Vaul

Modern cloud deployments involve many tools with different lifecycles, creating a heavy burden on engineers. The Kubernetes ecosystem offers a unified Control Plane approach. Sharing best practices through tech talks and inner-source collaboration can create an engaged community and drive adoption. By Ben Linders

Introduction This is the second part of sharing my journey to create a microservices-based backend system, in the previous part, I introduced the system and its services. In this part I am going to mention the main things that happened with me from then until now. Transitioning to online DBaaS platforms The first main thing was to transition my databases from my local device to accessible over the internet. I used Neon and MongoDB Atlas . Although performance-wise it is better to deploy the database on the same server that the whole system so all services can access the databases without network overhead , This solution is better from a point, that is avoiding consuming the free VM instance that I got to host my main services, as with DBaaS platforms I will not require storage for databases or additional overhead to handle the DBMS on a free small resources-constrained VM. Observability Observability is one of the main concerns in any system, it gives the ability for the system to expose what happens inside it without any need to guess and manually trace the code to determine where the error may happened. I utilized OpenTelemetry , as I found it is most used and accepted tool to log, trace and collect metrics about the system and the traffic. Also, I loved that it is not related to specific framework, that is .NET by the way, I loved the idea that it is standalone tool. But logging and tracing and metrics collection will not be beneficial if we do not see it actually and can achieve monitoring from those telemetry data, so I used Grafana Cloud to export the telemetry data to some place that is accessible online and a tool that can generate dashboards and visualizing for the metrics ( Prometheus ), and UI that can show all the telemetry data easily. Deployment Until this point, we have a system that is fully functional and have consistent docker configuration for its services via Docker Compose, and it database is already there and available. Now this is the point at

At this year's Microsoft Build 2026, Microsoft unveiled a broad set of enhancements to Azure Kubernetes Service (AKS) aimed at making Kubernetes a first-class platform for AI training, inference, and large-scale cloud-native applications. By Craig Risi

I have written some version of "never hardcode secrets, store them in Key Vault instead" in at least five of my last nine posts on this blog. I never actually stopped to explain what that means in practice. This post fixes that, using the real secrets this very blog depends on: a database connection string, an admin panel password, and a set of GitHub deployment credentials. What Azure Key Vault Actually Is Azure Key Vault is a managed service for storing secrets, encryption keys, and certificates securely in the cloud. Instead of a password sitting in a configuration file or a public GitHub repository where anyone with read access can see it, the password lives in Key Vault - encrypted, access-controlled, and logged every single time it is read. Picture your code as a house with see-through walls - anyone looking at the repository can see everything inside, including any password left lying on the kitchen table. Key Vault is a bank vault a few streets away. Your code does not hold the password directly; it holds a key card that lets it walk over and request the password at the exact moment it is needed. Lose the key card, and you still cannot get into the vault without proper identity verification on top of it. Three Things Key Vault Stores Secrets are plain string values - passwords, connection strings, API keys, tokens. Keys are cryptographic keys used for encrypting and decrypting data, or for signing and verifying it. Certificates are X.509 certificates used for TLS or client authentication between services. Most applications, including this one, primarily use the Secrets feature. An Honest Admission About TechStackBlog's Own Setup This blog does not actually use Key Vault directly today. The database password lives in Azure App Service Configuration. The admin panel password and deployment credentials live in GitHub Secrets. For a single-application personal project, this is a perfectly reasonable and secure setup. Key Vault earns its place once you have multi

Azure Functions shipped a serverless agents runtime in public preview at Build 2026. Agents are defined in .agent.md markdown files with YAML triggers, MCP server access, 1,400+ connectors, and sandboxed execution. The Functions team confirmed to InfoQ that the runtime adds no cold start overhead and no billing premium beyond standard Flex Consumption. By Steef-Jan Wiggers

A couple of years ago, I built a custom flashcard app. I had a huge list of words and sentences in Japanese that I collected in an Excel file. I wanted an app that could easily take them and display them on flashcards. The flashcard app was useful, but the main issue was that I could only use it on my laptop. This meant that when I wasn't home, I had no access to it. I made some updates so that I could deploy it to Azure and now I can use it on the train or at the park. I wanted to share the app and lessons learned during development. What It Does The app is a straightforward spaced repetition flashcard tool. You create collections, fill them with cards (front/back/optional notes), and review them. After each card you rate your recall: Button Meaning Easy Remembered without effort Good Remembered correctly Hard Remembered with difficulty Again Forgot (resets to day 1) Ratings feed the SM-2 algorithm, which is the same algorithm as other popular spaced repetition apps like Anki. Cards that are easy get pushed further and further into the future. Cards that are difficult will come back sooner. After a while, you're just reviewing what you actually need to review. There's also a 45-second timer per card. If it expires before you complete the card, it automatically counts as Again (Resets to day 1). Before the timer, I found it easy to lose focus or open another tab and forget about the current card. This has helped me stay focused for longer and stay on this task. The CSS is specifically designed to be mobile friendly. The Tech Stack Frontend: Blazor WebAssembly (.NET 10) Backend: ASP.NET Core minimal API (.NET 10) Database: Azure SQL (Basic DTU tier) Hosting: Azure Static Web Apps (frontend) + Azure App Service F1 free tier (backend) I mostly use C# at work, so Blazor WASM was a natural fit. The whole app shares models and flows together without jumping between languages. Importing Cards from Excel This Excel import function is one of the main reasons I made this app.

Azure API Management shipped a Unified Model API that lets clients speak one format while APIM transforms requests to Anthropic, Vertex AI, and other backends. Content safety policies now cover MCP tool calls and Agent-to-Agent payloads alongside LLM traffic. Token metrics expanded to track reasoning, cached, and audio tokens across providers. By Steef-Jan Wiggers

Microsoft used their Build 2026 event to announce new functionality for Microsoft Foundry. Citing Foundry as "the place where AI agents move from experiments to production systems," in a blog post, Nick Brady writes that the release brings “runtime, tools, memory, grounding, models, observability, and governance” that developers need for production agents, rather than just new model endpoints. By Matt Saunders