Post invitado: "DNN Cloud Services: software + servicios sobre Windows Azure" por David Rodríguez

  • Article

Introducción

El pasado mes de Julio fue algo movido para la comunidad de usuarios de DNN, viendo por fin la luz el resultado de muchos meses de trabajo. Para los iniciados en la materia, DNN -anteriormente denominado “DotNetNuke”- es el mayor y más exitoso proyecto Open Source en el ecosistema Microsoft nacido en 2002, permitiendo la creación de sitios web de una forma sencilla, ágil y segura. Más de 700.000 sitios web y una comunidad de más de un millón de usuarios lo avalan.

Las novedades introducidas en la última versión 7.1 de DNN, así como los nuevos anuncios han dado bastante que hablar: un cambio de marca, donde DotNetNuke pasa a llamarse simplemente DNN; la versión Community pasa a denominarse DNN Platform mientras que la Professional ahora se denomina Evoq Content, incluyéndose en una nueva suite DNN Evoq que ahora también dispone de un nuevo producto Evoq Social; y finalmente, la presentación en sociedad de DNN Cloud Services, una plataforma desarrollada sobre Windows Azure para ofrecer la suite DNN Evoq en la nube.

El concepto de “software + servicios” (S + S) no es un concepto nuevo. Fundamentalmente, “Software + Services es todo acerca de cómo habilitar la mejor opción posible en computación, y es por eso que Microsoft y sus socios están invirtiendo en infraestructura, plataformas y servicios que permitan una experiencia de usuario sin fisuras a través de todos los dispositivos: desde los equipos en nuestros escritorios y los teléfonos móviles en nuestras manos a las pantallas gigantes en nuestras salas de estar y oficinas” (ver Microsoft Software Plus Services). Más que una forma de ofrecer software, se trata de una completa estrategia donde la nube es el siguiente paso lógico, visión que comparte DNN Corp.

En esta entrada me centraré en describir el conjunto de servicios que actualmente componen DNN Cloud Services así como su arquitectura, fruto del excelente trabajo del equipo Cloud de DNN para ofrecer su suite de productos DNN Evoq sobre la plataforma Windows Azure.

En ruta hacia la nube

A finales de 2010, surgió a través de la comunidad –me declaro culpable de ello- un proyecto Open Source denominado DNN Azure Accelerator para facilitar el despliegue del gestor de contenidos sobre la plataforma Windows Azure. Este proyecto, que ha ido evolucionando hasta ser parte fundamental de la suite DNN Evoq en la nube, permite desplegar de forma automatizada el gestor de contenidos sobre Azure Cloud Services (PaaS), usando para ello en su forma más simple un web role, almacenamiento para los contenidos y SQL Azure Database como base de datos. Cabe decir que este proyecto sigue y seguirá siendo Open Source para cualquiera que desee utilizarlo.

A través de los años siguientes, mientras se perfilaba la visión de DNN Cloud Services, uno de los principales caballos de batalla era la compatibilidad de DNN Platform con SQL Azure. Y aquí nació una de las primeras premisas en el equipo de producto de DNN: todo el código debe ser compatible con Azure, siendo la versión DNN 6.0 la primera en ofrecer esta compatibilidad, realizándose las correspondientes pruebas de integración antes de cada release.

Muy bien, pero solucionar los problemas de compatibilidad con SQL Azure en el núcleo de la plataforma no lo es todo, ya que la extensibilidad de DNN Platform permite que desarrolladores amplíen la funcionalidad de la misma. Prueba de ello son los miles apps disponibles en la DNN Store, así que para facilitar el trabajo a los desarrolladores se comenzó a trabajar en este sentido desde etapas muy tempranas. Fruto de ello es el EVS (Extension Verification Service) que incluye, entre muchas otras, una comprobación automatizada de la instalación y desinstalación de la extensión a verificar en un entorno real en Windows Azure. Puedes leer más sobre el funcionamiento de este servicio gratuito en esta entrada de la Wiki.

