4 ms·

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 thes

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.

Mossy9 2y ago
That's the next step - hopefully. Moving to Linux, possibly with containers. Maybe in 5 years...
bragh 2y ago
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.
- easton 2y ago
  Add the executable as a windows service, stop service, replace executable (SMB copy or rsync or whatever), start service? Probably a cleaner way, but it’s just a exe, so replace it like a exe?
  - bragh 2y ago
    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.
  - p_ing 2y ago
    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. Kestrel is fast, though.
- bob1029 2y ago
  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.
- neonsunset 2y ago
  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).
stackskipton 2y ago
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.
- p_ing 2y ago
  This depends on your requirements. If you want high performance non-blocking async networking, Windows is the better bet with .NET.
  - stackskipton 2y ago
    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. You can see some benchmarks here FROM 2017: https://robertoprevato.github.io/Comparing-Linux-hosted-to-Windows-hosted-ASP-NET-Core-applications-in-Azure-Application-Service-Plan/ https://robertoprevato.github.io/Comparing-Linux-hosted-to-W... where Linux is beating out Windows in Async web workloads. That's only gotten better since years have gone on. 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."
  - neonsunset 2y ago
    .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.
    - p_ing 2y ago

Mossy9 2y ago

That's the next step - hopefully. Moving to Linux, possibly with containers. Maybe in 5 years...

bragh 2y ago

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.

easton 2y ago
Add the executable as a windows service, stop service, replace executable (SMB copy or rsync or whatever), start service? Probably a cleaner way, but it’s just a exe, so replace it like a exe?
- bragh 2y ago
  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.
- p_ing 2y ago
  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. Kestrel is fast, though.
bob1029 2y ago
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.
neonsunset 2y ago
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).

stackskipton 2y ago

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.

p_ing 2y ago
This depends on your requirements. If you want high performance non-blocking async networking, Windows is the better bet with .NET.
- stackskipton 2y ago
  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. You can see some benchmarks here FROM 2017: https://robertoprevato.github.io/Comparing-Linux-hosted-to-Windows-hosted-ASP-NET-Core-applications-in-Azure-Application-Service-Plan/ https://robertoprevato.github.io/Comparing-Linux-hosted-to-W... where Linux is beating out Windows in Async web workloads. That's only gotten better since years have gone on. 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."
- neonsunset 2y ago
  .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.
  - p_ing 2y ago