Azure Media Services Explorer

Azure Media Services Explorer es una herramienta esencial para la gente que trabaja con Azure Media Services. Actualmente, para poder administrar los Azure Media Services seguimos obligados a utilizar el antiguo portal de administración de Azure, y además no hay muchas opciones precisamente. Muchas de las posibilidades y características que ofrece este servicio solo pueden accederse a través de código en la mayoría de las ocasiones. Para un usuario con perfil de desarrollador esta puede ser una opción válida, pero desde luego no es la más óptima en cualquier caso. Y, de hecho, un usuario sin habilidades técnicas de desarrollo no puede acceder a estas opciones. Además, el nuevo portal de administración de Azure no ofrece información sobre las nuevas características que proporcionará para Azure Media Services ni de cuándo estarán disponibles.


Es por ello que el equipo de producto de Azure Media Services creó hace más de un año una herramienta que proporciona una interfaz de usuario para gestionar este servicio: Azure Media Services Explorer. Esta herramienta es completamente gratuita y de código abierto y está disponible a través de GitHub. Ofrece características que permiten:

  • Gestionar, subir y descargar assets
  • Procesar assets (codificar, claves, thumbnails y progreso de trabajos entre otras características)
  • Streaming (gestión de canales y reproducción)
  • Publicar assets (gestionar locators y encriptación dinámica entre otras características)
  • Informes (información detallada de assets entre otras características)


Puedes encontrar una lista más detallada de características de Azure Media Services y un ejemplo de uso con pantallazos en el siguiente post del blog oficial de Azure: http://azure.microsoft.com/blog/2014/10/08/managing-media-workflows-with-the-new-azure-media-services-explorer-tool Si tienes que trabajar con Azure Media Services, ¡seguro que agradeces conocer esta herramienta! ¡Espero que te facilite tanto tu trabajo diario como me lo ha facilitado a mí!

iPaaS–Logic Apps

Si hablamos de integración en un ámbito de tecnología Microsoft, uno de los primeros productos que nos viene a la cabeza es BizTalk Server. Este es un producto muy potente pero que necesita de un periodo de aprendizaje considerable antes de que se pueda empezar a ser productivo. Una vez que aprendes lo suficiente sobre BizTalk te das cuenta de las enormes posibilidades que este producto tiene, así como de todo el ecosistema de adaptadores creados en torno a el, que nos permite integrarnos con la mayoría de los servicios o aplicaciones de línea de negocio existentes, pero debido al coste del producto y de la formación o contratación de un consultor especializado, las empresas suelen optar en ciertos casos por realizar desarrollos a medida para llevar a cabo la integración entre sus sistemas.

Dependiendo del tipo de integración, estos desarrollos a medida muchas veces resultan más caros y difíciles de mantener que lo estimado inicialmente. Aquí es donde surge iPaaS (Integration Platform as a Service), que no es otra cosa que una serie de servicios en la nube que nos facilitan las tareas de integración con otros servicios en la nube u on-premises. Si nos centramos en Azure, Microsoft utiliza Bizalk Services como base de su plataforma de integración.

Logic Apps

Microsoft en un intento de democratizar la integración de aplicaciones y permitir que de una forma fácil podamos automatizar nuestros procesos de negocio, ha creado Logic Apps apoyándose en los servicios que proporciona BizTalk Services.

image

Con Logic Apps podemos, de forma gráfica y sencilla, diseñar nuestros procesos de negocio aprovechando el gran número de conectores que forman parte de la plataforma, aparte de crear los nuestros propios si fuera necesario. A continuación podemos ver un listado de los conectores que podemos encontrar out of the box:

Logic Apps connectors

Logic Apps nos permite implementar flujos de trabajo que se ejecuten de forma recurrente o que se inicien como resultado de un evento como por ejemplo la llegada de un correo, un nuevo archivo o un nuevo registro en una tabla de Azure Storage.

Cada uno de los pasos del flujo de trabajo recibe el nombre de Acción y cada acción suele ser una operación de un conector o de una API App (hablaremos de esto más adelante).

Entre la lista de conectores podemos encontrar a BizTalk Services para casos de integración avanzados, donde necesitemos transformaciones de esquemas, validaciones o procesamiento de reglas de negocio.

Un ejemplo podría ser la implementación de un flujo de trabajo que realice una búsqueda cada x minutos en Twitter, sobre un nuevo producto que acabamos de lanzar par ver la opinión de la gente. Cada uno de los Tweets los podemos guardar en una tabla de Azure Storage para analizarlos posteriormente.

Ejemplo de proceso de negocio impementado con Logic apps