Perfecto, ya tenemos una solución que es compatible con Azure y una manera sencilla de desplegar nuestra plataforma en la nube, aprovechando los beneficios de la misma.

Pero en DNN queríamos ir mucho más allá. ¿Era la solución lo suficientemente sencilla para que alguien sin conocimientos de TI pudiera ponerla en marcha? ¿Podría esta persona realizar copias de seguridad de una forma sencilla? Incluso para una persona con conocimientos de TI, ¿cuánto tiempo tardaría en realizar estas tareas? ¿Qué pasa cuando sale una nueva versión? ¿Cuál es el método recomendado para actualizar?

Premisas para un servicio 10

Está claro que elegir una plataforma como Windows Azure aporta ya de sí muchas ventajas como la disponibilidad y seguridad de la misma, la geo-redundancia inherente, así como la mejor relación rendimiento/precio. Pero es que además ofrece unos servicios de plataforma de alto nivel que casaban a la perfección con lo que teníamos en mente, tales como SQL Azure Database, almacenamiento, Active Directory, Media, CDN o Mobile Apps. Mucha gente, cuando tratan de moverse a la nube, intenta reproducir exactamente el despliegue que tienen on-premise y comparar los costes “hardware” de una y otra solución, sin llegar siquiera a plantearse los beneficios adicionales que ésta aporta. A mí me gusta ver Windows Azure como un Lego con muchas piezas distintas para jugar, donde la combinación de las mismas te permite diseñar tu solución personalizada y escalar simplemente añadiendo más piezas. Una vez entendido esto, te permite ver Azure no como un conjunto de máquinas virtuales, sino como una completísima tienda de Lego donde poder construir una Estrella de la Muerte de última generación.

¿Qué solución queríamos ofrecer? La mejor, y estas fueron algunas de las premisas de la solución que queríamos construir:

  • Los usuarios tienen que poder probarla de forma gratuita: y cuando hablamos de usuarios, hablamos de cualquier usuario de negocio, no sólo personal de TI;
  • La puesta en marcha debe ser inmediata: hay que eliminar cualquier barrera de entrada, y la instalación es un proceso superfluo desde el punto de vista del usuario, que realmente no está interesado en ver cómo se instala el producto;
  • Copias de seguridad a varios niveles: no sólo las típicas copias programadas con políticas personalizables o copias bajo demanda, sino también la creación de puntos de restauración automáticos en eventos importantes del sistema como una actualización de la plataforma, quedando automáticamente restaurado en caso de fallo de la misma. Por supuesto, ya que los datos pertenecen al cliente, todas estas copias de seguridad debían estar disponibles para descarga, para su restauración on-premise o un off-boarding, con lo que el formato de estas copias deberían hacerse en un formato estándar de la industria;
  • Actualizaciones automáticas: las actualizaciones debían simplificarse al máximo, incluyendo la posibilidad de probar la actualización en un entorno de pruebas partiendo de un clon de producción. Además, el proceso debía incluir eventos de copias de seguridad automática para una eventual vuelta atrás automática en caso de fallo del mismo;
  • Acceso remoto: los usuarios deberían poder acceder directamente al sistema de ficheros del sitio a través de protocolos estándar;
  • Escalabilidad: no solo a nivel de tenant con múltiples instancias de web roles sirviendo sus sitios web, sino también a nivel de miles de despliegues de DNN para clientes a nivel mundial en distintas regiones además de miles versiones de prueba mensuales, usando la arquitectura que ofreciera la mejor relación de costes para cada tipo de despliegue;
  • Automatizada: al hablar de miles de despliegues, está claro que la automatización juega un papel principal para minimizar los costes y tiempos de respuesta. Todos los subsistemas deberían estar automatizados;
  • Costes adecuados: por supuesto, la solución final tenía que tener un balance positivo y si bien Windows Azure ofrece unos costes muy bajos gracias a las economías de escala en la nube, también se trataba de usar la pieza de Lego que mejor encaje, no solo en su forma, sino también en el color;
  • Que reine la simpleza: todos los servicios anteriormente descritos deben tener como máxima la simplicidad, eliminar todo lo superfluo para quedarnos con lo mejor.

