Un año entero de I+D PRISA

ImasD_PRISA_850

En febrero de 2016 se formalizó el departamento de investigación y desarrollo tecnológico de El País, un año entero lleno de innovación que pone a este medio en el mapa de la transformación con iniciativas que están en la vanguardia digital, tales como: HLS, Apple TV, Bots, Service Workers + HTTP/2, IPv6 y Docker. Vamos a hablar de ellas.

HLS

La primera fue fácil: intentar erradicar el Flash de nuestros vídeos. Justo cuando el New York Times publicó su artículo Flash-Free Video in 2016, nosotros ya estábamos trabajando en algo muy similar y tomando casi las mismas decisiones.

Nos centramos en dos posibles tecnologías:

HLS: con él conseguiríamos llegar a todos los móviles actuales e incluso a casi todos los de generaciones anteriores, a los principales navegadores de sobremesa, set-top boxes, etc; podríamos codificar en varias calidades; adaptar el bitrate de transmisión en función de la disponibilidad de ancho de banda; en el momento en que el usuario parase la reproducción, se pararía la transmisión; etc. ¿Problemas? Pues que no todos los navegadores lo soportan nativamente pero fue bastante fácil solucionarlo con la librería HLS.js.

DASH: la principal diferencia frente a HLS es que es un estándar internacional y, puestos a experimentar, vimos necesario probarlo. Además de esa ventaja, nos pareció muy interesante la posibilidad de distribuir vídeos con varios canales de audio que, por ejemplo, para Santillana es muy interesante. Sin embargo, encontramos un gran problema con su soporte, algo que ya suponíamos. Para empezar, ningún móvil parece soportarlo nativamente — o no lo encontramos en aquel momento — con lo que, aun con el uso de librerías como DASH.js, quedábamos muy por detrás del soporte de HLS y seguiría siendo necesario codificar en más de un formato.

Por supuesto, valoramos WebM pero, al igual que con el anterior, nos vimos más limitados en su soporte que con HLS.

1-xk2OA8BI4Ed-Mi0zk-3wTw

Por tanto, la elección fue centrarnos en HLS y ver si conseguíamos llegar a la práctica totalidad de los navegadores que nos visitaban usando su soporte nativo o mediante el uso de HLS.js. Se abrieron dos fases:

  • Ver qué habría que cambiar en los procesos de codificación, ya fueran internos o externos. En el primer caso, solucionamos con Bento4 MP4 & DASH Class Library, SDK and Tools. Integrando esas utilidades en nuestros flujos de conversión fuimos capaces de producir vídeos en formato HLS, con múltiples bitrates y varias resoluciones. En el segundo caso, era tarea del proveedor o CDN realizar esa última conversión.
  • Algo similar pero aplicado a los dos grandes reproductores que tenemos en PRISA: por un lado, el propio de la plataforma PEP y, por otro, el de TOP. Había que hacer cambios pero, en ambos casos, parecían razonables.

1-nWHNrC2J2eRdmv3rPlY4Dw

Por supuesto, todo ello tanto para vídeos enlatados (VoD) como para retransmisiones en directo.

1--glbO1JVEA_LttVRCqjNYg

A partir del momento en que quedó claro que la tarea era realizable, pasó a los equipos de desarrollo e integración y a sus colas de trabajo. Por ejemplo, la integración completa en el reproductor de PEP, como se puede ver en los dos ejemplos anteriores, fue muy rápida.

Apple TV

Esto fue una casualidad o, más bien, una curiosidad. Investigando nuevas interfaces, llegamos a tvOS Human Interface Guidelines y a About TVML Apps, de Apple. Básicamente, nos picamos :-). Nos pareció tan fácil crear una aplicación usando [like-] HTML y JS, que nos pusimos a ello:

  • Modificamos las plantillas de los ejemplos para adaptarlas mejor a nuestras necesidades.
  • Diseño nos ayudó con el CSS necesario para que aquello se viese bien.
  • Nos enganchamos en los flujos de publicación de EL PAÍS y de AS
  • ¡Toooma! Lo teníamos :-).

¿A partir de ahí? Se nos echó el verano encima y lo más complicado fue conseguir que las redacciones correspondientes decidiesen qué contenido publicar pero nuestro trabajo ya estaba hecho. Siguiente.

P.S.: si tienes un Apple TV y quieres la App, hay mucha más información aquí o podéis buscarla en la Tienda de Apple de vuestra TV.

Bots

