Using the cloud has been an interesting experience, I recommend you spend some time up front to organize your resources by resource group and subscription. Automating the deployment of your resources to your production environment can be tricky.

What are some of the Services we leveraging in Azure?

  • Logic Apps
  • Function Apps
  • Key Vault
  • Azure Virtual Machines
  • Application Insights
  • Integration Accounts
  • App Services
  • App Service Environments
  • Application Gateways
  • Azure SQL
  • Storage Accounts
  • Service Bus
  • Azure Monitor

How are we organizing our cloud Resources?

  • By subscription

    Be mindful of the subscription service limit, quotas, and constraints. We separated our development and production environments by subscriptions which allowed us
    to limit access to production resources as well as have a clear division for our billing.

  • By Resource group

    Pay close attention to the location you put your resource groups in. This will be the default location for any resources you create in that resource group unless you specify a different one.

What to watch out for

  • Make sure you put some thought into organizing your resource groups
  • Microsoft has a good guide on naming conventions for you azure resources https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions
  • We started off with one resource group to rule them all and found out when we went to go export the resource group, there is a hard limit of 200 resources, also there is a limit of how many historical deployments that are saved for a resource group in Azure currently the limit is 800. You will need to create a scrip to go in and delete the historical deployments.
  • Think about parameterizing your resources early, but be careful, you lose visibility to those values in Logic Apps designer for example. Even when you go into the code view of your Logic Apps, those values could be misleading. You have to export the template of your Logic App to see the actual values being passed in.
  • Some resources will require more work than others to get into a deployable state.

Deploying resources to your environments

  • We ended up building Release Pipelines that leverages the Azure Resource Manager, Bicep, Az PowerShell and CLI.
  • We have variable groups in our Azure DevOps that contains the values for the desired environments, and we pass the values for the environment at release time.
  • We have all out secrets saved on Key Vault and we use a reference to get the secrets or ARM expressions.
  • We setup a git repository to house all our ARM templates, Bicep templates, PowerShell Scrips, SQL Scrips and CLI Scrips.
  • We created Master templates to have a baseline that we can build on if needed.
  • We keep all the resources for a solution on the same resource group when possible.

Thoughts

You can only take the cloud tools so far. If it starts to become difficult enforce patterns or track dependencies, you may need to drop down to code. If this becomes the case for you, take a step back and evaluate your options right away.