El reto estaba servido, ahora tocaba divertirse implementándolo.

Diseñando la arquitectura

Diseñar una arquitectura que cumpla con todos los requerimientos descritos es en sí un proceso iterativo. La arquitectura a día de hoy es el resultado de un proceso que ha ido madurando a lo largo de más de año y medio, a través de iteraciones revisando continuamente la arquitectura y evaluando los resultados.

Con la visión de ofrecer una nueva y completa experiencia de usuario durante el periodo de evaluación, uno de los mayores retos fue dar con la arquitectura adecuada para permitirnos ofrecer versiones de evaluación de forma gratuita a un coste razonable. Si bien la arquitectura para la solución de pago sobre PaaS ofrecida por el DNN Azure Accelerator se adaptaba a los requerimientos, desplegar miles de máquinas virtuales para la versión de evaluación tenía un coste desproporcionado.

Había que buscar una solución, y la encontramos de la mano de Microsoft en lo que inicialmente se denominaba “Antares” y que finalmente tiene el nombre de Windows Azure Services for Windows Server. Por simplificar, lo que ofrece es la posibilidad de desplegar el mismo software que se utiliza en Windows Azure Websites en tu propio datacenter, de manera que puedes ofrecer una experiencia personalizada sobre un entorno de alojamiento de “alta densidad” a través de acceso programático mediante APIs de administración.

La principal ventaja de un entorno de alta densidad como el descrito, es que, basándote en la teoría de que hay un alto porcentaje de estos sitios que no están continuamente en uso, sus recursos pueden ser liberados tras un periodo de inactividad, lo que finalmente permite servir miles de sitios web en una misma infraestructura común. El segundo punto interesante es que puedes escalar añadiendo más o menos recursos según convenga, pudiendo ser estos también máquinas virtuales en sí mismo.

De este modo, la solución adoptada para el despliegue de las versiones de evaluación está basada en Windows Azure Services for Windows Server, desplegado en máquinas virtuales (IaaS) en Windows Azure, algo que podría verse como una nube dentro de otra nube (sí, como en la película “Inception”).

Por poner algunos números, normalmente hay sobre 1.000 sitios web de evaluación activos, habiéndose servido cerca de unos 20.000 desde el comienzo del proyecto.

Mismo software en on-premise que en cloud: bienvenido sea el Device

Una vez que tenemos definidos los distintos modelos de despliegue tanto para las trials como para las versiones completas de pago, con el objetivo de que los procesos de automatización sean capaces de desplegar el software siendo agnósticos en cuanto a la infraestructura subyacente, nacen los conceptos de “DeviceProvisioningProvider” y “DevicePool”, entendiendo por “Device” un despliegue de una instancia de DNN sea cual sea el medio.

El DeviceProvisioningProvider no es más que un interfaz que es implementado de forma personalizada para cada tipo de infraestructura subyacente. Así, a día de hoy, hemos implementado dos proveedores: uno para el despliegue en PaaS (conteniendo mayormente código existente en el DNN Azure Accelerator Wizard) y otro para las versiones de evaluación sobre Windows Azure Services for Windows Services.

Cada implementación especifica qué métodos soporta, como aprovisionar, desplegar, reiniciar, actualizar, etc. ya que determinadas funcionalidades pueden no estar disponibles en un determinado proveedor de infraestructura, como puede ser la no posibilidad de acceder mediante escritorio remoto a las versiones de evaluación ya que Azure Websites no lo permite en el modo de alta densidad, o el soporte de múltiples instancias de cómputo, opción que solo está disponible en la versión de pago.