En nuestro caso vamos a implementar un flujo de trabajo para la gestión automatizada de peticiones de vacaciones. Monitorizaremos el buzón de correo de solicitud de vacaciones y por cada una de las peticiones recibidas se desencadenará un flujo de aprobación.

Flujo de Aprobación

  • Cuando creamos una nueva Logic App en caso de que no hayamos creado aun un nuevo plan de servicio podremos realizarlo en el mismo paso.

image En esta pantalla deberemos introducir el nombre de la Logic App que estamos creando, así como del App Service Plan. Para el App Service Plan debemos seleccionar el tipo (Standard, Basic, Premium), el Grupo de Recursos, y la Localización del  datacenter de Azure donde queremos crearlo. El Grupo de Recursos que seleccionemos es importante porque en el caso de que creemos nuevos conectores debemos desplegarlos en este Grupo de Recursos para que estén disponibles. Además todos los conectores dentro del mismo Grupo de Recursos compartirán la misma configuración.

  • Una vez creada la Logic App podremos empezar a trabajar con el diseñador para crear nuestro flujo de aprobación:

image

  • En la lista de conectores seleccionamos el conector POP3, el cual configuraremos con los parámetros de la cuenta a monitorizar (nombre de usuario, password, servidor pop3 y puerto).

image

  • Una vez configurado el conector podemos seleccionar la operación que más nos interesa, en nuestro caso seleccionaremos la operación Get Email, ya que lo que nos interesa es obtener cada uno de los correos que lleguen a la cuenta de solicitudes (por ejemplo vacaciones@miempresa.com) para que se inicie el flujo de trabajo. Get Email recibe como parámetro la frecuencia con la que queremos que se ejecute, en este caso para propósitos de depuración podemos seleccionar como frecuencia 1 Minuto.
  • Debemos ver el flujo de trabajo de las Logic Apps como una tubería donde la salida de un conector es la entrada del siguiente y donde hasta que no finaliza el conector anterior no se ejecuta el siguiente.
  • A continuación añadimos un nuevo conector al que pasaremos como parámetro la información del correo recibido por el conector POP3. En este caso vamos a guardar la solicitud recibida en una lista de O365, que usaremos como repositorio de solicitud de vacaciones. Para ello hacemos click en SharePoint Online Connector.

image

En este conector especificamos la url del sitio donde se encuentra la lista en la que queremos almacenar la solicitud y la URL relativa de la lista. Si nuestra lista se llama PeticionVacaciones el formato de la url relativa es Lists/PeticionVacaciones. Como antes, una vez que hemos configurado el conector ya podemos seleccionar de la lista de operaciones disponibles aquella que más nos interese. En este caso selecionamos Insert Into peticionvacaciones.

image

Si hacemos click en el botón “…” en el campo Título, obtendremos un listado de los campos que nos proporciona el conector de correo. El campo título del elemento de la lista queremos que contenga lo que el solicitante haya escrito en el Subject del correo, asi que en este caso seleccionamos Get Email Subject. Para el campo Solicitante seleccionamos Get Email From. En nuestro caso hemos creado un campo en la lista PeticionVacaciones al que hemos llamado Body, donde vamos a almacenar el contenido del email de la solicitud, así que seleccionaremos Get Email Body para insertar el contenido de la petición en dicho campo.Ya por último especificamos el estado de la solicitud, en nuestro caso será la cadena Denegado provisionalmente como estado inicial y en posteriores pasos del flujo de trabajo iremos modificando este estado dependiendo de ciertas reglas de negocio.

Si todo ha ido bien debemos tener el conector configurado de la siguiente forma:

image

Una vez que grabemos nuestro flujo de trabajo, este empezará a ejecutarse y podremos comprobar como cada minuto se obtendrá la lista de solicitudes del buzón de correo y se insertarán en la lista de SharePoint para un posterior procesamiento.

Continuará …

En un posterior post veremos como crear un conector personalizado con un API App que recibirá como parámetro el solicitante de las vacaciones así como la información de la solicitud. El conector personalizado después de aplicar las reglas de negocio necesarias devolverá como parámetros el estado de la solicitud (es decir si aprobamos o denegamos esta) y el responsable encargado de validar la petición. Con esta información actualizaremos la información en la lista de solicitud de vacaciones y enviaremos un email al responsable con un enlace al elemento de la lista como recordatorio de que tiene que aprobar dicha solicitud.

image

Azure Web Apps vs Cloud Services (I)

WebApps

