De SysAdmin a DevOps: Parte II Reflexiones sobre mi propia transición (o cosas que me hubiera gustado saber antes de…)

19 junio
Heber Benitez, DevOps
De SysAdmin a DevOps: Parte II  Reflexiones sobre mi propia transición (o cosas que me hubiera gustado saber antes de…)

Según Wikipedia, DevOps es una práctica de ingeniería de software que tiene como objetivo unificar su desarrollo (Dev) y operación (Ops). Para mí, es más bien un movimiento cultural que tiene como objetivo dinamizar los tiempos de desarrollo, testeo y puesta en producción del software. En este artículo, voy a contarles el camino que recorrí para llegar a convertirme en DevOps, y que me permitió crear esta definición.

Un poco de historia

Mi primera computadora llegó a casa cuando yo tenía 14 años: era una Commodore 64 y lo primero que hice fue decirle “LOAD” para que me cargara un juego desde un cassette. Cómo imaginarse que ese simple momento iba a marcar el rumbo de mi vida. Un año después y ante una ola de continuos “por qué”, mis padres me inscribieron en un instituto de computación. Más adelante, comenzaría finalmente a estudiar Sistemas en la facultad.

No pasó mucho tiempo hasta que me topé con Windows95, con SuSE Linux (cuando era gratis) y finalmente ¡con Internet!

pic
pic

Cuando cumplí 19 años empecé a trabajar y no, no fue programando ni nada similar. Como le pasa a la gran mayoría de las personas, mi primer empleo no tuvo nada que ver con lo que yo quería: me convertí en operario metalúrgico. Plop! Las vueltas de la vida me llevaron a trabajar en el diseño de estructuras para soportar pequeñas cañerías y, más adelante, en control de producción.

Hardware, sistemas operativos, redes y almacenamiento

Persevera y triunfarás. Un tiempo después, desembarqué finalmente en el rubro de Sistemas, dando soporte técnico informático. Allí me vi hablando con terminólogas como socket, TCP/IP (IPX… si, conocí Novel Netware y el famoso directorio SYS) y computación de procesos por lote, en una caja gigante que decía “IBM AS400” y echaba viento por atrás. Me solicitaron que estudie Windows NT y certificar algo a lo que llamaban “Windows 2000”. También me pidieron crear un script (¡palabra mágica para mí!) que pudiera dar de alta usuarios en LDAPv3.

Con todo esto, entendí que podía acceder a cualquier computadora sin permiso y que también podían hacerlo con la mía. ¡Hay que tener cuidado!

Aprendí también que tenía mucho más para dar y me decidí a un cambio laboral (spoiler alert: a lo largo de mi carrera hice varios cambios, incluso ahora mismo me encuentro en una transición). Ese camino me permitió ganar mucha experiencia, ver surgir a los hipervisores, toparme con sistemas distribuidos, rackear blades, upgradear hardware en caliente, tirar cable UTP Cat 4 y 5, montar y configurar una SAN y un NAS, setear RAID levels, clústeres, balanceadores de capa 4, Proxis y sistemas de inspección de paquetes.

Por último, entendí que todo debe estar orquestado, y no me refiero sólo los servicios IT, sino también los procesos y los procedimientos; que deben existir políticas que acompañen y delimiten el camino.

Los de operaciones VS. “ellos…”

Ya como Administrador de Sistemas, una de mis primeras tareas fue presentarle un reporte a mi jefe sobre el uso de discos del ambiente productivo. Como eran servidores Windows, usé VBS y valiéndome de un sitio de aquel tiempo que se llamaba “Hey, Scripting Guy”, hice un tuning de código y todo salió de maravilla. Pero esto era distinto a escribir código para una aplicación y ahí me surgió el interrogante: ¿cuál es exactamente la diferencia entre lo que hace un desarrollador y estos “scripts” que hago yo?

Hasta ese momento, lo único que sabía era que el desarrollador era la pieza que introducía parte de los problemas en el ambiente operativo, es decir: era la persona a la que le decías “NO” casi por deporte. De hecho, todo funcionaba siempre bien hasta que el desarrollador “te metía” una nueva versión de su aplicativo, que te tiraba por la borda los SLAs, KPIs y cualquier estadística que tuvieras.

