The art of simplicity

Dapr (Distributed Application Runtime) is a free and open-source runtime system designed to support cloud-native and serverless computing It provides APIs that simplify microservice connectivity, enabling developers to write resilient and secure microservices. Dapr abstracts away the complexity of common challenges developers encounter regularly when building distributed applications, such as service discovery, message broker integration, encryption, observability, and secret management It runs as a sidecar wherever your application runs whether hosted on Kubernetes, VMs, deployed on the cloud, on-premises or on the edge. Although the documentation is great, it can still be a challenge to start building your first dapr enabled application. Therefore I can recommend the Dapr workshop ; it contains several hands-on assignments that will introduce you to Dapr. You will start with a simple microservices application that contains a number of services. In each assignment, you will ch...

Last Friday I did a presentation at Visug XL . If you missed my presentation or are interested in the slides, I've made them available for download here . No idea what my talk was about? Here is the abstract: There it is! After months of struggling your well decomposed microservices architecture finally sees the light. Nicely separated services with their own datastore, well defined service boundaries, clear API contracts, … . A software architect dream is coming true. But now you need to start working on the frontend and gone is all your clean separation! In this session we’ll walk the last mile and evaluate multiple ways on how to bring information from multiple (micro) services together so that they can be consumed by the frontend. ViewModel composition, gateway aggregation, Backend for Frontends, GraphQL Federation and other options are compared and pro’s and con’s of each technique will be discussed.  

I recently upgraded the (development) RabbitMQ cluster of one of my clients to RabbitMQ 3.9. The upgrade went smoothly and none of the development teams mentioned any issues. So I was happily preparing for the production upgrade. A few weeks later I was contacted by one of the team leads who was investigating a specific issue he had in one of his applications; he was using a message published to RabbitMQ to trigger a long running task (a batch job). This message was picked by a Windows Service that uses a MassTransit consumer to execute this long running task. The strange this was that the task sometimes failed. The normal behavior in MassTransit is that this message would end up in the error queue (maybe after a few retries). However this didn’t happen and the message was put back on the queue. What was going on? I started by having a look at the error logs and notice a message like this: "Message ACK failed: 258", "The channel was closed: AMQP close...

If you are a regular reader of my blog, you know that I’m a big fan of GraphQL. Unfortunately there is still a lot of misunderstanding on what this technology exactly is and what problems it helps to tackle. So if you meet someone who is new to GraphQL or has some misconceptions around it, send them a link to the following blog post: https://www.the-guild.dev/blog/how-not-to-learn-graphql . In this post Charly Poly handles the following mistakes: Mistake #1: GraphQL is a front-end technology Mistake #2: Design GraphQL APIs like REST APIs Mistake #3: Learning GraphQL only through Apollo Mistake #4: Throwing errors from resolvers Mistake #5: "Federation is the only viable way to compose schemas"

If you are interested in message or event based architectures, bookmark the link to the following Github repo: https://github.com/clemensv/messaging This repository is created by Clemens Vaster, the product architect of the messaging and eventing services in the Microsoft Azure cloud. It refers to a lot of talks and articles that help you to get started with message and event based systems and links to the product pages of multiple cloud providers and open source products that exist in this space.

Using a non sequential GUID in an index is not a good idea as it leads to index fragmentation and decreased performance. We could switch to an identity field but this is not ideal in a highly distributed (micro)services architecture. RT.Comb to the rescue! RT.Comb implements the “COMB” technique, as described by Jimmy Nilsson, which replaces the portion of a GUID that is sorted first with a date/time value. This guarantees (within the precision of the system clock) that values will be sequential, even when the code runs on different machines. RT.Comb is available as a NuGet package and provides different strategies for generating the timestamp optimized for different database platforms: RT.Comb.Provider.Legacy : The original technique. Only recommended if you need to support existing COMB values created using this technique. RT.Comb.Provider.Sql : This is the recommended technique for COMBs stored in Microsoft SQL Server. RT.Comb.Provider.Postgre : This is the reco...

