This post was originally published here
One of my favourite things in Azure is the ability to group stuff into resource groups. Maybe it’s a reflection on myself but I hate looking at messy environments that look like a kid has just emptied their toy box over the floor.
With resource groups you have the ability to group related stuff together in kind of a sandbox. Now there are much more powerful features to resource groups such as the ability to automate their setup and deployment but without even considering those, just the grouping of stuff on its own is very handy. Recently I was working with some of the support team around some knowledge transfer sessions to help them understand our integration platform and as you would expect when a group has limited experience with cloud there is an element of fear of the unknown but when I started explaining how the complex platform was grouped into solutions to make it easier to understand you could see this was a good first step rather than showing them a million different components which they wouldn’t be able to understand the relationships between.
Below is a picture showing some of our resource groups.
In this particular one here is what some of them do:
- Integration-API = This contains app service components which support our API & Microservices architecture
- Integration-API-Bridge = This contains a web job which acts as a bridge between service bus queues and our API
- Integration-API-Legacy = This contains some older API style components which are expected to be deprecated soon
- Integration-BizTalk = This contains some Azure services which support some of our BizTalk applications. Mainly app insights and some storage. Note our BizTalk instance is on premise in this instance
- Integration-CloudDataLayer = We have some shared data which is available and is stored in this resource group, it includes DocDB, Azure Storage and Azure Search
- Integration-CRMEvents = This contains some Web Jobs and Functions which handle events published from Dynamics CRM Online to Azure Service Bus
- Integration-Management = This contains some tools and widgets to help us monitor and manage the platform
- Integration-Messaging = This contains service bus namespaces for relay and brokered messaging
- Integration-ScheduledJobs = This contains Azure Scheduler to help us have a single place for triggering time based integration scenarios
As we use new Azure features it helps to group these into new or existing resource groups so we have a clear way of logically partitioning the integration platform and I think this helps from the maintenance perspective and keeps your total cost of ownership down.
Wonder how other people are grouping their stuff in Azure for integration?