¡Y había algo peor! Ellos argumentaban que el problema debía ser de infraestructura, entonces te pasabas toda la noche o todo el fin de semana trabajando hasta encontrar que el problema no era tuyo, sino que ese aplicativo te comía toda la memoria del server.

Obviamente los administradores no estábamos exentos: a veces, nosotros mismos nos olvidábamos de popular ciertos puertos hacia la base de datos en las reglas del firewall y claro, los usuarios se quedaban atónitos ante la oleada de mensajes OLEDB que se estampaban en su pantalla.

Del otro lado: “From ServerFault to StackOverflow”

En mi siguiente trabajo me tocó dar soporte directo a un grupo de desarrolladores que preparaban un ERP para una cadena de farmacias. Ahí fue donde mi visión cambió radicalmente: estas personas eran gente ‘copada’, con una forma muy diferente de pensar las cosas y de ver la vida. No digo que era mejor o peor, sino simplemente distinta, y eso siempre te hace ver todo de una nueva forma.

pic

Aprendí mucho de ellos. Por ejemplo, que programar es mucho más que sentarse a escribir código. Es entender los requisitos del negocio, es hacer que cada release pueda acomodarse y cumplir su función con releases hechos por otros developers, es compilar (cuando es necesario) para luego testear, era lidiar con VMs (Docker recién aparecía), con librerías/paquetes, es volver atrás con algún cambio de último momento por la incorporación de algo que al cliente se le había olvidado, es cumplir con plazos de entregas aún cuando descubriste que tenés un bug que hay que fixear, es lidiar con los SysAdmin para que "te dejen" introducir algo en su ambiente, es escuchar que te digan que están asustados antes de que hagas el pasaje de una nueva versión a producción, que hablen mal de tu código (AKA: tu hijo). ¡Y que es mucho, pero mucho, trabajo en equipo!

Desde lo técnico, esta etapa me introdujo a GitLab, y ahí comencé a acostumbrarme a escuchar cada vez más términos como: comitear, pushear, mergear, y varios “ar” más. Aprendí a usar MySQL, que el RFC para el protocolo HTTP es tan complejo como la arquitectura de una catedral gótica y qué cada browser también tiene mucho para decir. Descubrí que Amazon no sólo vendía libros y, metodológicamente, aprendí que Agile estaba entre nosotros para ser la salvación... :| ? ¡y que Docker era magia!

¿Dónde están mis servers?

Habiendo logrado un cierto grado de madurez, comencé a trabajar como líder del equipo de infraestructura.

¡Fue realmente una buena experiencia! Tuve varios logros y, casi siempre, todo salía siempre acorde a lo planificado. Pero como siempre sucede en la vida, todo cambia.

La tecnología acompañaba los caprichos de la globalización económica y todo comenzó a inclinarse fuertemente hacia lo online. Las apps móviles explotaban por todos lados, los sitios se topaban con un problema llamado C10K, Internet sufría múltiples DDOS y los CDN empezaban a aparecer en boca de todos - menos en la mía -. Desde mi zona de confort, veía que ese nuevo mundo de “afuera” (ecommerce, velocidad, HTTP, www, balanceadores de carga L7, APIs, teléfonos celulares, etc.), era muy distinto al de “adentro” (DHCP, red perimetral, clúster SQL, usuarios, computadoras de escritorio e intranets).

pic

En el fondo, sentí que tenía que moverme y salir de esa comodidad en la que estaba, aunque me gustaba mucho la idea de seguir en lo técnico duro. En un abrir y cerrar de ojos, me encontré trabajando como DevOps.

Conocía en profundidad los pilares de toda infraestructura de IT, sabía programar, tenía experiencia trabajando en un ambiente de desarrollo, conocía los fundamentos de los procesos, de la seguridad informática y de la información, sabía cómo arquitecturar soluciones robustas, y muchas cosas más. “¡Acá la rompo!” pensé con cierto grado de confianza y una gran sonrisa sobradora, que hoy en día aún la sigo buscando.

