Si has llegado a este post con la esperanza de confirmar que NoOps es, por fin, la desaparición de alguna forma mágica de las Operaciones, siento defraudarte. Estoy totalmente de acuerdo en que el nombre lleva a confusión, pero cuando hablamos de «NoOps» no hablamos de «cero operaciones». Hablamos de que la capa de operaciones… se vuelve invisible. ¿Cómo? ¿Y por qué hablamos de nuevo de Operaciones? Vamos a verlo.
¿Por qué ahora hablamos de NoOps?
Para poder entender por qué ahora el concepto de NoOps (No Operations) toma tanta relevancia, tenemos que mirar al pasado y entender de dónde venimos. Porque realmente NoOps es la evolución natural del DevOps, como así DevOps lo fue del SysAdmin:
La era del SysAdmin
Han pasado muchos años desde que los servidores eran tratados como «Mascotas» (Pets). Servidores físicos con muchísimos cables donde cada uno era cuidado con mimo y pocas personas sabían tratarlos. El SysAdmin era considerado un semidiós dentro de una organización tecnológica (o su departamento) ya que la dependencia de sus habilidades y conocimiento era absoluta. En esos tiempos la fricción entre desarrollo y operaciones era enorme. El equipo de desarrollo «escribía código» que entregaba al equipo de operaciones que, sin ningún tipo de contexto, lo desplegara manualmente (o en el mejor de los casos con scripts). El miedo al cambio era la norma.
La era del DevOps
DevOps aparece para paliar problemas de la era anterior, y potencia la colaboración. No es una herramienta, es una cultura. En esta era es donde se introduce el concepto de «Ganado» (Cattle): los servidores ya no son únicos, son reemplazables. Se rompe esa barrera que comentábamos y los desarrolladores empiezan a aprender de operaciones e infraestructuras y los SysAdmin empiezan a programar. Pero, aunque esto fue un gran avance, sobre todo con la aparición de la integración continua (CI/CD) pero el equipo de operaciones sigue teniendo mucho peso, ajustando pipelines y gestionando la infraestructura. Y aunque suena muy bien, la verdad es que ahora los desarrolladores aparte de programar, también deben saber Docker, Kubernetes, redes, seguridad… demasiadas cosas a la mochila.
La era del NoOps:
La evolución natural del DevOps, más que un concepto técnico, es un concepto cultural también. Podríamos decir que es DevOps llevado al extremo gracias a las automatizaciones y al Cloud. Las operaciones se delegan a proveedores de servicios o plataformas de autoservicio (Internal Developer Platforms). Si en DevOps un desarrollador tenía que «mantener aquello que construía», en NoOps son estas plataformas las que operan por ti.
Pilares del NoOps
Si tuviéramos que decir cuáles son los tres pilares sobre los que se sostiene y han facilitado la invisibilidad de las operaciones serían los siguientes:
Abstracción total
La infra se vuelve invisible, el equipo de desarrollo vuelve a centrarse en el código, en aportar valor a negocio y se olvida de la gestión de servidores. De ahí la frase «Focus on Code, not YAML«. Ahora es el proveedor quien, para bien o para mal, ya veremos, se encarga de todo.
Automatización inteligente
La automatización llevada a su máximo exponente. Absolutamente todo el flujo desde el commit hasta la puesta en PRO está automatizado. Es lo que llamaríamos el CI/CD «zero touch«, mediante el uso de pipelines inteligentes (sí, la IA nos va a ayudar de nuevo) en herramientas como GitHub Actions o GitLab, que son reactivas a cambios de código y aseguran todo el ciclo sin intervención humana.
Self-service
Llega para quedarse la cultura del autoservicio. Se acabaron los sistemas donde tenías que solicitas al equipo de operaciones una nueva tabla en una base de datos y tenías que pasarle el script. Ahora si necesito una base de datos, la defino en mi código, y, mediante herramientas de infraestructura como código (IaC), ¡voilá! está disponible al instante.
Desventajas
Porque no es oro todo lo que reluce, NoOps tiene tres puntos críticos a tener en cuenta:
- Vendor lock-in: al delegar toda tu capa de operaciones e infraestructura en un mismo proveedor (como puede ser AWS, Azure o Google) estás «vendido». Es decir, por supuesto que puedes irte en cualquier momento, pero una vez que tienes una estructura suficientemente grande, el cambio no es tan fácil, puede convertirse en una pesadilla técnica y económica. Tu código se ha vuelto esclavo de sus herramientas
- Pérdida de control y diagnóstico: al estar todo en el ecosistema del proveedor, en caso de querer realizar el triaje de un error no puedes simplemente conectarte por consola a un servidor y repasar logs. Dependes totalmente de las herramientas que tenga habilitadas para tracking el proveedor que pueden ser muy buenas o muy malas.
- Costes fantasmas (FinOps): si cualquiera puede generar infraestructura, y el autoescalado es maravilloso… ¿Quién garantiza que un fallo en el código no se dispare el uso de recursos provocando una factura astronómica?
Conclusiones
NoOps es el siguiente paso natural, y el que antes era SysAdmin, luego DevOps, ahora ya no apaga fuegos de forma manual. Diseña sistemas que son capaces de apagar los fuegos por sí solos. Eso es lo importante. Además, no hay que obsesionarse. Tenemos que ver NoOps como un horizonte al que nos gustaría llegar, pero, siendo sinceros, es poco probable que tengamos el 100% de nuestros sistemas sin intervención humana. Pero cuanto más cerca estemos, mejor.