tl;dr – don’t bring your own image unless you really have a good use-case and you’ve already modernized configuration management processes. Re-evaluate what is baked into the standard deployment and carefully plan automation. Test thoroughly.
When first investigating running applications in Azure, customers often ask me “How do I upload my base image to Azure?” My response, invariably, is “You probably don’t.” There are a few reasons why I recommend this. First, Azure is a fantastic opportunity to think about alternate ways to run all the applications that today run in VMs. We’re not going to get into that in this post; I’ve discussed it here in greater depth. Second, moving to the cloud is a great opportunity to discover new ways of managing infrastructure. The entire model is different, so assumptions that are made on-premises should not be carried over to the public cloud. This is discussed a bit more here, in the context of automation. Thirdly, there is a learning curve to building a good image in Azure as many of the traditional ways of operating are either not possible (VM Console access and snapshots for example) or are accomplished using PowerShell or CLI, which is usually not the quickest way to accomplish the task. Finally, the simple fact that Azure is at the other end of a limited Internet pipe usually makes it a bit more time-consuming to manage large files, like a VM image.
Fundamentally, the question is about whether the organization can understand the change that moving to a large-scale public cloud vendor will require – whether it’s AWS, Azure, or Google Compute Engine, the traditional datacenter paradigm no longer applies. Each application has unique configurations and requirements. Heavily-customized images will require changes based on the application. Simplified images will require changes for most applications. In both cases, manual configuration often results in misses – configuration that is inconsistently applied across the application stack. Furthermore, all applications require configuration, and the only reliable way to apply this configuration is through automation. Fortunately, we have tools now, such as PowerShell DSC, to apply and enforce configuration.
Modern configuration management tools have their roots in DevOps processes. This means that changes to the desired configuration are easily identified and, importantly, easily rolled back[footnote]This assumes that the basic process for applying changes to servers is well debugged, documented, and understood[/footnote]. Changes are stored in plain-text files that can be easily differenced and can be stored in a source code management system, which enables changes to be quickly identified. Importantly, the configuration is re-evaluated frequently, and reapplied if the configuration drifts.
Azure represents an opportunity to completely re-tool the IT organization. Applications can be re-platformed for efficiency, reliability, and security, and IT processes updated to make increased used of automation.
One more thing – Azure VMs expect to be able to talk to the Internet, and there’s no console access. If an image is hardened too aggressively, it can interrupt normal operations of the VM. If you need to re-create your VM Image, it’s usually not a very quick process. .
Why you should use an image in Azure
This is not to say it is impossible to deploy from your own images in Azure. It may be a great idea, in some cases. For example, VM Scale Sets can dramatically benefit from the deployment improvements that are possible with a partially-configured image – if a long-running task is always required, that can be baked into the image, and the runtime application can be deployed via configuration management. A web application, for example, may rely on a MSI being installed and data being present in a specific directory. Rather than downloading all that data and installing the application, possibly with several reboots, the server can just start up, find the application and data, and install the webapp code and be ready to serve customers in a fraction of the time. As with everything, trade-offs exist, and strict CM deployment must be balanced against speed of deployment.
Another reason you may wish to bring your own image is if you’re using Managed Disks. Managed Disks have a pricing model that is different than blob storage. That means, if you provision a 1TB image, you pay for a 1TB disk – even if you’ve only got 10GB of files on the disk. Managed Disks can be resized, too, which means that you can easily start with a tiny disk. Microsoft provides small images for some of their offerings; however, many third party images are not optimized for small sizes, so you might find yourself paying for a lot more storage than you’re using.