I’m currently working on some automation within Azure to deploy a hub-spoke web application. This web application authenticates with Entra ID using an App Registration and Role-Based Access Controls (RBAS) using App Roles. So, I need to create an app registration, enterprise app, and create the app roles.
One of the persistent questions I get asked about Azure Mobile Apps is how to support older tables. Let’s say you have an older application that was never designed for mobile applications. It likely has a model like this:
If you are an Azure developer, you likely spin up an application, do some work, then shut it down again. However, shutting down resources and deleting them has an order to them. If your service is network isolated (in a virtual network), then you can’t delete the application until the private endpoints are shut down. Budgets don’t get deleted with the resource group. Diagnostic settings can’t be deleted if the resource no longer exists. There is an order you should do things:
I work a lot with Azure API Management, which means I turn up and down services quite a few times a day. Azure API Management has an awesome feature that prevents you from accidentally deleting a service, called soft-delete. Instead of immediately deleting the service, it marks it as soft deleted and purges it later on. Unfortunately, that means that you can’t immediately reuse that service name. In production, this is a great thing to have. In development, it turns into a pain. That’s b...
As you may have guessed by now, I’m delving heavily into the world of Bicep right now, mostly in order to describe the infrastructure for my personal projects in a readable way. JSON and YAML (used by ARM) is most definitely not readable for the average consumer. Part of that work was learning about bicep modules, which I love for modularizing my code. However, there is one distinctive problem with this.