Why use IIS or apache tomcat instead of self-hosting?

Question

I am a .NET developer. I see ASP.NET MVC framework now started providing a self-hosting feature. It makes a lot of sense (to me). A self-hosted application feels complete with no external dependency.

The question I have in my mind is now why would anyone NOT want to self-host ? I mean, Are there any advantages that IIS will give me over self-hosting. I am sure there are some advantages because otherwise, Microsoft would not have bothered creating IIS integration with asp.net core.

I don't want my question to be specific to .NET. So, I am gonna go with- why go with why use IIS or apache tomcat instead of self-hosting ?

• svidgen: At a high level, major web servers come with a lot of functionality you need to totally rebuild, that you can otherwise configure or simply ignore, if you "self-host." Simple things, like serving up static files, and configuring Expires and ETag headers. And then more complicated things, like separating traffic by host, keeping applications away from each other's memory, SSL, and managing thousands of concurrent requests ...
• Matthew Whited: You could just write your own HTTP service using C++ sockets.
• Matthew Whited: dotnetfunda.com/interviews/exclusive/show/755/…
• CodesInChaos: Many .net applications call themselves "self hosted" while they still use http.sys, which is rather misleading IMO.
• YSharp: In my view, it's merely a historical consequence of the evolution of the use cases for the TCP/HTTP protocols and services stack. E.g., in the case of HTTP, the daemon or service used to be sitting on top of the OS as a sort of central hub of anything-web content, to which other local or remote applications would delegate the consumption or offering of hypertext/hypermedia content.

Answer 1

IIS provides a number of common capabilities that are not available by default in self-hosted web services. Supervisor: it monitors the health of the web application and will kill/respawn the application if it starts looking unhealthy (using too much memory, CPU, etc. -- configurable). Resource limits like CPU usage, connection limits, etc. Run as a certain user for least privilege security. Manage certificates/SSL. Host/manage many applications through one port/interface. Reverse proxy to console applications. A lot of other things I didn't mention like request logging.

I'm unfamiliar with Tomcat, but I assume it's the same story. You get extra hosting features that self-hosting does not give you by default and may be quite difficult to implement yourself.

Often products that do expose a self-hosted web service will still recommend putting them behind a reverse proxy or other supervisor in production. This may be to ensure it will survive crashes or be graceful during network interruptions. I'm thinking of NGINX for Docker services, for instance. In the .NET space, I believe Kestrel is reverse proxied through IIS as standard practice (or maybe NGINX on Linux/Mac).

Traditionally, ASP.NET apps have been windows-only hosted on Internet Information Server (IIS). The recommended way to run ASP.NET Core applications on Windows is still using IIS, but as a reverse-proxy server. The ASP.NET Core Module in IIS manages and proxies requests to the Kestrel HTTP server hosted out-of-process.