DevOps esencial

Introducción
Presentación del curso “DevOps esencial”
Hola, soy Álvaro González Crespo y soy administrador de sistemas especializado en
soluciones "cloud" y contenedores. En este curso, vamos a familiarizarnos y a aprender los
conceptos de la filosofía de trabajo DevOps, de dónde proviene, qué nos ofrece para
mejorar nuestros flujos de trabajo y cómo aplicarla a nuestros procesos. Durante el curso,
veremos los orígenes de DevOps en el "Toyota Production System" de los años 40, qué
problemas arrastramos en nuestras metodologías de trabajo tradicionales en el entorno
de la consultoría informática, en qué consisten los procesos de mejora continua y qué
métodos –como la monitorización, el análisis de código, los test automáticos, la
programación por pares y más– podemos implantar en nuestra infraestructura para
mejorar el flujo de trabajo y reducir nuestra problemática diaria. Al terminar el curso,
seremos capaces de realizar una profunda revisión de todo nuestro flujo de trabajo de
desarrollo y operaciones y podremos detectar los puntos débiles del mismo para mejorar
significativamente la velocidad de respuesta, la productividad y la visibilidad de todas las
partes de nuestro proyecto, al mismo tiempo que reducimos la tasa de errores y los
tiempos de caída del sistema.

Orígenes y base de DevOps

Historia de DevOps
DevOps es un término usado ampliamente hoy en día en IT para casi cualquier cosa. Se
usa como puesto de trabajo, como nombre de herramienta, como filosofía de vida...
Vamos a ver sus orígenes y con quién y qué se relaciona. Lo primero de todo es conocer el
término del que estamos hablando y del que tanto habéis oído por las redes. Si hacemos
una gráfica de tendencias de búsqueda del término DevOps contra el término Sysadmin,
podéis ver que desde aproximadamente 2009-2010 DevOps no para de crecer y crecer,
mientras que Sysadmin, sin embargo, se mantiene en una ligera caída estable. Y eso que
los Sysadmins no estamos desapareciendo, os lo aseguro. Por cierto, que no os extrañen
los pequeños picos de la gráfica que hay en julio de cada año, que son causados porque el
27 de julio se celebra el "Día de apreciación al administrador de sistemas", una fiesta que
deberíais celebrar. ¿Y por qué lo he comparado con los administradores de sistemas?
Bueno, pues porque el término DevOps es un acrónimo de dos palabras: "developers" y
"operations", esto es, desarrolladores y operaciones, dos departamentos esenciales en el
funcionamiento del mundo IT que hasta ahora han trabajado casi siempre de manera
bastante independiente. Por un lado, por desarrolladores, sí que tenemos una imagen
clara de quiénes son y qué hacen; que son los programadores de toda la vida, vaya. Sin
embargo, puede que la parte de operaciones podáis no tenerla muy clara. En operaciones
englobamos los departamentos que mantienen el funcionamiento de la infraestructura de
IT. Esto es, los administradores de sistemas que trabajan con los servidores y aplicaciones,
los administradores de red que mantienen toda la parte de "networking": redes,
"switches", "routers"... y el "help desk", que según el país podríais llamar mesa de ayuda,
mesa de servicio o atención al usuario, que son el interlocutor directo con los usuarios
cuando encuentran problemas, que se dedican a reportar las incidencias y ayudarles en su
resolución. Conocido el origen sintáctico del término, vamos ahora a conocer su origen
histórico, para lo cual nos tenemos que remontar al congreso Agile Conference 2007 en
Toronto. Andrew Shafer, en ese momento trabajando para Puppet, empresa de la que fue,
de hecho, uno de los cofundadores, prepara una charla exprés sobre la aplicación de la
metodología Agile a la infraestructura. Desafortunadamente o no, no se inscribe nadie a
esta charla excepto una persona: Patrick Debois. Patrick Debois, muy interesado en este
concepto, se reúne con Shafer en uno de los pasillos del congreso. Charlan largo y tendido
y deciden fundar la lista de correo "Agile System Administration" –administración de
sistemas ágil–. En la lista, de la que aún se pueden consultar sus archivos históricos en
Google Groups, trabajan sobre estos conceptos e intercambian información. En 2009
ocurre el congreso O'Reilly Velocity 09 en California, donde se realiza la ya famosa charla
"Diez despliegues al día" de Flickr, en la que se empieza a hablar de la fusión de los
departamentos de desarrollo y operaciones. Os recomiendo encarecidamente que, si no
habéis visto esta charla antes, echéis un vistazo rápido a las diapositivas de la
presentación, que están aún disponibles para visualizarlas. Debois, que en ese momento
lamenta no poder asistir al congreso por la distancia desde su casa, decide montar el suyo
propio en Bélgica: el DevOpsDay 2009, donde se encuentran una buena cantidad de
desarrolladores, administradores de sistema, personal de operaciones para hablar de los
puntos a trabajar y las herramientas necesarias entre los diferentes departamentos para
agilizar el trabajo y los despliegues. Los DevOpsDays se empiezan a multiplicar por todo el
mundo y la abreviatura DevOps se populariza como sinónimo de automatismo y gestión
eficiente de los recursos en IT. A partir de aquí, como podréis intuir en aquella primera
gráfica de tendencias de búsqueda, es cuando empiezan a aparecer y desarrollarse
muchas técnicas, herramientas y teorías de la filosofía DevOps, que aprenderemos a
utilizar.

