¿Cuál es la diferencia entre un sitio web de Azure y un rol web de Azure?

¿Cuáles son las diferencias materiales entre los nuevos sitios web de Azure y los roles web tradicionales de Azure para una aplicación ASP.NET MVC? ¿Qué razón elegiría un “sitio web” sobre un “rol web” o viceversa?

Supongamos que necesitaría la misma capacidad en cualquier caso (p. Ej., 2 instancias pequeñas). Los precios parecen comparables, aparte del hecho de que hay un descuento temporal del 33% para los sitios web mientras se encuentran en su período de vista previa.

¿Hay cosas que puedo hacer con un “sitio web” que es difícil o imposible con un rol web? Por ejemplo, ¿se vuelve fácil poner múltiples sitios web en un solo conjunto de máquinas virtuales utilizando “sitios web”? ¿Pierdo algo con un “sitio web” frente a un “papel web”? Posibilidad de afinar IIS? Posibilidad de usar el servicio de caché localmente?

Los roles web le brindan varias funciones más allá de las aplicaciones web (anteriormente sitios web):

  • Posibilidad de ejecutar scripts de inicio elevados para instalar aplicaciones, modificar configuraciones de registro, instalar contadores de rendimiento, ajustar IIS, etc.
  • Posibilidad de dividir una aplicación en niveles (tal vez rol web para el front-end, rol del trabajador para el procesamiento de back-end) y escalar de forma independiente
  • Capacidad de RDP en su máquina virtual para fines de depuración
  • Aislamiento de red
  • Dirección IP virtual dedicada, que permite que las instancias de rol web en un servicio en la nube accedan a máquinas virtuales con restricción de IP
  • Puntos finales restringidos por ACL (agregado en Azure SDK 2.3, abril de 2014)
  • Soporte para cualquier puerto TCP / UDP (los sitios web están restringidos a TCP 80/443)

Las aplicaciones web tienen ventajas sobre los roles web:

  • Implementación casi instantánea con historial de implementación / reversiones
  • Visual Studio Online, github, git local, ftp, CodePlex, DropBox, soporte de implementación de BitBucket
  • Posibilidad de implementar uno de los numerosos CMS y frameworks (como WordPress, Joomla, Django, MediaWiki, etc.)
  • Uso de la base de datos SQL o MySQL
  • Escalado simple y rápido desde el nivel gratuito al nivel compartido al nivel dedicado
  • Trabajos web
  • Copias de seguridad del contenido del sitio web
  • Herramientas de depuración basadas en web incorporadas (consola de depuración cmd / powershell simple, explorador de procesos, herramientas de diagnóstico como transmisión de logs, etc.)

Con las implementaciones de abril de 2014 y septiembre de 2014, ahora hay algunas características comunes tanto a las aplicaciones web como a las funciones web (y las funciones de los trabajadores), que incluyen:

  • Staging + producción de máquinas tragamonedas
  • Comodín DNS, certificados SSL
  • Integración de Visual Studio
  • Soporte de Traffic Manager
  • Soporte de red virtual

Aquí hay una captura de pantalla que tomé del formulario de selección de la galería de sitios web: enter image description here

Creo que las aplicaciones web son una excelente forma de comenzar a usar rápidamente, donde puede pasar de recursos compartidos a reservados. Una vez que supere esto, puede pasar a Roles web y expandir según lo necesite.

EDIT 2014: Por lo que vale, mucha de la información en esta respuesta ya no es correcta – ver comentarios.

Agregue más a la respuesta de @David:

Con los sitios web de Windows Azure, no tiene control sobre IIS o el servidor web porque está utilizando una porción de recursos junto con cientos de otros sitios web en la misma máquina, está compartiendo recursos como cualquier otro, por lo que no hay control sobre IIS.

La gran diferencia entre un sitio web compartido y el rol web de Azure es que un sitio web se considera vinculado al proceso mientras que los roles están vinculados a VM.

Los sitios web se almacenan en un contenido compartido al que se puede acceder desde todos los “servidores web” de la granja de servidores, por lo que no se requiere replicación ni nada de eso.

Los sitios web de Windows Azure no pueden tener su propio nombre de host, en su lugar deben usar websitename .azurewebsites.net y puede usar la configuración CNAME en su proveedor de DNS para enrutar su solicitud exactamente igual que con Windows Azure Role anterior solo cuando se ejecutan en modo reservado. . La configuración CNAME no es compatible con sitios web compartidos.

