Differences between Azure Resource Manager and Azure Service Manager - a developer’s perspective

We are grateful for the preparation of the article to Mikhail Tryakhov ( @PerseptronYar ) from the company Akvelon (Yaroslavl) for the help in writing this article. Mikhail works on the Microsoft Azure CLI team (Command Line Interface) with a specialization in Networking Services.

Hello!

Since 2008, those of us who have worked with Azure, perhaps unknowingly, have used the so-called ASM (Azure Service Manager) mode, which is now called classic. The Azure platform, meanwhile, grew, developed, spawned many useful services, support for new platforms, and a lot of other good things. With the growth of supported and increasingly complex component architectures, a number of changes matured, which it was decided to bring into a separate complex - ARM (Azure Resource Manager). In this article, I will share some of the moments that you encounter while mastering this platform. But first, let us remember what is so serious about the new.


')

The first thing that will strike the eyes of less hardcore readers, who, as before, use the web version of the Azure management portal , is the portal itself, modified in both form and content. The new version is currently under intensive development and now allows to perform most of the necessary actions conveniently. As for usability, there is no fundamental change in the structure of the site, which would immediately sharply delight users. Some difficulties in carrying out the usual actions will arise. Therefore, the support of both versions of the site in the short term is a logical and very loyal step by Microsoft.

Changes come in the Azure Service Management API. The former portals * .windowsazure.com work through the API, typical of the classical mode, the new, ARM-ovskie, portals * .azure.com use the new API, which we will focus on the details. The concept of a resource type and the corresponding API is introduced. The virtual machine has its own, the database has its own. We'll take a closer look at the new REST API in more detail - for the time being we’ll touch on slightly more significant differences.

After all, the following innovation beats on a very burdensome lack of work with the classical API. Before, we happily could create everything that our heart desires, from blob-a to a web-site. But the pain began already in the next step - the stage of working with security, for each element was configured separately. It was not possible, for example, to uniformly indicate access to a virtual group of osprey, or to establish similar orders in access to a web site and its services, database. Working with roles is also kind of neutered - the subscription has admins and co-admins. Everything! No security matrix, role distribution. Such is the longstanding dance around the same pillar.
ARM allows you to create resource groups (resource groups) , within which to create the necessary sets of applications, services and databases. Now there is a three-step hierarchy - a subscription (as the root of everything), a group of resources and a resource. All of them use the RBAC authorization model (role based access control) , which have a long-awaited role cluster (including owner, contributor, etc.) with appropriate access rights (Access Control List, see an example below).



Resources can (and, according to the creators, should) be tagged. Created resources can be distributed into groups and tags according to the functionality they carry, filtered by products using them, responsible employees and departments of the company ... This allows you to more effectively group and systematize resources, visualize traffic distribution and analyze the costs incurred. This allows a more obvious way to optimize the cost of maintaining the work of the deployed architecture and at least somewhere, finally, save.

There are a number of situations where the grouping of several resources simplifies their uniform modification. The simplest, as usual, remove everything. But more constructive cases are setting up security policies, configuring ip-addresses, balancing and, as we will see in this and subsequent articles, much more. In practice, Azure in ASM and ARM modes are used quite similarly and differ only in minor details. It is not necessary to retrain for a long time, with care, to migrate all their long-term developments. There are already standardized hybrid solutions for painless and fast combining of already developed, classical, and on-premises solutions - this will be on the way soon.
First, let's talk about using Azure Networking Services. As already described in other articles, Networking Services allows you to create your own virtual networks, in which the user controls the location (location) of the network, security (security groups), subnets (subnets), configurations (NICs, VMs), it is convenient to scale ... and, and and.

Just an example. Consider the simple and clear architecture of a multi-tier application in the following diagram.



