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.
