2020 Articles

In a world where we use auto-scaling a lot, its often not just one metric that we will take into consideration when deciding whether or not to scale our applications. For example, we might have a combination of CPU usage, memory usage and web request latency. Some services like AWS CloudWatch Metrics only allow scaling based off a single value. Luckily, we can blend metrics together to create new ones, which we can then use in our scaling policies. A blended metric is made up of however one or more existing metrics that you choose, called aspects, and can be published as if it were any other metric, eg: publish to DataDog/Cloudwatch.

In a previous post I took a look at how we can utilize .NET event counters to record metrics in our applications. However, I never covered the implementation of how I write the metrics to either CloudWatch or DataDog. In this article, I’m going to take a look at how to publish metrics to CloudWatch and one way of integrating it with the aforementioned blog series.

In the vast majority of companies that I’ve been in, software engineering & infrastructure best practises have often been left as something that needs to be updated later because building the product comes first. This is completely understandable as if you don’t have a product, you don’t have employment. This presents problems later when companies are beginning to scale rapidly and become popular. Not only does the company becomes a target for malicious actors, but security-related incidents can easily occur by leaving storage devices open accidentally. Once a malicious actor is in your system, you usually have pretty big problems unless you design your architectures with Zero Trust in mind.

In this article, I want to take a look at a scenario that I came across this week which I’ve come across a few times. Occasionally, you will have an interface that you wish to mock out with Moq and find you have troubles because the method signature takes a ref or an out parameter. This week, I’ve found a way that we can successfully mock the method without too much of a change to the test code.

Over the past few months, I’ve been looking into the internal architecture setup for Checkout.com and seeing how we can scale it for the next few years. As part of that research, I’ve been looking into the CloudEvents specification as a potential option as the basis for a common event schema across teams.

In my previous article, we took a look at setting up a template repository for our .Net projects. Repository templates can massively help with the consistency and startup speed of a new project. In this article, we will take a look at a different repository template that I’ve been using for work for running our performance tests.

Over the past few weeks, I’ve been updating some of my projects to latest standards, adding in Github Actions where appropriate etc. Most recently I’ve setup a template repository in Github.

Recently, we’ve had the need to build a few feature toggles in our applications that can be changed at runtime. This article walks through a simple approach that you can use in your applications, including a description of a route to dynamic feature toggles.

Over the past year or so, I’ve had the pleasure of mentoring people on their software development journeys. Some of those personnel have expressed a desire to pursue the software architect route. As it’s something that I often refer to, I’ve decided to post a mini-pathway to help guide on some of the basics.

Git aliases are used to create new git commands that can either invoke a function, or be used to create commands that map to longer commands. For example, we could map git co to git checkout or have git undo undo our previous commit. In this article, I’m going to show you some of my favourite git aliases.

In a previous article, we took a look at a way to use dotnet-counters with an external image. This article takes a look at how we can embed the tooling that we require into the image so that we extract the counter/memory information as required. This approach does not require elevated permissions as before.

In my previous article we took a look at how to monitor outbound HTTP requests using a DiagnosticListener. In this article, we will re-use some of the same components to monitor inbound HTTP requests. We could use middleware to do as most approaches do, but this approach is highly dependent on the middleware that you have and the duration of this, so we will re-use some of the code from last time.

Throughout the course of my Diagnostics in .Net Core series, we’ve taken a look at the basics of how to use the Event Counters API. In this article, we will take a look at how we can capture all outbound HTTP requests automatically as they occur.

Today, I have been doing a general tidy up of my blog repository. One of the things that I decided to do, was reduce the overall amount of whitespace in the generated html files.

In my previous post, I described how we can leverage the new EventCounter diagnostics API to add custom event counters and listen for built in counters. In this article, I will walk through how we can leverage the dotnet-counters tool with a running docker image.

Recently, I’ve been playing with the new diagnostic improvements in .Net Core 3. Traditionally, I’ve always used the great AppMetrics package to capture the metrics from our applications and send scrape them with a Prometheus & Grafana setup. Whilst reading about the improvements, I wondered whether or not it would be possible to push metrics to Prometheus.