Codemotion 2017: Perspectiva de un DevOps

Un año más, Codemotion Madrid se despide de la universidad San Pablo CEU (Campus de Montepríncipe) con un listado de asistentes increíble. En esta edición hemos podido otear un poco el horizonte, viendo hacia dónde apuntan los caminos de los próximos años: Serverless (cloud functions), microservicios, programación reactiva, automatización...

A continuación te resumo algunos de los puntos clave vistos durante las charlas a las que asistí. ¡Me resultó imposible estar presente en todas las que me hubieran gustado!

Seamos "Hipster", pensemos en ServerLess

El viernes empezó fuerte con "Seamos "Hipster", pensemos en ServerLess" donde el ponente Manuel Delgado Diaz (@mdelgadodiaz83) expuso paso a paso de qué se trata esta “moda” (o no tan moda). Serverless es un concepto por el que, al fin y al cabo, se facilita la vida del desarrollador donde este no se va a preocupar nunca de la infraestructura (menos aún). Serverless responde a eventos, estos eventos pueden ser desde una petición HTTP, un mensaje en una cola de mensajería o un evento en el block storage ejecutando una “función” creada por el desarrollador. Manuel es MVP en Azure y por tanto hizo un ejemplo en vivo de una función en Azure.

Ahora bien, desde mi humilde punto de vista la configuración es algo tediosa en Azure. Si comparamos con Amazon Lambda, el servicio serverless de AWS, vemos como los tiempos de configuración son bastante más ágiles en AWS. También es verdad que la configuración se realiza una sola vez y deberíamos comparar rendimientos, facturación, lenguajes de programación soportados, etc, etc.

De hecho, hablando con Manuel en petit comité después de la ponencia, le comenté que le echara un ojo a Serverless (el framework) el cual trata de homogeneizar la configuración de la “function” siendo agnóstico al proveedor cloud elegido.

Infraestructura Inmutable: GitHub + Terraform + Packer

A continuación, y como DevOps que soy, entré en el track 3 para escuchar uno de mis temas favoritos, infraestructura inmutable. La charla "Infraestructura Inmutable: GitHub + Terraform + Packer" la impartió Alejandro Nieto Boza (@alejandronietoi). Fue una charla bastante teórica, repasando históricamente cómo se gestionaba la infraestructura desde los entornos tradicionales (CPDs de la propia empresa), virtualización y por último el cloud computing. Alejandro introducía términos como infraestructura como servicio, los beneficios de esta así como las tecnologías que hacen posible esta inmutabilidad: Terraform, packer, ansible…

Una charla bastante recomendable para aquellos que están empezando o piensan adoptar la filosofía DevOps 🙂

Monitoring social, economic and geopolitical events through Big Data

El día iba avanzando y las charlas para DevOps no aparecieron en mi radar por lo que entré en una charla sobre análisis de datos y big data ofrecida por Tomasa Rodrigo López, (@TomasaRodrigo). Realmente interesante la labor desempeñada por el departamento de BBVA research donde Tomasa y su equipo reune información de numerosas fuentes de datos (me quedé alucinado con GDELT, no lo conocía) y son capaces de cuantificar el efecto de los eventos políticos como la independencia de cataluña o las guerras que se libran actualmente en paises islamicos. Estos datos son clave para el banco a la hora de tomar decisiones estratégicas como la expansión del mismo,  el cierre/apertura de oficinas en un determinado punto geográfico o cuando comprar/vender divisa extranjera.

Big Data y análisis de datos en Codemotion 2017

Personalmente, estas charlas me dan un poco de respeto y es que soy bastante temeroso del poder que ofrece disponer de estos datos. Ya sabemos que todo gran poder conlleva una gran responsabilidad.

El viernes acabó con dos charlas de dos compañeros de Intelygenz, Noemi Medina y Gustavo Marin, gracias por el gran esfuerzo dedicado y a la gran charla expuesta en Codemotion Madrid.

Chasing the perfect CI/CD Pipeline

El sábado por la mañana, temprano… muy temprano, empezaba una de las mejores charlas, desde mi humilde punto de vista, ofrecida por los chicos de “IT” de Adidas. Y sí, Adidas tiene un departamento propio de tecnología aunque era de esas empresas que subcontrataban servicios de terceros para entregarles productos de dudosa calidad.

La charla la denominaron: "Chasing the perfect CI/CD Pipeline – Create applications in the future at Adidas" cuyos ponentes (Fernando Cornago, Iñaki Alzorriz Armendariz y Javier Pelayo Gil) comentaron la fuerte inversión realizada por adidas para crear un departamento de IT potente. El camino recorrido por estos chicos fue duro. Al principio, cuando llegaron no tenían un set de herramientas como jira, bitbucket, bamboo o jenkins… nada. Pero, poco a poco, fueron transformando y mejorando esta hasta llegar a una arquitectura basada en microservicios desplegados sobre un orquestador de contenedores como kubernetes, y usando como infraestructura nubes públicas como AWS o Azure.