In this case, we have the Frontend Tier, open and accessible to users, the application business logic in Application Tier and the good old Backend Tier, which we do not forget to back up frequently and correctly.
Immediately, I note that in order to produce certain actions within a subscription, there is a whole bunch of possibilities. Creating, modifying and deleting Azure tools and services is now truly broad. In addition to the usual web portal , Azure PowerShell , REST API , you can also use the Azure CLI platform that is being actively developed at the time of this writing. It is implemented on Node.js with an open source project, which, as you probably understand, makes it possible to fully use on Windows, Mac and many Linux distributions.

From the materials that I studied in preparation for writing this article, I realized that the most obvious option is using the REST API. It is reduced to creating a template (template) in JSON-format that contains all the necessary information. Naturally, there is already a whole gallery of similar templates for the deployment of such an architecture. The selected option, the most suitable for the wishes of the user, is customized and means, for example, Visual Studio is deployed in your subscription.

It is not hard to guess that the PowerShell and Azure CLI platforms do nothing more than form the same JSONs, but with buns in the form of hints, validations, restrictions that will allow you to deploy the desired with the least pain for our brother.

Please note that I deliberately try to avoid an abundance of specific code examples, because this will significantly overload reading, and the article will condemn to obsolescence and loss of relevance. Let's believe that references to manuals and documentation will be supported much better than examples updated under the control of your humble servant.

Actually, the example of the architecture considered in our example has already been implemented and published. Rate and download it here . JSON-s look, at first glance, scary and redundant. But when the shock subsides and the mind prevails, we will see in how clear and, it turns out, the obvious format specifies all the settings of the virtual network and its elements. At the same time, it is immediately possible to specify all the necessary dependencies, the security policy, the separation of business logic.

So, to implement such a scheme using Azure, you need to create a virtual network in which subnets are created for each of the levels described. The next step is setting up permissions. For these purposes, we turn to Network Security Groups. NSGs provide network access (or lack thereof) to specific virtual machines or entire subnets. They contain a set of ACL rules (the same Access Control List) for allowing or denying access to the specified area. By default, a number of inbound / outbound rules are created that allow covering a significant chunk of the scope of security groups. Azure provides the means to specify all the necessary security settings at each level. In particular, in the template I have cited, we can distinguish how access to the data level is limited by the rule setting — it is directly and clearly written "access": "denied" . The task of the rules is made in a fairly obvious way, and I propose to study some ways of customizing them, at least in our example, independently.

Network security groups is a great thing and, in addition to the above, it includes convenient loggers of various types, which allows you to quickly and painlessly assess the problems encountered when using the created architecture, to catch and drown the hidden inaccuracy. The user can comprehensively analyze the statistics of calls to this group. All this is encouraging. Some series of actions is recorded by default, but it is possible to enable "additional" logging within the framework of this Network Security Group - a much more extensive range of stored information will open up. Connected logs will allow you to see in detail all the necessary data on calls to resources related to NSG. This can greatly help in debugging, especially in the early stages of architecture formation. How to get these joys, what to say and where to look is described in the Log analytics for NSGs documentation .



To provide Internet users access to the “top”, frontend level, an Application Gateway is created with all the parameters, like frontend ip, backend address pools, dependencies, and more. I recommend reading about the Application Gateways settings additionally, for example, in Application Gateways Docs , or at least to carefully view the template presented. A detailed description of the configuration of the gateway, the wonders of Load Balancer and Traffic Manager, Route Tables, I will not discuss this time - I will discuss this in detail in the next section.

I note that, since we started talking about deployment directly through the REST API, if necessary, make modifications to the architecture — change any parameters, or add new elements (network, subnet, whatever). You only need to make changes to the template already used. This does not mean that the whole colossus with love will be re-deployed and will eat a separate portion of resources. The system is smart and will track only the changed pieces of code and will produce any CRUD action in an optimal way.

So, the first step is done. Improvements implemented in ARM, look quite logical and necessary continuation of previous versions, and explicit shoals are not visible yet. The new web portal quickly stopped scaring, and solutions for modifying solutions that are already working look quite friendly. I really hope for constructive feedback and a quick continuation. Thanks you!