Azure API Management recently announced the general availability of a new feature called Versions and Revisions. Versions allow you to group multiple versions of your API, revisions allow controlled, safe and testable API changes. Here is another post that explains things in more detail.

This post is sort of a follow up on a previous post where I attempted to prevent a duplicate login when accessing both Azure Resource Manager and Azure AD in the same PowerShell script, still without success by the way.

UPDATE (2018-02-12): The method described below does not work, unfortunately. Connect-AzureAD runs without error but the AD context you get is not authorized to perform AD operations.

One of our customers runs on Azure Service Fabric (SF) which is backed by a Virtual machine scale set (VMSS). We had a connectivity problem recently and one of the developers enabled remote debugging on the SF cluster to see what went wrong. Little did he know that (among other things) a large number of additional TCP ports are opened on the cluster load balancers to allow debuggers to attach.

Spring Cloud Config server is a Java-based application that provides support for externalized configuration in a distributed system. A number of external configuration sources are supported like the local file system, Git or HashiCorp Vault. For this post, I use a Github repo as my configuration source. Centralizing configuration on a source control repo has several advantages, especially in a micro services architecture:

I was looking at options to run some PowerShell scripts in Azure and my first idea was: why not start a Windows Server Container with the right PowerShell modules and run the scripts there? Turns out there are better options for running PowerShell scripts in Azure ([Azure Automation Runbooks][1]) so I did not continue on this path but this is really cool technology and I learned a few things so I thought: let's write this down.

I was struggling for about an hour getting debug logging to console working in ASP.NET Core so I thought I should write it down. I got tricked by the default appsettings.json and appsettings.Development.json that get generated when you run dotnet new.

I'm developing a smoke tests app in Go that tests a number of services (Redis, RabbitMQ, Single Sign-On, etc) that are offered in the marketplace of a CloudFoundry installation at one of our customers. These tests produce simple JSON output that signals what went wrong. Now the customer has asked for a dashboard so the entire organization can check on the health of the platform.

This is part 2 of a series of (still) unknown length where I try to describe how to deploy the [SDL Tridion Web 8.5 Discovery Service][1] on CloudFoundry.

A customer of ITQ is running [SDL][1] [Tridion][2] content management software and has asked us to deliver a proof-of-concept of running a Tridion website and the Tridion 8.5 micro services on Pivotal CloudFoundry. This post is a journal of my attempts of deploying the [SDL Web 8.5 Discovery Service][3] on CloudFoundry.