The art of simplicity

Last week I shared my understanding of how capacity works in Microsoft Fabric. I just hit publish when I got a message that I exceeded my Fabric capacity (again). Time to open the Fabrics Metrics dashboard I introduced in my last post about Fabric and see who is the culprit: I opened the Compute tab and hovered over the top item in the list.  Turns out that Copilot is eating up a lot of my capacity. Whoops! I decided to disable copilot for this data warehouse. Therefore, I opened up a query in the data warehouse and clicked on the Copilot completions item at the bottom of the screen: This opens the configuration settings for my data warehouse where I can disable the completions:   If you want to disable Copilot completely, you can do that at the tenant level :   Remark: If you are still confused on how Fabric capacity exactly works, I found this great post by Tom Keim where he compares CU usage to watts: Just like electricity, where we’re billed by k...

Azure DevOps offers a repository health feature, which allows to monitor multiple metrics that contribute to the health of your Git repositories. If you are using Azure DevOps services, you maybe already know this feature. But with the latest release of Azure DevOps server (December 2025) , it finally arrived on-premise as well. Reasons enough to have a deeper look at it and write this post. Let’s dive in! Why is this feature relevant for my team? Think of your Git repository like a living organism. As it grows with more commits, blobs, branches, and objects, it can become sluggish and unwieldy. Large repositories increase the load on Azure DevOps infrastructure, affecting performance and user experience. Without proper maintenance, your team could face slower clone times, degraded git operations, and even service disruptions. The repository health feature now provides visibility into key health metrics and offers actionable recommendations before problems escalate. Getting t...

Being new to Microsoft Fabric, one of the topics that I found challenging, is how Fabric capacity and especially the throttling works. And what is a better way to structure my understanding than writing a blog post. Let’s give it a try! Remark : If I made some mistakes, please feel free to let me know so I can update this article. What is Microsoft Fabric Capacity? Microsoft Fabric capacity is the compute and storage resources you purchase to run Fabric workloads. Unlike traditional per-service pricing models, Fabric uses a unified capacity model where you purchase Capacity Units (CUs) that power all Fabric experiences including Data Engineering, Data Warehouse, Data Science, Real-Time Analytics, Power BI, and Data Factory. When you purchase a Fabric capacity, you're essentially reserving a pool of compute resources that can be shared across different workloads and users within your organization. This capacity is measured in Capacity Units, which represent the computational...

I promised yesterday that it would be my last post about how we are using Dependency Track. But turns out that there is some confusion and a few people asked me the following question: "How should I organize all these projects?" This is a good question because a well-structured project hierarchy makes the difference between a dashboard that provides clarity and one that creates confusion. In this post, I'll share the project organization strategies we've explored and practical examples you can adapt to your organization. Understanding Dependency-Track's model Dependency-Track organizes work around several key concepts: Projects : The fundamental unit representing a software component. Each project has a name and version. Remark: A project can also be flagged as current. Versions : Projects can have multiple versions representing different releases or deployments. Classifiers : Indicates if the project type is a library, framework, ...

Welcome to the final post in this Dependency-Track series! We've covered what Dependency-Track is and why we started using it , how to deploy it on Azure Container Apps , and how to configure OIDC authentication with Microsoft Entra ID. Now it's time to put it all together by integrating Dependency-Track into our Azure DevOps CI/CD pipelines. In this post, I'll show you how to automatically generate Software Bill of Materials (SBOMs and upload them to Dependency-Track, By the end, you'll have a fully automated vulnerability management workflow that provides continuous visibility into your software supply chain. CI/CD architecture We adopted the following approach for integrating Dependency-Track in our CI/CD architecture: During the CI phase we generate an SBOM as part of the build process using language-specific tools and store it among the other build artifacts During the CD phase , the code is rolled out in multiple environments with approval checks between...

In my previous posts, I introduced Dependency-Track and showed you how to deploy it on Azure Container Apps . Now that you have a working instance, it's time to secure it properly by integrating with your organization's identity provider. In this post, I'll walk you through configuring Dependency-Track to use OpenID Connect (OIDC) authentication with Microsoft Entra ID (formerly Azure Active Directory). This integration will allow your users to log in using their existing corporate credentials, enable single sign-on (SSO), and leverage conditional access policies for enhanced security. Why using OIDC with Microsoft Entra ID? Before diving into the configuration, let's understand the benefits of this integration: Centralized Identity Management : Users authenticate with their existing Microsoft Entra ID accounts, eliminating the need to manage separate credentials for Dependency-Track. Single Sign-On (SSO) : Users already logged into Microsoft services can acc...