Como comentábamos en el punto anterior, la investigación de nuevas interfaces — que nos hizo pasar por la PoC anterior — nos llevó a meternos de cabeza con los Bots, algo que ha explotado este año pero que ha venido para quedarse.

Cuando comenzamos a bucear en ello, la mayoría de las plataformas todavía estaban muy poco evolucionadas (o directamente no existían), pero descubrimos que Slack contaba ya con un estupendo API, así que ya teníamos una plataforma con la que empezar. Además, dentro de EL PAÍS ya se usaba Slack, teníamos un grupo de betatesters a mano.

1-8_ZKcR5SgGrqm2saubxfbgComenzamos a construir servicios para alimentar al Bot alrededor de nuestro CMS, orientados fundamentalmente a la vigilancia de medios (tanto de la casa como externos). De este modo, lográbamos enviar notificaciones a los usuarios conectados a un canal de Slack cuando se produjesen cambios en portadas y portadillas, así como ante alertas informativas de última hora.

A finales de abril, el anuncio por parte de Facebook de la publicación de su API para bots en Messenger, nos dio la opción a hacer público y dotar de visibilidad al Bot. En este punto decidimos evolucionar en dos aspectos clave: el envío de información personalizada y la construcción de un interface próximo al lenguaje natural.

1.- SUSCRIPCIONES

Para permitir el envío de información personalizada a los usuarios, construimos un sistema de suscripciones junto a un motor que vigila el contenido que se genera o cambia en la Web. Hay tres tipos de suscripciones:

  • Última hora: alertas informativas.
  • Portadas y portadillas: cambios en las primeras noticias de la portada o de las portadillas de las secciones.
  • Temas y autores: publicación de nuevas noticias de los autores o temas que elijas.

Este último tipo de suscripción es el que abre unas posibilidades de personalización impresionantes: seguro que hay temas y autores que me interesan mucho y de los que me gustaría saber todo lo que se publica pero, en ocasiones, o no me entero de su publicación, o no siempre ese contenido está accesible de manera sencilla. Es un canal a explotar porque pocos como nosotros tienen tan “etiquetado” el contenido mediante el gigantesco Colabulario que PRISA — con EL PAÍS como punta de lanza — ha ido construyendo todos estos años alrededor de PEP y que ya acumula más de 100.000 etiquetas temáticas.

2. INTERFACE

El mayor reto en la construcción de un bot es lograr una interacción con el usuario mediante lenguaje natural (NLP). Teniendo claras nuestras limitaciones (por ejemplo, no podíamos asumir un año de desarrollo), nuestro objetivo era que pudiera reconocer frases complejas como esta:

1-uBX3AoNCteKdVMBQjv74CQ

Para conseguirlo, tuvimos que clasificar (según su intención) 10.000 verbos en castellano, integrarnos con Freeling para analizar el texto escrito por los usuarios e integrarnos también con el buscador de términos del Colabulario cargado previamente en Sphinx. Con todo ello, logramos que el Bot ‘comprenda’ que, con la frase anterior, nos interesa “Manuel Jabois”. El grado de comprensión alcanzado, pese a no ser perfecto, nos ha sorprendido incluso a nosotros mismos.

1-u_9zDlKpBPcxQDNZ5JA-IwUniendo estas dos piezas, ya teníamos la base sobre la que fuimos desarrollando todas las funcionalidades existentes. Durante estos meses, el Bot ha estado informando a una (todavía) pequeña masa de usuarios pero con un grado de aceptación y de continuidad entre los mismos excelente: más de un 40% de los mismos interactúa con el Bot a diario. Tiene lógica: le estás pidiendo que te avise cada vez que se publique algo sobre los temas que te interesan o de tus autores preferidos.

Por todo esto, se confirma que estamos ante un nuevo canal de comunicación con los usuarios que habrá que evolucionar y continuar explorando en un futuro, dotándole de una interacción más fluida con el usuario y de una mayor inteligencia. Además, los datos son sorprendentes: los temas o autores a los que se suscriben los usuarios están completamente fragmentados pero, al ser personales, tienen un índice de apertura muy alto. Hay gustos e intereses muy diferentes entre ellos, confirmando la utilidad de los robots como herramientas de envío de información absolutamente personalizada.

Service Workers + HTTP/2

La siguiente PoC se convirtió en dos por aquello de la interconexión entre ambas. La idea original era usar Service Workers para mejorar el rendimiento de nuestras páginas web pero, por el medio, tuvimos que lograr servir esas páginas mediante SSL y, como nos crecimos :), optamos por usar HTTP/2. ¿Resultado? Fantástico, pero vayamos por partes.

HTTP/2