Objetivos de DevOps
No nos interesará implementar un método de trabajo DevOps si no vemos ninguna
ventaja. Así que vamos a ver cuáles son los principales objetivos que obtenemos o que
buscamos obtener con un flujo de trabajo de este tipo. Aunque dependiendo de la
especialización o del autor de la metodología DevOps que consultemos los objetivos o los
nombres no serán exactamente los mismos, me voy a basar en cinco puntos muy comunes
y sencillos que encontraréis a menudo en mucha metodología. En el mundo tradicional del
desarrollo, estamos acostumbrados a compilar y desplegar muy poco. Con compilar me
refiero a una "release" o versión completa de nuestro proyecto, que normalmente
preparamos solo cada muchos meses o quizá años. Y es que es muy típico ponerse a
programar como locos durante meses y meses, y solo cuando ya creemos tener una
versión completa empezamos a compilarlo y empaquetarlo, y es entonces cuando
empezamos a encontrar todo tipo de errores, problemas de integración, etc. Por lo tanto,
uno de los objetivos que pretendemos cumplir utilizando metodologías DevOps es
mejorar la frecuencia y, por supuesto, la calidad del despliegue. Utilizando herramientas
como el "continuous delivery" o el "continuous deployment" –esto es, la entrega continua
y el despliegue continuo–, compilamos y testeamos nuestro código continuamente cada
vez que se realiza un cambio, y así, por un lado, captamos los errores tempranamente y,
por otro, tenemos siempre listas versiones entregables de nuestro "software". Mejorar el
"time to market" o nuestro tiempo de salida al mercado. Precisamente la aplicación de,
entre otras, las técnicas anteriores nos permiten salir al mercado de manera más ágil al
detectar los errores con celeridad y empezar a trabajar con productos funcionales
tempranamente. Además, la aplicación de estos ciclos de monitorización, testeo continuo
y corrección –que no nos cansaremos de repetir en el curso– nos permite capturar rápido
los errores que se nos escapan al entorno de producción y corregirlos produciendo el
menor impacto posible, reduciendo las tasas y los tiempos de error en nuestro producto.
No solo eso, sino que, además, al trabajar con menores cantidades de cambios cada vez y,
por supuesto, aprovechando toda la monitorización que realizamos, las correcciones se
realizarán en un tiempo mucho más corto al poder encontrar con más facilidad el origen
de los fallos. Los objetivos que buscamos no son triviales ni el proceso a llegar a ello
tampoco, pero una vez puesto en marcha el proceso, cada paso será más sencillo que el
anterior. Así que os animo a seguir investigando el tema.

Toyota Production System

La filosofía de Bobs se apoya en una serie de métodos de trabajo desarrollados en los
últimos 30 años, tanto en entornos empresariales, industriales como tecnológicos. Uno de
los más importantes es el Toyota Production System, que tiene su origen en el Japón de
mediados del siglo 20. El Toyota Production System se origina a través del trabajo de
Sacchi. Toyota, fundador de Toyota. Su hijo Ichiro y uno de sus ingenieros. Taichi o no? El
origen del Toyota Production System viene del sistema de los cinco. ¿Por qué? De Sacchi.
Toyota? Este es un sistema simple en el que se formulan una serie de preguntas o porqués
para conseguir llegar a la raíz de cada uno de los problemas detectados en la cadena de
montaje. En el ejemplo tradicional que mostramos se sigue la falla de un vehículo. El
vehículo no arranca porque la batería está descargada, que lo está porque no funciona el
alternador, porque la correa se ha roto, porque se ha utilizado más tiempo del
reglamentado, porque no se realiza un correcto mantenimiento del vehículo. Donde
llegamos a la raíz del problema. No necesariamente tienen que ser cinco preguntas. Es un
número que Toyota encontró a lo largo de la experiencia como el número más común de
preguntas que había que hacer para llegar a esta raíz. Lo importante no es, por lo tanto, el
número de preguntas, sino el poder encontrar el verdadero problema que hay que
solucionar. Taichi o no, avanza un paso más en estos métodos y se pone como objetivo
eliminar lo que él llama desperdicios o muda en japonés. Y es que ya veréis que se utilizan
muchos términos japoneses y se centra primeramente en siete de ellos en la cadena de
montaje. Los retrasos, la sobreproducción, la realización de tareas innecesarias, el
transporte de productos, los movimientos de los productos o los operarios en la línea de
montaje, el inventario y los defectos de los productos. Para ello, pon en marcha una nueva
lista de palabras japonesas. Las cinco eses. Uno. Sari organizar. Clasificación de los
elementos del puesto de trabajo. El desechar los innecesario. Archivar lo que ya no se usa.
Deshacerse de todas las herramientas que no nos son útiles. Dos Peyton o la ordenación
de tu puesto. Colocar las herramientas de trabajo en orden de uso. Dejar todos los
elementos comunes al alcance del operario. Usar una organización visual o de colores.
Convertir en eficaz el puesto de trabajo. Tres. Seis ocho. Limpieza Limpiar el puesto de
trabajo aprovechando para detectar problemas y anomalías y retornar continuamente el
puesto a condiciones adecuadas de trabajo. Cuatro. Soy ketchup. Estandarizar creando
documentación, identificación de zonas y formando al personal. Señalar las anomalías
comunes que nos encontramos. Y por último cinco. Sin azúcar. Que es el mantenimiento
de la disciplina y seguir mejorando continuamente los procesos. Lo que nos conecta
directamente con el concepto raíz de todos estos sistemas de gestión de procesos, tanto
en el Toyota Producción System como en el Lin Manufacturing y todos los sistemas
similares. El Kaizen o la mejora continua en los procesos. Nos referimos al Kaizen como la
evaluación de los procesos y la introducción de cambios que nos permitan mejorarlos en
pequeños pasos, pero de manera continua. Esto lo podemos ver en técnicas como la
llamada PDA. Esto es plan. Planea. Haz check. Comprueba act. Actúa en una extrapolación
del clásico método científico cada vez que identificamos un punto a mejorar o corregir.
Por ejemplo, con el método de los cinco. ¿Por qué? Planearemos los objetivos y una
posible solución. Haremos la puesta en marcha de la posible solución. Comprobaremos los
resultados de esta nuestra solución. Y si han sido los que esperábamos, convertiremos
este cambio que hemos realizado en parte del estándar de nuestro proceso. En caso
contrario, seguiremos iterando en este bucle, realizando nuevos cambios hasta que
lleguemos al resultado deseado.

El flujo de trabajo DevOps

