Virtual Machines in a Scale Set provide a great way to spin up many identical machines in parralell. Thes VMs are all based on a common VM image and so unless all you need on your VMs is Windows, you are going to need to load applicaitons and data into these VMs. Getting your applications into that image can be done one of two ways:
Use a Gallery image for your scale set and apply your applications on each VM when it is deployed using something like the PowerShell DSC extension, or Chef/Puppet etc.
In an on premises world, with Active Directory, password expiry is easy. Set the required policy for your domain, make sure it’s applied and forget about it, AD will take care of enforcing password changes and compliance with your password rules. Moving your identity to Azure complicates things, and that’s what we are going to talk about today, and in particular password expiry and related processes in the world of Azure AD Connect.
A while back I wrote an article talking about the new “Condition” option in Azure Resource Manger (ARM) templates. This was the first step into conditional logic in ARM templates and worked great where you needed to apply a condition at the resource level. Where it fell down was where you needed a condition inside a resource, this resulted in you having to duplicate objects with different settings and work around issues like duplicate naming.
Microsoft today released a public preview of a new service, Azure Container Instances. This may seem confusing initially, Azure already has a container service called Azure Container Services (ACS), but this is a somewhat different offering. ACS is a full container hosting solution, including orchestrators, deployed on top of multiple IaaS based Azure Virtual machines. Azure Container Instances (ACI) is not an orchestrator, it is a platform for deploying containers quickly and simply.
As your Azure usage increased you will inevitably need to grant rights to other users to create and manage resources. Often you need to apply limits to what these user can do with their Azure subscription. Role Based Access Control allows you to put users into roles which grant them access to specific top level resources (virtual machines, storage, SQL etc.), what RBAC doesn’t do however is limit what you can do with those resources.
In my last article we discussed the various different options for providing SMB shares in Azure given the lack of shared storage. One of the options we discussed for this was using a new feature of Server 2016 – Storage Replica, and in this article we will take a deep dive into how to setup this up in Azure. This Windows Server feature allows you to replicate data between two servers (or two clusters) and could potentially be a great solution for replicating shares in Azure, if you can cope with the limitations.
In an ideal world, all our cloud applications would be designed from the ground up to work with the cloud, they would be designed to work with cloud principals, make use of PaaS services and provide high availability. Unfortunately, this is often not the case. We are regularly tasked with moving existing on-premises applications into the cloud as a “lift and shift” type operation, until they can be redesigned to be cloud native.
I previously wrote about using VS Code for authoring Azure Resource Manger templates, in particular about using the snippets from the cross platform toolkit to create skeletons for many ARM resources. In this post I documented the manual installation process for these snippets, as there was not a VS Code extension to install these automatically. This is no longer the case, I have recently published a VS Code extension that takes these snippets (with attribution) and packages them up and makes them available in the VS Code marketplace for easy installation and updating.
Azure Resource Manager (ARM) templates are a great resource for deploying Azure infrastructure, including virtual machines, in a declarative manner. However, using an ARM template to deploy a VM will only get you as far as having a VM deployed and the operating system installed and running. The next step is to get any applications and supporting software installed on those machines. Of course you can RDP to machine and do this manually, but this breaks down quickly if you have lots of machines or need to regularly deploy VM’s.
Disaster recovery is, or should be, a must for for many production applications. Having the ability to recover your application in a separate geographic location should a major incident occur is vital to the continued availability of your service. Microsoft have offered a DR service called Azure Site Recovery (ASR) for some time now, but this has been focused on taking on-premises applications and providing a DR solution for these in Azure.