Servir páginas mediante HTTP/2 no tiene mucho misterio (en nuestro caso, últimas versiones de NGINX + certificado de LetsEncrypt + Apache por detrás hablando HTTP/1.1) pero sí cuando tienes años y años de hemeroteca y varios millones de páginas por detrás. Además, hay que olvidarse de muchos de los trucos que hemos usado durante años para servir en HTTP/1.1.

Con el servidor ya funcionando, lo que construimos fue un proxy en HHVM (basado en miniProxy) con el que logramos servir todo EL PAÍS desde un único dominio y, gracias al NGINX, hablando HTTP/2. La ganancia de rendimiento es significativa y — aunque a nuestro modo de ver un poco interesada — se puede resumir en la siguiente comparativa de Cloudflare.

1-kgHTndKKCK7YSJxgv-Zcww

SERVICE WORKERS

Con la parte de SSL solucionada, empezamos con la prueba que realmente queríamos hacer: usar Service Workers (SW) para mejorar el rendimiento de la página de EL PAÍS.

1-jrevGgGfssJdiMFNCLAhtA

Con los SW se pueden hacer cosas muy interesantes pero, en este punto, lo que nos interesaba era:

  • Son un PROXY, toda petición pasa por ellos.
  • Se programan mediante JavaScript y se ejecutan en un hilo separado dentro del navegador.
  • Se tiene acceso a la caché del navegador y a Indexed DB.

¿Problemas?

  • No están soportados por todos los navegadores pero, si sumamos los que sí lo soportan, en nuestro caso nos vamos a un 65–70% (aprox.).
  • Necesitan SSL pero eso ya quedó solucionado en el punto anterior.

Con eso en mente, la idea fue:

  • Construir una PoC que no modificase nada del producto/salida actual. Seguimos hablando de Elpais.com.
  • Si el navegador soporta SW, perfecto y se ganará rendimiento. Si no lo soporta, mala suerte y no habrá beneficio pero todo seguirá funcionado.

Los primeros resultados fueron impresionantes. Con una mala — malísima — conexión de GPRS la diferencia se dispara al cargar una noticia (sin publicidad):

1-JnDKfdgXtt5mTirdvUbJ3w

A partir de ahí nos fuimos a una comparativa mucho más real, con publicidad, y con distintos anchos de banda. La página cargada fue:

1-ZDQdikeyBf6IgPGJgYHyvA

Y los tiempos de carga dejan más que claro la ventaja de usar los SW:

1-f9sp2V_H6zaIa5RzajxOiA

Como se ve, incluso con la mejor conectividad, la carga directa es casi un 9% más lenta que usando el SW. Impresionante para una página ya optimizada de por sí.

DEL MOBILE FIRST AL OFFLINE FIRST: ¿VAMOS HACIA LAS WEBAPPS?

Parece que este nuevo “mantra” nos sugiere que deberíamos tener la posibilidad de acceder a cierto contenido en situaciones donde no tenemos conexión. A estas alturas, donde todo dispositivo está hiperconectado, ¿nos hemos vuelto locos? No tanto. Hay multitud de ocasiones donde la conectividad no es la que nos gustaría: aviones (el servicio de WiFi de algunas compañías no es tan bueno como lo pintan), en el metro o en el tren o, simplemente, queremos tener el contenido descargado previamente porque no queremos consumir nuestra tarifa de datos. Con Service Workers es posible: podemos precachear el contenido de nuestra Web para consultarlo cuando estamos offline. Somos capaces de detectar cuándo cambia la conectividad del dispositivo para comprobar si hay nuevo contenido disponible y descargarlo (por ejemplo, únicamente cuando estemos conectados a través de una WiFi) a nuestro terminal. De nuevo, el resultado de la PoC fue sorprendentemente bueno :).

Con Service Workers también podemos gestionar y aplicar inteligencia a las notificaciones push. Somos capaces de capturar las notificaciones que vayan dirigidas a nuestra web y decidir qué hacer con ellas: mostrarlas, ignorarlas si se reciben a una hora inapropiada, acumularlas, etc.

Teniendo en cuenta todo lo anterior, ¿todo esto no se va pareciendo mucho a lo que puede llegar a hacer una aplicación nativa y que les hacía tan necesarias frente a la web clásica? Además, los navegadores poco a poco van teniendo acceso al hardware del teléfono. Ya hay disponibles APIs que controlan la cámara, el micrófono, el sensor de luz, el estado de la batería o de la conectividad, la vibración. Entonces, ¿podemos llegar a sustituir las aplicaciones nativas por aplicaciones web? El usuario cada vez es más perezoso y reticente a instalar aplicaciones en el móvil. Además, internamente, evitamos duplicar desarrollos… Así que, directamente y sin complejos, nos preguntamos: ¿Es realmente es necesaria una aplicación nativa para EL PAÍS?