DevOps: cimientos para tus despliegues
Para poder desplegar y testear de una manera eficiente, necesitamos empezar por unos
buenos cimientos que nos permitan trabajar sin que se tambalee nuestro producto. Así
que os voy a contar unos buenos puntos de partida para vuestra infraestructura. Una de
las mayores causas de problemas en los despliegues en entornos reales es la falta de
testeo previo en entornos que simulen estas condiciones. Ya bien por trabajar con un
conjunto de datos de menor tamaño, con unas versiones de base de datos diferente, con
una cantidad de usuarios menor, una estructura de red diferente. Cuando realizamos el
despliegue en producción, todo falla. La solución para esto es dar capacidad a los
desarrolladores con herramientas de gestión de infraestructura, de generar réplicas de los
entornos de producción, desarrollo o pruebas bajo demanda. El poder realizar pruebas en
cualquier momento contra un entorno que simula la producción sin tener que abrir un
ticket y esperar días a su resolución por parte de sistemas o de operaciones, nos ahorrará
muchísimos disgustos y tiempo. Es común que para poder desplegar o mantener un
software o infraestructura de nuestra empresa necesitemos buscar ficheros de
configuración, scripts, secretos, ejecutable, código o cualquier tipo de objeto en muchos
sitios diferentes repositorios, FTP, discos externos, documentación. Esto puede inducir a
error por las diferentes versiones que nos podemos encontrar de un mismo objeto y a
confusión por la dificultad y tiempo que supone poderlos encontrar todos. La solución a
este problema es crear una única fuente de verdad de todos estos objetos con un sistema
de control de versiones que nos permita buscar todo lo necesario para desplegar nuestros
sistemas en el mismo sitio y de manera ordenada y con mucho énfasis en el control de
versiones que nos permitiría retornar a determinado momento en caso de problemas o
replicar con exactitud la infraestructura que había disponible en cierta fecha o estado del
desarrollo. Cuando tenemos algún problema en nuestra infraestructura, tendemos a
intentar repararlo y parchar el problema que nos hemos encontrado. Puede que,
evolucionando, cambio tras cambio y con el tiempo a un sistema que no coincide con lo
designado en nuestra documentación o diseño y que además es difícil de replicar en caso
de problemas. A la larga se vuelve difícil de gestionar y es conveniente adoptar otro
modelo más mantenible. Como veis, el disponer de esta pequeña o grande, según se mire,
va a ser infraestructura, nos permitirá trabajar de manera mucho más fácil y eficaz y
ahorrarnos muchos disgustos.

DevOps: tests automáticos

En este punto, los desarrolladores ya pueden acceder a una única fuente de verdad y
además disponen de entornos para realizar sus pruebas. Pero muchos de los defectos y
problemas seguirán llegando a producción si no ponemos en marcha un sistema de test
automáticos para nuestro código que se ejecute continuamente y no sólo cuando vamos a
llevar una nueva versión a producción. Para conseguir nuestro objetivo de un producto de
calidad es necesario realizar test continuos de nuestro software sin depender de su
ejecución manual para recibir un feedback continuo sobre los problemas que se van
encontrando. La idea es crear un flujo de despliegue en el que se ejecuten una serie de
test automáticos cada vez que un desarrollador realiza un cambio en el código. Utilizando
herramientas que nos facilitan esta tarea como Bambú, GitLab o Travis, creamos un flujo
de test a ejecutar automáticamente tras cada commit que por ejemplo compilan el
software, lo empaquetan, lo ejecutan, se realizan test unitarios, análisis de código, análisis
de estilo de cobertura. Lanzar todo esto tras cada cambio nos crea un sistema de alerta
temprana, nos sirve como control de calidad obligatorio que debería pasar todo nuestro
código y además nos puede preparar versiones empaquetadas listas para desplegar en
cada una de las versiones de nuestro software. Y para que todo esto funcione hay que
crear una serie de test automáticos que debería ser obligatorio pasar y que generalmente
se clasifican en tres tipos. Los test unitarios son los que sirven para comprobar el
funcionamiento de un solo método o función de nuestro código, para ver que al
alimentarlo con datos devuelve el resultado esperado. Test de aceptación testean la
aplicación completa para verificar a un alto nivel que funcionan como está designado en la
documentación de las historias de usuario. Test de integración verifican que la aplicación
que hemos programado se comunica de manera correcta con todos los servicios externos
a los que debe conectarse para cumplir su cometido. APIs bases de datos. Micro servicios.
Aplicaciones externas. La ventaja que tenemos de poder capturar los errores lo antes
posible. Gracias a estos test se nos invalida si al ejecutar tantos procesos no estamos
recibiendo los resultados de los test a tiempo. Es necesario que los tests se ejecuten
rápido, tanto mejorando el proceso de ejecución como ejecutando en paralelo todos los
que sea necesario. Y para que el ciclo de testing sea todo lo eficiente y rápido posible,
elimina todas las tareas manuales que sea posible para convertirlas en procesos y test
automáticos. Esto nos permite eliminar retrasos y esperas en la cadena de despliegue y
construcción. Por último, aunque casi siempre que pensamos en test lo hacemos en test
funcionales. Es también muy importante integrar también test de rendimiento en estos
flujos. La mayoría de las veces solo nos estamos fijando en si el software pasa o no pasa
las pruebas de integración. Pero a lo mejor estamos pasando por alto un gran problema
de rendimiento que hemos introducido en nuestro último cambio. Monitorizar los
cambios de rendimiento en nuestro software durante los flujos de test nos podría evitar
más de un disgusto.

Despliega con bajo riesgo con DevOps

Los test automáticos de nuestro código se integran muy bien en el tema que vamos a
tratar en este capítulo: los despliegues de bajo riesgo. Lo que podríamos llamar, entre
comillas, como una programación de bajo riesgo al tener en marcha todo tipo alertas para
los fallos más evidentes de nuestro código, lo tenemos además que unir a una buena
política de despliegue. No solo el proceso de "testing" tendría que ser automático, sino
también el de despliegue. Es de mucha utilidad integrar en este flujo de desarrollo una
serie de tareas como el empaquetado del código en un formato listo para el despliegue, la
creación –si procede– de los contenedores o máquinas virtuales necesarias, la instalación
de todos los paquetes o "software" necesario para el despliegue, la subida de estos
paquetes a los servidores, el reinicio de los servicios de la aplicación, la inserción de
"secretos" y contraseñas o ficheros de configuración, la ejecución de test directos contra
la aplicación; por ejemplo, test de navegador... Igual que mencionábamos la posibilidad de
que los desarrolladores crearan sus propios entornos de test bajo demanda y solo con un
clic, es muy interesante que también puedan desplegar todo este código directamente a
Producción. Los desarrolladores, usando la automatización y configuración necesaria
desplegada por Operaciones, deben de ser capaces de responsabilizarse con transparencia
de su código y, con un clic, poder lanzarlo al entorno que deseen, sin "tickets" ni
burocracia. Una vez el despliegue está automatizado, se puede integrar en todo nuestro
flujo anterior proveyendo al desarrollador, tras el paso de todas las unidades de test,
compilación y empaquetado, de un botón o comando que le permita desplegar y además
le devuelva "feedback" sobre la corrección o no de este despliegue y de los problemas que
se ha podido encontrar. Los despliegues no tienen que ser, por lo tanto, una fuente
continua de riesgo ni de errores ni un motivo para subir el estrés de los trabajadores. Este
seguimiento continuo de los errores y problemas del código y todos sus procesos de
automatización nos permitirán desplegar con mucha más tranquilidad en nuestras
infraestructuras o clientes.

