BBVA Labs

Tras los incidentes de los últimos meses (SolarWinds , Codecov ,...) cada vez se va haciendo más patente la necesidad de tener inventariado y controlado el listado de todos los componentes con los que construimos nuestro 'software', así como de fortalecer el proceso con el que lo construimos.

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.

Hace unas semanas unos compañeros de desarrollo nos transmitieron su preocupación acerca de la generación de JSON Web tokens (JWT) que estaban haciendo como parte de la integración de una nueva herramienta. Habían oído acerca de "bastantes" problemas de seguridad y querían que les ayudaramos a validar si los tokens emitidos eran correctos y cumplían con algunos requisitos de seguridad básicos.

Actualmente estamos trabajando en un proyecto que ayuda en la automatización de tests de seguridad, APICheck, que hemos publicado recientemente como 'open source'. APICheck consiste en un conjunto de pequeñas herramientas que se pueden interconectar mediante pipes para poder encadenar la ejecución de distintos tests sobre peticiones a APIs, así que nos pusimos manos a la obra con la generación de una herramienta que permitiera validar los tokens que emitían, jwt-checker, en la que hemos implementado la posibilidad de pasar las validaciones que comentaremos sobre los tokens. Más adelante mostraré un ejemplo de un test usando la herramienta.

La transaccionalidad en bases de datos es fundamental para sistemas críticos, pero la histórica asimetría entre lecturas (masivas) y escrituras (puntuales, pero que pueden impactar en medio de una lectura) podría resolverse con un nuevo enfoque. El año pasado Databricks liberó a la comunidad su nuevo formato de persistencia de datos construido sobre almacenamientos del tipo 'Write-Once' 'Read-Many' (HDFS, S3, Blob storage) y basado en Apache Parquet.

Dada una actividad económica excesivamente compleja como para modelar bien sus factores de coste e ingreso, su optimización mediante Inteligencia Artificial (IA) puede dar lugar a una solución académicamente correcta, pero lejos de la optimalidad económica.

En los últimos meses, en BBVA Next Technologies hemos dedicado cierto esfuerzo a investigar herramientas y técnicas de interpretabilidad de modelos de aprendizaje automático (‘machine learning’). Estas técnicas son de gran utilidad para entender (o hacer entender a otros) las predicciones de un modelo, para extraer información de negocio a partir de un modelo que ha conseguido capturar los patrones subyacentes de interés, y para depurar modelos y estar seguros de que estos toman las decisiones correctas por las razones correctas.

En este artículo explicaremos cómo hemos aplicado estas técnicas para evitar poner en producción modelos fallidos que a priori eran totalmente correctos según los criterios estándar de validación.

El patrón sidecar se presenta como una herramienta muy potente en el nuevo mundo de los contenedores y se le puede encontrar en muchos casos de uso. En el presente post nos centramos en analizar algunos de los casos de uso más interesantes desde una perspectiva de la seguridad en IT.

En este artículo explicamos cómo gracias a Timecop (Auto ML en series temporales) podemos buscar anomalías o predecir series temporales en un gran número de casos de uso de una forma simple y rápida.

El problema de la verificación de la integridad de los datos en un tema clásico que ha sido bien estudiado en las últimas décadas. Muchos sistemas de base de datos o de log corren sobre servidores no confiable o están expuestos a ataques maliciosos por parte de personal propio y, por tanto, son vulnerables a manipulación indebida. Con el advenimiento de la computación en la nube y la posibilidad de tener que tratar con datos confiados al exterior, tal situación se ha visto agravada. Este problema es un desafío esencial para las instituciones financieras donde la preservación de la corrección de los datos de cliente y las transacciones es crucial en términos de cumplimiento legal y reputació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 este post abordaremos la gestión de dependencias de software. Aquí tienes un resumen en 10 segundos:

Los problemas que ello implica, cómo ser capaces de automatizar la gestión de las mismas, recibir alertas en tiempo real ante nuevas vulnerabilidades y cómo implementar un sistema productivo y satisfactorio usando herramientas Open Source: Deeptracy y Patton.

En este artículo explicamos cómo incluir seguridad en el navegador y poder monitorizar en tiempo real ataques dirigidos al cliente y que son muy complicados de controlar en el servidor.

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.

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.