All posts by Allan Hardy

ASP.NET CoreKubernetes

Azure Kubernetes Service First Look

I’ve read a fair bit about Kubernetes over the last couple of years but never got around to having a proper hands on go at running applications in a Kubernetes cluster. Most of my cloud development has been on AWS however my workplace for the past almost 2 years has been on Azure so decided to give AKS a go.

My approach to getting a proper feel was to have a couple of very simple applications hosted on AKS with typical application requirements such as exposing an API to the public internet with custom DNS, TLS termination, some type of application secret management, pub/sub via an API call and a worker subscribing to the published message etc.

You can find the source code here on Github with complete steps on getting the solution running on AKS.

The solution includes two .NET Core 3.0 applications, an API and a background worker process, intentionally kept very simple.

The ASP.NET Core 3.0 API provides a few endpoints:
1. GET /env which returns the machine / pod name that the API is running on.
2. GET /secrets which returns all the applications secrets
3. POST /command which sends a message to Azure Service Bus using NServiceBus

The .NET Core 3.0 worker process subscribes to the message sent by the /command API endpoint and simply does a console.writeline on the message body.

The solution uses Azure Active Directory Pod Identity to assign User Managed Identities to pods allowing access to Azure resources. The application’s in the solution use two different types of Azure resources, Azure KeyVault and Azure Service Bus. The reason why I chose KeyVault for secret management was that it by default provides encryption at rest and is easily configured to provide auditing and soft deletes.


My Open Source Journey

A couple of years back I forked Metrics.NET to provide dotnet core support and modernise the library as I found it useful in my work and personal projects. Reason for forking was that the colleagues of the original author (Iulian Margarintescu), who were kind enough to invest their own time attempting to keep the project alive, did not have sufficient “free” time to further it, which is fair enough, no criticisms at all as there are of course many factors which will take one away from working on open source projects. Props to Iulian Margarintescu for his efforts in porting the Java dropwizard metrics project over to .NET.

Because I had been a contributor to Metrics.NET and used the library in many of my of projects I did make a few attempts to move it along and initially implemented an aspnet core wrapper around Metrics.NET, however after some time I decided to fork the project allowing me to move at my own pace, implement and refactor what I needed which became App Metrics.

Why do developers even bother with open source? I mean it’s normally time taken away from family and leisure outside of day jobs.

Well for myself, after being introduced to application metrics, monitoring and various TSDBs, I developed a passion for really getting to know my applications behaviour in a production environment and being alerted when something abnormal occurred, or even, was about to occur. I couldn’t find a library that supported exactly what I wanted, so invested time in App Metrics.

Yes there is ETW and things like EventCounters in corefx which look promising in the space, however samples and documentation are really lacking, there are many lengthy github issues on this topic. In saying that I should probably contribute there by working things out myself and blogging on the topic, however App Metrics, although an opinionated Metrics/Health Check implementation, works well for most of my use cases and is where my open source efforts are spent.

Open source can be a great way to keep up to date with the latest pre-release builds of the framework your building on and explore new features which can be leveraged by your project very early. In a day job, that may be a little more difficult to do, or justify to a business. However staying up-to-date through an open source project allows you to stay ahead of the curve through a practical piece of work, may assist others who review your code, allow you to go back to work to apply and share your learnings with your team as opposed to spending more time learning on the job.

App Metrics is my first attempt in owning an open source project. So far I’ve felt it’s definitely a great feeling getting support and motivative feedback on your project, even if that’s constructive criticism. It’s a great opportunity to build software which you are passionate about for your own use but then share it with others who may also find it useful, at the same time develop your understanding in an area of interest and a way to really stay up-to-date with the technology you’re working with.

Open source I’ve found is not all positive though, it can be a lot of late night commits, an annoyed wife and expectations that you yourself should maintain and implement features that others require. Efforts can also be wasted and not supported, for example the initial version of App Metrics included Health Check functionality in the core library. After coming across an early AspNet Core Health Check implementation from Microsoft I decided to separate Metrics and Health Checks, so that users could choose to use App Metrics for metrics specifically and Microsoft’s Health Check implementation when it was released.

Now seeing Microsoft advertise their equivalent Health Check implementation through documentation and popular code samples such as eShopOnContainers, I’ll probably just drop my implementation and direct users there. It would however be nice to get some type of support, especially before such a similar implementation, and there are also others out in the wild, but ah well.

Open source takes a decent amount of time and effort, well it has for me anyways. What I’ve really enjoyed in maintaining an open source project so far has been:

  • Investigating areas I’d normally not get a chance to in my day job
  • Having a project to apply new framework features and stay up-to-date as opposed reading an article or piece of documentation
  • Having others find the project useful I find rewarding
  • Feedback from users, again even if that’s constructive criticism which is a great way to learn and improve
  • Users willing to contribute, even small contributions which help such as documentation
  • Free for open source! Thanks JetBrains, OzCode, NDepend, AppVeyor, TravisCI, Coveralls

ASP.NET Core Real-time Performance Monitoring

Update: Based on App Metrics 1.0, latest documentation can be found here

One of my previous posts was about open source application performance management, and why we even consider open source. If we were to give an open source monitoring solution a shot for an ASP.NET Core application, what options are available? One option is an open source project I’ve been working on, App Metrics. It targets .NET Standard which of course makes it a cross platform solution, provides various extensions allowing metrics to be captured in process and persisted to several TSDBs, as well as providing application health checks.

Read More


ASP.NET Core Health Checks

Update: Based on App Metrics 1.0, latest documentation can be found here

Health checks are useful to not only test the internal health of your application but also it’s external dependencies such as confirming that a third party api is available or confirming the connectivity to a database for example. App Metrics provides such health checks and exposes a health endpoint whereby results can be viewed and monitored. Health checks in App Metrics are small tests which return either a healthy, degraded or unhealthy result. Health checks are executed when the health endpoint is requested via ASP.NET Core Middleware.

Here we’ll look at configuring App Metrics to provide health checks in an ASP.NET Core MVC application.

Read More