DevOps: El feedback entre departamentos

DevOps: Monitoriza
La ley de Murphy nos dice que, si las cosas pueden ir mal, irán mal. Lo mejor que podemos
hacer, por lo tanto, es monitorizar activamente nuestros servicios para darnos cuenta de
que algo va mal lo antes posible. Igual que hablamos en otros aspectos de que hay que
centralizar nuestras infraestructuras de configuración o conocimiento, hay que hacer lo
mismo con la telemetría y monitorización. Es importante dirigir todos los datos de los que
estamos tomando medidas, sean eventos, métricas, "logs"... a un enrutador centralizado
que decida qué hacer con ellas: si almacenarlas a largo plazo, utilizarlas para alertas, hacer
detección de anomalías... Y después de crear nuestra infraestructura, nos tenemos que
asegurar de que llegan "logs" suficientes y con la información adecuada para poder
generar los eventos precisos. Hay que configurar correctamente la severidad de los "logs",
por ejemplo, con el sistema clásico o estándar de categorizarlos en el nivel de "debug",
"info", "warning", "error", "fatal"... e información concreta de la situación generada. De
esta manera, podremos gestionar la necesidad de alertas o localizar el error potencial que
tenemos entre manos una vez le llegue el mensaje a Operaciones. Un investigador de
Gartner recomendaba la siguiente lista de eventos de los que había que generar "logs"
para realizar seguimiento correctamente: eventos de autenticación y autorización,
accesos al sistema y datos, cambios a la aplicación y al sistema, cambios a los datos,
entrada de datos inválidos, recursos (memoria, disco, etc.), salud y disponibilidad del
servicio, arranques y paradas, fallos y errores, disyuntores y "circuit breakers", tiempos de
retardo y éxito o fallo en las copias de seguridad. Y siento que me voy a repetir
continuamente, pero hay que imbuir una cultura de la telemetría en el proyecto y
conseguir que se convierta en un trabajo diario y que todas las partes de vuestra
aplicación y vuestra infraestructura hablen y se entiendan con el sistema de telemetría
que uséis. Ya sea la herramienta Stats de Telegraph, Fluende o cualquiera que uséis para
realizar la toma de datos, una vez elegido el "framework", habrá que disponer de una
librería adecuada que nos permita extraer telemetría de cualquier punto de la aplicación y
mandarlo a nuestro "router" de eventos y telemetría. Y para que la información sea útil,
hay que facilitar a todos los componentes de Operaciones el acceso a esta información.
Tienen que tener la capacidad del autoservicio, del poder acceder a una web o panel de
control donde revisar las gráficas ya generadas o crear las suyas propias y poder ver con
claridad qué efecto tienen los cambios en todo el conjunto de tus aplicaciones.

DevOps: Analiza
Es imposible revisar todos los datos que recibimos de la monitorización; y en su mayoría,
vistos de manera global, son innecesarios. Y es, por lo tanto, imprescindible que
realicemos un buen análisis de ellos para que tengan algún sentido. El primer recurso y el
más socorrido sería utilizar medias y desviaciones estándar. Si nuestros datos de
telemetría tienen una distribución gaussiana, que la mayoría de las veces no la tienen,
podría ser una buena idea establecer una alerta cada vez que la telemetría excede en X
veces la media de nuestros datos. Y aquí nos puede llegar nuestra primera duda: ¿y con
qué datos debemos poner las alertas? Si ponemos alertas en demasiados valores,
corremos el riesgo de molestar o despertar excesivamente al personal de operaciones,
muchas veces de manera incorrecta. Y es que cuando nos ponemos a monitorizar
utilizando las medias de nuestros datos, nos encontramos el primer problema: los picos
continuos de nuestro tráfico hacen saltar las alertas continuamente y elevar el nivel de
alerta hasta un punto en el que no se produjera este problema destrozaría todo el sentido
y la utilidad de las alertas en sí mismas. Para ello, el primer método que podemos utilizar
son las medias móviles. En vez de realizar –o dibujar, más bien– una toma de datos
instantánea de cada punto de la gráfica, juntamos los valores de los últimos 5, 10 o 15 min
para realizar una media, lo que suaviza extremadamente las gráficas y nos ayuda a evitar
estos picos que nos hacen saltar falsas alarmas. Y aquí llegamos con el segundo problema:
el truco de la media móvil nos detecta picos de tráfico continuados de periodos más largos
que la media móvil que se está calculando, pero no detecta auténticas anomalías, como
podría ser el caso de esta gráfica. Como podéis ver en este tráfico de media móvil, no
tenemos picos hacia arriba, sino que tenemos tres anomalías de bajada de tráfico que
podrían coincidir con algún tipo de problema o incidencia. Para solucionar este problema,
deberíamos usar un algoritmo de detección de anomalías, ya bien un Kolmogorov-Smirnov
o, por ejemplo, la herramienta que ha liberado Twitter para la detección de anomalías. Es,
por lo tanto, importante pensar que en cualquier método de monitorización y detección
de anomalías tendremos varios campos en los que trabajar: el dónde monitorizamos, el
cómo monitorizamos y qué problemas por arriba y por abajo de la gráfica no podemos
monitorizar que sean interesantes para nuestra producción.

DevOps: Feedback y reviews

