Probamos GPT-3 de OpenAI (uno de los modelos de lenguaje basados en Inteligencia Artificial más grandes jamás creados) en diez conversaciones de clientes sobre banca en español. Sin ningún tipo de adaptación previa, re-entrenamiento o aprendizaje por transferencia, le pedimos generar resúmenes que serían útiles para cualquier agente de banca que se una (o retome) la conversación.

Nuestra meta inicial es intentar responder a preguntas tales como cuándo es más apropiado usar AWS Lambda en vez de los servicios AWS EC2 y, especialmente, qué parámetros tienen más impacto en esta comparación.

En un entorno con diferentes Motores de Orquestación de Contenedores entre los que elegir (COEs, por sus siglas en inglés), como Kubernetes, OpenShift, DC/OS, Nomad o Swarm, hay ocasiones en las que la solución óptima para desplegar varias aplicaciones requiere de más de un COE. Cada uno de ellos tiene sus puntos fuertes y están enfocados a un tipo de tareas o trabajos específicos. Por ejemplo, Kubernetes está especialmente preparado para desplegar microservicios de una naturaleza muy dinámica. Sin embargo, en un entorno tan dinámico es complicado mantener un sistema de base de datos, para lo cual es más apropiado un sistema como DC/OS.

En BBVA Labs hemos usado actores Akka en diferentes proyectos durante bastante tiempo, gracias a su capacidad de distribución de la computación en escenarios de alta carga, usando actores con o sin estado que se envían mensajes entre ellos de forma asíncrona.

En este post veremos algunos de los puntos débiles a la hora de trabajar con actores clásicos sin tipado, y veremos qué beneficios nos aporta Akka Typed. Finalmente, presentaremos una breve descripción de los Session Types y la API de Process DSL, creada por el Dr. Rolan Kuhn. Todos los ejemplos están escritas usando la API de Scala.

Las técnicas de aprendizaje profundo o 'deep learning' nos ofrecen unos resultados espectaculares en diversos campos del aprendizaje automático, o 'machine learning'. Sin embargo, el entrenamiento de una red neuronal compleja con un conjunto de datos ('dataset') grande puede llevarnos una gran cantidad de tiempo. Por tanto, acelerar en lo posible el entrenamiento de los modelos de aprendizaje profundo resulta esencial, pero también supone un desafío.

Hoy en día casi todas las aplicaciones o servicios modernos son RESTful y utilizan definiciones de API para facilitar la comunicación entre ellas, ya que nos abstrae del lenguaje y la implementación subyacente del resto de componentes. Las APIs cobran aún más sentido en arquitecturas de microservicios o serverless donde nos podemos encontrar con decenas o cientos de microservicios/funciones que interactúan entre ellas.

En BBVA Labs seguimos la pirámide de tests propuesta por Mike Cohn: tenemos un conjunto grande de test unitarios, fáciles de implementar y que se ejecutan en cada cambio en el código; un conjunto de tests de aceptación que se ejecutan siempre que se haya pasado todos los tests anteriores; y por último, los tests end-to-end que sólo se ejecutan cuando se desea liberar alguna funcionalidad.

La complejidad de la implementación de estos tests van en aumento según se sube en la pirámide. En los tests end-to-end, donde también se prueba la integración de servicios, se requiere levantar la infraestructura, los servicios a los que se desea testear y las servicios con los que se integra. El establecimiento del entorno del testeo, junto con la implementación y ejecución de los tests, es bastante más complejo que los test unitarios.

Adicionalmente al coste de ejecutar estos tests, aparece otro problema cuando un servicio cambia de formato de mensaje. Lo que se desea evitar es un despliegue tipo Big Bang (desplegar el servicio y todos sus dependientes a la vez) debido a este tipo de cambios rompe el despliegue continuo. Por tanto, durante un periodo de tiempo el productor de un servicio tiene que dar soporte a dos versiones del mensaje mientras los consumidores se van actualizando a la nueva, pero los tests del consumidor prueban solo con una única versión del productor del servicio.

Desde BBVA Labs hemos realizado un experimento para reducir el número de servicios a desplegar en los test y para asegurar, en un sistema de despliegue continuo, que la comunicación entre servicios de distintos dominios se mantiene a lo largo del ciclo de vida del producto software. Para este experimento se ha decidido evaluar las actuales herramientas para realizar Consumer Driven Contract testing (CDC testing o simplemente contract testing).

El uso de Docker en el despliegue de software en sistemas productivos resuelve muchos problemas de agilidad y normalización de estos procesos pero, como toda tecnología “rompedora” con los procesos de IT anteriores, genera nuevos desafíos o requiere distintas soluciones para problemas siempre existentes. En esta última clasificación entra la gestión de secretos.

Este artículo es la segunda parte sobre la tecnología serverless, en donde abordamos la integración de uno de los productos más interesantes que implementan esta tecnología (Fission) en la plataforma de PaaS de RedHat, OpenShift.

Previamente a este artículo, se realizó un análisis de arquitecturas serverless o FaaS (Function as a Service), donde se introdujo esta tecnología, junto con su valor en desarrollos empresariales.

Siempre han sido nuevos tiempos para la innovación. Siempre lo han sido y siempre lo serán. Está en nuestra naturaleza estresar el modelo. Incluido el nuestro.

La arquitectura serverless también conocida como FaaS (Functions as a Service), habilita la ejecución de una aplicación mediante contenedores efímeros y sin estado; estos son creados en el momento en el que se produce un evento que dispare dicha aplicación. Contrariamente a lo que nos sugiere el término, serverless no significa «sin servidor», sino que éstos se usan como un elemento anónimo más de la infraestructura, apoyándose en las ventajas del cloud computing.

En este post exploramos, dejando de un lado el hype que acompaña al término serverless, las posibilidades que nos ofrece a nivel de arquitectura y desarrollo de aplicaciones. También estudiamos las principales alternativas de uso en clouds públicas y privadas.

El entrenamiento de redes neuronales plantea grandes exigencias tanto del punto de vista de temporal como de capacidad de procesamiento, incluso para los estándares actuales.  Existen dos maneras de reducir la cantidad de tiempo necesaria: recurriendo a máquinas más potentes o a un mayor número de ellas.

Para la primera opción existe la posibilidad de recurrir al uso de hardware dedicado como unidades de procesamiento gráfico (GPU o grafic processing units), o incluso FPGAs y  TPUs – tensor programming unit en el futuro. Pero también puede lograrse dividiendo la tarea entre equipos de uso normal, como las que se utilizan en los sistemas basados en la nube.

Este documento resume las conclusiones alcanzadas tras investigar el uso de redes neuronales distribuidas.