The art of simplicity

In message-driven systems, configuring consumers correctly is key to achieving maintainable, scalable, and flexible systems. In MassTransit, two common approaches to achieve this are using ConsumerDefinitions and Endpoint configuration . While both serve the purpose of defining how consumers work within the system, they differ in terms of flexibility, separation of concerns, and implementation details. In this post, we’ll explore the differences and best practices for using them. MassTransit Consumers: The Basics Before diving into the comparison, let’s briefly cover what a consumer is in MassTransit. A consumer is a class responsible for handling incoming messages in a message broker (such as RabbitMQ or Azure Service Bus). Consumers are central to the processing pipeline and play a key role in event-driven architectures. Here is a simple example: Consumer Configuration The question is now how will this consumer be wired to the underlying transport mechanism. As mentioned

Last week we had a production issue at one of my customers where a server went offline due to high memory usage. So far the bad news. The good news is that we had Azure Application Insights monitoring in place, so we could easily validate that the high memory usage  was causing the issue as our Application Insight logs showed a long list of OutOfMemoryException s. However as a separate Application Insights instance was used per application, we couldn’t easily pinpoint which application was the main culprit. Remark: Unfortunately it isn’t  possible to show multiple resources on the Metrics tab, so that is not an option(you can upvote the feature if you like it): I could go through every Application Insights resource one by one, but that wouldn’t be very efficient. Therefore I decided to turn to KQL and write a query on top of the Log Analytics workspace where all the data was consolidated. Here is the query I used in the end: And here is how the result looked like when I exec

As Semantic Kernel could work with any OpenAI compatible endpoint, and Ollama exposes it language models through an OpenAI compatible API, combining the 2 was always possible. However not all features of Ollama were accessible through Semantic Kernel. With the recent release of a dedicated Ollama connector for Semantic Kernel, we can start using some of the more advanced Semantic Kernel features directly targetting Ollama deployed models. The new connector is using Ollama Sharp(I talked about it in this post ) so you can directly access the library if needed. Giving the new connector a try… Create a new Console application and add the Microsoft.SemanticKernel.Connectors.Ollama NuGet package: dotnet add package Microsoft.SemanticKernel.Connectors.Ollama --version 1.21.1-alpha Now instead of creating a Semantic Kernel instance, we can directly create an OllamaChatCompletionService instance: The remaining part of the code remains the same as with the default

A colleague trying to add SonarQube integration to his build pipeline in Azure DevOps, contacted me because he got an error in his build pipeline. This is the error he got: ##[error]No agent found in pool default which satisfies the following demand: Agent.Version. All demands: msbuild, visualstudio, Agent.Version -gtVersion 3.218.0 The problem was caused by the SonarQubePrepare task he just added to his build pipeline: It still worked with an older SonarQubePrepare version however the task is marked as deprecated: ##[warning]This task is deprecated. Please upgrade to the latest version. For more information, refer to https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/scanners/sonarqube-extension-for-azure-devops/ Updating a build agent I thought the fix would be easy; just update the outdated build agent(s). Therefore go to Project Settings –> Agent Pools . Click on the Agent pool which contains the agent you want to update:  On the

In Azure DevOps, managing external service connections for pipelines and deployments can become complex, especially when you have multiple projects. Sharing service connections across projects in Azure DevOps not only streamlines pipeline configuration but also enforces consistent security policies. In this post, I’ll show you how to share service connections across multiple projects. But let me first explain what service connections actually are. What is a service connection in Azure DevOps? Azure DevOps uses service connections to allow pipelines to communicate with external services like Azure, AWS, Docker registries, GitHub, and more. These connections store credentials, allowing seamless integration with external systems without hardcoding secrets in your pipelines. You can configure service connections at the project level by going to Project Settings > Service connections . If you click on New Service Connection , you get a list a possible connection types: How t

Yesterday I talked about OllamaSharp as an alternative (to Semantic Kernel) to talk to your Ollama endpoint using C#. The reason I wanted to directly use Ollama and not use Semantic Kernel was because I wanted to give the recently announced Ollama Tool support a try. And that is exactly what we are going to explore in this post. Keep reading... Tool support Tool support allows a model to answer a given prompt using tools it knows about, making it possible to interact with the outside world and do things like for example calling an API. It makes your model a lot smarter as it can start using information that was not part of the originally trained model and do more things than just returning a response. Remark: A similar feature exists in Semantic Kernel through the concept of Plugins but as far as I’m aware the Plugins are not using the Ollama tools support (yet).  When writing this post I noticed that a new Ollama connector was released for Semantic Kernel which uses OllamaSha