gRPC is a really great fit as a communication protocol between your (internal) microservices. It runs on top of HTTP/2 and gives you great performance. One caveat is that the HTTP/2 prerequisite requires by default that all communication is happening securely. So you have to setup TLS and create certificates for all your services. But what should you do when you are using Kubernetes and use TLS termination at the ingress controller level? A new feature announced in .NET Core 3.0 brings rescue. You can turn on unencrypted connections for HTTP/2 by setting the DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT environment variable to 1 or by enabling it in the app context:

Every year I shout out on my blog that a new edition of .NET Conf is coming(this year November 10-12 for the .NET 5 launch). What I was not aware of is that the organizers of .NET Conf started a series of smaller events focused on specific things you can do with .NET. There have been 2 editions so far; one focusing on Blazor and the other one on Xamarin. The next one is about Microservices (who could have guessed that?) on July 30, 2020. .NET Conf: Focus on Microservices is a free, livestream event that features speakers from the community and .NET teams that are working on designing and building microservice-based applications, tools and frameworks. Learn from the experts their best practices, practical advice, as well as patterns, tools, tips and tricks for successfully designing, building, deploying and running cloud native applications at scale with .NET. Check out the agenda and the amazing list of speakers .

While running some stress tests on our environment, I noticed that our queues started to fill up. When I took a look at our MassTransit consumers, they were processing 10 messages simultaneously but not more although the CPU on the server was not stressed at all. What is going on? The reason is due to the number of messages the RabbitMQ transport will “prefetch” from the queue. The default for this is 10, so we can only process 10 messages simultaneously. To increase this, we can do 2 things: Configure the prefetchcount for your endpoint using the PrefetchCount property on the IRabbitMqBusFactoryConfigurator class. Add a ?prefetch=X to the Rabbit URL. Remark: As a general recommendation, PrefetchCount should be relatively high, so that RabbitMQ doesn't choke delivering messages due to network delays.

Something that was kind of confusing for me was the relationship between MassTransit Fault<T> events and Error Queues. When a MassTransit consumer throws an exception, the exception is caught by middleware and the message is moved to an _error queue (prefixed by the receive endpoint queue name). The exception details are stored as headers with the message. I was thinking that the Messages were wrapped in a Fault<T> event before they were stored in the queue. But it turns out that they are unrelated. What really happens is that in addition to moving the message to an error queue, MassTransit also generates a Fault<T> event. This event is either sent to a FaultAddress or ResponseAddress if present or the fault is published.

When you publish a message through MassTransit to RabbitMQ, a default naming strategy is used to create a corresponding exchange. The default naming convention is the fully qualified name of the message class, so if you have a class named HelloWorldMessage in a namespace MyCompany.Messages.V1, you’ll end up with an exchange named MyCompany.Messages.V1:HelloWorldMessage. This is ok if you are running RabbitMQ locally(through Docker for example), but it gets quite annoying if you are publishing to a shared infrastructure during development. The problem is that you start receiving messages from other developers which makes debugging a lot more difficult. To solve this problem I created a custom EntityNameFormatter that allows you to specify an extra environment setting that can be set to for example to a specific username. Doing this in MassTransit 5 is not that hard as you can set this for the whole MessageTopology(something that was not easily done in previous versions). Here is t...

I tried Azure Service Fabric before but didn’t like it so much at that time(about 2 years ago) due to 2 reasons: Really flaky SDK and Visual Studio integration. We had a lot of problems to keep everything up and running when SDK updates where released. Lack of ecosystem around it, especially the dashboard and monitoring options were too limited compared to other solutions However after watching the following video, I think it’s time I reevaluate my opinion and give Service Fabric a second try:

Perfect reading material for during the Christmas holidays! Microsoft released some new material together with a reference implementation on how to build a microservices application on top of the Azure platform. Microservices have become a popular architectural style for building cloud applications that are resilient, highly scalable, and able to evolve quickly. To be more than just a buzzword, however, microservices require a different approach to designing and building applications. In this set of articles, we explore how to build and run a microservices architecture on Azure. Topics include: Using Domain Driven Design (DDD) to design a microservices architecture. Choosing the right Azure technologies for compute, storage, messaging, and other elements of the design. Understanding microservices design patterns. Designing for resiliency, scalability, and performance. Building a CI/CD pipeline.