Por que usar o IIS ou o apache tomcat em vez de auto-hospedagem?

Sou desenvolvedor .NET. Vejo que a estrutura do ASP.NET MVC agora começou a fornecer um recurso de auto-hospedagem. Isso faz muito sentido para mim). Um aplicativo auto-hospedado parece completo sem dependência externa.

A pergunta que tenho em mente agora é por que alguém NÃO gostaria de se auto-hospedar? Quero dizer, existem vantagens que o IIS me dará sobre a auto-hospedagem. Estou certo de que existem algumas vantagens, porque, caso contrário, a Microsoft não se incomodaria em criar a integração do IIS com o núcleo do asp.net.

Não quero que minha pergunta seja específica ao .NET. Então, eu vou com - por que ir com por que usar o IIS ou o apache tomcat em vez de auto-hospedagem?

— bilal fazlani
fonte

Em um nível alto, os principais servidores da Web vêm com muitas funcionalidades necessárias para reconstruir totalmente, que você pode configurar ou simplesmente ignorar , se "se auto-hospedar". Coisas simples, como servir arquivos estáticos e configurar Expirese ETagcabeçalhos. E coisas mais complicadas, como separar o tráfego host, manter os aplicativos afastados da memória um do outro, SSL e gerenciar milhares de solicitações simultâneas ...

— svidgen

Você pode simplesmente escrever seu próprio serviço HTTP usando soquetes C ++.

— Matthew Whited

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

— Matthew Whited

Muitos aplicativos .net chamam a si mesmos de "auto-hospedados" enquanto ainda usam o http.sys, o que é um IMO bastante enganador.

— CodesInChaos

Na minha opinião, é apenas uma consequência histórica da evolução dos casos de uso da pilha de protocolos e serviços TCP / HTTP. Por exemplo, no caso do HTTP, o daemon ou serviço costumava estar no topo do sistema operacional como uma espécie de hub central de qualquer conteúdo da Web, para o qual outros aplicativos locais ou remotos delegariam o consumo ou a oferta de hipertexto / hipermídia conteúdo.

— YSharp 29/09/16

O IIS fornece vários recursos comuns que não estão disponíveis por padrão em serviços da web auto-hospedados. Supervisor: monitora a saúde do aplicativo da web e mata / reaparece o aplicativo se ele começar a parecer prejudicial (usando muita memória, CPU, etc. - configurável). Limites de recursos, como uso da CPU, limites de conexão, etc. Execute como um determinado usuário para ter menos privilégios de segurança. Gerenciar certificados / SSL. Hospede / gerencie muitos aplicativos através de uma porta / interface. Proxy reverso para aplicativos de console. Muitas outras coisas que não mencionei, como o registro de solicitações.

Não estou familiarizado com o Tomcat, mas presumo que seja a mesma história. Você obtém recursos extras de hospedagem que a auto-hospedagem não fornece por padrão e pode ser bastante difícil de implementar.

Muitas vezes, os produtos que expõem um serviço da web auto-hospedado ainda recomendam colocá-los atrás de um proxy reverso ou outro supervisor em produção. Isso pode garantir que ele sobreviva a falhas ou seja gracioso durante as interrupções da rede. Estou pensando nos serviços do NGINX for Docker, por exemplo. No espaço .NET, acredito que o Kestrel possui proxy reverso através do IIS como prática padrão (ou talvez NGINX no Linux / Mac).

Tradicionalmente, os aplicativos ASP.NET eram hospedados apenas no Windows no Internet Information Server (IIS). A maneira recomendada de executar aplicativos ASP.NET Core no Windows ainda está usando o IIS, mas como um servidor proxy reverso. O ASP.NET Core Module no IIS gerencia e solicita proxies ao servidor HTTP Kestrel hospedado fora de processo.

— Kasey Speakman
fonte