Todavía queda camino para lograrlo, sobre todo porque falta soporte en ciertas plataformas críticas (¡Vamos Apple!), pero a día de hoy el camino está bastante claro.

IPv6

Quien lleve en esto varios años, seguro que ha oído hablar de que las direcciones de Internet se estaban acabando… y el hecho es que los RIRs las han agotado. Es de verdad, la direcciones IPv4 se han acabado y en breve nos veremos abocados a implementar IPv6 sí o sí.

Como hace años y años — en una vida pasada :) — ya nos habíamos metido con el IPv6, pensamos que (1) todo se habría estandarizado mucho más y (2) que deberíamos dar un paso más allá e implementar una red completa dual-stack.

Al igual que pasa con IPv4, Ediciones EL PAÍS hace años que tiene asignado un PI de IPv6 (un /48) y nuestros routers tienen visibilidad completa de la red global IPv6 por BGP. Por tanto, la base estaba puesta. A partir de ahí construimos algo como:

1-u4g_Q3kk93yqLNUlYewmaw

Por partes:

  • Aislamos una red, la de I+D, del resto de las del Grupo.
  • Nuestra conexión con el resto del mundo, ya sea interno o externo, es mediante un router + firewall con Debian (tostrozo). Sus rutas son estáticas.
  • La red de I+D usa NAT para IPv4 y tiene direccionamiento público para IPv6.
  • Miedo: nuestros equipos tendrían direccionamiento público por lo que el papel del firewall es muy importante para cortar cualquier problema.

MONTAJE

Básicamente montamos un PoP completo: BIND, ISC DHCP, Postfix, Dovecot, NTP, NGINX, HHVM, etc. Todos ellos soportan bastante bien IPv6 con lo que no hubo grandes problemas.

Hay que tener cuidado con la reglas del firewall porque ciertos servicios los dan las máquinas que hay por detrás y estos son directos en IPv6 (o sea, si pepino01 lo da, es su propio puerto de IPv6) pero no en IPv4 (donde realmente será una redirección desde el puerto real de tostrozo). Con eso en mente, es solo tener cuidado.

Sí hemos tenido problemas con la asignación de direcciones en IPv6 y, sinceramente, creemos que es un tema que aún está abierto y no preparado para el mercado real. Básicamente hay tres forma de trabajar:

  • RADVD: todo se autoconfigura y se usa RDNSS y DNSSL para asignar servidores de DNS y dominios en los que buscar, respectivamente.
  • RADVD + DHCP Stateless: en este modo el RADVD permite que las máquinas se autoconfiguren su IPv6 y el DHCP da el resto de información (servidores NTP, DNS, dominios, etc.), siendo mucho más amplias — y reales — las posibilidades de configuración
  • RADVD + DHCP Stateful: el RADVD anuncia el router y el DHCP pasa a ser el responsable del resto de configuración.

Tras unas pruebas iniciales con la primera opción, optamos por la tercera. Creíamos — y seguimos creyendo — que la tercera opción es la que más flexibilidad te da: ¿que quieres asignar a ciertas máquinas IPs concretas? Puedes ¿Que otras son libres? Puedes. Tienes, como en IPv4, todo el control de lo que quieres hacer. ¿Problema? Android no soporta DHCPv6 y no todas las versiones de Windows lo hacen con RDNSS. Lo de Android, por mucho que lo expliquen, no es serio y está complicándolo todo. Por tanto, por ahora estamos con la segunda opción aunque este escenario no sería realista para una extensión completa por una gran red como la de PRISA.

Resumen: actualmente nuestra red, la de I+D, es una red dual-stack en la que todos los servicios que vamos levantando sirven tanto por IPv4, como por IPv6. Salvo por el problema del DHCP, que no es ni mucho menos despreciable (porque también hay problemas con la redundancia), todo parece funcionar bien. Incluso funciona perfectamente dar direcciones IPv6 desde OpenVPN y encaminar todo su tráfico para que tengan visibilidad IPv6 en sus máquinas IPv4. Al igual que antes, mucho cuidado porque las IPs vuelven a ser públicas y debes protegerte adecuadamente.

Lo que sí está claro es que IPv6 es una realidad y cada vez son menos las excusas para no soportarlo.

Docker-izando todo

