Microsoft/azure

2 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.