Cultura devops en REA

Como muchos sabéis ya, hace algo más de 4 meses que inicié mi aventura en tierras Australianas y comencé a trabajar para REA, grupo que se dedica a la gestión de publicidad online para el mercado inmobiliario, principalmente en Australia, pero con presencia internacional en Italia, Luxemburgo, HongKong, etc…

Deajando aparte el factor aventura, y las ganas de conocer esta parte del mundo, cuando me ofrecieron este trabajo se unieron la oportunidad de trabajar en una compañía que maneja algunos de los portales con más tráfico de Australia con mi interás por dedicarme a las operaciones web a gran escala. Uno de los elementos que más me atrajo fue la cultura de la compañía, que por lo que pude adivinar en las entrevistas, y he verificado postriormente, destaca por una implantación muy alta de metodologías ágiles, equipos de alto rendimiento y gran nivel técnico, mentalidad hacker, mimo por los empleados y una cultura devops muy evolucionada.

Un ejemplo del arraigo de la cultura devops en la empresa es que los dos grupos que celebran reuiones en la zona sobre el tema: «Melbourne devops» e «Infrastructure coders» están siempre sobre poblados de gente de REA, ya sea en el público, como colaboradores o como organizadores. Fuera de Australia, cuando uno de mis compañeros recientemente asistió a Velocity y Devopsdays en Estados Unidos recibió comentarios de admiración sobre el grado de implantación de la cultura devops en la compañía.

Pero después de tanto rollo, ¿cómo es la cultura devops en REA? Podría decirse que en una compañía como esta, en la que los conceptos de agilismo y lean están tan marcados en todos sus estratos, la búsqueda de la eficacia y las mejores prácticas es una evolución constante. Si aplicamos estos elementos al concepto de cómo operamos nuestros servicios nos damos cuenta de que se trata de un viaje que implica un cambio constante. Podemos marcar el comienzo de este viaje hace ya algún tiempo, cuando las operaciones eran ejecutadas de forma centralizada por el equipo de Operaciones Web (dentro del área de IT). Los ya consabidos problemas consecuencia de la separación de Operaciones y Desarrollo, sumados a la desalineación de ambos con los intereses del área de negocio, llevaban a un funcionamiento ineficiente. Operaciones estaba descontento porque no podía solucionar los problemas endémicos, ya que no estaba presente en el proceso de creación y/o mejora de los productos. El equipo de Desarrollo por su parte veía en Operaciones un elemento bloqueante, que no le permitía alcanzar la velocidad demandada por el entorno del negocio, en aras de mantener la estabilidad del entorno. Y todo acaba con las consabidas peleas de perros y gatos, tan ilustradas en cualquier presentación sobre devops.

Los primeros refinamientos del proceso se basaron en empezar a «infiltrar» miembros del equipo de Operaciones en los distintos equipos de Desarrollo, para intentar mejorar la comunicación, y para conseguir que el elemento de operaciones estuviera presente en el día a día del desarrollo y mejora de los servicios. Al parecer el comienzo no fue muy fácil ni agradable y en algunos casos los equipos rechazaban al nuevo miembro, como cuando un cuerpo rechaza un transplante, y también había choques culturales, siendo los «infiltrados» los que no se sentían cómodos en este nuevo ambiente. Su trabajo consistía casi únicamente en realizar pasos a producción de forma manual una y otra vez. Por aquel entonces, había un segundo equipo denominado SPA (Site performance and availability) que se encarga del soporte global de las operaciones, es decir del cuidado de las infraestructuras y gestión de incidencias relacionadas con producción.

Transcurrido algún tiempo comenzaron a hacerse evidentes las ventajas del modelo, gracias al éxito de los equipos que lo habían implementado. Esto dió paso a prácticas que mejoraron el proceso de despliegue y gestión de los servicios mediante la automatización de los mismos y al comienzo de la adopción de un modelo PaaS (Plataforma cómo servicio) cuyo objetivo era la estandarización de los entornos y la simplificación en las operación de los mismos.

