Since 2008, we have been using the classic, Azure configuration mode: ASM (Azure Service Manager). During this time, the Azure platform kept growing brining to life many useful services such as new platform support and even Microsoft’s new SEO. With the growing complexities of architectural components, a new separate configuration mode, ARM (Azure Resource Manager,) came about to address these changes. In this article, we will share key instants that we ran into with this new platform, which will help you better work with it going forward.
The first thing that comes to mind, especially if you are not too hardcore of a tech person and have been using the web-portal to control Azure, are the portal changes used instead of cmdlets to manage subscriptions. The new portal has changed both in design and in content and allows users to easily execute actions without unnecessary steps. While many users can immediately appreciate the new usability, there is still a learning curve required while familiarizing yourself with the structure changes. That is why both old and new portals are still supported. A logical and user friendly step on behalf of Microsoft.
Changes occurred in the Azure Service Management API as well. Old portal versions *.windowsazure.com work through old ASM API, but new portals use *.azure.com format and a new ARM API. We will further discuss these differences later on in this article. A new term was introduced ‘resource type’, which describes every feature details and its corresponding, specified API: for virtual machines, database services for all required actions.
Another burdensome issue, when it comes to classical API, is addressed through the new platform’s innovations. In the old version we could use: virtual machines, services, data bases, etc. But the pain truly began on the next step of working with security when we encountered numerous restrictions, such as having only administrator and co-administrator subscription. There were no other roles and/or chances to make new difficult roles based on the security matrix. We had to customize each item, personally, without a way to group them together.
ARM gives us an opportunity to create ‘resource groups’ for needed complex applications, services and databases. Currently there are three layers: subscription (as the root of everything), resource group and resource. They all use the RBAC authorization model, role based access control, which have a list of roles (owner, contributor and many others) with access rules such as an Access Control List for every layer. The graphic below illustrates this process.
Resource must be assigned by tags. Existing resources can be separated by groups and tags depending on functionality and may be filtered by related products, owners, managers or departments. It creates an opportunity to group and systemize resources, visualize traffic data and analyze spent money. This also helps optimize costs of architecture and, as a result, saves money.
There are numerous cases when grouping helps users make resources modifications easier. For instance, you can simply delete all grouped resources. On the other hand, something perhaps more useful, is the ability to customize security rules for a group of resources, IP-addresses modifications, balancing and many others.
User can work with ARM and ASM APIs in quite a similar way. There are a lot of published tutorials on how to combine new, classical, and on premise solutions already, but make sure to keep an eye out for our next post to learn more. Now…let’s dive into more detail about Azure Networking Services.
As you can see in many other articles, Networking Services contain tools to help work with virtual networks, customized network locations, security groups, subnets, configs (NIC, VMs), easy to scale, etc. For example, consider an easy, multi-layer architecture as shown in the scheme below:
In this case, there is the Frontend Tier available for users from the internet, the Application Tier with product business logic and the Backend Tier to work with data.
There is a large scope of tools to modify any item in subscriptions:
- Web-portal (old and new ARM version)
- Azure PowerShell Cmdlets
- REST API
You can also use the new platform, Azure CLI, which I have personally work with. It is written on Node.JS, which means available operations can be made from Windows, Mac and some Linux distributives.
REST API is considered the most understandable format for newbies. Which means you should create a JSON template, which contains all required information about deploying infrastructure. There are a lot of examples illustrating how this is done, a whole gallery is available. After customization, the template may be deployed for subscription (f. e., via Visual Studio). To no surprise, PowerShell, Azure CLI platforms actually make the same JSON requests but also contain a lot of user friendly helpers, hints and validators.
Please note that I have purposely excluded actual code examples as they would become outdated soon, unlike the Azure manuals in the post, which would be updated just in time.
An example of our multitier architecture is published too, you can review and download it here. JSONs looks huge and unreadable, but very quickly you will see that they are not that complicated and can easily be read. Not only an item can be created via API, but also any relations we need.
To deploy the out structure, we need to create virtual network and subnets for each tier. The next step is to access rules customization. Network Security Groups get an access to virtual machines and whole subnets, with all sub-items. NSG contain ACL (Access Control List) to allow or deny an access to specified resources. There is a scope of default inbound/outbound rules, which help us work with the most casual tasks. NSG can also contain custom rules for more difficult cases very easily. As you can see, in the example, access was denied to the backend layer from the internet users via the easy rule with ‘access’ parameter ‘denied’ value. You can further review such rules settings in the shared example.
Network Security Groups as also useful because they could be created easily, but also can be tested by different tools. There is a default logger which saves common information, but user can also turn on the custom NSG logger, which would save a lot of deep details to test whether an NSG security policy was customized correctly or not. This can be very time consuming, especially at the first stages of architecture deploying. These logs can be integrated with other Microsoft platforms. You can investigate more about NSG logs here.
The next step in our example is the application gateway customization (frontend IP, backend address pools, dependencies, etc.) to manage income requests in the Frontend layer. I recommend you review both the app gateways docs and the template.
The following article will contain the next steps, app gateways, Traffic Manager, Load Balancers, Route Tables and many other interesting features.
Last but not least, I should mention that REST API has another smart feature. If you need to modify, an already deployed infrastructure, all you need to change is your template. Any CRUD operation would be done successfully without existing items or re-deploying. For instance, if you want to add a subnet, just add it in JSON and the only action that would be made on the server is the specified subnet creation.
We are halfway there. ARM features look logical, useful and easily compatible with previous versions. The new web-portal looks good and useful. Now we just need some time to practice!
