Seattle, WA, March 27 2015 – Seattle has a reputation for being geeky. Last month that reputation proved true, as hordes of developers, software engineers, and all manner of computer crazed geeks descended upon the Showbox in downtown Seattle for Geekwire’s annual Ping Pong and Anniversary Bash 2015. Akvelon was represented well along with many other local tech companies as techies came together to share their geek/tech skills and comradery.

Akvelon fielded a stellar team to compete this year in the fiercely competitive ping pong tournament offered by Geekwire. As the former 2012 Ping Pong Champion, Akvelon representatives were anxious to regain their title as champion among their fellow geeks. After a (slightly) intense night of ping pong competition and great opportunities to mix and mingle, Akvelon player representative Valeri Kim took home the gold…or at least the title of Geekwire’s Ping Pong Bash 2015 Champion. Among other ping pong competitors representing Akvelon at the tournament were Microsoft account manager Toby Rawlinson and CEO Sergei Dreizin.

Microsoft’s Biggest Event

San Francisco, CA – The Build Developer Conference is Microsoft’s biggest event of the year – this is the conference where Microsoft announces the latest products, technologies and tools for developers.

Build will cover all Microsoft Platforms – expect rich new content and information on Windows, Azure, Office 365 and more. Developers will receive deep training, allowing them to take advantage of the incredible advances in our platforms, including Windows 10, and providing access to over 1.5 billion devices.

Akvelon is proud to be a part of this event, as we have helped Microsoft deliver many of the technologies and tools demonstrated there, including:

Docker

Day One Keynote

3-618 The Next Generation of Azure Compute Platform with Mark Russinovich

2-704 Windows Containers: What, Why and How

2-683 Thinking in Containers: Building a Scalable, Next-Gen Application with Docker on Azure

At present time our team is participating worldwide //build TOUR, next stop is DevCon 2015 (Russia), were we will share our expertise in cross platform app development and Internet of Things. Come and join us.

Azure Resource Manager. Step 1

25 Feb Azure Resource Manager. Step 1

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.

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!