Los siguientes pasos en este proceso son la incorporación de la obre la gestión de las operaciones en estos equipos que ahora serán responsables del servicio de forma global incluyendo la creación, mejora y operación del mismo. Este proceso incluye la gestión y resolución de incidencias, ahora los miembros de SPA se han enbebido completamente en los equipos, y el siguiente paso es conseguir que la responsabilidad de solucionar los problemas recaiga en todo el equipo: desarrolladores, calidad, operaciones e incluso los productores y responsables de negocio que poco a poco se han ido incorporando al equipo en su día a día, formando algo parecido a mini startups dentro de la empresa. Por lo que ahora todo el equipo se sienta en la misma zona de la oficina, atiende a las reuniones diarias (standups) y participa en el trabajo cómo uno más. Se acabó esto no lo podemos resolver esto porque X o G no colaboran. Los problemas se priorizan dentro del equipo y se decide que demandas se deben atajar primero y el diseño de nuevas funcionalidades siempre cuenta con la idea de cómo vamos a operar el servicio cuando este esté en producción.

Respecto a la tecnología usada dentro de los equpos relacionada con devops podríamos describirlo cómo que cada equipo tiene libertad para utilizar los elementos que le sean más productivos para conseguir sus objetivos, es la ventaja de tener el control y la responsabilidad de extremo a extremo de los elementos, y en muchos casos esta apoyada en la estandarización que provee el uso de una plataforma común, de la que ya hablaré en un articulo posterior. Por tanto nos encontramos elementos muy distintos cómo puppet o chef para la gestión de configuración, el uso de rpms para la distribución de nuestras aplicaciones, nagios, newrelic, gomez y graphite para monitorización y métricas entre otros muchos.

La implantación de la cultura devops en una compañía no puede medirse cómo blanco o negro, más bien se trata de un gris que va cambiando de tono ya que está en constante evolución persiguiendo el fin último de mejorar la forma en que ofrecemos nuestros servicios y aumentamos el valor para nuestros clientes, así que os mantendré informador de futuras mejoras y la implantación de los planes actuales.

Pensando en Devops

No sé si os lo he comentado ya varias veces pero me encanta la nueva mentalidad alrededor de las tendencias Devops y las Operaciones Web ágiles. Creo que es un cambio de mentalidad necesario y un gran avance para nuestra profesión pero que implica cambios a todos los niveles. Ya llevaba tiempo pensando en escribir sobre el tema ya que los recursos en inglés sobre el mismo son inagotables, pero creo que no hay tanto en español, así que os voy a dejar un batiburrillo de reflexiones que últimamente me dan vueltas en la cabeza.

El otro día estuve en el London Puppet User Group meeting y disfruté bastante de las charlas especialmente la segunda en la que mostraron un enfoque diferente en la definición de recursos orientado a provisionar varios servidores a través de Open Nebula y dejarlos configurados y operativos, todo ello a través de Puppet. Pena que todavía no he tenido la suerte de poder acercarme a London Devops y me alegro infinito de que Madrid Devops siga viento en popa, desde aquí mis felicitaciones a Mari Carmen por el empeño que está poniendo y a todos los que os acercáis a compartir por ese foro, ¿se nota que os echo de menos? 😀

Una de las primeras cosas que me vinieron a la cabeza es que no estoy seguro de si la orientación que está tomando la gente de Puppet Labs va muy en la línea de lo que yo busco en su producto. Por un lado, mantener dos desarrollos separados para la edición Enterprise y la edición Comunidad y por otro, el enfoque hacia grandes corporaciones y hacia la incorporación de elementos cómo gestión de CMDB, Workflows, etc para mí rompe un poco con la mentalidad Unix: pequeñas herramientas que hacen muy bien su trabajo y que en conjunto te dan una gran flexibilidad. Personalmente me gustaria que se trabajara más en la parte de orquestación y en romper el enfoque nodista, decidir el estado de mis nodos, por uno mucho más orientado a conjunto o a servicio.

