Arguably, IIS is more advanced than typical Linux hosting services, where the standard for decades has been "stop and restart the service" for configuration cha

Arguably, IIS is more advanced than typical Linux hosting services, where the standard for decades has been "stop and restart the service" for configuration changes, causing a temporary outage. I'm sure that's improved over time (has it?), but IIS had continuous operation modes since at least the year 2000. Historically my experience with Linux web deployment has also been "copy in a bunch of files", so I don't see how it's any better or worse! (Docker support is available for both as well.) Some random IIS capabilities include: - You can edit any part of the IIS configuration live, and this won't require a service restart. You can even edit .NET application code and configuration files live, and changes can take effect non-disruptively even if a process restart is required for the virtual app. IIS will buffer requests and overlap the new process with the old one. https://learn.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525803(v=vs.90)#overlapped-recycling https://learn.microsoft.com/en-us/previous-versions/iis/6.0-... - Web Deploy is basically just a zip file of a web application that can be produced by Visual Studio, vaguely similar to packaging up a site and its config with Docker: https://www.iis.net/downloads/microsoft/web-deploy https://www.iis.net/downloads/microsoft/web-deploy - Visual Studio integrates directly with IIS using "publish" settings that can target an IIS server and be used to deploy a complete web app with a button-press from the IDE: https://learn.microsoft.com/en-us/visualstudio/deployment/tutorial-import-publish-settings-iis?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/deployment/tu... - The volume shadow service can be utilised by IIS to create backups of its entire configuration including all files on a schedule: https://usavps.com/blog/13597/ https://usavps.com/blog/13597/ - Shared configuration allows scale-out web farms to be created. The key IIS config files and web content are moved to a UNC file share and then the workers just "point" at this. With an external load balancer that supports traffic draining this allows for seamless OS reboots, upgrades, etc... There's even a trick where SMB Caching is used to automatically and transparently create a local disk cache of the shared content, allowing IOPS to scale with web farm server instances without any manual deploy or sync operations. https://learn.microsoft.com/en-us/iis/web-hosting/configuring-servers-in-the-windows-web-platform/shared-configuration_211 https://learn.microsoft.com/en-us/iis/web-hosting/configurin... - The above goes hand-in-hand with Centralized SSL Certificate Support: https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-centralized-ssl-certificate-support-ssl-scalability-and-manageability https://learn.microsoft.com/en-us/iis/get-started/whats-new-... If you want to use container technology on Windows for web apps, you can do that too. Windows Server supports Windows Containers, and ASP.NET Core has excellent support with a whole bunch of pre-prepared base container images for both Windows and Linux hosts. If you have many such sites on a Windows web host, you would use the IIS Application Request Routing reverse proxy to add HTTPS to back-end containers running on HTTP. That, or just use Azure App Service, or YARP, or... Personally, if I had to run a large-scale IIS web farm again, I would keep things simple and just use the Azure DevOps agent with the IISWebAppDeploymentOnMachineGroup task: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/iisweb-app-deployment-on-machine-group-v0?view=azure-pipelines https://learn.microsoft.com/en-us/azure/devops/pipelines/tas...