El flujo de información entre los desarrolladores y los sistemas es muy importante. La
revisión entre pares antes del despliegue y la telemetría de los sistemas tras el despliegue
son información fundamental para el éxito. Por ejemplo, en GitHub podemos utilizar el
proceso de los "pull request". El desarrollador que quiere trabajar en algo nuevo crea una
nueva rama, es decir, una copia del código que está dedicada exclusivamente a esta
funcionalidad o a ese "bug" en el que va a trabajar. Aplica en esa rama del código todas las
modificaciones y, cuando tiene su trabajo listo, abre lo que se llama una "pull request",
esto es, una petición al administrador del repositorio para unir su código modificado con
el código principal. Durante este proceso, se pueden recibir comentarios sobre el código
desde los otros programadores y, si todo es correcto, aceptar estas modificaciones. En
algunos proyectos de "software" libre, como en este caso Coreboot, utilizan herramientas
de revisión de código como Gerrit. En Gerrit, habrá que pasar revisión de todo el código
que enviamos al repositorio por un determinado número de programadores o revisores,
que nos tendrán que dar su visto bueno y comentarios para que el código pueda
aceptarse en el repositorio. En la sección de las verificaciones podemos ver cómo,
dependiendo del tipo de usuario, pueden ofrecer más o menos puntos positivos por sus
votos. Durante todos estos procesos, como veis, se reciben comentarios de diferentes
compañeros de proyecto aceptando o debatiendo los cambios. Y, utilizando herramientas
de "bots", pueden lanzar procesos automáticos como la aprobación del código o el
lanzamiento de unidades de test, como en este "commit" del repositorio de "kubernetes",
que tras un comando escrito en el chat lanza 9 test de código, errores e integración de
manera automática. También tenemos la programación por parejas o "pair programming",
que es un sistema o metodología de trabajo de programación que se popularizó al
principio de los 2000 en los momentos de alza del "extreme programming" y del "agile".
Consiste en la formación de grupos de dos programadores: el que toma el rol del
controlador y es el que realiza la programación, y otro es el navegador, que es el que
realiza la revisión del código que está escribiendo su compañero. El trabajo conjunto hace
que se transfieran habilidades entre ellos y se facilite la resolución de problemas. Pero,
aun así, el exceso de revisiones y consultas en el código nos puede ocasionar problemas.
En el gráfico que vemos, proveniente de una charla de Google acerca de sus procesos de
desarrollo, se puede ver la relación entre el tamaño de una proposición de cambios de
código en el eje X y en el eje Y el tiempo que se tardó en aprobarlo. Como vemos, hay una
relación muy fuerte directa entre el tamaño del código y el tiempo que se tarda en
aprobar. La creación de caminos de trasmisión de información fomenta el trabajo
conjunto hacia unos mismos objetivos, facilita la resolución de problemas y su alerta
temprana y mejora la adquisición de conocimiento de los programadores.

DevOps: El aprendizaje técnico

DevOps: Cultura de trabajo
No sólo vamos a crear el aprendizaje a base de documentación, sino que debemos
establecer una cultura del conocimiento y el aprendizaje en nuestra empresa que nos
produzca un hábito de compartir y mejorar la información entre todos. Y el objetivo no es
otro que mejorar el autodiagnóstico, conocer mejor nuestra aplicación, cómo se comporta
para al mismo tiempo mejorar la capacidad de recuperación y de reparación que podamos
tener ante cualquier eventualidad. Uno de los sistemas de políticas o de principios que se
propone en este sentido es la cultura del caos, que no tiene nada que ver con poner
nuestra oficina patas arriba, sino con poner patas arriba nuestra aplicación. Podéis
consultar, por ejemplo, Principos of Chaos, Punto o RG Los principios del caos en los que
hay un grupo de programadores que proponen determinados principios de cómo hacer
fallar nuestra aplicación a propósito, cómo crear el caos dentro de nuestros sistemas
distribuidos para aprender cuál es la manera que tiene de fallar y cómo podemos hacer
que cuando falla, lo haga de la manera más grácil o más blanda posible, por decirlo de
alguna manera. Se basan simplificando en cinco hipótesis una construir una hipótesis
alrededor de un estado estable de la aplicación, como llaman ellos, que es no fijarse en el
interior de la aplicación y cómo está funcionando, sino en fijarse cómo funciona el
exterior, que son los datos que vuelca y si lo está haciendo de forma correcta. Otra que es
basarse en eventos del mundo real. Basarse en la aleatoriedad que nos puede ocurrir o en
el problema que podemos tener en nuestra nube. Nuestro proveedor de que pueda morir
un nodo de que pueda fallaron balanceador de que pueda fallar una red, etc. Además, nos
piden que corramos experimentos en producción, que ejecutemos estas maldades, estas
monerías en nuestros servidores de producción con tráfico real para poder capturar con
realidad con un tráfico auténtico. ¿Cómo serían los resultados de nuestros experimentos?
Además, piden que auto maticemos los experimentos para que corran continuamente. Es
decir, que en nuestro día a día tengamos procesos que nos estén haciendo perrerías a
nuestros sistemas, que nos estén rompiendo nodos, que nos estén estropeando la calidad
de la red a propósito, en ciertos sitios para probar que seguimos manteniendo esta
calidad. Y al final del todo lo que dice es que minimizamos el radio de impacto que una vez
vayamos viendo cómo funciona toda nuestra aplicación. ¿Qué piezas fallan? ¿Cuándo
fallan? ¿Cómo se rompe? Podamos hacer que la aplicación, incluso cuando se rompe, se
rompa de la manera más blanda o de la manera que podamos decir que afecta menos a
nuestros usuarios. La idea es realizar todo este esfuerzo de ingeniería del caos para que,
en el mundo real, con problemas reales, con fallos reales, nos aseguramos de que los
efectos negativos de los fallos de nuestra aplicación son los menores posibles. Toda esta
idea proviene de un experimento de Netflix en Amazon. En Amazon Web Services. Es
cuando estuvieron escalando y convirtiendo todos sus sistemas para que fueran, digamos,
connected, es decir, nativos para la nube. Estuvieron pensando en la escalabilidad, en
cómo funcionaba, en cómo fallaría, y decidieron inventar una pieza de software que se
llamaba Cash Monkey, el mono del Caos. Este software lo que hacía era aleatoriamente
destrozar recursos sobre los que corría Netflix en producción para ver cuál era su sistema
de fallo, cuántos usuarios quedaban sin servicio, por dónde fallaba cuando había algún
servicio de backend que no estaba funcionando y a partir de ahí mejorar todos los
webservice es el funcionamiento interno de la aplicación. Todo lo que es el flujo en
general de datos para que cada vez que fallar alguna pieza ya fuera a propósito o ya fuera
de manera fortuita, que la aplicación pudiera responder de la mejor manera posible ante
los usuarios mientras se reparaba ese problema. Y con todo esto lo que hay que
establecer es una cultura del aprendizaje. Hay que eliminar el miedo al fallo. El miedo a los
despidos. El miedo a la culpa a los que podrían tener sobre un fallo. Un problema que
hemos tenido en la aplicación para poder trasladarlo y convertirlo en un aprendizaje sobre
los fallos que hemos tenido. Que cada vez que tengamos un problema podamos revisar
cuál es la raíz, cómo se ha producido, cómo podemos mejorarlo y cómo podemos evitar
que ocurra en un próximo caso. Para ello es muy importante poner en marcha un
postmortem. Un post Mortem, concretamente uno que sea libre de culpa, un blog inglés
post-mortem que dirían los americanos. Tiene que ser una reunión en la que vayan todos
los ingenieros, todos los técnicos, todos los jefes de proyecto, todas las personas que
puedan ser responsable en una manera mayor o menor del fallo que hemos tenido para
que se pueda hacer una limpieza, ya no de culpas, sino de la resolución del problema, del
origen del mismo, de cómo se puede evitar que ocurra de nuevo y de cómo ha sido todo
el hilo desde el inicio del problema, desde la primera notificación hasta su resolución
completa. Hay que pensar siempre que los post-mortem no son nunca para realizar
ninguna carga de culpa, no son para despedir a nadie, sino para evitar que vuelva a ocurrir
de nuevo. Una vez hemos creado el caos en nuestros sistemas, hemos mejorado la
respuesta a estas incidencias. Hemos reducido el daño que recibe la aplicación cada vez
que encuentra uno de estos fallos y cada vez tenemos menos alertas en nuestro sistema.
Contra todo pronóstico, lo que tenemos que hacer es reducir el margen de tolerancia de
nuestros sistemas de monitorización para que cada vez nos avise de fallos más pequeños y
triviales y tengamos un sistema más perfecto.