Me encanta mcollective, creo que es una herramienta muy potente, pero no dejo de verla cómo un loop ssh para ejecutar un comando en el resultado de la busqueda de nodos que cumplen ciertas características y no lo termino de enlazar con una orquestación más basada en estados cómo es puppet sino en acciones.

Por cierto, si tenéis tiempo libre y os interesa el tema de Puppet os recomiendo que le echéis un vistazo a los videos de la pasada Puppet Conf y también a este repositorio Git que ha compartido la gente de Wikimedia con los manifiestos que ellos están usando para gestionar su infraestructura.

Otra reflexión sobre puppet, antes de pasar a otro tema, me vino del descubrimiento que en las plantillas para ficheros tipo erb podía utilizar todo el código Ruby que quisiera y esto solucionó algunos de los problemas que me estaban rondando últimamente para definir algunas plantillas algo complejas. Desde entonces un run-run en mi cabeza no para de decirme si aplicando el mismo concepto no sería mucho más potente el uso de Chef que utiliza una sintaxis más amplia y te permite utilizar el juego completo de instrucciones de ruby en tus manifiestos. Hace tiempo que no pruebo Chef, pero comentando esto con gente de la conferencia me comentaban que la orientación de Chef no cambia únicamente en eso sino que también hay que tener en cuenta que al contrario que Puppet, la ejecución de la configuración en Chef en varias ocasiones consecutivas sobre el mismo entorno en el mismo estado podría no dar lugar a los mismos efectos. Aquí me vendría bien ayuda de gente que se haya pegado más con los dos sistemas, ¿cómo véis el estado del arte los Chefistas y los Puppeteros?

Y de paso aprovecho también para volcar a texto otra de mis inquietudes de los últimos meses. Hace ya tiempo que quiero ampliar mis habilidades aprendiendo y cogiendo práctica con un lenguaje de scripting que me ayude a ser más eficiente y amplie mis posibilidades. Al principio python parecía el camino adecuado, pero cada día que pasa siento que hay más y más herramientas de administración escritas en ruby, con lo que me crece la duda, por ahora sigo poco a poco la senda de python y ya sé que la respuesta a la pregunta es: aprende los dos, pero cómo el tiempo es limitado habrá que dividir los esfuerzos o priorizarlos, ¿cómo lo véis?

Una parte de la charlas posteriores entre cervezas y pizza que me encantó era lo que comentaba uno de los asistentes: «Yo no quiero a los desarrolladores anden tocando en mis servidores», pero estuve pensando y creo que no sólo es la idea correcta sino que habría que ampliarla «No quiero a nadie rondando en mis servidores, ya sean de los equipos de desarrollo u operaciones y menos aún alguien de fuera», si hay que hacer retoques en los entornos de producción estos deberían hacerse siempre desde las herramientas de gestión de configuración y cambios de tus entornos y a través de unos workflows definidos y probados ampliamente, nunca tener que realizar acciones directas sobre las máquinas. Otro de los comentarios fue que «los equipos de desarrollo quieren estar modificando continuamente lo subido y a veces van demasiado rápido», y creo que aquí está otro de los puntos clave del cambio que estamos intentando llevar a cabo con mentalidades ágiles y devops: nuestro objetivo debe ser el de habilitar el cambio y potenciarlo, eso sí poniendo los mecanismos necesarios para asegurar el éxito: integración continua, desarrollo guiado por pruebas, automatización del despliegue, paso rápido entre entornos de pre y pro o despliegue continuo son los habilitadores para ello y tenemos que encontrar la mejor manera de integrarlos en nuestros ciclos para ganar en agilidad.

