Logic Apps connector performance (3/3) - The good

This blog series consists of:

• Logic Apps connector performance (1/3) – The bad!
• Logic Apps connector performance (2/3) – The ugly!
• Logic Apps connector performance (3/3) – The good!

This post discusses my preferred approach for connecting Logic Apps to systems that have API’s exposed.

Use the HTTP action

Instead of using the out-of-the-box connector, I prefer to leverage the plain HTTP action. What’s the reasoning behind this? Well, I see several advantages:

• Better performance: that’s what’s this series is all about. As far as I know, the HTTP action has no throttling at all. It allows for extreme scalability on the connectivity.
• Full control: you control the complete life cycle of the connector. No more connectors that remain in preview forever, no more hidden limitations, no more dependencies on the product team if upgrades are needed
• Better security: you can leverage Managed Service Identity to connect to systems that support it. This ensures that you don’t need to handle credentials anymore in your release pipeline.
• Cheaper: you pay only for native actions, which is 5 times cheaper compared to standard connectors. This can result in huge cost savings, when dealing with high throughput scenarios.

Walk-through

I’ll give you a simple example for the blob storage connector.

• Configure the HTTP action to consume the blob storage API:
  • URI: https://{storageAccountName}.blob.core.windows.net/{containerName}/{blobName}
  • Headers: some mandatory headers: x-ms-blob-type, x-ms-date and x-ms-version
  • Authentication: Managed Identity
  • Audience: https://storage.azure.com/

• Enable Managed Service Identity for the Logic App.

• Give the Logic App identity Storage Blob Data Owner rights on the particular blob container

• Put the Logic App under a high load and see that all messages appear in the blob storage container, with low latency

This is a simple, but powerful approach. Preferably, I offload some of this functionality to Azure API Management, so it becomes reusable across Logic Apps. The consumption tier of Azure API Management is a perfect fit for this, as you only pay for what you use. If you configure an optimized Open API definition, you can even reach the usability of a real Logic Apps connector.

Conclusion

Consider using the native HTTP action, instead of the out-of-the-box connectors. It provides better performance, full control, optimized security and cost-effective connectivity. Most of the logic can be offloaded and centralized in Azure API Management, the consumption tier is a perfect match for this.

It would be great if the Logic Apps team could open-source their codeless connectors, because they are nothing more than (sometimes complex) Azure API Management policies. For the other connectors… I hope to see an increase in the throttling limits soon!

Thanks for reading,
Toon