Comunicación y conocimiento en DevOps

Es clave, al igual que centralizamos nuestro código y nuestra configuración, el disponer de
canales claros de comunicación y documentación tanto para los humanos como para los
procesos y, además, que haya visibilidad y facilidad de acceso para todos los eventos que
están ocurriendo en el día a día. Hoy en día, con todos los sistemas de comunicación y
colaboración que tienen tanto uso en las empresas, como Slack, Hipchat o Stride,
Mattermost, etc., son muy útiles y muy utilizados también los "chatbots" informativos. Te
advierten de las siguientes reuniones que tienes en tu departamento, te sirven para
reservar una sala, te avisan de la completación de un despliegue o de una compilación de
una aplicación y a veces responden a comandos específicos para informarte de estas
ocurrencias. Los hay más serios o más humorísticos, pero en general son un gran atajo y
ayudan para mantener la visibilidad de los procesos de los sistemas dentro de los
entornos comunes. Y la evolución, no extremadamente técnica pero quizá sí organizativa,
sería lo que se llaman "chat ops", bots con los que no solo se responde a comandos
sencillos para recabar o almacenar información, sino que además están conectados a más
o menos complejos flujos de trabajo de los servidores o servicios y nos permiten realizar
operaciones directamente desde la ventana de chat como si fueran un administrador de
sistemas. Por ejemplo, lanzar un despliegue, mantener un contenedor o escalar un grupo
de servidores. A nivel menos operativo, pero no menos importantes, es vital para un
proyecto la estandarización de la documentación: creación de plantillas de documentos
obligatorios para los proyectos y aplicaciones, requisitos de información mínima que ha de
ser puesta al alcance de los usuarios para la correcta operación de las aplicaciones; si es
posible, documentación a través de los test como en el paradigma TDD, automatización de
los sistemas de creación de documentación a partir del código, etc. Hay que reservar
tiempo para la creación de conocimiento. Toda la creación y gestión de la documentación
suele quedar en los proyectos relegaba a un par de trozos de texto cortados y pegados en
los últimos 30 min asignados al cliente. La documentación también tiene que ser un
participante de primera clase en el proyecto y para asegurarnos de su completitud y
calidad hay que reservar, por los jefes de proyecto, tiempo específico para su creación. Y
un gran caldo de cultivo para el conocimiento son las charlas de formación interna entre
los propios empleados: el compartir sus experiencias, ya sea en la resolución de un
problema curioso o dificultoso, el aprendizaje de un nuevo "framework", plataforma o
sistema de trabajo, consejos para mejorar el manejo de una de sus herramientas de uso
diario, o incluso una charla para aprender cómo no resolver determinado problema que se
les atascó una vez en el departamento. Todo esto creará un flujo de información y
realimentación del aprendizaje muy positivo para el equipo.

Herramientas DevOps
DevOps: Integración y despliegue continuos
En el centro de casi cualquier plataforma DevOps podemos encontrar herramientas de
integración continua y despliegue continuo, tanto "online" como integradas dentro de
nuestros servidores. Veamos unas cuantas. Por supuesto, la primera solución de la que os
hablo es de Jenkins, que es prácticamente el más clásico o el más conocido de los sistemas
de CI. Es "open source", es heredero de un sistema de CI más antiguo que Jenkins llamado
Hudson. Es una CI muy clásica, pero que tiene gran cantidad de "plugins" para casi
cualquier cosa: para conectar con la nube, para autoescalar, etc. Proviene del ecosistema
Java. Era muy, muy conocido y muy popular dentro de Java y además se está poniendo
muy al día con una reestructuración de código que están haciendo que se llama Blue
Ocean. Gitlab CI es un "software" "open source" que es un sistema completo para gestión
de vuestro código. Tiene el sistema de control de versiones, que está basado en Git.
Podría decir, vagamente, que es una especie de clon de GitHub, tiene sistema de gestión
de incidencias, tiene sistema de DevOps para despliegues automáticos, tiene "workers"
locales o en la nube para hacer nuestras compilaciones, tiene por supuesto la integración
continua y se puede instalar tanto en nube, puedes tener también una instalación
administrada por ellos de pago o puedes instalártelo en local. Aparte, los test para la CI
están integrados dentro del código y por lo tanto están versionados. Los test que lances
para las aplicaciones serán dependientes de la versión y por lo tanto podrán ir
personalizados para cada rama o versión que estés ejecutando. Atlassian Bamboo es un
"software" cerrado, un "software" privativo que es parte de la suite Atlassian. A día de
hoy, solo está la versión On Premises, aunque antes había una versión también de la nube
que podías pagar aparte. A día de hoy, si quieres una versión Cloud, tendrás que usar la
que está gestionada por Bitbucket Pipelines, ya que Bitbucket, que es propiedad también
de Atlassian, tiene una versión un poco más sencilla, pero "cloud" de integración continua,
que a lo mejor te puede ser suficiente. Las licencias de Atlassian Bamboo se compran por
cantidad de agentes. Circle CI es otro "software" cerrado, otro "software" privativo que lo
tienes en versiones "enterprise" On Premise o también en versiones en la nube. Corre
tanto en Linux como en OS X, por lo tanto, te permite hacer compilaciones de "software"
de OS X y te cobran las licencias ya bien por "builder", ya bien por usuario. Travis CI tiene
dos versiones: tiene On Premises o en la nube. Ambas dos son propietarias, son de
"software" cerrado, y las licencias de Travis CI se cobran por trabajos simultáneos.