Y en el terreno herramientas, no puedo dejar de comentar una de mis favoritas en los últimos días es Vagrant, si no la habéis probado no tardéis mucho en hacerlo. Hace tiempo que estaba buscando un sistema que me permitiera gestionar facilmente máquinas virtuales en mi portátil de forma que si necesito probar algo en una Debian, Redhat o lo que sea pueda levantarla rapidamente tener un entorno configurado rápidamente y hacer la prueba y destruir la máquina. Para ello Vagrant es ideal, es un conjunto de scripts en Ruby, elo aquí de nuevo, que usan Virtualbox por debajo normalmente en modo no gráfico y que te permite levantar una serie de plantillas de máquinas virtuales (os recomiendo vagrantbox.es para descargarlas), además tiene integración con puppet y chef de forma que puedes indicarle que ejecute un manifiesto al arrancar y que te deje el entorno ya configurado según unos parámetros. Impresionantes las posibilidades también para los equipos de desarrollo a los que se puede pasar un entorno similar al de producción y ellos pueden ejecutarlo en sus máquinas para desarrollar, hacer pruebas, etc… Vamos, no hay día que no me levante al ritmo de un comandazo «vagrant up»!

Por último voy a dejar a continuación tres juegos de transparencias que me han gustado bastante en los últimos días y que creo que son bastante explicativas de todo esto al rededor del movimiento Devops:

Y lo más importante, si has llegado hasta aquí por favor deja tu comentario en la entrada para que generemos algo de debate al rededor del tema. Muchas gracias a todos. 😀

Mudanza virtual de servicios a la devops

Hace un par de meses al llegar a UK y aprovechando que Amazon tiene envío a domicilio gratuito para algunos libros, aproveché para pillar un par de libros: «Web Operations» y «Continous Delivery«. Con todo el lío no había tenido tiempo para empezarlos, pero se me ocurrió comentar un día en twitter la pena que me daba tenerlos ahí sin leer cuando @trek1s me recomendó que leyera cuanto antes el de Web operations porque le había gustado bastante, así que me puse a la tarea y lo llevo bastante avanzado (prometo poner una reseña en el blog porque la verdad el libro la amerita).

Web Operations

En uno de los capítulos dedicado a la infraestructura como código nos cuenta cómo el reconstruir todos los servicios de una empresa ante una catástrofe debería ser tan sencillo como provisionar infraestructura en un proveedor de cloud no afectado por la catástrofe, aplicar sobre ella nuestra herramienta de gestión de la configuración para configurar todo lo necesario y rescatar del backup, aquel que estaba offsite y no fue afectado por la catástrofe, la versión más actualizada para los datos. Y si uno lo piensa bien, el tema debería ser así y nuestros esfuerzos como sysadmins deben de estar dirigidos en gran parte a objetivos tan loables cómo salvar a la empresa de la quiebra ante una catástrofe.

Cuando empezamos a implementar la plataforma de salud de Andago, uno de los primeros objetivos que me marqué y que hace tiempo llevaba intentando poner en práctica fue el de tener una buena política de la gestión de la configuración y del despliegue de las aplicaciones. En algunos de los proyectos internos ya se llevaba tiempo trabajando en esto pero normalmente en los proyectos y servicios de cliente no se había podido avanzar tanto como se debería, así que como siempre decimos una oportunidad para empezar de cero es una oportunidad para no volver a cometer los mismos errores.

Una vez definida la política, siempre sujeta a cambios y mejoras, nos pusimos a implementarla. Abriendo nuestro maletín de herramientas devops (marca Acme) decidimos utilizar subversion, puppet y los servicios de Amazon EC2. No voy a ahondar en cómo fue la implementación pero un punto que sí me ha resultado muy interesante ha sido el cambio en el modo de trabajar que hemos tenido que sufrir como equipo. Hace tiempo que venimos practicando Scrum como metodología ágil para los proyectos nuevos a desarrollar pero esta vez le sumamos el cambio que supone trabajar con la infraestructura como código. El trabajo habitual de un proyecto en la parte de configurar servicios en Linux suele ser de trastear mucho en la consola e ir documentando en nuestro wiki de referencia. En este caso el tema cambió y nos dedicamos a escribir el código de Puppet que se encargaría luego de hacer la configuración y además, con unos buenos comentarios, cubre una parte importante de la documentación del servicio.

