Imagina que un arquitecto hace el diseño de un edificio innovador, que rompe paradigmas y que estará en las portadas de todas las revistas. Todos querrán ver el edificio y querrán tomarle fotos. Solo hay un pequeño problema: el arquitecto no construye el edificio, solo lo diseña.
Ahora imagina que tú eres el ingeniero a cargo de la construcción del edificio. Quizás lo primero que pienses sea: “esa huevada se va a caer”. Sin embargo, tienes que construirlo y asegurarte de que no se caiga porque es tu trabajo.
Pero, si se cayera, ¿de quién sería la culpa? ¿del arquitecto por diseñar algo que desafía las leyes de la física? ¿o del ingeniero por no ser capaz de llevar esa innovadora visión a la realidad? Seguramente se terminen echando la culpa uno al otro sin llegar a un acuerdo.
Pero tú qué piensas, ¿de quién es la culpa? ¿Del arquitecto, o del ingeniero 🤔?
El mismo problema ocurre en el mundo del software. Solo que ya no es un edificio, sino una aplicación o un sitio web. Si la web se cae, al igual que el edificio, ¿de quién es la culpa? ¿la persona encargada de escribir el código o la persona que implementó ese código en los servidores?
DevOps intenta terminar con esa pelea. Acabar con ese muro de la confusión. Si has escuchado el término DevOps pero no tenías claro de qué se trata exactamente, en este blog podrás solventar todas tus dudas.
Programadores VS Sistemas
En el desarrollo de software existen dos equipos con roles muy importantes: los programadores, que son los que crean el software, escribiendo el código e implementando soluciones, y el equipo de TI o sistemas, que se encarga de la configuración de la infraestructura, servidores y en general, que todo funcione.
Los programadores abrazan al cambio porque están constantemente creando nuevas características o escribiendo mejoras al software y quieren ver esas mejoras en producción lo antes posible. Le decimos producción a la etapa del software en que los usuarios finales reciben los cambios.
Mientras tanto, el equipo de TI abraza la estabilidad, que todo funcione y nada se caiga. Ellos saben que cada nuevo cambio de los devs tiene la posibilidad de tumbar algo.
Entonces: un equipo quiere el cambio, y el otro, desea que nada cambie. O como diría el joker: ¿Qué pasa cuando una fuerza imparable se enfrenta a un objeto inamovible? ¿Quién gana?
En realidad, no gana nadie, sino que pierde la empresa porque no puede entregar nuevas mejoras a sus clientes y no tiene un producto estable. Y además, la compañía tiene a sus equipos en discusiones constantes, lo que les hacen perder el tiempo. También pierden los clientes, porque pueden estar esperando nuevas características, o que se mejore ese bug que lleva tiempo sin corregirse y se cansen de esperar y busquen opciones. En resumen: no gana nadie, y pierden todos.
Esta brecha entre programadores (devs) y sistemas (ops) se conoce como Muro de la confusión porque ambos equipos trabajan de manera aislada, comprenden sus propias tareas pero no el proceso en su totalidad. Aquí es donde entra DevOps.
¿Que es DevOps?
Devops no es una tecnología, no es un software, ni un framework o librería. Tampoco es un rol en la empresa. Si comprendiste por qué surge el muro de la confusión, te quedará claro que DevOps.
Realmente es un cambio en el pensamiento del equipo de programadores y de sistemas. Un cambio en su manera de trabajar, un cambio en sus procesos y las herramientas que utilizan. Por si quedaba alguna duda: DevOps viene de juntar Dev (programadores) y Ops (operaciones de TI).
Entonces, DevOps es un conjunto de cultura, procesos y herramientas para entregar actualizaciones de software más rápido, garantizando la calidad del código, la estabilidad de la aplicación y evitando, así, el aislamiento de los equipos.
5 conceptos clave de DevOps
- Cultura, procesos y herramientas
- No por usar ciertas herramientas ya haces DevOps. Si no hay un cambio organizacional a nivel de cultura y de procesos, no se va a derribar el muro de la confusión. De hecho, este es el principal reto al implementar DevOps en una organización: creer que es solo el uso de herramientas.
- Evitar el aislamiento de los equipos
- Al cambiar la cultura y los procesos podemos implementar el uso de herramientas que hagan que en lugar de haber dos etapas separadas en el desarrollo de software (devs y ops), sea un único ciclo, donde todos colaboran. Y si algo falla, el responsable es el proceso, no las personas.
- Garantizar la calidad del código
- Con las herramientas adecuadas se pueden hacer revisiones (tests) automáticos al código para evitar que el código de un programador entre en conflicto o rompa la funcionalidad de otro desarrollador.
- Garantizar la estabilidad de la aplicación
- Con las herramientas adecuadas de operaciones y monitoreo, se garantiza que el sistema sea estable y no se caiga. Y si algo falla, podemos recibir alertas rápidas de qué pasó, donde pasó y corregirlo a alta velocidad.
- Entregar actualizaciones de software más rápido
- Finalmente, con el cambio de cultura y procesos, además del uso de las herramientas adecuadas, podemos entregar actualizaciones de software más rápido, haciendo que los clientes estén satisfechos y que la empresa comience a crecer.
El rol de DevOps NO EXISTE
Devops, como ya explicamos, es el cambio de cultura, procesos y herramientas. Por lo tanto, no existe como tal el rol de DevOps, ingeniero de DevOps o términos similares. Suele pasar que algunas empresas ponen ese tipo de roles en sus búsquedas pero en términos específicos, no es correcto.
El profesional que se encarga de implementar DevOps en un equipo es un SRE: Site Realibility Engineer (en español: Ingeniero de confiabilidad del sitio). El término SRE viene de antes de la implementación del término DevOps, pero en la práctica, es lo que hace un SRE: implementar mejoras en los procesos y en el uso de las herramientas que garanticen la entrega de software confiable y de calidad.
Así que ya sabes: quien implementa DevOps, se llama SRE.
Ciclo de vida del software
Si buscas DevOps en Google y te vas a la sección de imágenes, te encontrarás muchas ilustraciones de infinitos, que representan un ciclo que nunca se detiene. Se trata de la representación de la idea de DevOps, que el ciclo de vida del software nunca se detenga, por nada, y está dividido por etapas:
Dev
- Plan
Esta es la etapa en la que se analizan los requerimientos y se planifica cómo desarrollar el proyecto, dependiendo de la metodología que usen. Por ejemplo, en Scrum se definen historias de usuarios y entregables del primer sprint.
- Code
En este paso, los devs empiezan a escribir el código de la aplicación según las tareas que tengan asignadas en el paso anterior.
- Build
El código de todos los programadores debe integrarse y crearse un build (un paquete o ejecutable) que contenga la nueva versión de la aplicación luego de pasar los tests de integración.
- Test
Se ejecutan una serie de tests para garantizar que la aplicación funcione según los requerimientos.
Ops
- Release
Luego de pasar los tests, la aplicación se crea una imagen, artefacto o ejecutable (depende del tipo de desarrollo) listo para el deploy.
- Deploy
La etapa en que la nueva versión de la aplicación se despliega a los servidores de producción. De acuerdo a la arquitectura que se esté utilizando, puede implicar un único paso o varios.
- Operate
Son todas las tareas de configuración, optimización e implementación de infraestructura como servidores, réplicas, bases de datos, caché, etc.
- Monitor
Las aplicaciones pueden fallar en el momento menos pensado. Por eso la monitorización consiste en saber si una app está en riesgo de fallar (por sobrecarga) o cuando falló, saber exactamente por qué falló y corregirlo con la mayor velocidad.
CI/CD
Como vimos, DevOps implica pasar por todo el ciclo de vida del software a la mayor velocidad posible para luego volver a empezar el ciclo de forma infinita. ¿Cómo podemos atravesar todo el ciclo rápidamente si implica a varias personas de diferentes roles que tienen que coordinar entre sí? A través de un conjunto de técnicas conocida como CI/CD, que permiten pasar del código a producción de forma automatizada.
CI (Continuos Integration)
Cuando cada programador escribe su parte del código, está trabajando en su propio entorno (su computadora o la que le haya asignado la empresa), dónde todo es seguro porque su código no se mezclara con el de otros programadores. Hasta que toque hacer merge a master. Este es el momento en que se separan los adultos de los niños.
En ese momento el código de un programador puede romper lo que hizo otro e impedir el merge. La integración continua consiste en crear tests automatizados que prueben el código y garanticen que no hay conflictos. Si el test no pasa el código, es devuelto al programador, indicando que debe solucionar el conflicto para que sea aprobado.
De esta manera, no solo se evitan los conflictos, sino que los programadores reciben feedback más rápido y pueden corregir los problemas. Además, cada programador es dueño y responsable de su propio código y de mantener su calidad.
CD (Continuous Delivery, Continuos Deployment, Continuos Distribution)
Continuous Delivery: significa tomar el código, que ya pasó los test de integración, y crear un ejecutable listo para producción.
Continuos Deployment: es la siguiente etapa, y se trata de mandar a producción directamente. Es decir, hacer el deploy.
Continuos Distribution: Es una forma de agruparlos a ambos (Deployment y delivery). Los tres son CD y todos felices. La idea es que el código que de un programador, llegue solito a producción, y si no llega, se lo devuelven para que lo corrija. Así pasamos todo el ciclo rápido, peleándonos menos.
Y, en lugar de hacer un deploy a la semana y al mes, podemos hacer varios deploy al día.
Herramientas para DevOps
Herramientas para DevOps existen en todos los sabores, colores y tamaños. Te explicaré en el orden del ciclo de vida del Software para que quede mucho más claro.
En el primer escalón, la planeación, se analizan los requerimientos y se asignan las tareas. Una de las herramientas más usadas es Jira, principalmente en el desarrollo ágil, como Scrum. Y recuerda, puedes aprender Scrum en EDteam. Visita nuestro curso: Scrum desde cero.
También está Asana, que es una de las aplicaciones más usadas en el mundo del desarrollo de software por varias empresas. Nosotros también utilizamos Asana y, por supuesto, puedes aprenderlo en EDteam: Productividad y trabajo en equipo con Asana.
Otra opción es Trello, una aplicación famosa por ser fácil de usar y, además, es excelente para proyectos pequeños, que tienen pocas personas. Y por último tenemos a Notion, que es todo en uno: base de datos, documentos, visualizados. Notion es una de las aplicaciones con mayor crecimiento en los últimos años. Y, si quieres aprender a dominarla, en EDteam tenemos un curso: Equipos súper productivos con Notion.
La siguiente etapa es el código. Aquí, los programadores hacen lo que más les gusta hacer: echar código. Las herramientas son obvias: GitHub, que es el sistema en la nube más importante para gestionar repositorios Git. Esta herramienta, inicialmente, era una red social de programadores y luego se convirtió en una completa suit de herramientas para desarrolladores. Hay de todo, incluso, inteligencia artificial que escribe código por ti. Además, en GitHub se alojan los proyectos open source más importantes del mundo. Aprende GitHub en EDteam: GitHub para programadores.
Por otro lado, tenemos a GitLab, que es el competidor directo de GitHub. Sin embargo, su enfoque siempre a sido más lanzando hacia el DevOps y puedes aprenderlo ahora mismo en EDteam: GitLab para programadores..
Ahora, sigue el build o compilación. En esta parte, tenemos a Apache Maven, que es una de las herramientas más conocidas porque ayuda a la compilación, empaquetado y gestión de dependencias del software. Luego, sigue Gradle, que hace exactamente lo mismo que Apache, pero incluye gestión de dependencias, pruebas y también, políticas para el código.
En la parte del testing, tenemos herramientas como Selenium o Gremlin, mientras que, para el CI/CD, se encuentran herramientas como Jenkins, que es la más conocida y usada en el DevOps. También está GitHub Action y, además, GitLab ya incluye esas herramientas para CI/CD. Domínala con nuestro curso: CI/CD con Gitlab.
Luego se encuentra operaciones, que consiste en configurar y dar mantenimiento a toda la infraestructura. En primer lugar, la infraestructura como código, que se trata de hacer la configuración, ya no desde una consola, como en AWS, sino desde código. Esto permite tener una especie de recetarios de configuraciones que puedes desplegar fácilmente para configurar tus instancias, máquinas virtuales o lo que sea que necesites.
En este punto, se encuentran herramientas como Ansible, Puppet, Chef o Terrafom. Dentro de operaciones, también tenemos el tema de contenedores y microservicios, para estructurar la arquitectura de la aplicación. En ese caso, tenemos a Docker, que lo puedes aprender con nuestro curso: Docker desde cero, y Kubernetes, para orquestar muchos contenedores y hacer deploy, también lo puedes aprender en EDteam: Kubernetes desde cero.
Y finalmente, tenemos las herramientas de monitoreo, que están constantemente examinando el sitio web o la aplicación para detectar posibles fallas y sobrecargas que la puedan tumbar. Aquí tenemos a New Relic, Amazon Cloudwatch, Grafana y Prometheus, entre otros.
¿Quieres ampliar esta información? Ve nuestro video en Youtube. Y si aprendiste algo nuevo, recuerda que lo aprendiste en EDteam.