Todos los que estamos involucrados en el desarrollo de aplicaciones sobre la plataforma Microsoft Azure hemos tenido en algún momento la duda de si es más optimo para nuestra aplicación el uso de Azure Web Apps (“Los Azure Web Sites de toda la vida”) o si por el contrario necesitamos usar Cloud Services (para esta entrada del blog no vamos a meter las máquinas virtuales en la ecuación). Si esa pregunta nos la hacíamos hace unos cuantos meses la respuesta era fácil, en la mayoría de los casos veíamos que era necesario el uso de Cloud Services, porque las funcionalidades de las Azure Web Apps no cubrían todas nuestras necesidades. Sin embargo las Azure Web Apps han evolucionado considerablemente y eso nos permite tenerlas muy en cuenta a la hora de diseñar la arquitectura de nuestra solución.

Esta entrada es la primera de una serie en la que se analizarán la funcionalidades que nos proporcionan ambas soluciones. En este post analizaremos las características tanto de las Azure Web Apps como de los Cloud Services desde los siguientes puntos de vista:

  • Despliegue: opciones de despliegue, continuous delivery, slots, Trafic routing.
  • Control: remote desktop, kudu, instalación de .msi personalizados, start-up tasks.
  • Escalabilidad: autoscaling y cambio de tipo de máquinas en caliente.
  • Gestión de trabajos: Worker Roles y WebJobs.

DESPLIEGUE

Continuous delivery
Continuous delivery

Tenemos varias formas de desplegar una Azure Web App así como de automatizar este proceso. Por ejemplo podemos configurar un proceso de despliegue continuo con repositorios como Visual Studio Online, BitBucket, DropBox o GitHub. Si has trabajado con Azure Web Apps verás que el despliegue es muy rápido y normalmente no suele llevar mas de un par de minutos.

Un Cloud Service sin embargo está mas limitado en cuanto a la forma de despliegue, ahora mismo si queremos usar “Continuous Delivery” solamente tenemos la opción de utilizar Visual Studio Online, bien usando el repositorio de TFSVC o de Git.

Tenemos una opción alternativa que yo únicamente utilizaría en un entorno de desarrollo,  que es la de desplegar nuestro código mediante WebDeploy a un Cloud Service. La limitación que tiene esta opción es que solamente se realizará el despliegue a una instancia con lo que si tenemos varias, tendremos que hacerlo en todas ellas.

Si nos fijamos en los Slots donde podemos desplegar nuestra aplicación, veremos que las Web Apps proporcionan mucha más funcionalidad que los Cloud Services:

  • En el caso de los Cloud Services tenemos un slot de producción y un slot de staging, los cuales en cualquier momento se puede intercambiar mediante la opción “Swap”. Así tenemos una opción bastante rápida para poder realizar pruebas antes de desplegar a producción una nueva versión.

En el caso de las Azure Web Apps tenemos el Slot de producción y podemos tener hasta 5 slots más en el caso del plan de servicio Standard y 1 slot más en el caso del plan de servicio Básico. Los slots son completamente funcionales y pueden ser utilizados simplemente añadiendo el nombre del slot a la url. Si la url de nuestra Web App es mitienda.azurewebsites.net y hemos creado un slot llamado testing, podemos acceder a este mediante la url mitienda-testing.azurewebsites.net.

Un escenario probable, es que ya hayamos probado nuestra aplicación y solamente queramos utilizar el slot de staging para evitar una caída de servicio en el despliegue. En este caso las Web Apps nos permiten realizar un Auto-Swap. Esto consiste en que cuando desplegamos al slot de staging, automáticamente se hace un swap a producción sin que tengamos que realizar ninguna acción manual.  Por defecto esta opción esta desactivada y la tenemos que activar:

autoswap

  • Por último vamos a reseñar una funcionalidad más que nos proporcionan las Web Apps llamada Trafic Routing. Esto nos permite realizar pruebas de tipo A/BImaginémonos que queremos desplegar una funcionalidad nueva, pero no estamos totalmente seguros de como va a impactar al rendimiento de nuestra aplicación, la aceptación por parte de los usuarios o el impacto en las ganancias en nuestra tienda online. En este caso podemos desplegar dicha funcionalidad en un slot y configurar dicho slot para que reciba el 30% del tráfico de nuestra aplicación y que el slot de producción reciba el 70% restante. De esta forma podremos realizar “pruebas en producción” sin impactar al total de los usuarios.

Enrutamiento web apps

CONTROL

Los Cloud Services nos proporcionan una mayor capacidad de control que las Web Apps, ya que nos permiten conectarnos directamente a la máquina por escritorio remoto y realizar cualquier operación que necesitemos con permisos de administrador. Sin embargo que no podamos conectarnos a la máquina por escritorio remoto no quiere decir que no tengamos ningún control sobre nuestra Web app. Para suplir esa carencia, tenemos una herramienta de diagnóstico y resolución de problemas llamada KUDU.

Para poder acceder a esta herramienta simplemente tenemos que navegar a la siguiente url https://webappname.scm.azurewebsites.net, siendo webappname el nombre de nuestra Web App y logarnos con el usuario de Deployment .