Por otro lado sumamos que estamos trabajando de forma distribuida tanto en ubicaciones como en horarios, yo desde Reino Unido y luego equipos en España y Panama, el reto era bastante interesante. Lo bueno es que en lugar de estar toqueteando cada uno servidores en remoto lo que estabamos produciendo es código que se iba almacenando en nuestro subversion y que luego puede ser testeado, aplicado y pulido múltiples veces hasta llegar al punto deseado. A través de rsync empujábamos el código a instancias de Amazon y comprobando que todo funcionaba bien. Curiosas las sesiones de despliegue en la que todos en remoto estábamos conectados por ssh al mismo screen y viendo cómo desplegaba nuestra criatura mientras comentábamos la jugada por skype.

El siguiente reto será ir por la integración continua y las pruebas automáticas, es decir todas aquellas cosas que siempre les estamos pidiendo a los desarrolladores pero que luego nosotros no estábamos aplicando a nuestro trabajo.

Por ahora no hemos sufrido ninguna catástrofe para comprobar lo narrado por el libro pero sí hubo un punto de prueba muy interesante. El equipo de negocio decidió que, debido a que nuestro público objetivo en gran medida estaría en Estados Unidos, el despliegue que inicialmente se había realizado en la zona de Irlanda habría que migrarlo a la zona de la costa este de gringolandia. Ciertamente aún no estábamos en producción y seguíamos en las fases tempranas del proyecto y eso facilita las cosas, pero la transición fue bastante parecido a lo descrito al inicio lo cuál no hace más que reafirmar que vamos avanzando por el camino correcto.

Gestionando servidores con Puppet

Aquí os dejo las transparencias de la charla «Gestionando servidores con Puppet» que impartí en los cursos del GUL de la Universidad Carlos III de Madrid el pasado 09 de Noviembre:

Las transparencias se liberan cómo Creative Commons Reconocimiento 2.5 de España respetando la licencia de las imágenes utilizadas cómo fondo, podéis ver un listado de los autores y la licencia de sus obras al final de las transparencias.

La charla se dividió principalmente en 3 partes: describir el problema que encaramos cuando intentamos administrar el creciente número de servidores que requiere cualquier entidad que consuma servicios de IT, algunas de las posibles soluciones que podemos encontrar así cómo qué características debe tener una solución a este problema y por último cómo Puppet puede ser esta solución y una pequeña introducción a cómo funciona.

Como siempre el auditorio estuvo bastante participativo y las preguntas hicieron más amena la exposición. Como siempre la parte de la demo siempre es la más complicada, de nuevo el bendito Android y la conexión 3G me facilitaron las cosas, pero sirvió para hacer una demostración de los conceptos mostrados en la parte teórica. Muchas gracias a todos los que os acercasteis a la charla y gracias por los comentarios positivos sobre la misma que hicisteis en el blog, así da gusto prepararse cualquier tema.

Charla: Gestionando nuestros servidores con Puppet

Otro semestre más vuelven los cursos del Gul de la Universidad Carlos III de Madrid que durante la semana próxima, del 08 al 14 de Noviembre, tratarán de temas tan interesantes cómo Git, tunning de Mysql, Android o ITIL. Yo me apunto de nuevo a dar una charla y esta vez será sobre Puppet y cómo puede cambiar radicalmente la concepción de la gestión de nuestros servidores ofreciendonos grandes ventajas en la automatización, gestión de configuración y la reutilización.

Mi charla será el Martes 09 de Noviembre a las 18:00 en el aula 4.0.E02 en el Campus de Leganés de la Carlos III, así que si os interesa el tema nos vemos por allí.

ACTUALIZACIÓN: Ya tenéis un resumen y las transparencias de la charla disponibles en el blog.