Por otra parte, el concepto de DevicePool no es otro que el de tener un pool elástico de Devices listos para servir basado en tres variables: tipo de producto, idioma y ubicación geográfica. Cada pool contiene un número mínimo de Devices, de modo que cuando uno se asigna a un nuevo usuario, inmediatamente se encola un nuevo despliegue para volver a llenar el pool. Además del mínimo, también tiene configurado un máximo, de manera que dinámicamente, entre estos valores mínimo y máximo, se utilizan reglas de acción heurísticas para añadir unidades adicionales basándose en el consumo durante un periodo de tiempo determinado o eliminando exceso para ahorrar costes.

Estos conceptos van a facilitar cumplir con dos objetivos:

  • Maximizar la experiencia de usuario, eliminando las esperas para el despliegue inicial y dejando al usuario con sesión iniciada en su site personalizado (incluyendo hasta su nombre y apellidos como usuario host), gracias al DevicePool;
  • Minimizar los costes, ya que el nivel de abstracción del DeviceProvisioningProvider permite desplegar DNN Evoq en cualquier infraestructura subyacente, como puede ser un entorno de alta densidad, así como la adaptación dinámica de los pools dependiendo de la demanda en un periodo determinado de tiempo.

Orquestando e integrando

Por supuesto, la plataforma Cloud de DNN necesita comunicarse con sistemas externos, pasando por sistemas de como el CRM, el ERP o distintas automatizaciones de marketing, pero también con sistemas internos como son los propios worker roles encargados de procesar los mensajes encolados, el backend de DNN Cloud Services o la misma Cloud Control Bar que, gracias a la extensibilidad de DNN, permite realizar cualquier gestión desde el mismo Device cuando se ha iniciado sesión como super usuario.

La plataforma DNN Cloud está compuesta actualmente por cuatro worker roles que inician trabajos bajo petición, más un web role respondiendo a llamadas WebAPI, así como otro web role para el backend. Las peticiones procesadas por los worker roles son mensajes en colas de mensajería para garantizar la entrega y escalabilidad del sistema.

Las funcionalidades de cada uno de ellos son:

    • Deployment Worker: es el encargado de procesar mensajes dirigidos a un device en concreto. Las peticiones pueden ser: desplegar, actualizar, eliminar, reiniciar, etc. Gracias a la capa de abstracción del Provisioning Provider, puede comunicarse con los sistemas de infraestructura subyacentes;
    • Device Pool Worker: es el encargado de supervisar los pools, añadiendo y/o eliminando capacidad según el momento;
    • Backup Worker: es el encargado de procesar las peticiones de copias de seguridad, conectándose remotamente a los devices según está implementado en el Provisioning provider correspondiente;
    • Order Processing Worker: es el encargado de procesar las peticiones de asignación de Devices a los usuarios, comunicándose con los sistemas de facturación, CRM y Márketing
    • DNN Cloud WebAPI y backend: a través de llamadas WebAPI y un completo site de backend desarrollado bajo un patrón CQRS, todas las peticiones son encoladas y procesadas posteriormente por los workers anteriormente descritos.

Por supuesto, cada uno de estos subsistemas está desplegado en alta disponibilidad pudiendo escalar simplemente añadiendo más instancias de cómputo para procesar más mensajes por minuto o Web Requests por segundo.

Al final, como no nos bastaba con el backend, y ya que teníamos un WebAPI desarrollado, también terminamos desarrollando un conjunto de CmdLets de PowerShell para administrar desde línea de comandos lo mismo que el interfaz web de backend ofrece.

Extendiendo DNN en Azure

Otra de las principales características inherentes de DNN Platform es su extensibilidad, de manera que puedes instalar nuevos módulos incrementando la funcionalidad inicial, añadir Skins, modificar los sistemas de autenticación, etc.