Acabo de publicar una publicación integral del blog sobre este mismo tema en http://robdmoore.id.au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/ .

Un extracto de mi conclusión: si necesita una enorme escala, SSL, centros de datos asiáticos u occidentales, una configuración no estándar (de IIS, puertos, diagnósticos, certificaciones de seguridad o scripts de inicio), RDP o Roles de trabajo rentables ( combinado con su rol web), entonces tendrá que apegarse a funciones web por ahora.

¡De lo contrario, los sitios web son una gran opción!

Azure Web Role es como un host privado virtual. Obtiene una VM que actúa como su servidor web, y usted es dueño de esa instancia de VM.

Los sitios web de Azure son como un servicio de alojamiento compartido elástico. Implementa su aplicación en un servidor web que no está controlado por usted y que también sirve servidores de otros sitios de usuarios. Puede escalar su sitio hacia arriba y hacia abajo (con un cargo adicional) para que sea más elástico a medida que cambian sus necesidades de recursos.

Hay un escenario más que está por el air: después de eliminar estas 500 excepciones, no han dicho nada acerca de la capacidad de Azure Websites para manejar comodines CNAME. Varios de nosotros estamos usando el acelerador de roles web de Nate en servicios en la nube, ya que el software de Nate ofrece una función de subdominio de comodín de hackeo de una sola línea. No podemos mover estas aplicaciones de subdominio comodín hasta que sepamos que Azure Websites podrá manejarlas. Si nunca será capaz de hacer eso, se considerará positivo en el lado del papel web de la ecuación. También es importante señalar que, con los precios exactamente iguales (después de que caduque el descuento de la vista previa), no estoy seguro de querer renunciar a mi acceso a RDC y al Visor de eventos (solo por mencionar dos cosas).

Los sitios web Azure le permiten crear sitios web altamente escalables rápidamente en Azure. Puede usar Azure Portal o las herramientas de línea de comandos para configurar un sitio web con lenguajes populares como .NET, PHP, Node.js y Python. Los marcos admitidos ya están implementados y no requieren más pasos de instalación. La galería de sitios web de Azure contiene muchas aplicaciones de terceros, como Drupal y WordPress, así como marcos de desarrollo como Django y CakePHP. Después de crear un sitio, puede migrar un sitio web existente o crear un sitio web completamente nuevo. Sitios web elimina la necesidad de administrar el hardware físico, y también proporciona varias opciones de escala. Puede pasar de un modelo compartido de múltiples inquilinos a un modo estándar donde las máquinas dedicadas brindan servicio al tráfico entrante. Los sitios web también le permiten integrarse con otros servicios de Azure, como la base de datos SQL, el bus de servicio y el almacenamiento. Con la vista previa del SDK de Azure WebJobs, puede agregar procesamiento en segundo plano. En resumen, los sitios web de Azure facilitan el enfoque en el desarrollo de aplicaciones al admitir una amplia gama de idiomas, aplicaciones de código abierto y metodologías de implementación (FTP, Git, Web Deploy o TFS). Si no tiene requisitos especializados que requieran servicios en la nube o máquinas virtuales, un sitio web de Azure es probablemente la mejor opción.

Los servicios en la nube le permiten crear aplicaciones web escalables y de alta disponibilidad en un entorno rico en plataforma como servicio (PaaS). A diferencia de los sitios web, primero se crea un servicio en la nube en un entorno de desarrollo, como Visual Studio, antes de implementarlo en Azure. Los marcos, como PHP, requieren pasos de implementación personalizados o tareas que instalen el marco en el inicio del rol. La principal ventaja de Cloud Services es la capacidad de admitir architectures multinivel más complejas. Un único servicio en la nube podría consistir en un rol web frontend y uno o más roles de trabajador. Cada nivel se puede escalar de forma independiente. También hay un mayor nivel de control sobre la infraestructura de su aplicación web. Por ejemplo, puede escritorio remoto en las máquinas que están ejecutando las instancias de rol. También puede crear scripts de IIS más avanzado y cambios en la configuración de la máquina que se ejecutan al inicio del rol, incluidas las tareas que requieren el control del administrador.