Pero no solo lo relativo a la infraestructura de ejecución era interesante, sino que tienen bien montado, y con cabeza, todo el ciclo de integración y despliegue continuo. Todo en Adidas es medido al milímetro y el código no iba a ser menos. Cada servicio nuevo o modificación de uno anterior debía superar el 90% de cobertura de código con test unitarios. Además, se pasan pruebas de validación para asegurar que el contrato con terceros (el api) no se rompe y pruebas de regresión para comprobar que la funcionalidad no se ha visto comprometida.

Sin embargo, no todo es nuevo en adidas, tiene herencia de un (o varios) monolito. A este también se les pasa el mismo criterio de pruebas salvo la cobertura de código. Cuando un monolito no se ha hecho con buenas prácticas, no suele tener un porcentaje alto de cobertura de test. Por lo tanto, el requisito del 90% lse ha cambiado por otro más amigable, y es que la cobertura vaya subiendo con cada nuevo commit en el repositorio de GIT. En caso contrario, el cambio nunca se llegará a desplegar.

Sin duda, una de la mejores charlas y mejor montaje de arquitectura/infraestructura/ci&cd presentado en Codemotion 2017.

Clustering Tensorflow con Kubernetes y Raspberri Pi

Sábado media mañana… Clustering Tensorflow con Kubernetes y Raspberri Pi. Parece que son los términos de moda: Tensorflow, Kubernetes y Raspeberry Pi. Esta charla, impartida por Andrés Leonardo Martínez Ortiz y Laura Morillo-Velarde Rodríguez nos enseña a montar un cluster “escalable” (entrecomillado) de tensor flow sobre  kubernetes y raspberry pi.

Clustering Tensorflow en Codemotion 2017

El primer paso es disponer de las placas raspberry pi. El que no lo conozca, son placas integradas con procesador ARM y potencia suficiente para decodificar ficheros de vídeo en alta definición. Gracias a la comunidad a estas placas se les puede instalar el demonio de docker y como no, kubernetes. Esto hace que montar un cluster de pruebas en casa o bien en proyectos pequeños productivos tenga un coste realmente reducido en cuanto a la inversión inicial y a la factura de la luz.

El montaje de un cluster de kubernetes es bastante “asequible” y sencillo de realizar con una buena documentación. El problema viene a continuación con el montaje o instalación de un “cluster” de tensorflow. Es bastante tricky la instalación de tensorflow por el mero hecho que debes conocer el hostname y las ips de las máquinas donde se va a ejecutar el entrenamiento de los modelos o la ejecución del mismo. En un entorno como kubernetes no es lo ideal tener “pods” levantados en un statefull set preservando IPs y hostnames. Va en contra del paradigma cloud y esperamos que tensorflow cambie este requisito.

Por este motivo no se puede configurar un autoescalado en kubernetes para soportar/acelerar el entrenamiento de un modelo mayor siendo necesario acción manual para escalar el statefull set de kubernetes y volver a configurar el cluster de tensorflow…

¿Qué es un Senior Developer?

Después de un par de charlas técnicas me adentré en la ponencia Luis G. Valle resolviendo la duda ¿Qué es un Senior Developer? Sin ninguna duda una charla muy interesante sobre el mundo confuso donde vivimos. Senior Developer al fin de cuentas es aquel con madurez, con capacidad mentorado, con un camino recorrido por el cual ha ido aprendiendo de diferentes proyectos y clientes… Uno no se acuesta siendo junior y se acuesta levanta convertido en senior. Ni siquiera hay un número de años preestablecido… Charla muy recomendable para todas aquellas personas que tiene prisa por quitarse el título junior de su perfil de linkedin para cambiarlo por senior.

Adding containers to your CI/CD pipeline

Volví a una charla técnica impartida por Nacho Coloma sobre construcción de imágenes en un sistema de CI&CD como jenkins. La charla se denomina: Adding containers to your CI/CD pipeline y aunque me esperaba algo como la ejecución de los diferentes pasos de un pipeline en contenedores aislados me resultó muy educativa.

Mostró herramientas como Helm, Jenkins, gcloud… He introdujo SAS de google para la construcción de imágenes de docker en cloud y el storage de las mismas en un docker registry dentro de la plataforma de google.

Y es que si queremos plantearnos montar un sistema de orquestación de contenedores en cloud debemos echar un ojo a GCP (Google Cloud Platform) ya que da la instalación y la administración de un cluster de kubernetes como servicio además de la integración con las herramientas mencionadas anteriormente de construcción y almacenamiento de imágenes.

El Informático

Para finalizar el día, y Codemotion, entré en el track 1, la sala más grande, donde David Bonilla expuso El Informático. Una reflexión sobre qué es ser informático y qué responsabilidades conlleva. No me atrevo a resumir todos sus pensamientos en un par de párrafos, pero animo a todo aquel que tenga media hora libre a ver la ponencia de David Bonilla. Se tratan temas como la neutralidad de la red, sindicatos, discriminación racial y de géneros, el status quo…

 

Y así quedaría el resumen de Codemotion 2017 Madrid, de un reciente DevOps que antes era senior developer 🙂

¿Te gustaría trabajar con nosotros? Genial ¡te esperamos!