DevOps: Monitorización
La monitorización, esencial para saber el estado de nuestra plataforma, debe de ser capaz
de captar información de todos nuestros servicios y mostrarla de una manera útil. Dentro
del "software" de monitorización, uno de los que más solera tiene, y quizá en algunos
ambientes sea de los más conocidos, sería Nagios o su "fork" Icinga. Es un sistema de
monitorización muy clásica orientado sobre todo a sistemas, a cacharros físicos –por
decirlo de alguna manera– y funciona con agentes que se conectan como NRPE, NRDP,
NSClient++, NCPA... y además se puede conectar a través de SNMP a servidores SNMP
para hacer extracción de datos de estado. Tiene un gran catálogo de "plugins" que puede
servir para realizar extensiones a su funcionalidad. Quizá se le tiene en mente como un
poco chapado a la antigua para lo que es el estado del arte actual de la monitorización.
Telegraf y Statsd son dos agentes ligeros, o muy ligeros casi cabría decir, que hacen
extracción de datos de los nodos y envían a bases de datos de tiempo información sobre
ellos. Telegraf funciona de manera "pull" extrayendo datos o con "plugins", aunque tiene
la opción de un "listener", es decir, de abrir un puerto para recibir información sobre estas
estadísticas. El "backend" que utiliza por defecto para almacenar la información es
InfluxDB, la base de datos de eventos de tiempo, aunque tiene "plugins" para Graphite,
Prometheus, ficheros, etc. En Statsd, quizá la orientación es un poco diferente o casi al
revés. Es un agente ligero en el que tiene un puerto, un "listener", en el que recibe
contadores directamente de las aplicaciones. Son las aplicaciones las que le mandan
información a él. El "backend" por defecto que utiliza es Graphite, pero tiene "plugins"
para InfluxDB, Mongo, StackDriver, etc. Graphite y Grafana serían las partes visuales. Lo
que hacen es conectarse a una base de datos de eventos de tiempo o una base datos en
general –soportan Graphite, InfluxDB, Prometheus, CloudWatch, etc.– y visualizarlo según
nuestras reglas, según las plantillas que nosotros creamos para poder tener visibilidad de
todos los eventos que nosotros creamos oportunos. Tiene integración con alertas y
además podemos establecer determinados niveles de alerta para visualizarlas, y tiene
soporte de un montón de "plugins" para extraer información de servicios externos que no
son su "backend" habitual como Graphite o InfluxDB. AWS CloudWatch y Google
StackDriver son dos sistemas de monitorización como servicio que están cada uno
desplegados en su respectiva nube y que están integrados con todos sus servicios.
Realizan monitorización, "logging", alertas, etc. y tienen integración con procesos
externos, tanto como para recibir datos y guardar la monitorización como para abrir sus
datos al exterior y que podamos tomar la información de sus eventos. Pingdom y
StatusCake son dos monitores clásicos de disponibilidad de páginas web, de "sites". Lo
que hacen es conectar remotamente al puerto que nosotros designemos, al 80 o al 443, y
verificar que la página está activa y no se ha caído, que sigue funcionando. Tienen varios
servicios, como monitorización de certificados SSL para evitar que nos pille el toro con el
tema de las caducidades de los certificados, control de "uptime" de los "sites", guardan
una base de datos de cuántas son las caídas, de cuánta duración y nos pueden decir el
"uptime" de funcionamiento de nuestros "sites". Tienen sondas repartidas
geográficamente. Esto es, las sondas que realizan las conexiones a nuestros "sites" para
comprobar que están activos no están localizadas solo en un sitio, sino que tienen decenas
de ellas por todo el mundo para ya bien evitar o incluso mostrar problemas de red que
nos podían evitar una falsa alarma dentro de un "site". Aparte, soportan envío de alertas
por Pushover, por SMS y algunos servicios adicionales. NewRelic y Rollbar entran en una
categoría un poco diferente de monitorización. Están más orientados a lo que se llama el
APM: "Application Performance Management", es decir, la gestión de monitorización del
"performance", del rendimiento de las aplicaciones. Monitorizan directamente el
rendimiento, tanto de "front", como de "back", como de móvil. Tienen test de percepción
de rendimiento por el usuario, por los tiempos de carga. También vigilan y tienen control
sobre los errores que tiene la aplicación. Producen "logs" de ello y además pueden volcar
alertas en el caso de pasar algún tipo de límite, de "threshold". Y además soportan
múltiples lenguajes y "frameworks" en los que se pueden integrar para extraer estos datos
de "performance".

