Balancing Logic Apps and Azure Functions within API and Service Layers

Developers and architects are frequently faced with the decision of how best to integrate various components into their architecture. This video delves into the nuanced decision-making process behind integrating Logic Apps and Azure Functions into API and service layers. It addresses common queries regarding when to utilise an API layer for these components and when it’s more appropriate for them to be part of a service layer. Through a detailed exploration of considerations such as HTTP triggers, API Management, and internal versus external accessibility, this guide offers insights into securing, cataloguing, and maximising the reuse of these services across an organisation. Whether dealing with public APIs or internal microservices, this introduction sets the stage for a comprehensive discussion on optimising cloud services integration for enhanced functionality and organisational efficiency.

One of the questions we get asked repeatedly when we’re talking about Logic Apps and Azure Functions is when should I put them in an API layer, and when should they just form part of a service layer. So, there are a couple of considerations here that we’ll go through. Logic Apps that have an HTTP trigger, in other words, they’re exposed as an HTTP REST API, those can be surfaced in API Management, and Logic Apps can call other Logic Apps via HTTP. So, when might you have them in API Management, and when wouldn’t you? Similarly, Azure Functions also appear as an API, as a REST API, and they could be in API Management.

When would you do that, and when would you have them just calling each other internally? So, a few considerations here, because there is no right and no wrong answer for everything. But generally speaking, if you want things to be secured in one place, particularly if you’ve got public or external consumers of that service, then API Management will be a good way to go if you want them to be discoverable. In other words, you’re using API Management as a way of cataloguing your APIs and making them available elsewhere, then that also lends itself to this and similarly reuse, but particularly wider reuse across your organization. API Management is definitely the way to go.

If, however, you’ve just decided that you’re building up a solution and you’ve just broken it down into manageable chunks, some of which might be other Logic Apps and some of it might be Functions, but effectively they’re private, there may be reuse of them, but that’s inside the solution as a whole. So, one function could be called by many Logic Apps but within the same solution. And effectively it’s just internal to your organization or internal to your department, then by all means just treat those as private APIs, and there’s no need to put them in API Management. You still need to solve the problem of how you’re going to secure them, and you still need to make sure you’ve got the right network access to them and all those sorts of things. And you might still want to think about how you’re going to do metering and diagnostics and all that kind of thing, the stuff that API Management gives you for free.

But just as a rule of thumb, here are some thoughts about when you might choose API Management and when you might not.

Chat to us about your Integration journey

Get in touch

Share this post

happy holidays

we want to hear from you

https://calendly.com/345andrew/30min