Archive for November, 2015


Previously within the Azure PaaS and IaaS environments, the auto-scaling of VM instances is done in a manner that replicates additional instances of a running VM.  If you have ‘N’ instances of a VM in a Cloud service scaling up means you now have N+X instances of the VMs (where X is the amount of VMs you increment by in a period of time).  In the IaaS VM world you would have to first pre-allocate VMs into an availability set, then shut them down. Once Azure was triggered (via metrics and threshold indicators to manage the attributes around a scale-out process) Azure would scale instances up (turn the VM on), or down (turn the VMs off). Each of these VMs used the same base image as those running in the availability set. 

This scaling only worked at the VM level. Other Azure resources, such as storage, were not part of that scaling operation.  With Azure VM Scale Sets you take a VM PLUS a set of related resources, and creates a base ‘stamp’ image.  You then create one or more instances of these resource sets while scaling out. Unlike single-instance VMs, you do not need to independently define and correlate network, storage and extension resources for individual VMs as the resources scale as a ‘set’ of resources.

Scale sets leverage Azure Resource Manager (ARM), with its efficient and parallel resource deployment model. With ARM templates, you are able to provision groups of related Azure resources with a JSON script file.   That means you can create a relationship between the VMs that need to scale out and other resources like NIC cards, VM extensions, storage, and any other Azure resource you want to include in the scaling process.  Using VM Scale Sets allows you to create and manage a group of identical VMs to correlate the creation of many independent resources.  For instance, the scale set you deploy could have multiple VMs behind an external load balancer with a public IP address with inbound NAT rules that allow you to connect to a specific instance for solving problems, and Azure storage accounts.  Just think how hard that would be to do that in a scaling situation without Scale Sets.

Right now you use resource group templates for Scale Sets.  Eventually you will be able to create Scale Sets directly from the Azure portal.

 

Azure Dev Test Labs

Practically speaking…wow! Take a look at the new (Public Preview) features called Azure Dev Test Labs. It rocks! This will be an incredibly popular feature for our customers.  With Azure Dev Test Labs your development and test team can dynamically use a self-service provisioning mechanism to quickly deploy Windows or Linux test environments in the Azure cloud. There is a built in process to template specific types of resource allocations. Once provisioned, there is a way to utilize quotas and policies to manage the expense and usage of those resources. That way you make sure your team does not ring up unnecessarily large bills for unused or over-provisioned resources.

With the advent of Azure Resource Manager and resource group templates a process exists to repeatedly allocate entities in Azure using a full reproducible and repeatable method.   The same concept of a template exists in Azure DevTest labs to allow you to create an on-demand Dev-Test environment in a few simple strokes on the mouse.  Leverage these templates via source control across groups in your company or across the enterprise. You can use Visual Studio online along with Git (version control system), and GitHub (web-page on which you can publish your Git repositories and collaborate with others) to add private artifacts. Artifacts can be items like tools that you want to install on a VM, actions that you want to run on the VM, or applications that you want to test. Azure DevTest Labs ships with a lot of key artifacts to get going.  There is a blade on the Azure Preview Portal that asks for the GIT Clone URI and the folder path. The Azure DevTest Lab will speak to the Git repository and sync the content.

DevTest Labs can be worked into your deployment process where you can set a limit to manage the costs and lifetime of you Azure Dev/Test resources. There are also existing pools of VMs from which you can quickly draw from to expedite the setup of your development or test environment.

To manage security of who has access by using role-based access control, such as the DevTest Lab user role. This allows to manage access at different levels (i.e. subscription, lab level, etc.) to use and provision resources.

For more info on Azure Dev/Test Labs go to https://azure.microsoft.com/en-us/services/devtest-lab/

 

As you may know, the Azure cloud platform has been built from the ground up to be an open platform, and currently 1 in 4 Azure virtual machines is powered by Linux and 60% of the solutions in Azure marketplace are Linux based. This week, we are announced another significant step forward in our ongoing openness efforts and support for Linux on Azure, and I am pleased to inform you that we have entered into a partnership with Red Hat to provide joint, enterprise grade support on Azure for a breadth of Red Hat solutions. Key elements of the partnership include:

  • Red Hat solutions available natively to Microsoft Azure customers. In the coming weeks, Microsoft Azure will become a Red Hat Certified Cloud and Service Provider, enabling customers to run their Red Hat Enterprise Linux applications and workloads on Microsoft Azure. At this time, Red Hat Cloud Access subscribers will be able to bring their own virtual machine images to run in Microsoft Azure. Microsoft Azure customers can also take advantage of the full value of Red Hat’s application platform, including Red Hat JBoss Enterprise Application Platform; Red Hat JBoss Web Server; Red Hat Cluster Storage; and OpenShift, Red Hat’s Platform-as-a-Service (PaaS) offering. Also, in the coming months, Microsoft Azure and Red Hat plan to provide Red Hat On-Demand— “pay-as-you-go” Red Hat Enterprise Linux images available in the Azure Marketplace, supported by Red Hat.
  • Integrated enterprise-grade support spanning hybrid environments. Customers will be offered cross-platform, cross-company support spanning the Microsoft Azure and Red Hat offerings in an integrated way, unlike any previous partnership in the public cloud. By co-locating support teams, the experience for customers will be simple and seamless.
  • Unified workload management across hybrid cloud deployments. Red Hat CloudForms will integrate with Microsoft Azure and System Center Virtual Machine Manager, offering Red Hat CloudForms customers the ability to manage Red Hat Enterprise Linux on both Hyper-V and Microsoft Azure. Support for managing Azure workloads from Red Hat CloudForms is expected to be added next year, extending the existing System Center capabilities for managing Red Hat Enterprise Linux.
  • Collaboration on .NET for a new generation of application development capabilities. Expanding on the preview of .NET on Linux announced by Microsoft in April, developers will have access to .NET technologies across Red Hat offerings, including OpenShift and Red Hat Enterprise Linux, jointly backed by Microsoft and Red Hat. Red Hat Enterprise Linux will be the primary development and reference operating system for .NET Core on Linux.

There is significant customer demand for Red Hat support on Azure, and this announcement unlocks a huge opportunity for our partners to engage with customers to help them move existing or new Red Hat solutions to the Azure platform.

For more information:

  • Visit the Microsoft and Red Hat landing page here and view the announcement webcast by Microsoft’s Scot Guthrie and Red Hat’s Paul Cormier.
  • Attend (or watch a recording) of a technical webinar on running Red Hat solutions on Microsoft Azure.
  • Go here to learn more about our overall Microsoft open cloud approach and join our social blog.