DevOps: Alerta
Tanta monitorización no nos servirá de mucho si no tenemos un sistema de alertas que,
de día o de noche, nos haga saber si hemos perdido el control de algún servicio. Kapacitor
es un "software" que se conecta a nuestro InfluxDB para realizar extracción de datos con
"Influx Query Language". Es capaz de detectar anomalías con los diversos "plugins" que
contiene analizando los flujos de información. Es capaz de reconvertir esos flujos de
información y volver a insertarlos luego en InfluxDB. Está orientado a acciones. También
se pueden programar anomalías personalizadas con un sistema de UDF. Y es capaz de
integrarse, entre otros, con HipChat, OpsGenie, Alerta, Sensu, PagerDuty, Slack, etc.
OpsGenie, VictorOps y PagerDuty son sistemas de gestión de turnos de guardia y
operaciones. Son capaces de hacer triaje de los eventos que reciben, pueden enrutar
llamadas y alertas según horarios, preferencias, niveles, escalado, etc. Pueden
automatizar respuestas respecto a las alertas que reciben para ir creando eventos
automáticos y nos ayudan a realizar los informes "post mortem" después de una alerta o
de una operación o de una incidencia. Pushover es un sistema muy sencillo, pero muy
eficaz, de notificaciones móviles. Hace una cosa y la hace bien, que es enviar
notificaciones a Android, iOS y equipos de escritorio y gestionarlo a través de grupos.
Además, tiene un sistema que le permite integrarse con terceros para enviar estas
notificaciones.
La infraestructura como código en DevOps
Aprovechando esa fuente de la verdad única que deberíamos tener en nuestro proyecto,
podemos almacenar toda la configuración de la infraestructura y servidores en forma de
código y gestionar los cambios como si fueran versiones de nuestro "software". Ansible es
un "software" que permite automatizar el provisionamiento de "software", la gestión de
configuración, el despliegue de aplicaciones... tanto en máquinas virtuales como físicas. Es
parte de RedHat, está basado en Python, el formato que usa es el formato "push", es
decir, el cliente Ansible se conecta a los "host" que tiene que configurar y les empuja, les
envía la configuración necesaria. Puede funcionar con o sin servidor y lo puedes utilizar
tanto On Premises como en un servicio en la nube llamado Tower. Las licencias para el
servicio Tower se compran en número de bloques de nodos. Chef es otro sistema parecido
de provisionamiento, configuración y despliegue de aplicaciones que está basado en Ruby
y Erlang. en este caso el modelo es "pull", es decir, los nodos que queremos configurar
contienen un cliente Chef que se conectan al servidor y se traen la configuración y la
ejecutan. Tienen tanto instalación como On Premises, como en forma de servicio en la
nube, que se llama Chef Automate, y se pagan las licencias por número de nodos. Puppet
es aún otro sistema más de automatización y de orquestación, que está basado en C++ y
en Clojure, aunque antiguamente estaba basado en Ruby. Al igual que Chef, utiliza un
modelo tipo Pull –es decir, con un cliente en los nodos a configurar– y tiene tanto
versiones "enterprise" como "open source". Salt Stack es un sistema mixto también de
orquestación, provisionamiento, configuración, etc. que tiene tanto "push" como "pull".
Funciona de las dos maneras: empujando la configuración y tomándola desde un servidor.
Está basado en Python y dispone tanto de versiones "enterprise" como "open source".
Finalmente tenemos el "stack" HashiCorp, que nos lo puede hacer prácticamente todo.
Está basado en Go, tiene un sistema de uso "push", es decir conectándose a los sitios
necesarios para empujar la configuración. Y tiene varios módulos: Primero, Packer como
construcción de imágenes, es decir, es un "software" que se utiliza para construir todo
tipo de imágenes para máquinas virtuales, contenedores, etc. tanto en la nube: de
Amazon Web Services, Google Cloud Engine, para Azure, como para local: para Docker,
para VirtualBox, KVM, etc. Tenemos también Terraform, que es un constructor,
orquestador de infraestructura. Tiene una serie de "providers", de "plugins" que puedes
conectar a diferentes nubes: Google Cloud, Amazon, etc. y nos permite, partiendo de unas
plantillas basadas en unos ficheros de configuración que nosotros podemos mantener en
el código fuente, desplegar y mantener automáticamente toda la infraestructura de uno
de nuestros proyectos. Podemos mantenerlo en nuestro repositorio de código, ejecutar
los cambios directamente en estas plantillas cuando agregamos una máquina, cuando
cambiamos la cantidad de un escalado... Podemos aplicarlo con Terraform y él
automáticamente se encargará de conectarse a la API del servicio que estemos utilizando,
de preocuparse que todo está exactamente igual, que la receta, que la plantilla que
tenemos hecho... y si no está igual, de llegar a ese estado como haga falta. Consul es un
servicio relativamente pequeño que se utiliza para descubrir otros servicios. Lo que hace
es recibir conexiones de servicios que están públicos o que quieren ser públicos, que
informan, se anuncian para saber dónde están sus conexiones, dónde está su IP, dónde
está su puerto, cuáles son sus valores de configuración. Al mismo tiempo, otros servicios
que quieren conectarse a ellos, lo que hacen es consultar a Consul y utilizarlo como una
especie de guía, de páginas amarillas para saber qué servicios están disponibles, cuándo
aparecen, cuándo desparecen y cómo se pueden conectar a ellos. Y por último, tenemos
Vault como gran almacén de "secretos". Permite almacenar de manera cifrada y
conectado a muchos sistemas diferentes de nube, de gestión de claves nuestras
contraseñas, nuestras claves, nuestros certificados, etc. para tenerlos gestionados de
manera segura. Todo este "software" dispone tanto como de versiones "open source"
como de versiones de servicio en la nube.

Comunicación y ChatOps
Las herramientas de comunicación nos van a permitir que los trabajadores se comuniquen
eficientemente y que, gracias a ChatOps, puedan también tener "feedback" desde los
procesos o incluso lanzar operaciones desde el chat. Si queréis realizar algún tipo de "bot"
para ChatOps o para mantenimientos, quizá un buen punto para arrancar sería Hubot.
Hubot es un "bot" que se originó en GitHub, lo programaron ellos y lo utilizaron para sus
servicios internos. Es "open source". Se puede extender con muchos "plugins", y de hecho
lleva unos cuantos, integrados para gestión de imágenes, para integrarse con Google
Maps y con otros procesos, y se puede conectar con muchos servicios externos: con
HipChat, Slack, Gitter, XMPP, etc. Atlassian Stride viene a ser lo que es el antiguo HipChat,
que está desapareciendo o ya casi ha desaparecido del todo y este es su sustituto, que
tiene unas cuantas funcionalidades que nos pueden venir muy bien. Por un lado, tiene API,
por lo tanto, podemos realizar nuestras integraciones. Y tiene un MarketPlace en el que
podemos localizar integraciones, aplicaciones, etc. que se conectan a nuestro Stride. Por
supuesto, dispone de "bots" –tiene compatibilidad con ellos–, de integraciones –por
supuesto, teniendo API– y lo podemos usar en la nube como servicio, no lo podemos
instalar. Slack vendría a ser el más conocido de todos, seguramente. Tiene una famosa API
Web con la que nos podemos integrar externamente. Tiene "apps" para su uso en
móviles. Tiene la facilidad de tener "bots", ya bien porque se los programes tú o porque
utilices uno de los que ya existen, y de hacer integraciones con mucho "software" externo.
Y solamente se puede utilizar en la nube como servicio, no puedes instalártelo tampoco
en tu máquina. Finalmente tenemos Mattermost, que sería, digamos, la versión "open
source" de todos estos anteriores. Tiene una API Web, dispone de "apps" para móvil. Los
"webhooks" a Mattermost para lanzar integraciones son compatibles con los de Slack, por
lo tanto, una migración puede resultar bastante sencilla. Dispone de "bots", puedes
realizar tus propias integraciones o utilizar algunas de las que ya existen. Lo puedes
instalar On Premises o, por supuesto, en una nube, en una máquina virtual tuya. Y si
instalas Gitlab –está disponible en el interior–, solo necesitas activarlo para poder
utilizarlo. Mattermost es "open source", pero también dispones de dos versiones
"enterprise" que puedes usar con un poquito más de funcionalidad.