Running the agent on the app server seemed a bit risky since it will a) drain resources from the apps and b) needs to have a route open to Azure (Devops)
Apparently you have had good experiences with this? I'd be interested to learn more
Agent permissions to Azure are restricted based on the pipeline configuration to only allow things that are used in the pipeline. So if your pipeline does not involve cloning git some private git repo, agent cannot do that. And even that gives only access to that particular resource. So you normally have a build pipeline that generates package from you application and then deployment pipeline that only has access to that generated package which is then distributed to agents configured for some particular deployment environment.
I don't really have much direct experience with deployment side of things so someone else can probably provide extra info.
The resource usage is negligible.
If you really need that level of high efficiency that you can't spare the tiny amounts of memory the agent uses, then you'd be better off looking into using something like Packer to build a Server Core image in your pipeline, and deploying that to an Azure Virtual Machine Scale Set. This allows "zero outbound communications" deployments also because the image build step is out-of-band and isn't done anywhere near the live infrastructure network. https://learn.microsoft.com/en-us/azure/devops/pipelines/tas...
The above approach concept also works with any other imaging-based workflow such as Windows Docker containers running on App Service or Kubernetes. https://azure.github.io/AppService/windows-containers/
The packer + VMSS approach however allows the IIS workers to join an Active Directory domain "properly". Sure, Kubernetes has some limited support for this, but I wouldn't try it in production unless forced to at gunpoint.
> needs to have a route open to Azure.
If you're only deploying instead of running arbitrary pipeline tasks, then I believe just four firewall rules is sufficient to Azure DevOps (not "Azure"!), but you may need more depending on your requirements: https://learn.microsoft.com/en-us/azure/devops/pipelines/age...
> Apparently you have had good experiences with this?
It's pretty much the "only way" to do things in the current-gen YAML Azure DevOps pipelines.
The alternatives are Kubernetes, App Service, and the like, but those generally aren't 100% compatible with traditional domain-joined IIS web servers.
If you actually need the traditional Windows box "infrastructure" instead of a PaaS, then directly installed DevOps Agents would be one of the best ways to manage it.
The best alternative I know of is probably Nomad, but that's only good if your org is already invested into Hashicorp tooling.