Service Granularity

I liked the notion of “integration” and “disintegration” drivers. In my team, we run about 20 services. I sometimes wonder if we have the granularity correct and/or if our team is too small…

Software service granularity: Getting it right

Microsoft.FeatureManagement

This is probably not as spiffy as LaunchDarkly or even the stuff in (ridiculously expensive) Azure App Configuration, but as a free service I could see myself using this in combination with my modified Key Vault config provider (which can reload on an interval; something which is required, as the feature is built on top of .NET configuration).

.NET Feature Management

https://www.milanjovanovic.tech/blog/feature-flags-in-dotnet-and-how-i-use-them-for-ab-testing

Microsoft Clarity

Saw a demo at work the other day - it is pretty crazy to be able to track frustrated users attempting on stuff you did not intend them to click on, while overlooking the button you thought they would see.

They are very honest about

  • it is and will remain a free service
  • they run it, because they gets loads of profiling data sent in they can use themselves

https://clarity.microsoft.com/

Cloud Cloak

Great stuff - hiding secrets in Azure and elsewhere while streaming.

https://github.com/microsoft/cloudcloak

Philosophy

This made me laugh, I am a sucker for any trolley-problem setup

Philosophy

Making ASP.NET Core Controllers internal

Was doing some refactoring in a project and once more needed this to control “viral” public visibility in the project.

ASP.NET (Core)’s zombie virus of ‘public’: can controllers be internal?