azure

3 posts

microsoft

How Microsoft Engineers Build AI: Learn about scalable RAG-enabled AI Apps (opens in new tab)

Microsoft’s new *How Microsoft Engineers Build AI* video series explains how its teams develop AI applications at scale. The first episode focuses on retrieval-augmented generation (RAG), using Copilot for Azure’s Ask Learn plugin as a practical example. It shows how RAG can combine proprietary data with large language models to deliver accurate, contextually relevant answers. ## Building AI Applications with RAG - RAG is presented as a practical way to improve AI applications without relying solely on model fine-tuning. - It retrieves relevant information from a knowledge base and provides that context to an LLM when generating responses. - The approach is useful for applications that need current, domain-specific, or proprietary information. ## The Ask Learn Plugin - Microsoft engineers explain how they built the Ask Learn RAG plugin for Copilot for Azure. - The plugin helps Azure developers find answers quickly within their existing workflow. - The project involved product managers and engineering leaders sharing development challenges, design decisions, and best practices. ## Challenges in Developing Reliable RAG - Selecting the right source content is essential for producing useful answers. - Data must be preprocessed effectively before it can be retrieved. - RAG systems require careful performance evaluation to measure accuracy and relevance. - Keeping responses accurate and up to date requires ongoing improvements to content and retrieval methods. ## Broader Microsoft Applications - The episode discusses RAG implementations across: - Copilot in Azure - Microsoft Security Copilot - Dynamics 365 Business Central - These examples demonstrate how RAG can support different products and business scenarios. The episode is intended as a practical introduction for developers building RAG-based applications, covering prototyping, data management, evaluation, and common pitfalls. Developers can explore the series alongside Microsoft Learn resources and Azure AI development tools such as Visual Studio and GitHub Copilot.

microsoft

Managed DevOps Pools – The Origin Story (opens in new tab)

Microsoft’s vast, diverse engineering organization had accumulated more than 5,000 self-hosted Azure DevOps pools, creating duplicated tooling, inconsistent reliability, security gaps, and compliance challenges. Its One Engineering System (1ES) team addressed this with 1ES Hosted Pools, a standardized service for flexible, secure, and scalable CI/CD infrastructure. Adoption reduced costs by more than 60%, cut remaining self-hosted pools to a few dozen, and eventually led to the external Managed DevOps Pools offering. ## The Scale and Challenges of Self-Hosted Infrastructure - Microsoft supports over 100,000 engineers across many businesses, programming languages, operating systems, hardware platforms, build engines, and test frameworks. - By 2021, teams had created: - More than 5,000 self-hosted Azure DevOps pools - Hundreds of thousands of agents - Teams needed capabilities unavailable from Microsoft-hosted agents, including: - Larger compute sizes - Private-network connectivity - Custom images - Stateful agents - Long-running tests - The decentralized approach caused: - Duplicate engineering effort - Uneven support and reliability - Poor resource utilization and higher costs - Inconsistent patching and security practices - Difficult and time-consuming compliance audits ## 1ES Hosted Pools - 1ES developed a standardized internal service for custom Azure DevOps infrastructure. - Teams could connect agents to private resources such as package registries, secret managers, and on-premises services. - They could bring custom images, using centrally maintained images as their base. - Business continuity features allowed backup pools and failover to other Azure regions. - Agents were stateless by default, but teams could reuse stateful agents for better performance through local caches. - Stateful agents were automatically recycled based on age or available disk space. - Teams could select Azure VM families and sizes suited to their workload. - Standby agents could be pre-warmed on schedules or automatically provisioned using historical demand. ## Operational and Business Benefits - **Lower costs:** Infrastructure bills fell by more than 60% through improved utilization, better SKU selection, and selective use of Azure Spot VMs. - **Faster development:** Teams spent less time maintaining CI/CD infrastructure and more time building products. - **Simpler compliance:** Standardized telemetry made audits easier and allowed security and compliance improvements to be deployed centrally. - **Greater mobility:** Developers changing teams no longer had to learn different infrastructure-management systems. - **Improved security:** Features such as Azure Confidential VMs, Trusted Launch, and Secure TPM became available across pools. - **Reduced fragmentation:** By 2024, Microsoft had reduced its remaining self-hosted pools from more than 5,000 to only a few dozen. ## From Internal Platform to Managed DevOps Pools - 1ES first built Hosted Pools as an internal “Host On Behalf Of” service to validate whether centralized management could reduce self-hosting. - Success inside Microsoft, combined with customer demand, led to the external **Managed DevOps Pools (MDP)** service. - Organizations using VM Scale Set agents or self-hosted agents can migrate to MDP to gain standardized scaling, security, compliance, and operational support. - The external offering initially does not include every feature available in 1ES Hosted Pools, though additional capabilities may be added later. Centralizing CI/CD infrastructure can eliminate redundant platform work while improving cost efficiency, security, compliance, and developer productivity. Managed DevOps Pools extends Microsoft’s internal solution to organizations facing similar self-hosting challenges.

figma

Learn how a Microsoft designer built an Icon Library in his spare time | Figma Blog (opens in new tab)

Jackie Chui, a Microsoft designer, built a browser-based library containing more than 4,000 company icons in just three weeks. The tool unified icons across design applications, made them searchable through designer tags and engineering class names, and supported reverse searches using pasted icons. Its success came from focusing on practical user needs, leveraging familiar web technologies, and distributing a simple first version quickly. ## Researching Users and Existing Tools - Jackie interviewed Microsoft designers and observed their workflows to identify problems with existing icon management. - He evaluated IconJar, which offered organization and copy/paste functionality but lacked: - Shared, crowdsourced tagging - Browser and cloud access - Windows compatibility - These limitations led him to build a custom internal solution after hours. ## Designing and Building the Library - Jackie first created the interface in Sketch, borrowing ideas from IconJar and applying Microsoft’s Fabric design language. - With existing HTML, CSS, and JavaScript experience, he used Meteor.js to build both the frontend and backend. - A Meteor React tutorial helped him adapt a simple to-do-list database into an icon database. - Working on a concrete problem allowed him to learn development concepts while building the product. ## Extracting and Organizing Icons - Microsoft’s icons were stored in a font file, requiring users to copy and paste special Unicode icon characters into their designs. - Jackie extracted the icon files and retrieved each icon’s Unicode character. - He found Microsoft documentation containing the corresponding engineering class names. - The names were collected in Excel, converted to JSON, and imported into the application. - The resulting library let designers search for icons and copy their characters from one central location. ## Distribution and Adoption - Jackie hosted the application on Microsoft Azure. - He initially emailed the link to his team, after which word-of-mouth spread it throughout the design studio. - Users helped identify bugs and suggest features for version two. - The library quickly became part of many designers’ regular workflows. ## Future Plans - Jackie planned to convert all 4,000-plus icons into Figma components with a single click. - This would let Microsoft teams organize and search icons directly in Figma rather than through a separate browser tool. - He also hoped to release the converter more broadly so anyone could turn an icon font file into Figma components. The project demonstrates that an effective internal tool can start with focused user research, modest technical foundations, and a rapid first release. A browser-based, searchable library is a practical way to eliminate design-tool silos and create a shared source of truth for icons.