Como se imaginarán, la experiencia fue muy distinta a lo que yo me imaginaba. Lo primero que se me vino a la cabeza fue: “¿Dónde están mis servers? ¿dónde está el inventario? ¿y los planos?”; lo segundo, fue aún más trágico: ¿Smoke Testing?, ¿Endpoint? (no, no hablamos de Symantec Endpoint Protection), “Architecture” (¡acá soy crack! ah, no… te referías a algo llamado “Event Driven Architecture”… ok, ok…).

Tarde me di cuenta de que había cometido un grave error: dependiendo del enfoque del negocio, generalmente el approach al oficio de DevOps era hacia CI ¡el cual es un pequeño mundillo! Y digo “generalmente” en vez de “siempre”, porque su scope a veces puede estar orientado al mantenimiento de la infraestructura Cloud, por ejemplo, a permitir algún puerto TCP/UDP, reconfigurar el AutoScaling, o arreglar alguna configuración errónea. Es decir, no se trabaja con desarrolladores directamente.

Por otra parte, si bien ya contaba con experiencia en microservicios, jamás había trabajado con la metodología de Continuous Deployment. Encontré que era de suma importancia hacer constantes y pequeños releases de software antes que esperar y hacer pocos y grandes deployments. Ahora bien, para que esto fuera satisfactorio, todo el circuito debía estar muy bien aceitado y comprendido; después de todo, no queremos que un cambio no satisfactorio impacte producción ¿no es cierto?

Varias cosas me sorprendieron y me gustaron:

  • Tags por todas partes: puedo asignar un tag a un grupo de objetos y, luego, referenciarlos de manera fácil desde otro sistema. Cool!
  • Serverless y Batch computing. ¡Qué bueno!
  • Infraestructura como un código. Nunca me gustó abrir blades y tener que ensuciarme las manos para agregar memoria. ¡Hermoso!

A modo de anécdota, recuerdo como si fuera ayer que, en mi primera call, el cliente me dijo: “Just save the artifacts into Artifactory”. ¡No tenía idea de lo que me estaba hablando! Con toda mi atención puesta en lo que se me había pedido, primero traté de comprender el significado de “Artifact”. Superada esta barrera inicial y esencial, lo segundo que hice fue tratar de ver dónde residían esos Artifacts y qué procesos los creaban. Una vez que los encontré en un directorio específico dentro de una instancia Docker correspondiente a lo que en GitLab se llaman “Runners”, me dieron una URL.

Sin conocer que existía una diferencia entre URL y Endpoint (referidos nuevamente a términos exclusivos del mundo de la programación REST vs NON-REST), la pegué en mi browser favorito esperando la ventana de login. Lo que obtuve no fue mas que un conjunto de datos en format JSON que no me decían más que “Access Denied”. Error de novatos. Me tomó otro tiempo comprender que ese acceso sólo era posible a través de la salida del pipeline de GitLab.

Otras tareas que me dejaron flipando fueron:

  • Scriptear en YAML y en HCL
  • Entender las dependencias de una app GO, IOS ¡y hasta Java!
  • Crear un pipeline sin saber cómo interactúa cada lenguaje con el proceso de testing
  • Entender toda una infraestructura manejada con módulos de Terraform intrínsecamente ligados con cientos de ramificaciones, sin tener mucho conocimiento del GUI de AWS
  • Crear un circuito de tareas interdependientes entre Lambda, SNS, Slack y Datadog sin conocer qué era cada una

Reconozco que varias veces me vino a la mente una vieja frase que había escuchado mucho en el pasado: “esto es de desarrollo, pasales el ticket a ellos”. Pero ahora era yo quien debía analizarlo. De repente, volví a ser junior.

Polemizando un poco

