¿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? ¿Por qué razón elegiría un "sitio web" en lugar de un "rol web" o viceversa?

Supongamos que necesitaría la misma capacidad en cualquier caso (por ejemplo, 2 instancias pequeñas). Los precios parecen comparables además del hecho de que hay un descuento temporal del 33% para los sitios web mientras están en su período de vista previa.

¿Hay cosas que puedo hacer con un "sitio web" que sean difíciles o imposibles con un rol web? Por ejemplo, ¿se vuelve fácil poner múltiples sitios web en un solo conjunto de máquinas virtuales usando "sitios web"? ¿Pierdo algo con un "sitio web" frente a un "rol web"? Capacidad para ajustar IIS? Posibilidad de utilizar el servicio de caché localmente?

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

• Capacidad para ejecutar scripts de inicio elevados para instalar aplicaciones, modificar la configuración del registro, instalar contadores de rendimiento, ajustar IIS, etc.
• Capacidad para dividir una aplicación en niveles (tal vez Rol web para front-end, Rol de trabajador para procesamiento de back-end) y escalar de forma independiente
• Capacidad para RDP en su VM con 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 de 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)

Sin embargo, las aplicaciones web tienen ventajas sobre los roles web:

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

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

• Staging + ranuras de producción
• 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:

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

EDITAR 2014: por lo que vale, gran parte de la información en esta respuesta ya no es correcta; vea los 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 recurso compartido de contenido al que se puede acceder desde todos los "servidores web" de la granja, por lo que no se requiere replicación ni nada similar.

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

Acabo de publicar una publicación de blog completa sobre este 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 centros de datos de gran escala, SSL, Asia u Oeste de EE. UU., Una configuración no estándar (de IIS, puertos, diagnósticos, certificados de seguridad o scripts de inicio), RDP o roles de trabajo rentables ( combinado con su rol web), entonces tendrá que atenerse a los roles web por ahora.

De lo contrario, los sitios web son una excelente opción.

Azure Web Role es como un host privado virtual. Obtiene una VM que actúa como su servidor web y es el propietario de esa instancia de VM.

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

Hay un escenario más en el aire: después de que se eliminan estas 500 excepciones, no han dicho nada sobre la capacidad de los sitios web de Azure para manejar los comodines CNAME. Varios de nosotros estamos utilizando Nate's Web Role Accelerator en Cloud Services, debido a que un hack de una línea proporcionó la capacidad de subdominio comodín en el software de Nate. No podemos mover estas aplicaciones de subdominio comodín hasta que sepamos que los sitios web de Azure podrán manejarlas. Si nunca será capaz de hacer eso, entonces baja como positivo en el lado del Rol Web de la ecuación. También es de destacar que, dado que los precios son exactamente los mismos (después de que caduca el descuento de vista previa), no estoy seguro de querer renunciar a mi acceso a RDC y al Visor de eventos (solo por mencionar dos cosas).

Sitios web de Azurele permite 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 compatibles 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. Los sitios web eliminan la necesidad de administrar el hardware físico y también ofrecen varias opciones de escala. Puede pasar de un modelo compartido de múltiples inquilinos a un modo estándar donde las máquinas dedicadas atienden el tráfico entrante. Los sitios web también le permiten integrarse con otros servicios de Azure, como Base de datos SQL, Bus de servicio y 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 requieren servicios en la nube o máquinas virtuales, lo más probable es que un sitio web de Azure sea la mejor opción.

Servicios en la nubele permite crear aplicaciones web escalables y de alta disponibilidad en un rico entorno de Plataforma como Servicio (PaaS). A diferencia de los sitios web, un servicio en la nube se crea primero en un entorno de desarrollo, como Visual Studio, antes de implementarse en Azure. Los marcos, como PHP, requieren pasos de implementación personalizados o tareas que instalen el marco al inicio del rol. La principal ventaja de Cloud Services es la capacidad de admitir arquitecturas 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 trabajo. 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 usar el escritorio remoto en las máquinas que ejecutan las instancias de rol.

Maquinas virtualesle permite 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 migrar rápidamente aplicaciones web complejas locales a la nube, ya que las máquinas se pueden mover como un todo. Con Virtual Networks, también puede conectar estas máquinas virtuales a redes corporativas locales. Al igual que con los servicios en la nube, 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 su máquina virtual y la arquitectura de la aplicación completamente a nivel de infraestructura. Un ejemplo básico es que debe aplicar sus propios parches al sistema operativo.

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

Los sitios web de Azure, los trabajadores web y las máquinas virtuales 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 en buen estado y el IIS, porque las cosas de Azure lo hacen por usted
• Los roles web le dan más control (administrador de tráfico, escritorio remoto), pero es posible una mayor administración de su lado, lo que significa que puede romper algo a través del 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, las características que necesita y qué desea dejar para mantener las cosas de Azure. Y es un gran tema ...

Consulte estos artículos para obtener más información y hacer una elección más informada:

• http://www.windowsazure.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/
• http://davidpallmann.blogspot.com/2012/06/reintroducing-windows-azure-part-2.html

Se reduce a un equilibrio entre facilidad de uso y capacidades.

Dos cosas más que encontré fue el costo de obtener SSL para un sitio de dominio personalizado y configuraciones de múltiples inquilinos.

Para el sitio web, debe pagar mensualmente además de la instancia estándar (la opción más barata es la instancia pequeña). 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 admite todos los navegadores.

Para WebRole, puede obtener una instancia de 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, consulte Comodín dinámico de Azure de inquilinos múltiples 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í Rol web: Sí

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

Contenido y configuración compartidos - Sitio web: Sí Rol web: No

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

Sitio web de implementación casi instantánea: Sí Rol Web: No

Sitio web de soporte integrado de MySQL como servicio: Sí WebRole: Sí

Múltiples entornos de implementación (producción y puesta en escena) -Sitio web: No WebRole: Sí

Sitio web de aislamiento de red: No Rol web: Sí

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

Capacidad para ejecutar programas con permisos elevados -Sitio web: No WebRole: Sí

Capacidad para definir / ejecutar tareas de inicio -Sitio web: No Rol web: Sí

Posibilidad de utilizar frameworks o bibliotecas no compatibles -Sitio web: No WebRole: Sí

Soporte para Windows Azure Connect / Windows Azure Network-WebSite: No 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