¿Por qué usar IIS o apache tomcat en lugar de autohospedaje?

Soy un desarrollador de .NET. Veo que el framework ASP.NET MVC ahora comenzó a proporcionar una función de autohospedaje. Tiene mucho sentido (para mí). Una aplicación autohospedada se siente completa sin dependencia externa.

La pregunta que tengo en mi mente ahora es ¿por qué alguien NO querría ser el anfitrión? Quiero decir, ¿hay alguna ventaja que IIS me dará sobre el autohospedaje? Estoy seguro de que hay algunas ventajas porque, de lo contrario, Microsoft no se habría molestado en crear la integración de IIS con asp.net core.

No quiero que mi pregunta sea específica para .NET. Entonces, voy a ir con, ¿por qué usar por qué usar IIS o apache tomcat en lugar de autohospedaje?

— bilal fazlani
fuente

A un alto nivel, los principales servidores web vienen con una gran cantidad de funcionalidades que necesita reconstruir por completo, que de otro modo puede configurar o simplemente ignorar , si se "auto-hospeda". Cosas simples, como servir archivos estáticos, y configurar Expiresy ETagencabezados. Y luego cosas más complicadas, como separar el tráfico host, mantener las aplicaciones alejadas de la memoria de los demás, SSL y administrar miles de solicitudes simultáneas ...

— svidgen

Podrías escribir tu propio servicio HTTP usando sockets C ++.

— Matthew Whited

dotnetfunda.com/interviews/exclusive/show/755/…

— Matthew Whited el

Muchas aplicaciones .net se llaman a sí mismas "autohospedadas" mientras todavía usan http.sys, lo cual es bastante confuso para IMO.

— CodesInChaos

En mi opinión, es simplemente una consecuencia histórica de la evolución de los casos de uso para la pila de servicios y protocolos TCP / HTTP. Por ejemplo, en el caso de HTTP, el daemon o servicio solía estar en la parte superior del sistema operativo como una especie de centro central de cualquier contenido web, a lo que otras aplicaciones locales o remotas delegarían el consumo u oferta de hipertexto / hipermedia contenido.

— YSharp

IIS proporciona una serie de capacidades comunes que no están disponibles de forma predeterminada en los servicios web autohospedados. Supervisor: monitorea el estado de la aplicación web y matará / reaparecerá la aplicación si comienza a verse poco saludable (usando demasiada memoria, CPU, etc., configurable). Límites de recursos como uso de CPU, límites de conexión, etc. Ejecutar como un determinado usuario para la seguridad con menos privilegios. Gestionar certificados / SSL. Hospede / administre muchas aplicaciones a través de un puerto / interfaz. Proxy inverso para aplicaciones de consola. Muchas otras cosas que no mencioné, como el registro de solicitudes.

No estoy familiarizado con Tomcat, pero supongo que es la misma historia. Obtiene características de alojamiento adicionales que el alojamiento propio no le proporciona de forma predeterminada y puede ser bastante difícil de implementar usted mismo.

A menudo, los productos que exponen un servicio web autohospedado aún recomendarán colocarlos detrás de un proxy inverso u otro supervisor en producción. Esto puede ser para garantizar que sobrevivirá a los bloqueos o que será elegante durante las interrupciones de la red. Estoy pensando en NGINX para los servicios de Docker, por ejemplo. En el espacio .NET, creo que Kestrel es proxy inverso a través de IIS como práctica estándar (o tal vez NGINX en Linux / Mac).

Tradicionalmente, las aplicaciones ASP.NET se han alojado solo en Windows en Internet Information Server (IIS). La forma recomendada de ejecutar aplicaciones ASP.NET Core en Windows todavía está usando IIS, pero como un servidor proxy inverso. El módulo principal de ASP.NET en IIS administra y envía las solicitudes al servidor HTTP de Kestrel fuera de proceso.

— Kasey Speakman
fuente