Recently we introduced a new feature in Serverless360 called Resource Map. For 10 years I have worked with Azure and a common theme I have seen is that customers struggle to manage their cloud estate.
As the investment in the cloud grows this problem is compounded and they quickly find that the estate becomes so complex they lose sight of what it looks like and how it relates to their overall architecture.
In Azure, Microsoft has a number of features like Subscriptions, Resource Groups, and Management Groups which all look to provide some kind of grouping of resources into something that makes sense, but there is a big limitation in that the features provided look to address things from a physical view. They are focused on which box the resource is physically deployed to and there are constraints around physical deployment and relationships to other resources which dictates what goes where.
This problem is then compounded by the dev/test/production dimension which means you will often have dev/test/production versions of each component. Suddenly you have hundreds or thousands of resources.
Let’s take a step back for a moment and consider the example of a library. Libraries have been tackling the problem of how to organize resources for a long time. Some considerations for the organization of a library could include:
- Do you organize books by the weight of the book to minimize the effort required to move them around?
- Do you organize books by the publisher so that all the books by 1 publisher are in the same place?
- Do you organize books by author so all books by the same author are in the same place?
- Do you organize books on the topic so all books on a similar topic are in the same place?
Ok so we know if you are looking for a book in a library then the organization is by topic as the primary user of the library is a person looking for a book on a topic and this allows you to easily browse for other books which may be of interest. In a library, there are other systems to help you find books based on other criteria like the above but their layout of the library is based on the use case of the primary user looking for books on a topic.
If we come back to the Azure Portal, we have a similar scenario where the Azure Portal is set up to give you a layout and deployment model where resources are placed based on the optimal physical deployment model.
This is great for management of the physical architecture but requires significant knowledge of both Azure and your physical architecture to effectively use the Azure Portal to manage your resources
Azure Resource Map
Now we all know that the physical view is only one of a number of important ways of looking at your IT estate and with Resource Map we have tried to give you a way to map your underlying complex physical architecture to a much simpler logical model of your architecture. This then allows you to see your estate in a new way that we find demystifies a lot of the challenges people have in understanding their cloud estate.
To achieve this, we are really looking at your resources in terms of 3 dimensions:
- Scope
- Logical Resource
- Environment
Scope
The Scope represents a model in a tree structure of your Azure landscape. You would map resources to scope within the model and this indicates where the resource belongs. It might be the case in a large Azure environment that your Azure owner might allocate a resource to the Integration scope which is looked after by the Integration Manager. The Integration Manager will then reallocate the resource to sub-scopes which they have determined will more accurately represent the different groups of resources within the Integration area.
The below picture shows an example of what your tree could look like. In the example I have scopes for applications, for interfaces within the integration area. You can add your own scopes to make the tree represent what makes the most sense for your organization.
Logical Resource
When you have a dev/test/production scenario you will often find that you have multiple resources that are really the same thing. They are just the dev/test/production versions of each other. In Resource Map we provide a way that you can indicate that the physical resources are really just different instances of the same logical resource.
Environment
For each resource, you will allocate it to an environment. In the tree structure of scopes, you can set which environments your company uses. It may be Dev/Test/Prod or more complex. You can then inherit this structure down the tree and in some cases, you might decide that some areas have different environments such as Dev/Test/UAT/Production. You can model this as required. The result is each resource is also allocated to an environment.
Resource Assignment
Once your resources are assigned you will be able to see at each scope level on the tree the resource assignment. This is where we will pivot the information about your environment and you will see a grid that shows you the list of logical resources going down that belong to that scope, and then going across you will see the appropriate physical resource that matches that environment.
In the picture below on the first row of the grid, you can see that rmdevapp-api-dev, rmprod-api-prod and rmprod-api-prod are all Azure Web Apps which are the different instances of my API Resource.
If I now, try to explain the architecture of my FitApp application to someone who isn’t an expert in the Azure Portal suddenly I can make this quite a lot simpler. I would start by showing them that in my tree I have the FitApp scope under apps and in that, I have a list of things that are needed, an API, a CDN Endpoint and so on and then I could explain to them how each resource in the grid represents the different environment versions of that logical component.
Assigning Resources
With Resource Map you can assign a Service Principal for it to use and then sync to bring in resources and you can manually assign them to a scope. You can then give them a logical resource and then map them to an environment. The interface fully supports doing that by hand if needed but I really want to make the experience of keeping on top of a well organized and governed estate to require as little work as possible. We have implemented some rules which will allow you to allocate resources to scopes, logical resources, and environments. We will also be adding advanced rules to minimize the overhead needed to maintain your Resource Map.
Knowing When There Is Something to Do
One of the key elements to keeping on top of good governance is knowing when there is something to do. With that in mind, Resource Map can be set to auto-sync every night so any new resources added will be detected by Resource Map. If the rules can auto allocate them then they will, but if not then they will show up under the resources section as unmapped and you would know that they need to be mapped to a scope.
When resources are mapped to a scope but if they are not allocated then the tree view would display an indicator using a traffic light approach to show some work needed to be done. You can see in the picture below that I have added some resources to my FitApp scope and they are not assigned so the scope on the tree is showing as Red with an indicator that 7 things need to be done.
When I have mapped my resources then my scopes will be green again and I will know that everything is good, and my Resource Map is fully up to date. The intention of this approach is to help you see when every changing environment with new projects adding new resources creates a requirement for your map to be updated.
We hope that providing a tool to give a great experience for organizing your resources and keeping on top of the growing estate will remove many of the concerns IT Managers have that they feel their estate is out of control and we also hope that the Resource Map will help those organizations who feel their estate got out of control a long time ago will now have a way to get a handle on the estate and get it back to a state that can be understood.
Cost Analysis
Once there is a clear understanding of your estate on Azure, we can now begin to leverage the analysis of resources in a different way. In Azure, so much of the analysis of your resources is based around the constraints of the physical deployment view, but with a resource map, we can now begin to look at things based on the logical architecture too.
In the below picture you can see that for the FitApp scope I am able to get a cost analysis by day of the resources which belong to that scope. In this case, this is a view of the cost of my application. You could filter this by the environment and other things.
What’s Next
This first release of Resource Map is something we hope people will feel provides lots of good value to help to provide organization to your environment but for us its really just the start of cool things we have lined up in this area. Some of our immediate plans include:
- Deeper cost analysis
- Integration with Document360 which is our documentation and knowledgebase product
We also have a bunch of other stuff in the backlog which I will talk about another time.
