Problemas resueltos: conversaciones con los desarrolladores que construyen la Internet moderna | Vol. I, Spread Group

Martin Breest trabaja como Senior Software Architect en Spread Group, cliente de Fastly que agrupa varias marcas globales de retail online con servicio de impresión por encargo y con sede en Leipzig (Alemania). Nuestro Principal Developer Advocate, Andrew Betts, habló con Martin sobre cómo su equipo usa chatbots de forma creativa para ejecutar los comandos de Fastly, así como de su filosofía acerca de los errores y los retos que está deseando encarar para el próximo año.

Andrew: Una de las cosas que más me gusta de los clientes que usan Fastly de manera creativa es que nos dais otro punto de vista sobre nuestros productos, su finalidad y cómo los usan los clientes. Habéis hecho cosas muy interesantes en nuestra plataforma. Cuéntanos sobre el chatbot que creasteis y para qué lo usáis.

Martin: Seguramente se trata de nuestra mejor creación. El chatbot en sí mismo no es muy técnico, pero lo mejor es lo que se puede hacer con él: la capa de la CDN ya no es una caja negra o algo que hay que pedir a Operaciones que configure; ahora la puede tocar todo el mundo. 

De hecho, se me ocurrió la idea del chatbot durante la presentación de otro proveedor de CDN. Lo que pasaba era que resultaba difícil de implementar en nuestra CDN anterior, así que no hicimos nada al respecto. Y entonces llega Fastly y de repente tenemos todas las API disponibles, tenemos fragmentos dinámicos, podemos desplegar cambios en cuestión de segundos, y así la idea se hizo realidad. 

Quería usar el chatbot para dar todas las facilidades a los desarrolladores y poner todas las posibilidades de la CDN en sus manos, permitiéndoles implementar cambios, purgar cuando quisieran, ejecutar test A/B, bloquear IP... y todo en el marco de un chat de equipo. Así, alguien puede venir y decirnos: «Hola, ¿veis que estamos ejecutando una prueba de penetración?». Y respondemos: «Sí, ya vemos. ¿Te podemos ayudar en algo?». Y el cliente responde: «Sí, por favor. Queremos bloquearla». Y alguien de nuestro equipo bloquearía la prueba de penetración en el marco del chat, y todo el mundo lo sabría. La verdad es que eso está muy bien.

¿Consideras que tener ese chatbot disponible ha cambiado la cultura del equipo, o la forma en que el equipo aborda las operaciones en general?

Cuando trabajábamos con el antiguo proveedor de CDN, yo tenía que crear un ticket para el equipo de operaciones, y luego, quién sabe cuándo de ese día, el día siguiente o esa semana, realizaban la modificación en la capa de la CDN. Y tal vez implementaban mi configuración y, con algo de suerte, era la configuración correcta. Y luego, vuelta a empezar.

Ahora, todo va mucho más rápido. Toda la configuración de la CDN está en Git y podemos desplegar los cambios utilizando nuestras herramientas. Por ejemplo, tenemos al equipo de Spreadshirt, que suele pedirme que haga un cambio en la configuración. Puedo hacerlo por ellos y decirles mediante el chatbot: «Oye, acabo de implementar el cambio que me pedisteis. Aquí tenéis la nueva revisión de Git y podéis ver exactamente lo que he hecho». 

Y otros equipos, como el de Teamshirts, ya hacen ellos mismos muchas de las operaciones. Al principio, yo lo hacía por ellos hasta que se dieron cuenta de lo fácil que era y empezaron a hacerlo ellos mismos.

La realidad es que damos a los desarrolladores todo lo que quieren, y las cosas van más rápido. Así, los cambios de configuración, las purgas, los despliegues de pruebas; todo esto ya se puede hacer sobre la marcha y no hay que esperar varios días: se hace aquí y ahora.

Y también te da algo de confianza. Supongo que desaparecen la ansiedad y el estrés al lanzar versiones.

Sí, también tenemos registros en vivo para todo, así que si te cargas algo, siempre puedes arreglarlo. Confiamos en nuestro personal y les damos las herramientas. Pueden cometer errores, pero es de esperar que no cometan el mismo error dos veces.

Me parece bien. Hablando de los registros, registráis muchísimo de Fastly. 

Sí. También puedo contar algo sobre esto. Con nuestro anterior proveedor de CDN, los registros nos llegaban con una hora de retraso, lo cual era un problema. El otro problema era (y no miento) que solo disponíamos de 40 caracteres para datos personalizados. 

Luego pasamos a Fastly y hace poco activamos los registros en vivo, y ahora podemos registrar todo lo que te puedas imaginar: cosas básicas como URL de peticiones y códigos de estado, claro está, pero también datos más complejos como geoinformación, información de dispositivos y todo tipo de encabezados. Recientemente descubrí proxy type y proxy description, que son muy útiles a la hora de investigar sobre seguridad y sacar más información acerca de ataques o fraudes, por ejemplo.

Supongo que la idea es que, como los datos están ahí, hay que sacarles el máximo provecho. ¿Estáis utilizando ElasticSearch para recibir los registros?

Sí, los transmitimos a un clúster de ElasticSearch y los tenemos disponibles inmediatamente para investigar, lo cual está muy bien. Otra cosa que me gusta es que los podemos conectar a los registros de enrutamiento de centros de datos, los registros de aplicaciones, los registros de errores y otros registros que ciertos equipos escriben para lo que necesitan. Gracias a esto, tenemos información de calidad en tiempo real acerca de cómo va todo. 

