TLDR

Going to the cloud has been an interesting experience. Spend some time up front to organize your resources by resource group and subscription. Deploying your resources to your production environment can be tricky. Spend some time looking at the Azure Resource Manager REST API. Be careful with the Powershell Az Module. We got burned by it.

What are we leveraging in Azure?

• API Management
• Logic Apps
• Data Factory w/ SSIS Runtime
• Application Insights
• Integration Accounts
• Functions
• App Services
• Sql Database
• Storage Accounts
• Service Bus

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 subscription 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. Resources cannot talk across location. API connections you created in one location will not be reusable in another. You cannot share API connections across resource groups.

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.
  • Even after splitting resources into their own groups, we still ran into timeouts trying to export resource groups with only ~60 resources.
  • 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. API Management, for example, is a bear to deal with. We're still working on a solution to deal with this. If you're wiring up your endponts to logic apps, you may end up losing connections to your Logic Apps when we deployed to production.

Deploying resources to your production environment

• We ended up building a CLI that leverages the Azure Resource Manager Az Powershell module which allows us to pull and push resources. We had to make the jump to powershell 6 as well.
  • We extract the parameters out of the resource and put them in our environment specific parameter JSON file.
  • We setup a git repository to house all of our ARM templates. We discovered the order of properties drastically varied in our ARM templates from export to export, so you may need to run your ARM templates through something that orders your properties. This will makes diffs significantly more readable when you PR to master.
• Be careful with the PowerShell Az Module, we ran into issues where our property values did not serialize past a certain depth. While you can configure the depth, pay close attention to your ARM templates before you push to your higher environments.

Serverless 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.