Welcome again to another Logic Apps Best Practices, Tips, and Tricks. In my previous blog posts, I talked about some of the essential best practices you should have while working with Azure Logic Apps. Check out these Logic App tips and tricks!
Today I’m going to speak about another critical Best practice, Tips and Tricks that you need to implement while administrating your cloud integration resources: Implement good governance policies.
In my opinion, governance is undoubtedly one of the biggest pains in Logic App’s overall experience. Yes, we have different types and host options for Logic Apps. Yes, some pain falls in the developer experience, but nothing compared with governance. And I support this idea/sentence in the following facts:
First of all, almost nothing is available for you out of the box.
Second, normally people that will monitor your applications in terms of “infrastructure” (we are not speaking in servers here, but there are a lot of services behind like RBAC, Service Bus, API connectors, APIs, …) are not people familiar with Logic Apps or with the business. But they are in charge of monitoring and administering the Azure components/services.
For that reason, it is up to the developer team to provide all services/components and features that must be monitored and maybe to help them decide the best or possible ways to archive that.
On a quick look, we may find these 9 points as the basics of any Logic App governance:
Find Disabled Logic Apps – This may tell us that possible there was a new deployment and someone forgot to enable the Logic Apps. This is more common than you think. When we use polling triggers is a best practice to deploy the Logic App as disabled since we don’t want the Logic App to start trigger processes without double checking if everything is correctly deployed or if deployment is already finished. Or someone manually disabled a Logic App for a specific reason and forgot to enable it again.
Find Logic Apps not running for a long time – This may tell us that probably some Logic Apps are deprecated, and we need to confront the business with that facts. We want to have our resources the cleanest as possible, we don’t want to have stuff running on Azure that is already deprecated! Or probably something is not working correctly in the overall integration solution.
Find Orphaned Azure API Connections – Continuing the concept of the previous point, We want to have our resources the cleanest as possible. We don’t want to have stuff running on Azure that is already deprecated or orphaned (no one using it). If we are working in Logic App, especially in the Logic App Consumption, it is quite easy to create a bunch of API connections that will be broken and orphaned. In the end, you will see in your resource group several API connections like sql, sql-1, sql-2, … and probably only the last one is being used inside our Logic App.
Find broken Azure API Connections – This is worse than orphaned! These are API Connections that are being used by the Logic Apps, but they are broken for some reasons. Maybe the token has expired. Invalid credentials and so on. This is a critical point to manage.
Document what API Connections are being used in each Logic App – This may sound simple, but in fact is a complicated or time-consuming task to do it manually on Azure. What API Connection is being used by each particular Logic App, for example?
Find resources that are not according to your best practices naming convention – the naming convention is quite important in Azure, and you should enforce teams, especially developer teams, to apply good naming conventions or to follow the existing organization naming convention for Azure.
Find resources that don’t implement your tag policy – for the same reasons as the point above.
Notify any inconsistency internally on the team – and of course, if something is inconsistent, you need to notify the teams about these points.
Possible ways to solve these challenges
One of the approaches I created to solve these challenges was using PowerShell scripts. Take, for example, the Find Orphaned Azure API Connections I published in the past one PowerShell script that you can find it here: Find Orphaned Azure API Connectors in all Resource Groups with PowerShell. This PowerShell script will:
Check on all Resources Groups available on a single Subscription if API Connections are being used or not.
Provide a list of available API Connectors group by Resource Group
Provide a list of Logic Apps and API Connectors association group by Resource Group and Logic App
And finally will provide you a list of Orphaned API Connectors ordered by Resource Group
Using Function App (.NET or PowerShell Core) and Logic App to implement monitoring capabilities
Using Automation Account and Logic App to implement monitoring capabilities
In both options above, the Logic App is an optional component, and it is there to implement the notifications capabilities.
Taking Find broken Azure API Connections problem as a sample, I create a series of blog posts about how to monitor the status of the Azure API Connections using:
Az modules are not supported on a Consumption plan. At least I couldn’t make it work. So that means I need to use an App Service plan, which means I will have an additional cost or more costs associated with this solution, more or less 36.94€/month.
Using Automation Account and Logic App: How to monitor the status of Azure API Connections (Part III). Although this approach required quick learning about Azure Automation, that was quite simple, and for me, this is the best approach in terms of cost and architecture design.
And, of course, you may find other different ways to implement the same functionalities.
I hope you have enjoyed it! Stay tuned for the following Logic App Best practices, Tips, and Tricks.