Una de las características añadidas en DNN Evoq en Azure es la implementación de un nuevo Azure Caching Provider, que mejora enormemente el rendimiento, ya que sólo se almacena una copia de los objetos en una caché compartida, al contrario de otros proveedores de caché de DNN que normalmente mantienen una copia en memoria en cada instancia de una granja de servidores. Este proveedor utiliza la característica “InRole” cache, usando un porcentaje de memoria en los mismos servidores de la granja para alojar la misma. Si quieres saber más sobre esta característica visita esta página de la Wiki acerca del DNN Azure Caching Provider.

Otra de las características para mejorar y unificar la experiencia de usuario es la introducción de una Cloud Control Bar, que es una extensión de la Control Bar de DNN incluyendo un menú adicional con acceso directo a todos y cada uno de los servicios ofrecidos por DNN Cloud Services, como son los servicios de copias de seguridad, actualizaciones automáticas, etc.

El resultado

Finalmente llegamos al resultado que es lo que te animo a probar accediendo a una versión de prueba gratuita de Evoq Content o de Evoq Social. ¿Qué es lo que te vas a encontrar?

  • Instant On: en menos de 30 segundos, podrás acceder a tu versión de evaluación de DNN Evoq completamente instalada y personalizada hasta con tu nombre y apellidos. Los 30 segundos no son del despliegue de tu instancia ya que esta ya estaba pre-provisionada en los pools, sino el tiempo de personalización y precalentamiento de la instancia ya que entrarás en la misma incluso con la sesión iniciada;
  • Backup/Restore: en la versión de evaluación puedes acceder al interfaz de copias de seguridad que te permite tener hasta dos copias de seguridad personalizadas. En la versión completa del producto te encontrarás con otros dos tipos de backups: las copias de seguridad automáticas, con distintas políticas de retención, así como las copias de seguridad generadas por eventos del sistema, como los puntos automáticos de restauración en las actualizaciones automáticas. En todos los casos podrás descargar a local las copias de seguridad (incluyen el contenido del site en formato WebDeploy y la base de datos en formato .bacpac), o restaurar cualquiera de ellos tanto sobre el mismo site como en el entorno de pruebas –disponible en la versión completa de la solución.
  • Remote Access: en la versión completa de la solución podrás acceder al contenido remoto a través de varias opciones: escritorio remoto (RDP), ya que las máquinas virtuales que sirven tu site son exclusivas para ti, no se comparten; FTP para acceso al sistema de archivos mediante protocolo estándar; WebDeploy, para acceder a los contenidos a través de herramientas como WebMatrix o Visual Studio.
  • Entorno de producción y de pruebas: en la versión completa de la solución podrás optar a disponer de un entorno de pruebas para que puedas experimentar con un clon de tu site de producción, probar una actualización o hacer pruebas de rendimiento sin afectar a tu sitio en producción, ya que del mismo modo se usan máquinas virtuales distintas y dedicadas;
  • Actualización automáticas: cada vez que exista una actualización de DNN Evoq, aparecerá un icono para que procedas a instalarla cuándo y dónde prefieras: en tu entorno en producción o en el de pruebas. Durante este proceso se realizan copias de seguridad automáticas, antes de comenzar para que, si algo va mal, automáticamente deja tu sitio tal cual estaba antes de comenzar.
  • Soporte 24x7 y SLA: del mismo modo, la versión completa de la solución incluye soporte de los servicios en la nube de 24x7, así como un SLA del 99,9%

En este enlace puedes descargarte la hoja del producto Evoq en la nube.

Más información

Acerca del Autor

David Rodríguez es actualmente el ingeniero de software liderando el equipo Cloud de DNN, además del autor del proyecto open source DNN Azure Accelerator disponible en CodePlex. Con más de 15 años diseñando y desarrollando sistemas de alta disponibilidad, además es miembro del exclusivo grupo Windows Azure Insiders desde Febrero de 2013.

Puedes ponerte en contacto con él a través de su Twitter o su blog.