kudu

Vemos que la consola de Kudu nos permite realizar acciones como capturar un volcado de memoria, interactuar con los procesos de nuestro host o ejecutar comandos de powershell o de línea de comandos entre otras opciones. Esto es bastante útil sobre todo en caso de que se produzca alguna incidencia en nuestra aplicación y tengamos que investigar cual es la causa.

Un requisito que debemos tener en cuenta a la hora de decidirnos si usar Azure Web Apps o Cloud Services es la necesidad o no de instalar .msi personalizados o la ejecución de Start-up tasks que requieran privilegios elevados. En el caso de necesitar alguna de estas opciones tendremos que recurrir a los Cloud Services debido a que las Azure Web Apps no nos permite realizar operaciones que requieran de privilegios elevados.

En la siguiente url http://bit.ly/1FDy3Cx puedes ver un ejemplo de código de como ejecutar una Start-up task pero realmente como verás las posibilidades que tenemos son muy limitadas.

ESCALABILIDAD

Desde un punto de vista de escalabilidad tanto un Cloud Service como una Web App comparten la misma funcionalidad básica, permitiendo escalar automáticamente basándonos en unos parámetros previamente definidos como número de instancias mínimas y máximas o umbrales de CPU. Los Cloud Service nos permiten alguna opción mas como autoescalado basándonos en mensajes en colas pero que para un Web Site probablemente no sea necesario, estando más indicado para un Worker Role.

Los tipos de máquina soportados en un Azure Web App están limitados a Small, Medium y Large mientras que un Cloud Service soporta bastantes más tipos de máquina. Deberemos tener muy en cuenta esta restricción en caso de que nuestra solución tenga alguna necesidad especial que nos obligue a utilizar máquinas con una mayor capacidad de proceso o de memoria.

En este punto las Web Apps tienen una pequeña ventaja con respecto a los Cloud Services y es que no necesitamos redesplegar nuestra aplicación si decidimos cambiar de tamaño de máquina pudiéndose hacer en “caliente”.

Otra cosa que debemos tener en cuenta es que los Azure Web Apps por defecto usan afinidad de sesión, esto quiere decir que una vez que una instancia nos sirve una petición, siempre nos va a atender el mismo servidor todas las peticiones para la sesión actual. Una pregunta que nos puede venir a la cabeza es, bueno entonces puedo usar variables de sesiones en memoria sin preocuparme debido a que siempre me va a atender el mismo servidor. La respuesta es ni se te ocurra :). En el caso de que el servidor se caiga, automáticamente otro servidor empezará a servirte las peticiones con lo que habremos perdido todo el contenido almacenado en las variables de sesión en memoria. Yo personalmente recomiendo el uso de algún tipo de caché distribuida como por ejemplo Redis.

En el caso de que queramos deshabilitar la afinidad, simplemente tendremos que añadir lo siguiente al web.config:

stickysessions

GESTIÓN DE TRABAJOS

Hasta hace poco tiempo si queríamos ejecutar tareas en Azure que procesaran mensajes en una cola o que realizara tareas planificadas, la única opción que teníamos era usar Worker Roles. Ahora mismo asociados a las Azure Web Apps tenemos los WebJobs.

Algunos definen estos Web Jobs como una especie de Worker Role ligero donde se recomienda su uso para procesos que consuman pocos recursos.

Ya que seguramente los Worker Roles los conocemos mejor, permíteme que haga hincapié en algunas de las características de los WebJobs:

  • Los WebJobs en sí son gratis pero dependiendo del Scheduler seleccionado podemos tener coste. Debido a que consumen recursos del Web App donde esté alojado, debemos tener en cuenta la necesidad de procesamiento por si tenemos que escala esta Web App.
  • Trabajan con colas prácticamente sin necesidad de código.
  • Gestionan automáticamente los mensajes envenenados («poison messages»). Se reintenta el procesamiento del mensaje 5 veces.
  • Son capaces de ejecutar los siguientes tipos:
    • .EXE, assemblies complilados con el sdk de WebJob
    • .cmd, .bat
    • .sh (bash)
    • .py (python)
    • .js (node)

Como acabamos de ver, en el caso de que necesitemos realizar alguna tarea en background ya no es obligatorio el uso de los Worker Roles sino que podemos empezar a tener en cuenta a los WebJobs.


Hemos visto una pequeña pincelada de lo que tanto los Azure Web Apps como los Cloud Services nos ofrecen pero seguro que se te habrá pasado por la cabeza al leer este artículo «bueno todo esto está muy bien pero cual me da mejor rendimiento», la respuesta en el próximo post :).

Gracias por leernos.