Por ejemplo, el año pasado tuvimos problemas con ataques de relleno de credenciales y, en tiempo real, podíamos ver que estaba pasando algo. Y nos decíamos: «Vale, vamos a poner un bloqueo para un agente de usuario en concreto o para una combinación específica de agente de usuario y encabezado». Y podíamos ver en tiempo real que el bloqueo funcionaba. Es genial.

Además, los registros no nos sirven solamente para realizar operaciones; también los usamos a la hora de crear informes. Ahora ya podemos sacar un informe mensual de la CDN que dé una visión clara del coste y el desglose de la CDN, y eso marca una gran diferencia.

Hablemos de las fiestas, ya que estamos en plena campaña navideña para la mayoría de los retailers. ¿Qué cambios nota tu equipo al entrar en la campaña navideña, y qué diferencias hay este año a causa de la covid?

Spread Group es una empresa de impresión por encargo y tenemos instalaciones de producción en diferentes países de Europa y Norteamérica. Tenemos trabajadores reales en esas instalaciones que imprimen camisetas, tazas y otras prendas y accesorios. Por eso, como no solo somos una empresa digital, sino que también manejamos objetos físicos, tenemos que contemplar normas de seguridad, restricciones por confinamientos y posibles cierres de las fábricas, y eso es justo lo que ocurrió en marzo y abril. Algunas de nuestras fábricas tuvieron que cerrar y eso nos puso las cosas difíciles, porque no sabíamos cuánto tiempo duraría el confinamiento, cuánto tiempo podríamos mantener nuestro flujo de liquidez, etcétera.

Pero luego, como no podía ser de otra manera, el negocio se recuperó. De hecho, lo que nos salvó en parte de la caída de las ventas en marzo y abril fueron las mascarillas. Le gente las necesitaba y podíamos imprimir lo que quisiéramos en ellas.

Luego, los propietarios de la tienda online Spreadshop también regresaron. Y como también ofrecemos impresiones por encargo en Shopify, esos retailers usaban nuestro servicio SPOD para atender sus pedidos. Así, lo que empezó como un año bastante duro terminó siendo positivo, la verdad. 2020 será otro año récord para Spread Group, con un aumento de los ingresos superior al 10 %. 

También estáis realizando test A/B. ¿En qué se centran estos test, y cómo medís los resultados? La respuesta me interesa personalmente porque escribí el patrón de solución de test A/B utilizando Fastly, de modo que siento curiosidad por saber si usáis Fastly o seguís otro mecanismo. 

Básicamente utilizo tu solución. A la configuración del servicio le añado unos cuantos fragmentos dinámicos que contienen el código generado, y luego iniciamos y detenemos los test mediante nuestra herramienta de línea de comandos o el chatbot.

 Lo que sometemos a pruebas es lo que considero más complicado; aspectos que requieren trabajo de desarrollo. Por ejemplo, comparamos una versión del listado de una tienda online con imágenes que solo muestran los diseños (vista de diseño) y otra versión con imágenes de los productos y los diseños superpuestos (vista de producto); o bien un diseñador de camisetas con una presentación concreta y otro diseñador de camisetas con otra presentación. Y luego queda que el personal de análisis repase los números y que el personal de test A/B pruebe las hipótesis y evalúe los resultados.

¿Cuál es el siguiente gran reto técnico que más te apetece abordar?

Algo que siempre nos resulta problemático es la distribución de imágenes. A veces cambiamos las imágenes de los productos, por ejemplo. ¿Qué fue lo último que me pasó? Creo que fue una taza, y la imagen de la taza cambió, por lo que debes cambiar todas las imágenes que tienen diseños en tazas. 

¿Así que vuestra imagen canónica de la taza cambió y, como consecuencia, todo el posible material gráfico que haya y que se pueda poner en una taza tiene que modificarse? Esto es muy interesante. Así pues, podríais usar la optimización de imágenes para superponer el material gráfico en fondos genéricos, ¿o seguís viendo este paso como algo que hacéis en el origen?

Muy buena pregunta. Hay tres cosas que nos tendrían que resultar fáciles de hacer con Image Optimizer. La primera es distribuir diferentes formatos de imágenes, como JPEG o WEBP. Esta es la más sencilla. La segunda es cambiar el tamaño de las imágenes; por ejemplo, enviar una versión de 378 píxeles, una de 500 píxeles y otra de 800 píxeles. También es sencilla. La tercera, la superposición, ya sí que es algo más difícil. 

Antes de que añadiéramos imágenes de modelos en 3D (personas reales llevando nuestros productos), era un poco más fácil porque simplemente teníamos una camiseta lisa y había un diseño añadido a la camiseta lisa, y eso se podía hacer con superposiciones y transformaciones en 2D. 

Pero con 3D el asunto se complica; ya no se puede pegar a la camiseta sin más. A veces tienes imágenes de modelos en 3D que están un poco inclinadas y tienes que colocar el diseño usando la perspectiva correcta. Otras veces, el diseño está en el brazo y según lo miras desde el frente, solo ves un fragmento del diseño en el brazo, por lo que es algo más difícil. Tenemos nuestro propio proceso de procesamiento 3D escrito en Java en el backend, pero lo ideal sería averiguar cómo podemos hacer que sea más sencillo y escalable y tratar de pasarlo al edge.

Estaba pensando en una posible solución: por ejemplo, si tienes una imagen de origen con una malla de distorsión añadida, en teoría podrías hacer una transformación de matriz de la ilustración para que se ajustara a la malla de distorsión del fondo, en el edge. No podrías hacerlo en VCL o con el Image Optimizer actual, pero sí que podrías en Compute@Edge.

Sí, espero poder hacerlo; sería genial.