Las máquinas virtuales le permiten ejecutar aplicaciones web en máquinas virtuales en Azure. Esta capacidad también se conoce como Infraestructura como servicio (IaaS). Cree nuevas máquinas con Windows Server o Linux a través del portal, o cargue una imagen de máquina virtual existente. Las máquinas virtuales le brindan el mayor control sobre el sistema operativo, la configuración y el software y los servicios instalados. Esta es una buena opción para la migración rápida de aplicaciones web complejas en las instalaciones a la nube, ya que las máquinas se pueden mover como un todo. Con las redes virtuales, también puede conectar estas máquinas virtuales a las redes corporativas locales. Al igual que con Cloud Services, tiene acceso remoto a estas máquinas y la capacidad de realizar cambios de configuración a nivel administrativo. Sin embargo, a diferencia de los sitios web y los servicios en la nube, debe administrar las imágenes de la máquina virtual y la architecture de la aplicación por completo a nivel de infraestructura. Un ejemplo básico es que debe aplicar sus propios parches al sistema operativo.

Vea la comparación actualizada y completa de este enlace: http://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/

Los sitios web Azure, Web Workers y Virtual Machines son tres enfoques informáticos diferentes disponibles en Windows Azure. Difieren en el nivel de control y responsabilidades:

  • El sitio web de Azure tiene el nivel de control más bajo, pero no le importa mantener la máquina virtual de salud y IIS, porque las cosas de Azure lo hacen por usted
  • Las funciones web le brindan más control (administrador de tráfico, escritorio remoto), pero es posible que haya más administración de su parte, lo que significa que puede romper algo a través de un escritorio remoto, por ejemplo.
  • Virtual Machines le brinda control total de VM, por lo que requiere la mayor cantidad de esfuerzos de administración.

No hay una mejor opción, porque depende del nivel de control que necesita, de las características que necesita y de las cosas que desea dejar en Azure para mantener. Y es un gran tema …

Mire estos artículos para obtener más información para tomar una decisión más informada:

Todo se reduce a la compensación entre la facilidad de uso y las capacidades.

Dos cosas más que encontré fueron el costo de obtener SSL para un sitio de dominio personalizado y configuraciones Multi-tenant.

Para el sitio web, debe pagar mensualmente sobre la instancia estándar (la instancia pequeña es la opción más económica). Esto significa que para obtener un dominio personalizado, https le costaría ~ 70 / mes para una instancia pequeña más ~ 41 / mes para SSL que es compatible con todos los navegadores.

Para WebRole puede obtener instancias XS y agregar su propio SSL de forma gratuita, lo que significa ~ $ 15 por mes y tiene un dominio personalizado con SSL.

Para el sitio web de varios inquilinos echa un vistazo al comodín dynamic de Azure multi-inquilino CName

Un rol web es una máquina virtual que aloja varios sitios web

Esta es una pregunta común, y me gustaría dar un extracto de msdn.

Acceso a servicios como almacenamiento en caché, bus de servicio, almacenamiento, base de datos SQL Azure- Sitio web: sí WebRole: sí

Soporte para ASP.NET, ASP clásico, Node.js, PHP-Sitio web: Sí WebRole: Sí

Contenido y configuración compartidos – Sitio web: Sí WebRole: No

Implementar código con GIT, FTP-Sitio web: Sí WebRole: No

Instalación casi instantánea-Sitio web: Sí WebRole: No

Soporte-de MySQL-como-un-servicio integrado-Sitio web: Sí WebRole: Sí

Múltiples entornos de despliegue (producción y puesta en escena) -WebSite: Sin WebRole: Sí

Aislamiento de red-Sitio web: Sin WebRole: Sí

Acceso de escritorio remoto a servidores-Sitio web: Sin WebRole: Sí

Posibilidad de ejecutar progtwigs con permisos elevados-Sitio web: Sin WebRole: Sí

Posibilidad de definir / ejecutar tareas de puesta en marcha-Sitio web: Sin WebRole: Sí

Posibilidad de utilizar marcos o bibliotecas no compatibles: sitio web: sin WebRole: sí

Soporte para Windows Azure Connect / Windows Azure Network-WebSite: Sin WebRole: Sí

Para obtener más detalles, visite este enlace: http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to -use-which.aspx