Comenzó intentando resolver problemas.
Primero necesitábamos organizar mejor el trabajo del equipo. Después aparecieron retos en la planeación, los despliegues, la homologación de ambientes y la forma en que Desarrollo y Operaciones trabajábamos juntos.
Cada problema nos llevó a buscar una solución y, muchas veces, esa solución nos permitió ver el siguiente.
Hasta que en algún momento apareció también un equipo llamado DevOps.
Paradójicamente, fue entonces cuando entendí que tener un equipo DevOps no significaba necesariamente haber implementado DevOps.
En 2019 comenzamos implementando algo relativamente sencillo: un tablero Kanban.
Funcionó. Tuvimos mayor visibilidad de las actividades, los proyectos y su avance.
Pero la adopción no fue inmediata.
Hacer visible el trabajo también podía percibirse como una forma de supervisión o micromanagement. No bastaba con implementar el tablero; había que trabajar también en la forma en que entendíamos y utilizábamos la metodología.
Después llegó Scrum.
Queríamos mejorar la planeación y entender mejor nuestra capacidad de trabajo. En los primeros sprints nos concentramos principalmente en proyectos y mejoras.
Subestimamos la operación.
Todo nuestro esfuerzo planeado estaba orientado a los proyectos, pero la operación seguía ahí: servicios que mantener, incidentes, monitoreo y actividades cotidianas.
Terminamos incorporándola dentro de nuestra planeación y estimándola a partir del esfuerzo que históricamente requería.
Gestionábamos múltiples productos y ambientes.
Desarrollo trabajaba sobre los primeros ambientes y, conforme un producto avanzaba, Operaciones recibía la infraestructura que debía llevar hacia calidad, seguridad y producción.
Gran parte del proceso era manual.
Los ambientes no siempre estaban homologados. Un despliegue podía tomar entre 2 y 8 horas y un rollback aproximadamente otras dos.
Pero el tiempo era sólo una parte del problema.
Habíamos acumulado deuda técnica a lo largo del proceso, además de documentación insuficiente, diferencias entre ambientes y muchas decisiones que necesitaban traducirse entre Desarrollo y Operaciones.
Desarrollo conocía mejor el producto.
Operaciones conocía mejor la infraestructura.
Y entre ambos existía un muro de la confusión.
Comenzamos entonces a automatizar la infraestructura.
Adoptamos Terraform y poco a poco incorporamos componentes, módulos, variables, secretos y certificados hasta poder representar una infraestructura completa como código.
El resultado fue mucho más que reducir los tiempos de despliegue.
Los ambientes comenzaron a homologarse, la infraestructura podía reproducirse, los cambios podían versionarse y comenzamos a construir una línea base que incorporaba arquitectura, seguridad y monitoreo.
Pero funcionaba principalmente en los ambientes administrados por Operaciones.
Cuando un producto avanzaba hacia nuestros ambientes, todavía encontrábamos diferencias y configuraciones manuales.
Habíamos automatizado nuestros ambientes, pero no el flujo completo de entrega.
En ese momento ocurrió otro cambio en la organización: se creó un pequeño equipo DevOps, inicialmente formado por desarrolladores que comenzaron a asumir ese nuevo rol.
Desde Operaciones comenzamos a trabajar con ellos y compartimos buena parte de la infraestructura como código que habíamos desarrollado.
La intención era extender esas prácticas hacia etapas anteriores, para que IaC no comenzara cuando un producto llegaba a nuestros ambientes.
Y hubo resultados.
En algunos proyectos la infraestructura comenzó a llegar automatizada y homologada. Las prácticas que habíamos comenzado a adoptar desde Infraestructura empezaban a extenderse hacia otras etapas del ciclo.
Pero la cultura todavía no había permeado de forma transversal entre los equipos.
El nuevo equipo DevOps comenzó a encontrarse con muchas de las mismas necesidades de coordinación que antes encontrábamos en Operaciones.
Habíamos transferido código y automatización.
Pero también trasladamos el muro de la confusión.
Antes estaba entre:
Desarrollo │ Operaciones
Ahora teníamos:
Desarrollo │ DevOps │ Operaciones
En lugar de desaparecer, el muro se había desplazado y, en la práctica, terminamos teniendo dos puntos de separación.
El cambio comenzó cuando Operaciones y Seguridad fuimos invitados a participar desde etapas más tempranas de los proyectos.
En lugar de esperar a que un producto pasara de un equipo al siguiente, Desarrollo, Operaciones y Seguridad podíamos discutir decisiones mientras todavía se estaban tomando.
Desarrollo aportaba su conocimiento del producto; Operaciones, la perspectiva de infraestructura, disponibilidad, monitoreo y operación; y Seguridad podía integrar sus requerimientos desde etapas tempranas.
IaC podía formar parte del proyecto desde sus primeros ambientes y la misma línea base acompañarlo durante el ciclo de entrega.
Los pipelines también fueron evolucionando. Comenzamos a integrar pruebas unitarias, de integración y aceptación, además de controles de seguridad como SAST y DAST.
CI/CD dejó de ser solamente una forma de automatizar la entrega y comenzó a convertirse también en un punto de integración entre Desarrollo, Operaciones y Seguridad.
En la práctica, comenzábamos a aplicar shift-left: arquitectura, infraestructura, operación, automatización y seguridad podían incorporarse desde etapas más tempranas, en lugar de aparecer cuando el producto ya estaba avanzado.
Esa misma evolución nos fue acercando a DevSecOps: la seguridad dejaba de ser una validación al final del proceso y comenzaba a formar parte del ciclo de desarrollo y entrega.
Pero el cambio más importante no estaba solamente en mover actividades hacia la izquierda.
La retroalimentación ya no tenía que cruzar el muro de la confusión.
Cuando aparecía una necesidad, las áreas involucradas podían discutirla y trabajar sobre ella desde el mismo proyecto.
Seguíamos teniendo equipos y especialidades, pero trabajar juntos también comenzó a ampliar nuestras propias habilidades.
Desarrollo adquiría mayor contexto de infraestructura y operación; Operaciones entendía mejor el aplicativo y su ciclo de entrega; Seguridad participaba directamente en las decisiones del producto.
Comenzábamos a desarrollar habilidades T: manteníamos profundidad en nuestra especialidad mientras ampliábamos nuestro conocimiento sobre las disciplinas con las que trabajábamos.
Ya no se trataba solamente de pasar trabajo de un especialista al siguiente.
Comenzábamos a trabajar sobre un objetivo compartido.
Viendo el recorrido completo, cada etapa aportó algo.
Kanban y Scrum cambiaron nuestra forma de organizar el trabajo. IaC nos dio repetibilidad y homologación. CI/CD y la automatización transformaron la entrega. El shift-left y DevSecOps nos permitieron incorporar diferentes perspectivas desde etapas más tempranas.
Pero el cambio más importante ocurrió cuando esa forma de trabajar comenzó a permear entre los equipos.
Después de todo ese recorrido, para mí DevOps dejó de ser el nombre de un equipo y terminó siendo una cultura, una forma de comunicarnos y una forma de trabajar a través de toda la organización.
]]>Al día de hoy, la oferta de servicios ha crecido y también ha cambiado mi forma de entender la nube.
En aquel momento veía un movimiento que parecía bastante claro: muchas empresas comenzarían a llevar parte de su infraestructura de ambientes on-premise hacia la nube.
Y ocurrió.
Pero también ocurrió lo contrario.
Durante estos años hemos visto organizaciones adoptar servicios en la nube, mantener infraestructura propia, construir ambientes híbridos e incluso regresar determinadas cargas de la nube a on-premise.
También tuvimos que aprender nuevas formas de administrar y optimizar el costo de esos servicios, adoptando prácticas como FinOps, y a comparar ese modelo con conceptos que ya conocíamos, como la inversión y depreciación de los activos propios.
Entonces, ¿realmente ocurrió aquel cambio de paradigma?
Creo que sí. Sólo que el movimiento era más grande de lo que yo creía.
Mucho antes de aquel artículo había una frase que escuchaba constantemente:
“Empresa que no esté en Internet va a desaparecer.”
Yo la entendía y la había hecho mía.
Pero una cosa era entender lo que significaba y otra muy distinta vivirlo.
Durante mucho tiempo “estar en Internet” podía interpretarse como tener una página web, correo electrónico, algún sistema publicado o comenzar a ofrecer servicios digitales.
En 2020 entendí realmente lo que podía significar.
Con la pandemia llegaron las restricciones. En Jalisco y posteriormente en buena parte de México —y del mundo—, salir y permanecer en espacios de trabajo representaba un riesgo de contagio. Muchas actividades presenciales se detuvieron o quedaron restringidas, salvo aquellas consideradas esenciales.
De un momento a otro, muchas empresas tuvieron que responder una pregunta para la que quizá no estaban preparadas:
¿Podemos seguir operando si las personas no pueden estar físicamente aquí?
Internet dejó de ser solamente presencia.
Se convirtió en operación.
Trabajar, atender clientes, vender, colaborar, acceder a información y mantener procesos funcionando de manera remota dejaron de ser capacidades adicionales. Para muchas organizaciones se volvieron parte de su continuidad.
Ahí entendí aquella frase de otra manera.
El cambio no consistía solamente en que las empresas estuvieran en Internet.
Consistía en que fueran capaces de operar digitalmente.
Después de estos años la veo desde dos perspectivas.
La primera es técnica: la nube es, en buena medida, el datacenter de alguien más. Detrás siguen existiendo servidores, almacenamiento, redes, energía, redundancias, réplicas, mantenimientos, estándares y equipos de personas operando toda esa infraestructura.
La segunda es como plataforma de capacidades. Podemos desplegar servicios rápidamente, automatizar, utilizar servicios administrados, trabajar sobre líneas base y acceder a soluciones empresariales avanzadas sin tener que construir toda la infraestructura que existe detrás.
Y con esta segunda perspectiva aparece también un concepto importante: la responsabilidad compartida. Parte de la responsabilidad queda en el proveedor y otra parte continúa siendo nuestra.
Algo que me llamaba especialmente la atención desde aquellos años era lo que la nube podía representar para una empresa que comenzaba.
Imaginemos una organización nueva.
Antes de generar negocio puede necesitar servidores, almacenamiento, comunicaciones, respaldos, seguridad, redundancia y personal capaz de operar todo eso.
Construir esa capacidad requiere capital.
La nube ofrece otra posibilidad: consumir muchas de esas capacidades conforme son necesarias.
Eso permite que una empresa no tenga que descapitalizarse construyendo desde el primer día toda su infraestructura y pueda invertir una mayor parte de sus recursos en aquello que realmente genera su negocio.
Eso no significa que la nube sea automáticamente más barata.
Tampoco que sea la respuesta correcta para cualquier carga.
Significa que tenemos otra forma de consumir tecnología y otra herramienta para diseñar la operación.
Probablemente ésta sea una de las cosas que más han cambiado en mi manera de verlo.
Si una empresa ya tiene datacenters, infraestructura amortizada, personal, conectividad, procedimientos y cargas estables, mi respuesta no sería:
“Hay que moverlo todo a la nube.”
Sería:
Analicemos tu operación.
Veamos qué tienes, qué necesitas, qué problemas quieres resolver y si existe algo que tenga sentido operar desde la nube.
Puede haber cargas para las que cloud sea una excelente decisión.
Otras pueden tener sentido on-premise.
Y otras terminarán formando una arquitectura híbrida.
El objetivo no debería ser poder decir que estamos “en la nube”.
El objetivo es que la tecnología soporte correctamente al negocio.
En 2017 veía la nube como un cambio de paradigma.
Casi diez años después sigo pensando que lo fue, pero también cambió mi comprensión del cambio.
En estos años la tecnología cambió, pero yo también aprendí a decidir mejor dónde y cómo utilizarla.
Y quizá ese sea para mí el aprendizaje más importante.
Hoy estamos viviendo algo parecido con la inteligencia artificial. Parece que todo necesita IA porque es la tecnología que está transformando la industria.
Antes fue cloud.
Mañana será otra tecnología.
Pero la pregunta debería seguir siendo la misma:
¿Qué necesita el negocio?
No todo tiene que ser nube para estar bien.
No todo requiere ser on-premise.
Tampoco todo es IA.
No habilitemos capacidades por moda. Hagámoslo de acuerdo con las necesidades del negocio.