I’ve been back in the engine room a bit more over the last couple of weeks. And it’s been great - or at least it had been, until I starting helping one of my team with a problem they were facing with a solution we were building for a customer.

Finding a balance between agility and control when managing a cloud environment is like walking a tightrope. Lean too far on one side and your teams find themselves hamstrung, unable to innovate; the other, and before you know it, your environment resembles the Wild West.

When I say I wasn’t sure, I really wasn’t sure. It’s not that I didn’t think using ChatGPT would help me be more productive, or that I wouldn’t be able learn to steer it effectively. Rather, what I wasn’t sure about was whether regularly employing ChatGPT would erode some of the fundamental parts of my working day.

There is a lot of idealistic rhetoric in the software industry.  That’s not exactly new, and for the most part we’re able to look past the often quite absolute language (the “musts” and the “bests”), and remember the importance of context.  But that statement generally only holds when we talk about software engineering principles (tools, technologies, and design patterns). I feel we have a way to go when we talk about software delivery principles (people and processes).

In part 1 of this mini series I talked about some of the basics of Chaos Engineering and how Azure Chaos Studio can be used to perform experiments in a reliable, repeatable and safe manner. In this blog post I'll be looking at how to automate the execution and observation of the experiment I created previously to enable us to add regular resiliency testing to our development lifecycle.

Wy wife and I live in a small, fairly calm town in the UK and we love it - the peace and quiet suits us perfectly. That being said, everyone needs a dose of chaos in their lives from time to time, so this weekend I decided to take a look at the preview release of Azure Chaos Studio to find out how I can use it to breach the peace of my Azure deployments 😇

Availability Tests are a great feature of Azure Application Insights. They allow you to set up active black box monitoring from points around the world so that you can measure your application's responsiveness and availability from outside of your environment. There is one snag however: the built-in availability tests originate from hosts on the public internet which means your web app must be exposed for the tests to succeed.

One of the most powerful features of Azure Functions are their input and output bindings which enable simple integration with other services. Whilst the collection of bindings currently on offer covers a good number of common integration points, it is likely that we will need to communicate with a service that doesn't have a binding at some point in the future. When this happens we will need to implement this communication ourselves which, more often than not, will involve making HTTP calls to the service using whatever method is appropriate in our language of choice. As it's 2021 it really ought to be fair to assume that we'll be communicating with the service using HTTPS, so what happens when that service is offering up a non-public (e.g. self signed or produced by a private certificate authority) certificate for HTTPS?

Recently I needed to pull some information out of several Azure Function Apps as a final task in their deployment pipeline and I found that my go-to Azure PowerShell commands did not give me what I needed. This post describes how you can use the Azure REST API when your favourite tools don't quite cut the mustard.