Resource Groups for Azure Integration Services

In this video we will look at a question about how to structure your resource groups within an Azure Integration Services environment and some of the design considerations you should think about and how your decision will impact other stakeholders in your integration platform.
#logicapps #AzureIntegrationServices #Azure

[@zamarinen]

I think a good rule of thumb, should be that
resource groups should be scoped with a SLA, at the microservice level. that said, one specific purpose or function that does it job, should be within a resource group, not grouped with other services/functions that have a different SLA.

[@rezcan]

As always great content Mike….I have a completely different experience than you when it comes to physically organizing my integration resources in Azure (and AWS)…we only rely on resource groups for lifecycle management/change management, and everything else is managed at the subscription and management groups level from permissions, scalability and governance perspectives. Cheers Reza

[@robrider838]

Perfect timing. Had the same question.

[@robrider838]

I’m consulting for a large company and working with an integration team there. They have multiple integration projects deployed to a single resource group. There are over 450 resources in this resource group. It’s impossible to tell which resources are related to which integration. The current thinking is to break down this large RG into smaller logical integration/application view RG’s and also have a shared RG for platform services such as Service Bus. These integrations are completely separate integrations - under the same subscription for the business area. Everything is automated via CI/CD pipelines. RBAC will need to be considered for application view RG to platform RG, but I don’t see too many other issues. There are 10 - 15 integrations/applications inside this one large existing RG at the moment.
I’m not sure I like your idea of keeping everything in one RG. How is that understandable? Especially for new team members.

[@mikestephenson8525]

Hi Rob, thanks for your comment. The aim of the video is definitely to drive a conversation about what people are doing and what people see working and not working so we can all learn from each other. I think one thing I didnt get across too well in the video is that in the scenario I was thinking about the subscription had loads of other resource groups that have nothing to do with the integration team. That was our starting point. I totally get what your saying about people knowing where stuff is. I think if your breaking stuff out into lots of resource groups its much easier if you have dedicated subscriptions for the integration team. In the case I was thinking through we would have ended up breaking stuff out into logical groups we could have ended up with 100+ resource groups per environment for 5 environments. I think you end up with the same problem in reverse. I am hoping the take away from the video is the separation of the deployment view and application view in our thinking. In the future Id like to see the new integration environment providing the abstraction between the 2 views which helps address this question