Managing Azure API Management with APIOPS

Azure's API Management (APIM) resource is one of the most complex in the Azure ecosystem. It has several configuration pieces such as API endpoints, policy objects and secrets, with relationships between these objects. This complexity carries into Infrastructure as Code (IaC). When exporting an APIM instance with a few configuration items, the resulting ARM template can easily be over 15,000 lines line. Even using Bicep, where we can experience a 4:1 reduction in line count, we would be dealing with a very large file.

This leads to a conclusion that managing an APIM instance solely using Bicep or Terraform would be difficult. Fortunately, Microsoft have provided a toolset called "API Ops" which allows easy importing and exporting of APIM configuration.

DORA 2024 State of DevOps Report

The DevOps Research and Assessment (DORA) produces a yearly research report on the progress of DevOps practices in the industry. When reading it, a few points stood out.

Performance Bands

The majority (60%) of responding organisations sit in the Medium and Low performance level bands. Compared to 2023, there was only slight movement towards the higher performing bands. The report did attempt to explain some of this away, stating that longer Change Lead Times and slower Deployment Frequencies could be caused by teams putting more steps in their test/build/deployment processes. This does seem to line up with the outlier statistic of the Medium performance band having a lower Change Failure rate tha the High band (10% vs 20%).

However, the results do seem to indicate that a significant number of organisations, those stuck at the Low band, are not realising much of the benefit of DevOps. These organisations are stuck with high failure rates (40%) and very slow paths to getting their code to production. Given the relative maturity of DevOps methods and tools, this is a concern.

AI

The 2024 report also spent a lot of time on Artificial Intelligence, its uses, impacts and so on. A majority of organisations have shifted to increase the use of AI.

87% of respondents had "some level of trust" with regards to the code that AI tools can generate. This is a bit of a contrast to the experience of some of my peers (and my own) where the quality of code can be mixed, resulting in us having much lower trust and regard for the tools.

The report observed an interesting effect on AI adoption and its impact on valuable work vs toilsome work. Many people had the assumption that AI would be mostly utilised on the "drudge" work that adds little value, freeing up people to focus on the work that adds value. The data indicates the opposite is happening.

Platform Engineering

While Platform Engineering can add many benefits, the report found that in some cases it can actually lead to a degree in throughput. The theory the report put forward is the extra machinery present when using an Internal Developer Platform could be a cause. Extra tasks and steps in the process, such as testing and security checks, while likely improving quality, impact the throughput.

Rendering Issues with Nodejs/NextJS and Azure Front Door

Recently at my workplace, a new application using Node JS and NextJS was implemented. As with all our public facing websites, it was placed behind Azure’s Front Door service, to provide web application firewall (WAF) and caching functionality.

During testing, it was discovered that the site would sometimes not render properly. However it wasn’t a 100% failure rate.

An Early Theory – Geography

Early on a common theme was noticed. If the user device was located in Brisbane, regardless of OS, browser or ISP used, the site would fail to render. If the device was in or close to Sydney, it would render properly. Trying a few other geographical points using VPNs showed similar behaviours.

Azure Defender for DevOps – First Impressions

The recent batch of high profile security incidents at various companies in Australia highlights the need for appropriate security measures across all components of an organisation’s infrastructure. Defender for DevOps is a new functional addon (in preview) to Defender for Cloud. It provides security functionality for your code respositories and associated components.

Setup

When navigating to the Defender for Cloud interface, a new option will appear under the “Cloud Security” heading.

Image

Once we click on this, we are presented with an intro splash page with steps to getting started. The first step is to connect to the environments. Both Azure DevOps and Github repositories are supported environments.

Developing a Bicep Validation Pipeline

Azure’s Bicep is Microsoft’s newer format for defining Azure resources as code. In terms of look and feel, it’s very similar to Terraform.. If one considers Bicep files as code, then it would be a natural step to ensure that code meets a certain level of quality. In addition to that level of quality, because Bicep is deploying infrastructure, we would want to ensure that infrastructure is well designed and has a chance of successfully deploying.

When Bicep started to be adopted by the team I was working in, I became involved in designing a process to meet those quality goals as well as reduce the number of deployment issues.

Registering a VM with Multiple Azure DevOps Environments

Azure DevOps has the concept of Environments, a collection of resources which can be used during a pipeline. At the time of writing the only types of resources that can be used are Virtual Machines and Kubernetes resources. The official documentation on registering a VM resource doesn’t explicitly mention there being any issues with using the same resource across multiple environments, apart from “providing a unique name for the agent”. There’s an important consideration with how the registration process works relating to this.

“Could not create SSL/TLS secure channel” error when using self-hosted Azure DevOps Agent

Recently the team I’m in has been getting into Microsoft’s new Bicep language. As part of a release pipeline, the infrastructure was being deployed – in this case an Azure App Service. Then the application code was being deployed using the standard “Azure App Service Deploy” task. At this particular task, it would error out:

Error: Could not complete the request to remote agent URL 'https://<App Service Name>.scm.azurewebsites.net/msdeploy.axd?site=<App Service Name>'. Error: The request was aborted: Could not create SSL/TLS secure channel.

The pipeline was being run through our “Default” agent pool, which was a self-hosted agent.

Clearing Imperva Cloud WAF Cache using Powershell

Imperva’s cloud-based Web Application Firewall (WAF), previously known as Incapsula, provides protection capabilities as well as caching of website content. In some situations, it may be necessary to clear the cache. This can be easily achieved by using Powershell to interact with Imperva’s REST API.

PowerShell Quality of Life Improvements – PS Repository

In the last post, we were able to create a Release Pipeline that takes checked and signed Powershell code and deploys it to target servers. In some situations, it may not be desirable or viable to have every server configured as a deployment target. Or there may be a need to have an additional amount of control of the modules that a server gets. To deal with these issues, we can look at setting up a PowerShell Respoistory as an intermediatory step.

Setting Up The Respository

The Respository can be as simple as a file share on a server. At the higher end of complexity, it can be a website running NuGet Gallery. For this case, I’ve gone simple. By using a file share, we negate the need for setting up API keys and the like that a NuGet Gallery would need.

Once the PowerShell Respoistory is created, it needs to be registered on the relevant targets. This is achieved using the Register-PSRepository cmdlet, as shown below:

Register-PSRepository -Name psqol -SourceLocation "\\svr14\psrepo\" -PublishLocation "\\svr14\psrepo\" -InstallationPolicy Trusted If the InstallationPolicy value is set to “Untrusted”, then there will be a user prompt when attempting to install modules from the Repository.