[15/01/2020] Al principio, estaban el código y el codificador que lo creó. Los desarrolladores eran responsables de todo. Creaban la lógica y luego presionaban los botones para mantenerla ejecutándose en el servidor. Eso cambió a medida que los equipos se expandieron y los trabajos se diferenciaron; algunos miembros del equipo permanecieron con el código (desarrolladores: devs) y otros atendiendo las máquinas (operaciones: ops).
Hoy en día, gracias a la nube y al auge de los microservicios, el software se ha convertido en una constelación de docenas, o incluso miles, de componentes que se ejecutan en máquinas separadas. Cada una es técnicamente independiente, pero todas estas máquinas deben funcionar juntas. Asegurarse de que lo hagan se logra mejor con scripts automatizados. DevOps.
La tarea principal del equipo de DevOps es proporcionar la organización completa y de alto nivel de estas apps multifacéticas. Es posible que no se ocupen de los rincones profundos de la arquitectura del software, pero mantienen las partes funcionando sin problemas.
Aun así, el rol sigue siendo relativamente nuevo, con responsabilidades que no están claramente definidas o asignadas, y conjuntos de habilidades que aún están evolucionando. Algunos profesionales de DevOps combinan descripciones de trabajo, realizando una mezcla de programación y operaciones, pero muchos equipos están descubriendo que mantener todos los servidores funcionando sin problemas es suficiente trabajo. Configurarlos requiere una atención al detalle muy grande; y todo esto mientras el equipo de programación cambia el código y, por lo tanto, cómo debe ejecutarse.
A medida que más organizaciones recurren a DevOps para respaldar sus transformaciones digitales, es importante tener una visión clara. Aquí hay algunas verdades ocultas y conceptos erróneos ampliamente difundidos sobre el campo emergente de DevOps.
DevOps no es programación, pero lo es
Muchos gerentes piensan que DevOps no es programación y tienen razón. Los roles han divergido y gran parte del trabajo desordenado de lidiar con bytes y estructuras de datos se asigna a codificadores que viven en un mundo abstracto diferente. Estratégicamente, tiene sentido liberar a los programadores de la responsabilidad de mantener todo en funcionamiento, porque sus cabezas se pierden profundamente en la espesura de una pila moderna.
Pero los miembros del equipo DevOps aún tienen que escribir fragmentos de código. Necesitan seguir pensando de manera abstracta sobre las estructuras de datos ocultos. El simple hecho de mantener todo en funcionamiento requiere invocaciones interminables de la línea de comandos que generalmente se pueden recopilar y simplificar como shell scripts. Si bien algunos puristas de codificación pueden no clasificar el trabajo de alto nivel como este como codificación, incluso si incluye llamadas a funciones, parámetros y variables; la realidad es que muchos de los mismos tipos de habilidades de los programadores se aplican ahí.
Guiar a los programadores es trabajo
Incluso si los profesionales de DevOps no escriben el código, terminan administrando a los programadores y eso es, a menudo, igual de trabajoso. Cada desarrollador está creando algo nuevo y hermoso. Su código es arte. Cada uno quiere poner su contenedor en producción en ese mismo instante para que puedan tacharlo de la lista. ¿El código funciona sin problemas? Ellos piensan que sí. ¿Pero todo se vendrá abajo? Asegurarse de que los codificadores no arruinen las cosas es el trabajo pesado de DevOps.
DevOps se está haciendo cargo lentamente
Cuando el software era monolítico, los programadores tenían todo el control. Ahora que las aplicaciones generalmente se dividen en docenas o incluso cientos de microservicios, DevOps se encarga de qué tan bien se ejecutan. Sí, todavía hay arquitectos y programadores que toman decisiones sobre la forma en que se vinculan los servicios, pero los profesionales de DevOps se encargan de cómo se vinculan, lo cual es una pieza cada vez más importante del rompecabezas.
No se toman en cuenta los centavos
Las compañías de la nube fueron inteligentes cuando les pusieron precio a sus máquinas en centavos por hora. ¿Quién no tiene algo de cambio? Pero los centavos se acumulan a medida que aumenta el número de instancias de la nube y pasan las horas. Hay 720 horas en un mes de 30 días, por lo que una máquina grande que cuesta solo un dólar por hora costará 8.760 dólares por año. De repente, comprarse su propia caja comienza a parecer barato.
Después de recibir facturas impactantes, algunos equipos han empezado a configurar auditores DevOps con el único trabajo de hurgar en el desastre de las máquinas, buscando formas de ahorrar dinero. Examinan las decisiones de las personas en la línea y comienzan a decir "No". Contarán cada fracción de centavo porque saben que el presupuesto lo requiere.
Solo hay unas pocas palancas para aumentar el rendimiento
El trabajo de administrar la nube se hace más difícil por el hecho de que el equipo de DevOps suele tener solo unas palancas de las que puede tirar. Una vez que los programadores confirman el código y crean los contenedores, el trabajo del equipo DevOps es hacer que se ejecuten. Si parecen lentos, pueden intentar agregar más CPU virtuales o más RAM. Si las cosas siguen siendo lentas, pueden agregar más máquinas a la cápsula para distribuir la carga. Eso es todo.
Es una carrera de demolición
Uno de los problemas más profundos es que las computadoras siempre están ocultando sus errores. Una vez heredé una colección de contenedores que dejaba de funcionar cada pocas horas. Tal vez se trataba de una conexión de base de datos fallida. Tal vez era un parámetro mal configurado. La respuesta puede haber estado en la profundidad de los archivos de registro, pero nunca lo descubrí. Kubernetes tuvo la amabilidad de arrancar otra instancia y la cápsula siguió navegando, respondiendo consultas y haciendo su trabajo. Fue un hermoso ejemplo de arquitectura a prueba de fallas, a pesar de ser un desastre por dentro.
A veces debajo de la superficie, los contenedores y las instancias fallan por todos lados. Mientras los usuarios y los clientes estén logrando que el trabajo se realice, suele ser más fácil para todos mirar hacia otro lado e ignorar toda esa demolición virtual.
Las bases de datos controlan todo
Podemos preocuparnos por todo el código local y jugar con AJAX o CSS, pero al final, todos los datos encuentran un hogar en la base de datos. Las bases de datos clásicas siguen siendo el sol alrededor del cual orbita el código. Es la única fuente de verdad. Si el equipo puede mantenerlo funcionando y respondiendo consultas, casi todo el trabajo está hecho. Los usuarios pueden tolerar DIVs desalineados o nuevos diseños extraños, pero no bases de datos corruptas. Una vez audité el código para un equipo que estaba usando los últimos y mejores paquetes de Node.js, actualizando sin descanso su pila para mantenerse a la vanguardia. Pero la base de datos tenía más de 10 años. Nadie quería meterse con eso.
Nuestro conocimiento sobre cómo se ejecuta el código es limitado
Hoy en día, el nivel de instrumentación disponible puede ser sorprendente. Podemos sentir la oleada de datos a través de las diversas piezas de software como un marinero siente la oleada del viento. A medida que las cargas de las vainas suben y bajan, sabemos cuándo las cosas se ejecutan correctamente y cuándo se esfuerzan. Si estamos a cargo de una aplicación web de comercio electrónico, seremos los primeros en saber cuándo entran en vigor los descuentos porque aumentará la carga para ese rincón de la aplicación.
Pero la instrumentación solo puede darnos conocimiento limitado. Los números resumen el esfuerzo promedio y el tiempo de respuesta del componente, pero no puede decirnos por qué. Eso queda para los programadores que saben lo que sucede dentro de los componentes. Pueden aislar los errores y encontrar soluciones.
Es posible que algunas personas de negocios deseen que haya un personal técnico omnisciente y todopoderoso que pueda entender todo el conjunto de abajo hacia arriba. Existen algunos superhumanos por ahí, pero para muchas empresas el trabajo es demasiado grande y son demasiadas líneas de código. Es mejor trabajar para encontrar una manera fácil para que DevOps y los programadores colaboren.
Todo es un misterio
Las computadoras pueden ser máquinas completamente lógicas, donde el código evoluciona de una manera predecible y determinista. Cada error ocurre por una razón. Podríamos sacar los depuradores, desplazarnos por los archivos de registro y analizar el código, pero ¿quién tiene tiempo?
Del mismo modo que parece que el 90% de los problemas de soporte técnico se pueden resolver mediante un ciclo de encendido del dispositivo, gran parte de DevOps implica hacer lo mismo. Oh, claro, usamos palabras como "contenedores" e "instancias", y tenemos un sinfín de paneles para rastrear lo que está sucediendo; pero al final, muchas veces es más rápido y sencillo seguir adelante y, como sugirió Iris Dement, dejar que el misterio se mantenga así.
Peter Wayner, CIO (EE.UU.)
Puede ver también