If you read my blog post, Keys to Being Cost Effective in Azure, you already know that I prefer not to use virtual machines for either hosting or building solutions. Both Azure & Azure DevOps have resources available for providing these services, but the best part is that most of these resources come with either a free pricing tier or a relatively low cost pay as you go option after a monthly recurring allowance of free requests/instances. In this blog I will be writing about a resource in Azure which I have started using recently that is still in private preview at the time of writing but has tremendous potential - Azure Container Apps.
My first experience working with containers was soon after transitioning from testing to development. Our team was building a .NET Core application that was to be deployed to and hosted in Pivotal Cloud Foundary (a private cloud). In this case I was only developing & releasing our application to the container as we had a dedicated operations team but since then I’ve had to get a bit more hands-on with containers.
More recently I have used containers to speed up build & release pipelines in Azure DevOps which required a specific set of PowerShell modules & command line tools installed. Using YAML pipelines made launching pipeline jobs from custom container images stored in Azure Container Registry super easy - but I found that the more that was needed in the container the longer it took for the container job to start.
- stage: Test
displayName: Test Imges
dependsOn: [Build]
jobs:
- job: test_ubuntu
displayName: Test Image - Linux
container: $(imageRepository):$(tag)-ubuntu
steps:
- ...
- job: test_windows
pool:
vmImage: windows-latest
displayName: Test Image - Windows
container: $(imageRepository):$(tag)-windows
steps:
- ...
Typically for building I will rely on the Microsoft hosted agents in Azure DevOps and for hosting that means utilizing resources like Azure Function Apps, Automation Runbooks, Storage Accounts (often with static site enabled), & Static Web Apps.
When it comes to all types of software development the shorter your feedback loop is, the faster you can learn from and react to changes, and the faster you can deliver a valuable working product - but in many cases that has always came at the cost of at least one virtual machine.
Where the costs start to stack up in the software development industry is when you realize that virtual machines were needed not only for hosting any products & services (multiplied by the number of copies needed of the production environment for development, test/qa, etc.), but also for building & developing those products & services.
Now I will admit that I am not old enough to have seen for myself, but I hear from my elder peers that dedicated build virtual machines were not typically maintained properly - nor were they