Best practices regarding organizing Logic Apps into resource groups

Question

Best practices regarding organizing Logic Apps into resource groups

Veli-Jussi Raitila 341

In many situations, in the context of software development and building apps and services, various components (i.e. resources within Azure) related to a particular solution can be organised into some kind of a logical grouping. These are reflected in Azure as resource groups.

There are multiple heuristics one can use here, one obvious rule-of-thumb being that one puts such components into a single resource group which should be deployed simultaneously and form some type of an integrated solution - a functional "(sub)system" with its constituents sharing a lifecycle. The nature of ARM templates reflect this - a single template describes (the contents of) a single resource group.

Does this also apply to Logic Apps specifically? If not, what principles should one follow when making these decisions? In other words, do some best practices exist on how to organise LAs into resource groups?

Logic Apps are the sole iPaaS offering in Azure and advertised as such. Lots of experts in the field are familiar with on-premises integration products and bring in their own preconceived notions on how things are done here - in the context of these (largely, but not always) monolithic platforms.

In Azure, I have seen solutions where tens or hundreds of LAs are placed within a single RG (with an optional group for "shared" resources) - some of which are completely unrelated. And all the way from a single LA per group to attempts to create some type of a logical set of associated workflows. I'm sure no correct answer exists - but what would some of the guiding principles look like? Should LAs be treated differently than any other resource within Azure?

Answer 1

Alan Kinane 16,636 MVP

Personally, I would not treat them any different to other resources. Resource groups should be used to group resources logically, i.e. by application sharing a lifecycle so unrelated applications generally should have their resources placed in different resource groups.

The second reason is for access control. You may not want to give a particular user access to every logic app in a single resource group and trying to manage permissions by individual resources is far too difficult to maintain especially at a larger scale.

Veli-Jussi Raitila 341 Reputation points

2022-02-04T19:51:52.207+00:00

While I've never quite understood it - and still don't, majority of the companies that I've worked with treat "integrations" as its own thing.

Individual, distributed software teams within companies may naturally also rely on Logic Apps when appropriate, in which case I 100% agree with you.

But I'll have to play the devil's advocate here.

Not sure how common it is globally, but where I come from, there often also exists some type of a centralized function responsible for integrations at an enterprise level - either in-house, outsourced or a mix of both. This function is typically under ICT. And in these situations, it's pretty much a single team doing all the work. Would your viewpoint still hold, and if so, why?
Alan Kinane 16,636 Reputation points MVP

2022-02-07T09:40:56.053+00:00

You should use the resource groups however best suit your organisation but with a view to future proofing the use case. A shared service resource group is not uncommon and perfectly fine to use but if your Logic App integrates with other Azure resources would you not require access to those resources also? In which case I would probably place the logic app in the same resource group as the application resources that it will be using. Shared lifecycle and shared access control for the application as a whole. Your situation may be different but this is how I would commonly set this up. Remember, you can apply different authorisation levels to the resource groups using different RBAC role assignments, e.g. logic app operator or logic app contributor.
Veli-Jussi Raitila 341 Reputation points

2022-02-07T10:33:35.42+00:00

Regarding the Azure resources to integrate with - if said resource is owned by the centralised integration team anyway e.g. a shared instance of Azure Service Bus, they can just provision it within the same "kitchen sink" group or have another one for shared services relied upon by multiple LAs. Within the context, whether there are 1 or 2 groups, does not really make a difference.

Conversely, if it is a resource owned by some other team, I think it would be strange, from the deployment perspective, to mix assets with varying ownership within the same RG. It would be more natural to just allow access (by the team owning the target resource) for a managed identity (of the LA). Or, if some other method of authentication is required - handle credentials in Azure Key Vault. The vault would be owned and administered by the centralised team - and again provisioned within the single RG along (or beside one) with the LAs requiring access to said secrets.

To clarify, I'm not questioning whether an RG for shared services (e.g. logging, monitoring, enterprise-scale message bus...) is appropriate. That is tangential to the question. I'm specifically talking about the core integration logic implemented with LAs + related resources that are not shared.

So while I do not think you have given convincing arguments to split LAs into multiple RGs in the context of a centrally managed "integration platform", I will accept your answer. As I already suspected in the beginning, the topic itself might be unsuitable for a Q&A format as there is no clear-cut answer.

Best practices regarding organizing Logic Apps into resource groups

0 additional answers

Activity