Aquí abro el juego al debate: el camino hacia la cultura DevOps pareciera ser un poco más piadoso y endeble cuando el caminante proviene desde las bases mismas del desarrollo. ¿Por qué digo esto?

  • En primer lugar, porque un desarrollador quizás tenga más posibilidades de conocer desde un principio lo que implica trabajar con el pipeline de un producto de software. Por ejemplo, cómo armar un script.
  • En un día, una persona puede aprender cómo funciona un balanceador de carga; al siguiente, puede aprender sobre sus protocolos y/o RFC’s; y al tercero, ya lo puede poner en práctica. Pero aprender a programar no se consigue tan rápido.
  • La fase de Integración Continua contiene muchos elementos en común con el Software Testing y Quallity Assurance, que no forman parte del mundo de las operaciones (al menos en las tradicionales, ya que el ojo ávido puede alegar que es posible versionar y deployar vía IAC, lo cual es totalmente válido).
  • En un mundo en el que la mayoría de los servicios se vinculan a Internet, no resulta extraño que un desarrollador tenga experiencia interactuando con servicios de alta disponibilidad o de contingencia para un sitio web. Esta necesidad, pudo haberlo llevado a investigar sobre L4 y L7, Auto Scaling, Monitoreo, inclusive a armar un VPC y empaparse con subnetting.
  • En términos de sistemas operativos, no es extraño que un desarrollador interactúe con permisos a nivel de “File System”, con usuarios, con reglas de firewall e incluso que le pase vía Sysctl al mismo Kernel del sistema operativo.
  • Si hablamos de la nube, cada día más empresas y startups utilizan estos servicios. Como su nivel más bajo es IaaS, que permite manejar el storage, los sistemas de cómputo, el networking, etc., deja de ser necesario saber cablear, rackear un server, conocer sobre RAID o el sistema de cooling, saber cuántos IOPS tiene el sistema de storage que debo comprar, ni cómo enrutar tráfico BGP o preocuparme por el cifrado de datos en reposo. ¡Todo eso se puede manejar con unas cuantas líneas de código!
  • Respecto a la automatización, podemos decir que 15 o 20 años atrás no existía todo el amplio abanico de posibilidades de herramientas que hoy podemos ver: Chef, Puppet, Ansible, entre otras. Además, se suma la variable "serverless", en donde directamente ya no se necesita ninguna instancia operativa para montar. Por ejemplo, un LAMP Serverless permite deployar código al ambiente productivo sin tener que estar pensando en todo el planeamiento de capacidad, administración o configuraciones, que son irrelevantes para el negocio. Así, el desarrollador tiene una interfaz que esta meramente focalizada al resultado. Creería que esta modalidad va a incrementarse en el futuro, pero esta reflexión merecería todo un artículo aparte.
  • Mi punto más polémico es todo lo que un DevOps debe saber: programar en lenguaje de comandos y de programación, interpretar Go, Python, Java, PHP, C#, HTML, CSS, JavaScript; entender orquestadores como Kubernetes o Swarm; comprender contenedores y saber usar los servicios de Cloud Computing como AWS, GCP, Azure; sistemas de gestión de código como Github y CI como Gitlab; hacer deployments a servers usando Ansible, Puppet o Chef; conocer todo sobre Administración de Linux y Windows; saber montar balanceadores y clusters, cache de bases de datos, entender el funcionamiento de TCP, UPD, DNS, HTTP; saber criptografía para comprender SSL/TLS, bases de datos como MySQL, MSSQL, MongoDB, Redis, Casandra, Aurora; saber Infrastructure as a Code: Terraform o Cloud Formation;  saber sobre herramientas de monitoreo como New Relic, Datadog, Nagios, Zabbix; y disponer de una gran habilidad para manejar el enorme caudal de información que llega todo el tiempo. ¡Parecería que una sola persona conforma un departamento entero de Sistemas!

Conclusión

No existe un plano de transición único, ya que hay tantos caminos como personas en el mundo. Cada uno es distinto, con sus propias aristas, y es por eso que, a los conceptos de Continuous Integration, Continuous Delivery y Continuous Deployment, le agregaría uno adicional: “Continuos Learning”.

De lo que sí estoy convencido, es que el aprendizaje siempre debe ser lo más agnóstico posible, aunque en ciertas ocasiones sea necesario conocer en detalle algún producto específico; que mentorear a los recién iniciados y seguirlos en el camino es darle un valor importante al negocio; y que es vital conocer el mapa arquitectónico del flujo de procesos, el mapa de red, el de servicios.

DevOps es un método, no un trabajo. Y la transición no es sencilla: muchas veces se puede presentar larga, sinuosa y cuesta arriba. Me tienta mucho hablar sobre el lugar al que se llega luego de recorrer ese camino, aduciendo que puede ser bellísimo. Pero lo cierto es que no creo que haya un destino final: lo que se disfruta es el camino y, como nuestra concepción del propio universo, no tiene fin.

e