Nuestra última obsesión: ¿podríamos meter en contenedores una plataforma completa como PEP? PEP es la plataforma que soporta los grandes medios de PRISA (EL PAÍS, AS, Cinco Días, Cadena SER, Los 40, Radio Caracol, etc.). Si así fuese, podríamos dar un paso mucho más allá de la virtualización y, en general, sería mucho más simple desplegar [nuevas] aplicaciones, desarrollar, probar, mantener, operar y, todo ello, en cualquier sitio físico o virtual.

Docker, y el concepto de contenedores en general, no es nuevo pero sí lo es lo que estamos intentando hacer con él.

¿QUÉ ES DOCKER?

La primera pregunta es la de siempre: “O sea, otra forma de virtualizar, ¿no?” Pues no, es un paso más allá y una simple imagen lo resume perfectamente. Comparemos qué necesita un chalet y un piso para no hablar del kernel a la primera de cambio:

1-Vyt7vRirnPHfresM4W6RZA

En una casa individual, al igual que en una máquina física/virtual, debes gestionar tus propios recursos: tu acometida de agua, tu acometida de gas, de alcantarillado, tu antena de TV, etc. En un piso, como en un Docker, tienes muchos de esos recursos compartidos y gestionados de manera global. Ahora que el concepto está claro, algo mucho más técnico…

1-y3LsWKs69gw_6gJfzKCBiQ

… donde ese matiz de, por ejemplo, no tener un sistema operativo entero, marca una diferencia de simplicidad y rendimiento muy importante.

PRUEBAS DE RENDIMIENTO

Aun así, presuponiendo que todo debería ir bien, lo primero que hicimos fue probar el rendimiento que daba una máquina física (con NGINX + HHVM) y eso mismo — en esa misma máquina — pero metido en un Docker:

1-hJdS_LPHC-WPYyy6pi_HjQ

La prueba, que fue un poco más extensa, no pretendía probar el NGINX, ni el HHVM, ni el PHP7, ni enfrentarlos entre ellos. Lo que queríamos medir era si un entorno Web, con rendimiento salvaje, daría unos números muy similares cuando estuviese enclaustrado en un contenedor. Claramente, sí que lo da en modo “net host” y no cuando se hace mapeo de puertos del Docker a la máquina virtual. Por tanto, debíamos usar el modo “net host” que, por otro lado, nos limitará a futuro el uso de soluciones como Swarm.

A partir de ese punto, ya teníamos claro que Docker nos debería servir y empezamos a hacer pruebas con nuestro entorno de producción real. El resumen vuelve a ser que el rendimiento es igual corriendo los servidores en una máquina nativamente que cuando estos se ejecutan dentro de un contenedor:

1-rixcvPASCHDjmEg7Vfppsw

¿EN QUÉ PUNTO ESTAMOS?

Avanzando en varios frentes:

  • Definiendo qué contenedores deberíamos crear. La gran discusión interna es hasta qué punto construirlos por “servicios en su conjunto” o construirlos “por servidores”. Al final, no será blanco/negro y seguro que llegamos a un punto intermedio o de compromiso.
  • Probando la orquestación y el autodescubrimiento con Swarm y Consul. Aunque como comentamos antes no podremos usar Swarm cuando queramos un rendimiento extremo, para otras partes de la plataforma parece muy interesante y necesario su uso.
  • Viendo cómo gestionar las actualizaciones de configuraciones: integradas en el contenedor, mediante Git, despliegues tradicionales estilo DevOps (estilo Puppet, Ansible o Chef), etc.

El resumen sería que Docker nos ha sorprendido muy gratamente y que, salvo algo grave que descubramos en las próximas semanas, podría ser la base para construir una plataforma completamente desacoplada de dónde y qué se corra por debajo.

Como veis, año intenso y muy interesante. Nos hemos metido en varias cosas  — que podremos contar más adelante — pero, sobre todo, nos hemos dejado otras muchas en la recámara — más de las que quisiéramos — y con las que nos gustaría haber empezado a trastear. ¿Un ejemplo? Estamos locos por empezar a experimentar con Machine Learning pero, desafortunadamente, aún no nos ha dado tiempo :-(. Será para este año.


Raúl Rivero

Director de I+D en PRISA

Deja un comentario

MENU
Leer entrada anterior
Grandes_Profes_2017
La competencia digital y la transformación personal, protagonistas de ¡Grandes Profes! 2017

Más de 1.500 profesores de toda España asisten en directo al encuentro ¡Grandes Profes! 2017, el evento educativo organizado por...

Cerrar