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.

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.

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.

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.