If you have the choice, I'd strongly consider using Kestrel and self contained deployments.
IIS isn't "bad", but it's definitely way more complicated than these newer hosting models.
Controlling 100% of the hosting environment from code is a really nice shift in responsibility. Takes all the mess out of your tooling and processes. Most of the scary is resolved at code review time.
SRE here who deals with .Net (Core). If you have .Net and not running on Linux, you are just subjecting yourself to pain for no reason. .Net recommended runtime environment is Linux, preferable a container, otherwise, I'd recommended Ubuntu LTS.
To be fair, ASP.NET Core has pretty nice http.sys integration for IIS. I'm an advocate of running such workloads on Linux whenever possible too, but I wouldn't say that IIS is that bad, but it is definitely worse.
On the topic, please stop putting Nginx in front of Kestrel just for the sake of it (i.e. you have a single node, or it's an internal network without a load-balancer, etc.) - you're literally wasting resources on additional point of failure and more network hops.
We do it on Single node just because doing HTTPS with Kestrel in a container is painful. Volume mounting the config file + certificates along with Kestrel appsettings.json is annoying vs Proxy server which makes it much easier.
You can use ConfigMap instead of volume for providing the config (it is also nice since you can merge the application settings with the deployment manifest).
For certificates, you can retrieve them from whatever vault solution you have on hand, or you can, indeed, access a volume. I do not understand the difficulties with volume mounting however which is a standard practice.
I'm not saying just using Nginx is a bad choice, but, much like using Redis for things that have no business using Redis, I've seen a fair share of the same misuse with Nginx.
If you have ConfigMap, you have Kubernetes so Ingress is solved for you. ;)
> Configuring Kestrel programmatically is really straightforward too
Sure, but Developers tend to not want to futz with it. My use case is our application lives in a container, most of time we host it but occasionally a customer demands they host it so we give them the container. Some host it on Windows (we do build a Windows container of our application :vomit:) and some on Linux. In any case, we require them to use reverse proxy because HTTPS with Kestrel was becoming too high of support so we require they provide HTTPS proxy. We recommend IIS ARR for Windows users, and CaddyServer for Linux but Linux users tend to not need our advice.
EDIT: Our hosting platform is Azure Kubernetes Service, 100% Linux Nodes.
Might've as well shipped NativeAOT-compiled (or single-file trimmed JIT) build of YARP. Faster than Envoy which is faster than Caddy. Only Nginx and HAProxy are faster than YARP.
Dude, just wrong. Last job, we moved .Net RabbitMQ job processor that was making a bunch of async web calls nightly would handle 50k+ messages from Windows to Linux, our job processing time was cut by 2/3. In fact, first few mornings, no one believe the execution time, thought it had silently failed and Dev team manually checked it it's work. Nope, it did its job properly with less RAM/CPU.
In my personal experience dealing with .Net 6+ (Mostly 8 now), Linux destroys Windows in performance running .Net workloads hands down 95% of the time. This lines up with Microsoft .Net team advice, every time the topic comes up "Windows or Linux?" They say "Linux, it's easier to deal with and performance is better."
.NET has really good integration between async and networking via epoll/kqueue-based Socket (SocketAsyncEngine) implementation. Given that Linux is the main target for server workloads written in C# or F# nowadays, it has better or more uniform performance more often than not. My experience aligns with sibling comment by stackskipton.
I'm really not sure why you are arguing in favour of using Windows Server. This is legitimately bad advice.
ASP.NET Core team maintains an extensive suite of benchmarks. If you select plaintext or fortunes or json for Intel Gold Linux and Windows (both Kestrel and IIS) hosts, you will see that pure Kestrel with Linux has the best throughput and latency across the board.
How do you deploy your code with Kestrel though? If you already have Windows Server licensed, then you get IIS and msdeploy without any additional tooling or vendor needed.
The self-contained deployment piece helps with that.
I've built pipelines where the deployed code is responsible for cloning, building & redeploying itself based upon commands sent via an administration interface. The .NET SDK is relatively lightweight and can be included as a management component in a broader B2B/SaaS product.
It's better to use the same deployment process you would use for Node.js, Go, Rust, etc. Especially since .NET CLI tooling is excellent and lets you build fairly small completely self-contained binaries (with trimming) or you could easily get your hosts to have the runtime installed (which takes little space) and then just copy very small .dll files (you can do runtime-less single-file deployment, so it's going to be literally 1-5 files taking less than 1-5MB in total).
While you can do that, you lose the flexibility of IIS without a lot of infrastructure development should you not just want a single website per server running .NET only.
Yes, that is obvious, but the problem is that this requires some account to have permissions to start and stop services and to execute commands on the target host. Corporate IT departments are not too happy with that kind of approach nowadays.
IIS isn't "bad", but it's definitely way more complicated than these newer hosting models.
Controlling 100% of the hosting environment from code is a really nice shift in responsibility. Takes all the mess out of your tooling and processes. Most of the scary is resolved at code review time.