Using Azure Tags to make managing your Azure Spend Easier

By: Bill Chesnut

Tags have been around in Azure for a long time, but only recently have they been brought to the portal has a 1st class citizen.  They are now on the overview page of almost every resource type

image

This is an example of a Virtual Machine, and Tags are now visible on the Overview Page

One of the best practices that some Azure users have been following is to Tag the Resource groups that resources are in, one assumption here is that those Tags would be available in the billing portal and/or billing files, but that is not the case, since Resource groups have no billing information associated with them they don’t appear in the billing files and cannot be used to separate the bills by Resource group Tags.  This is a top request for most products that deal with reporting on Azure consumption.  Until these products add support for rolling down the Tag from the Resource groups, there is a manual way to make this happen, but it could be lots of work for large Azure subscriptions.

image

In your Resource group select all the resources you want to Tag, Click “Assign tags”

image

Add the Tags to assign at the top and click ‘Assign”

image

Select one of the resources to verify the tags have been assigned

You can now go into the Azure Portal Billing and Cost Analysis and select the Tag you have assigned and see the costs associated with that tag

image

Hope this blog post helps you manage your Azure environment easier.

Note: The feature to roll down Tags from Resource groups is being added to SixPivot’s Cloud Control Product in the near future, please go and try Cloud Control

image

Trial for Free today

Cross posted to https://www.biztalkbill.com

Publishing BizTalk SOAP Services as REST with Azure API Management

Currently BizTalk Server 2016 has support for REST, but the support is fairly limited and is missing some feature that most developer expect from REST services.

To overcome these missing feature for companies that are exposing these services to their consumers/partner over the internet, I will show you have to use Azure API Management to publish SOAP services from BizTalk as REST.

For this blog post I took the Hello World example from the BizTalk SDK samples and converted it to a Request/Response orchestration and used the WCF publishing wizard to publish

image

Publish schema as WCF service (this allows better control over the URL)

image

Rename the Service and Operation, Select Schemas

image

Select the location to publish to and I am allowing Anonymous for my example

Note: I ended up using BizTalkWcfService2 as the URL, because an issue I am working with the API Management group

image

Publish Service

image

Now you need to setup the App Pool and make sure you can get the WDSL, for this example, We also need to update the WSDL to have the internet name for the server, by default the WSDL is going to be generated with the local server name

image

I downloaded the WSDL file and changed the server name

Open your Azure API Management Instance and go to the Add a new API blade

image

Click Upload to upload the WSDL file, if it was not necessary to change the WSDL file you could use the URL instead

image

Update the highlighted fields with your values, Click “Create”

image

Wait for the create to complete, Click “Done”

image

Now before we can use our newly imported SOAP service exposed as REST, we need to add it to a Product to allow users to call it.

I am using a Product Named BizTalk, you can create and use any Product Name you like

image

Now I go back to the API Definition, Click on our “submit” operation

image

Then Click on the “Test” Tab

image

This is the Test blade, notice that API Management has supplied the API Management Subscription Key (necessary to call API Management, this is based on the product we put our API in), the Sample JSON Document and a “Send” button to test with.  Click the “Send” button

image

View the results of the call

image

You will notice that the send and receive bodies are JSON, but we are calling a SOAP Service, this is what the SOAP call would look like

image

Lets now examine how API Management published our SOAP Service as REST, on the API tab, Click the “View Code”

image

The API Management use a policy to do the inbound and outbound transformation, the policy uses the liquid language to do the translation from JSON to XML and them XML to JSON and include error handling

image

The process of importing our WSDL as REST to SOAP automatically created the policy that does the transformations and also created the inbound and outbound JSON schemas

image

In a later blog post I will talk about how you can modify the schemas and the transformation.

One of the main features that BizTalk is missing with its REST adapter is the ability to provide the definition of the API for the clients to use to generate the code to call our REST services, in the Developer Portal, API Management provides either Open API (swagger) or WADL for our clients to use.

image

I hope this blog post helped you understand how you can use Azure API Management to publish your BizTalk SOAP Services as REST

Moving VMs from ASM to ARM

As Azure continues to evolve it has changed and as part of this change is the migration from Cloud Services (web roles, worker roles and virtual machines) to Azure Resource Manager (ARM).  In this blog post I will talk about moving your virtual machines from Cloud Services (ASM) to ARM.

For myself this was something I had been looking at doing for over a year now, I have several virtual machines I had built over my time using Azure and most of them were in Cloud Services.  The reason I really wanted to get them to ARM was two fold, I really want to be able to enable the auto-shutdown feature of the ARM based virtual machines, as I sometime forget to turn off my virtual machines and use up all my MSDN Azure allocation for the month in just a couple of day.  The other reason want to move to ARM is the better network controls that are available in the ARM virtual networks.

Ok, to get started, I don’t believe in rebuilding the wheel, and there are several methods with differing versions of complexity to do the move, but I found a good blog post – https://www.petri.com/migrating-azure-vms-classic-service-management-resource-manager and I used that to do my moving. There are several caveats to moving from ARM to ASM and they are covered in the referenced blog post.

The moving from ARM to ASM is a multiple step process and there are several factors that determine exactly which commands that you need to use.  The first question you need to answer is are your ASM VMs in a virtual network, if so, you will need to move the whole virtual network and all the included VMs, if not, you can move just a single VM, but the process will create a new virtual network with the name of the VM and “–migrated” appended.

The actual process of moving is a 3 step process, first you need to prepare your VM or Virtual Network to be moved with the –prepare parameter on the command (see referenced blog above).  Once the prepare completes, both the existing and the new Virtual Networks exist, to allow testing.  One important fact to keep in mind, is if the VM you are moving was not in a Virtual Network, it will be restarted during the move.  After your testing is complete you will then need to either Commit (“-commit”) or Abort (“-abort”) your changes.

Once the move has completed there is still one last thing to more, the storage account where the VHDs for your Virtual Machines are stored.  Again this is a 2 step process of –prepare and then –commit or –abort.  Also note that all VHDs in the storage account will be moved it is necessary to have moved all the Virtual Machines sharing that storage account before moving the storage account.

I hope this blog post helps you get your ASM virtual machine over to ARM.