Durante el último año he observado un marcado auge de personas desarrolladoras y administradoras de sistemas interesadas en iniciarse en la cultura de DevOps. También he observado que: en una era donde un/a sólo/a desarrollador/a puede poner a punto una infraestructura globalmente distribuida para una aplicación con unos pocos dólares y unas pocas llamadas a APIs, la brecha entre el desarrollo y los sistemas de administración es más estrecha que nunca. Aunque he visto muchos artículos en blogs sobre buenas herramientas para DevOps e ideas a considerar, he encontrado menos contenido en cuanto a guías y sugerencias para las personas que quieren iniciarse en este campo.
Mi objetivo con el presente artículo es, con suerte, trazar cómo se ve ese camino. Mis ideas se basan en varias entrevistas, conversaciones y discusiones con muchas/os desarrolladoras/es y administradoras/es de sistemas. El artículo estará dividido en dos partes. La primera parte de esta serie brindará una resumida vista anecdótica al mundo de IT antes de que las ideas de DevOps tomarán al mundo por sorpresa. También exploraremos las habilidades que las/os reclutadoras/es están buscando cuando necesitan incorporar perfiles DevOps a sus compañías, y las habilidades útiles para las/os ingenieras/os que desean convertirse en expertas/os de DevOps. La segunda parte expondrá implementaciones de conceptos, comúnmente conocidos de DevOps, que he visto en la industria, junto a algunos libros útiles donde se discuten con mayor profundidad las ideas que hay detrás de este artículo.
Entender la historia es clave para comprender el futuro, y DevOps no es una excepción. Para entender la prevalencia y popularidad del movimiento DevOps, necesitamos comprender cómo era IT al final de los 90 y a partir del 2000. Esta fue mi experiencia.
Empecé mi carrera como administrador de sistemas Windows en una gran firma multinacional de finanzas a finales del 2006. En aquellos tiempos, expandir la infraestructura significaba llamar a Dell (o en nuestro caso, CDW) y realizar una orden de miles de cientos de dólares en servidores, equipamiento de redes, cables y programas. Todos destinados a los centros de datos, ya fueran internos o externos. Mientras que VMware aún intentaba convencer a las empresas de que usar máquinas virtuales era, de hecho, una forma de reducir los costos del mantenimiento de las aplicaciones que requerían especial atención al rendimiento, muchas otras empresas, incluyendo la mía, decidieron seguir corriendo las aplicaciones en su propio hardware físico. Nuestro departamento de Tecnología tenía un grupo entero dedicado a la Ingeniería y Operaciones del Centro de Datos, y su trabajo era negociar las tasas de arrendamiento para no tener que pagar una gran cantidad mensual, asegurarse de que nuestros sistemas estaban siendo refrigerados correctamente (lo cual es un gran problema a no ser que tengas un buen equipo) y, si se tenía un poco de suerte o el dinero necesario, el equipo de gente trabajando remoto en el centro de datos conocería lo suficiente acerca de los modelos de nuestro servidor para no equivocarse de enchufe durante las horas después de la comercialización.
Amazon Web Services y Rackspace empezaron a coger fuerza poco a poco, pero estaban lejos de alcanzar a la masa crítica.
En aquel entonces teníamos equipos dedicados a asegurarse que los sistemas operativos y el software que corría sobre aquel hardware funcionara cuando era esperado. Los ingenieros eran responsables de montar una arquitectura fiable para corregir fallos, monitorear y generar alertas en estos sistemas así como para definir cuál era la "imagen de referencia". La mayor parte de este trabajo se realizaba experimentando mucho manualmente, y el alcance de la mayoría de las pruebas se documentaba en un runbook, describiendo qué se hizo y asegurándose de que lo que se escribió hacía aquello que se esperaba. Esto era importante en grandes empresas como la nuestra ya que casi todo el soporte a nivel 1 y 2 se externalizaba y el entrenamiento que se daba se basaba en estos runbooks.
(Este es el mundo en el que viví durante los primeros tres años de mi carrera. ¡Mi sueño en aquel entonces era ser el que creara un modelo de referencia!)
Las entregas de software eran otro tema completamente diferente. Admito que no gané mucha experiencia trabajando en esa área. Sin embargo, debido a historias que he recopilado (y a experiencias recientes), puedo decirles que gran parte de la rutina del desarrollo de aplicaciones, en aquel entonces, era algo como lo siguiente:
Las/os desarrolladoras/es escribían código tal y como se especificaba en los requerimientos técnicos y funcionales que las/os analistas de negocio adquirían de reuniones en las que las/os desarrolladoras/es no estaban invitados.
De forma opcional, las personas desarrolladoras implementaban pruebas unitarias en su código para asegurarse de que nada demasiado raro pasara, como dividir entre cero sin lanzar una excepción.
Después de esto, las/os desarrolladoras/es marcaban su código como que estaba "listo para QA". Un QA cogía el código y lo corría en su propio entorno, el cual podía o no parecerse a producción o podría incluso ser el mismo entorno que el/la desarrollador/a original utilizó.
Los errores volvían a las personas desarrolladoras al cabo de "algunos días o semanas" dependiendo de otras actividades del negocio y/o de cuáles eran las prioridades en ese momento.
Mientras que las personas administradoras de sistemas y desarrolladoras no se veían frente a frente muy a menudo, la única cosa común a la que ambos se resistían era "el cambio de dirección". Esto era una composición de procedimientos altamente regulados, y en el caso de mi jefe en aquel momento, reglas muy necesarias que decidían cuándo y cómo los cambios técnicos ocurrían en la empresa. La mayoría de las empresas seguían la Biblioteca de Infraestructura de Tecnologías de Información, o el proceso ITIL, que, en resumen, hacía muchas preguntas sobre por qué, cuándo, dónde y cómo las cosas pasaban conjuntamente con un proceso para establecer un registro de auditoría de las decisiones que se llegaron a tomar.
Tal y como probablemente puedas deducir de la pequeña historia que acabo de contarte, muchas cosas en IT se hacían manualmente. Esto provocó muchos errores. Todos esos errores a su vez causaban una gran pérdida de ingresos. El trabajo de las personas a cargo de la administración de la configuración era minimizar esa pérdida de ingresos, y esto normalmente se transformaba, sin tener en cuenta su impacto ni su tamaño, en hacer entregas de software solo cada dos semanas y en hacer cambios en la configuración de los servidores, encolando dichas entregas o cambios entre el Viernes a las 4 de la tarde y el Lunes a las 5:59 de la mañana. (Irónicamente, esta pila de trabajo generaba aún más errores, que usualmente eran más serios).
Debes estar pensando “¿De qué está hablando Carlos y cuándo comenzará a hablar sobre Ansible?” Adoro Ansible pero esperen un momento; esto es importante.
¿Has sido asignado alguna vez a un proyecto y has tenido que interactuar con el equipo de “DevOps”? ¿O has tenido que apoyarte en un “Administrador de la Configuración” o en equipos de “CI/CD” para asegurarte de que tu pipeline fuese configurado correctamente? ¿Alguna vez te has visto obligada/o a asistir a reuniones sobre tus entregas de software donde predomina la conversación sobre por qué ha tomado semanas su salida a producción después de que el trabajo estuviera marcado como “código terminado”? ¿Alguna vez has formado parte del “Equipo Tigre” creado inicialmente como una solución temporal para alinear equipos y que finalmente acabó siendo un equipo permanente?
Sí es así, entonces estás reviviendo la historia. Todo esto viene de lo expuesto anteriormente y llamar a tu equipo “DevOps” no va a arreglarlo.
Los silos funcionales se forman a partir de nuestro instinto de trabajar con personas como nosotros[1]. Naturalmente, no sorprende que este rasgo humano también se manifieste en el lugar de trabajo. Incluso vi cómo esto se manifestó en una compañía en la que trabajé antes de unirme a Thoughtworks. Cuando empecé allí, todas/os las/os desarrolladoras/es trabajaban en estrechos espacios comunes muy cerca unos de los otros. A medida que el código base fue creciendo en complejidad, las personas desarrolladoras que trabajaban en funcionalidades comunes se alineaban de forma natural unas con otras para comprobar y afrontar la complejidad de sus propias funcionalidades. Al poco tiempo, estos equipos se consolidaban de manera oficial.
(Para ser claro, no creo que los equipos agrupados por funcionalidades sean universalmente buenos o malos. Pensé que había sido la decisión correcta para la compañía mencionada anteriormente. Sin embargo, eran silos, y ocurrieron de forma natural.)
Las personas desarrolladoras y administradoras de sistemas en muchas de las compañías en las que trabajé, no sólo formaron silos naturales como este, sino que también los defendieron ciegamente y compitieron ferozmente entre sí. Las/os desarrolladoras/es se enfadaban con las/os administradoras/es de sistemas cuando sus entornos dejaban de funcionar o se bloqueaban. A las/os administradoras/es de sistemas no les gustaba que las/os desarrolladoras/es estuvieran rompiendo sus entornos de forma arbitraria todo el tiempo y que pidieran más potencia de procesamiento que la necesaria.
Ninguna de las partes entendía a la otra, y peor aún, ninguna intentaba entenderse.
El propósito de DevOps era ponerle un fin a esto.
DevOps no es un equipo. No es un grupo en Jira. Es una manera de pensar. De acuerdo con el movimiento de DevOps, en un mundo ideal, las personas desarrolladoras, administradoras de sistemas y stakeholders, deberían trabajar como un único equipo, y aunque unos puedan desconocer muchos aspectos del trabajo de los otros, al menos conocen lo suficiente para entenderse entre sí, entender sus tareas y poder, la mayoría de las veces, hablar un mismo lenguaje. Todo el mundo gana porque todos se entienden entre sí.
Adam Jacob lo dijo magistralmente: “DevOps es la palabra que usamos para describir la parte operacional de la transición hacia compañías lideradas por el software”
Una pregunta bastante común que me suelen hacer es “¿Qué necesito saber para adentrarme en el mundo de Devops?" La respuesta, como a muchas otras preguntas abiertas, es "depende".
Dicho esto, nosotros en Thoughtworks normalmente buscamos Desarrolladores de Infraestructura y personas que aboguen por DevOps y que estén interesadas en aprender más sobre:
Los contenedores son cada vez más populares, y se han ido convirtiendo rápidamente en una excelente forma de alcanzar una densidad extremadamente alta de servicios y aplicaciones ejecutándose sobre pocos sistemas mientras incrementan su fiabilidad. (Herramientas de orquestación como Kubernetes y Mesos permiten poner a punto contenedores en cuestión de segundos si el host que los sirve falla).
Tener la habilidad de incorporar tu aplicación dentro de la imagen de un contenedor rápidamente y de forma fácil, como parte de la ejecución de un pipeline de entrega, y realizar su despliegue sobre cualquier hardware, físico o virtual, sobre (casi) cualquier sistema operativo de cualquier proveedor, los convierte en herramientas extremadamente lucrativas para quienes buscan realizar entregas más rápidas y más frecuentes. Los contenedores también mitigan muchos de los desafíos inherentes a la configuración de sistemas que las plataformas de administración de la configuración hace tiempo han estado resolviendo. La aplicación de parches, el manejo de variables de entorno y de estados del sistema, son obstáculos mucho más pequeños en una infraestructura basada en contenedores; todo lo que importa es que el kernel del sistema operativo, donde el contenedor está corriendo, soporte la ejecución de contenedores, y que cualquier dependencia externa necesaria para la ejecución del contenedor también esté presente.
¿Por qué es esto importante? Hay una alta posibilidad de que las habilidades de administración de la configuración de hoy queden completamente obsoletas en menos de cinco años.
El tiempo vuela.
Invierte tiempo en aprender cómo crear una imagen de un contenedor como parte de un pipeline. Explora las plataformas de orquestación de contenedores. Son muy poderosas.
Si eres un/a desarrollador/a, te recomiendo especialmente aprender más sobre UNIX, Windows y fundamentos de la red. Aunque la nube abstrae muchas de las complicaciones de administrar un sistema, depurar fallos en el rendimiento de una aplicación lenta se consigue sabiendo cómo funcionan las cosas por detrás. He incluido algunos libros sobre este tema en la siguiente sección.
Si esto te suena abrumador, no estás sola/o. Por suerte, existen un montón de pequeños proyectos donde puedes empezar tu aprendizaje. Uno de estos mini proyectos es el Servicio de Votos de Gary Stafford, una simple aplicación de votos basada en Java [5]. En Thoughtworks pedimos a nuestros candidatos coger un servicio de Github y ponerlo en una infraestructura de producción a través de un pipeline. Esto se puede combinar con la genial introducción a Ansible y CD [6] realizada por Max Griffith para aprender diferentes formas de cómo hacerlo.
Otra muy buena manera de familiarizarse con estas herramientas es seleccionar servicios populares y montarlos en una infraestructura usando solamente AWS y gestión de configuración. Primero, móntalo manualmente para tener una buena idea de qué hacer, y después mira cómo replicarlo usando solamente CloudFormation (o Terraform) y Ansible. Sorprendentemente, esta es una gran parte del trabajo que nosotros, las personas desarrolladoras de Infraestructura, hacemos para nuestros clientes en nuestro día a día. ¡Nuestros clientes consideran este trabajo altamente valioso!
Mi objetivo con el presente artículo es, con suerte, trazar cómo se ve ese camino. Mis ideas se basan en varias entrevistas, conversaciones y discusiones con muchas/os desarrolladoras/es y administradoras/es de sistemas. El artículo estará dividido en dos partes. La primera parte de esta serie brindará una resumida vista anecdótica al mundo de IT antes de que las ideas de DevOps tomarán al mundo por sorpresa. También exploraremos las habilidades que las/os reclutadoras/es están buscando cuando necesitan incorporar perfiles DevOps a sus compañías, y las habilidades útiles para las/os ingenieras/os que desean convertirse en expertas/os de DevOps. La segunda parte expondrá implementaciones de conceptos, comúnmente conocidos de DevOps, que he visto en la industria, junto a algunos libros útiles donde se discuten con mayor profundidad las ideas que hay detrás de este artículo.
El Antiguo Mundo de IT
Entender la historia es clave para comprender el futuro, y DevOps no es una excepción. Para entender la prevalencia y popularidad del movimiento DevOps, necesitamos comprender cómo era IT al final de los 90 y a partir del 2000. Esta fue mi experiencia.
Empecé mi carrera como administrador de sistemas Windows en una gran firma multinacional de finanzas a finales del 2006. En aquellos tiempos, expandir la infraestructura significaba llamar a Dell (o en nuestro caso, CDW) y realizar una orden de miles de cientos de dólares en servidores, equipamiento de redes, cables y programas. Todos destinados a los centros de datos, ya fueran internos o externos. Mientras que VMware aún intentaba convencer a las empresas de que usar máquinas virtuales era, de hecho, una forma de reducir los costos del mantenimiento de las aplicaciones que requerían especial atención al rendimiento, muchas otras empresas, incluyendo la mía, decidieron seguir corriendo las aplicaciones en su propio hardware físico. Nuestro departamento de Tecnología tenía un grupo entero dedicado a la Ingeniería y Operaciones del Centro de Datos, y su trabajo era negociar las tasas de arrendamiento para no tener que pagar una gran cantidad mensual, asegurarse de que nuestros sistemas estaban siendo refrigerados correctamente (lo cual es un gran problema a no ser que tengas un buen equipo) y, si se tenía un poco de suerte o el dinero necesario, el equipo de gente trabajando remoto en el centro de datos conocería lo suficiente acerca de los modelos de nuestro servidor para no equivocarse de enchufe durante las horas después de la comercialización.
Amazon Web Services y Rackspace empezaron a coger fuerza poco a poco, pero estaban lejos de alcanzar a la masa crítica.
En aquel entonces teníamos equipos dedicados a asegurarse que los sistemas operativos y el software que corría sobre aquel hardware funcionara cuando era esperado. Los ingenieros eran responsables de montar una arquitectura fiable para corregir fallos, monitorear y generar alertas en estos sistemas así como para definir cuál era la "imagen de referencia". La mayor parte de este trabajo se realizaba experimentando mucho manualmente, y el alcance de la mayoría de las pruebas se documentaba en un runbook, describiendo qué se hizo y asegurándose de que lo que se escribió hacía aquello que se esperaba. Esto era importante en grandes empresas como la nuestra ya que casi todo el soporte a nivel 1 y 2 se externalizaba y el entrenamiento que se daba se basaba en estos runbooks.
(Este es el mundo en el que viví durante los primeros tres años de mi carrera. ¡Mi sueño en aquel entonces era ser el que creara un modelo de referencia!)
Las entregas de software eran otro tema completamente diferente. Admito que no gané mucha experiencia trabajando en esa área. Sin embargo, debido a historias que he recopilado (y a experiencias recientes), puedo decirles que gran parte de la rutina del desarrollo de aplicaciones, en aquel entonces, era algo como lo siguiente:
Las/os desarrolladoras/es escribían código tal y como se especificaba en los requerimientos técnicos y funcionales que las/os analistas de negocio adquirían de reuniones en las que las/os desarrolladoras/es no estaban invitados.
De forma opcional, las personas desarrolladoras implementaban pruebas unitarias en su código para asegurarse de que nada demasiado raro pasara, como dividir entre cero sin lanzar una excepción.
Después de esto, las/os desarrolladoras/es marcaban su código como que estaba "listo para QA". Un QA cogía el código y lo corría en su propio entorno, el cual podía o no parecerse a producción o podría incluso ser el mismo entorno que el/la desarrollador/a original utilizó.
DevOps es la palabra que usaremos para describir el lado operacional de la transición hacia empresas lideradas por el software.
Los errores volvían a las personas desarrolladoras al cabo de "algunos días o semanas" dependiendo de otras actividades del negocio y/o de cuáles eran las prioridades en ese momento.
Mientras que las personas administradoras de sistemas y desarrolladoras no se veían frente a frente muy a menudo, la única cosa común a la que ambos se resistían era "el cambio de dirección". Esto era una composición de procedimientos altamente regulados, y en el caso de mi jefe en aquel momento, reglas muy necesarias que decidían cuándo y cómo los cambios técnicos ocurrían en la empresa. La mayoría de las empresas seguían la Biblioteca de Infraestructura de Tecnologías de Información, o el proceso ITIL, que, en resumen, hacía muchas preguntas sobre por qué, cuándo, dónde y cómo las cosas pasaban conjuntamente con un proceso para establecer un registro de auditoría de las decisiones que se llegaron a tomar.
Tal y como probablemente puedas deducir de la pequeña historia que acabo de contarte, muchas cosas en IT se hacían manualmente. Esto provocó muchos errores. Todos esos errores a su vez causaban una gran pérdida de ingresos. El trabajo de las personas a cargo de la administración de la configuración era minimizar esa pérdida de ingresos, y esto normalmente se transformaba, sin tener en cuenta su impacto ni su tamaño, en hacer entregas de software solo cada dos semanas y en hacer cambios en la configuración de los servidores, encolando dichas entregas o cambios entre el Viernes a las 4 de la tarde y el Lunes a las 5:59 de la mañana. (Irónicamente, esta pila de trabajo generaba aún más errores, que usualmente eran más serios).
Los equipos de DevOps no son “Equipos Tigres”
Debes estar pensando “¿De qué está hablando Carlos y cuándo comenzará a hablar sobre Ansible?” Adoro Ansible pero esperen un momento; esto es importante.
¿Has sido asignado alguna vez a un proyecto y has tenido que interactuar con el equipo de “DevOps”? ¿O has tenido que apoyarte en un “Administrador de la Configuración” o en equipos de “CI/CD” para asegurarte de que tu pipeline fuese configurado correctamente? ¿Alguna vez te has visto obligada/o a asistir a reuniones sobre tus entregas de software donde predomina la conversación sobre por qué ha tomado semanas su salida a producción después de que el trabajo estuviera marcado como “código terminado”? ¿Alguna vez has formado parte del “Equipo Tigre” creado inicialmente como una solución temporal para alinear equipos y que finalmente acabó siendo un equipo permanente?
Sí es así, entonces estás reviviendo la historia. Todo esto viene de lo expuesto anteriormente y llamar a tu equipo “DevOps” no va a arreglarlo.
Los silos funcionales se forman a partir de nuestro instinto de trabajar con personas como nosotros[1]. Naturalmente, no sorprende que este rasgo humano también se manifieste en el lugar de trabajo. Incluso vi cómo esto se manifestó en una compañía en la que trabajé antes de unirme a Thoughtworks. Cuando empecé allí, todas/os las/os desarrolladoras/es trabajaban en estrechos espacios comunes muy cerca unos de los otros. A medida que el código base fue creciendo en complejidad, las personas desarrolladoras que trabajaban en funcionalidades comunes se alineaban de forma natural unas con otras para comprobar y afrontar la complejidad de sus propias funcionalidades. Al poco tiempo, estos equipos se consolidaban de manera oficial.
(Para ser claro, no creo que los equipos agrupados por funcionalidades sean universalmente buenos o malos. Pensé que había sido la decisión correcta para la compañía mencionada anteriormente. Sin embargo, eran silos, y ocurrieron de forma natural.)
Las personas desarrolladoras y administradoras de sistemas en muchas de las compañías en las que trabajé, no sólo formaron silos naturales como este, sino que también los defendieron ciegamente y compitieron ferozmente entre sí. Las/os desarrolladoras/es se enfadaban con las/os administradoras/es de sistemas cuando sus entornos dejaban de funcionar o se bloqueaban. A las/os administradoras/es de sistemas no les gustaba que las/os desarrolladoras/es estuvieran rompiendo sus entornos de forma arbitraria todo el tiempo y que pidieran más potencia de procesamiento que la necesaria.
Ninguna de las partes entendía a la otra, y peor aún, ninguna intentaba entenderse.
El propósito de DevOps era ponerle un fin a esto.
DevOps no es un equipo. No es un grupo en Jira. Es una manera de pensar. De acuerdo con el movimiento de DevOps, en un mundo ideal, las personas desarrolladoras, administradoras de sistemas y stakeholders, deberían trabajar como un único equipo, y aunque unos puedan desconocer muchos aspectos del trabajo de los otros, al menos conocen lo suficiente para entenderse entre sí, entender sus tareas y poder, la mayoría de las veces, hablar un mismo lenguaje. Todo el mundo gana porque todos se entienden entre sí.
Adam Jacob lo dijo magistralmente: “DevOps es la palabra que usamos para describir la parte operacional de la transición hacia compañías lideradas por el software”
Habilidades
Una pregunta bastante común que me suelen hacer es “¿Qué necesito saber para adentrarme en el mundo de Devops?" La respuesta, como a muchas otras preguntas abiertas, es "depende".
Aprender Las Bases
Actualmente, las funciones del rol de “Ingeniero/a de DevOps” varían de compañía a compañía. Las compañías más pequeñas que tienen muchas/os desarrolladoras/es de software pero menos personas que entienden la infraestructura tienden a buscar personas con más experiencia administrando sistemas. Otras, usualmente más grandes y(o) antiguas que tienen una organización sólida de administradoras/es de sistemas seguramente optarán por un perfil más parecido a un “Google SRE”, por ejemplo: “un/a ingeniero/a de software para diseñar funciones operativas”[2] Esto no está escrito en piedra, sin embargo, como en cualquier otro trabajo de tecnología, la decisión depende en su mayoría de el/la gerente de reclutamiento a cargo.Dicho esto, nosotros en Thoughtworks normalmente buscamos Desarrolladores de Infraestructura y personas que aboguen por DevOps y que estén interesadas en aprender más sobre:
- Cómo administrar y desarrollar arquitecturas seguras y escalables usando plataformas en la nube (usualmente AWS, aunque los proveedores Azure, Google Cloud Platform and PaaS son populares también),
- Cómo construir y optimizar los pipelines y estrategias de entrega sobre herramientas CI/CD populares como Jenkins, GoCD y otras basadas en la nube como Travis CI o CircleCI,
- Cómo monitorear, generar logs y alertas frente a cambios en tu sistema utilizando herramientas basadas en series temporales como Kibana, Grafana o Splunk, y Loggly o Logstash, y,
- Cómo mantener la infraestructura como código, utilizando herramientas de administración de la configuración como Chef, Puppet o Ansible, así como la realización de despliegues usando herramientas como Terraform o CloudFormation.
Adoptar Contenedores
Los contenedores son cada vez más populares, y se han ido convirtiendo rápidamente en una excelente forma de alcanzar una densidad extremadamente alta de servicios y aplicaciones ejecutándose sobre pocos sistemas mientras incrementan su fiabilidad. (Herramientas de orquestación como Kubernetes y Mesos permiten poner a punto contenedores en cuestión de segundos si el host que los sirve falla).
Tener la habilidad de incorporar tu aplicación dentro de la imagen de un contenedor rápidamente y de forma fácil, como parte de la ejecución de un pipeline de entrega, y realizar su despliegue sobre cualquier hardware, físico o virtual, sobre (casi) cualquier sistema operativo de cualquier proveedor, los convierte en herramientas extremadamente lucrativas para quienes buscan realizar entregas más rápidas y más frecuentes. Los contenedores también mitigan muchos de los desafíos inherentes a la configuración de sistemas que las plataformas de administración de la configuración hace tiempo han estado resolviendo. La aplicación de parches, el manejo de variables de entorno y de estados del sistema, son obstáculos mucho más pequeños en una infraestructura basada en contenedores; todo lo que importa es que el kernel del sistema operativo, donde el contenedor está corriendo, soporte la ejecución de contenedores, y que cualquier dependencia externa necesaria para la ejecución del contenedor también esté presente.
¿Por qué es esto importante? Hay una alta posibilidad de que las habilidades de administración de la configuración de hoy queden completamente obsoletas en menos de cinco años.
El tiempo vuela.
Invierte tiempo en aprender cómo crear una imagen de un contenedor como parte de un pipeline. Explora las plataformas de orquestación de contenedores. Son muy poderosas.
Habilidad transversal: Mira hacia los lados
Si eres un/a administrador/a de sistemas y estás valorando hacer este cambio, también tendrás que saber cómo escribir código. Python y Ruby son lenguajes populares que se usan con este objetivo, ya que son portables (pueden ser usados en cualquier sistema operativo), rápidos y fáciles de leer y aprender. También se consideran la base de las herramientas más populares de la gestión de configuración (Python para Ansible, Ruby para Chef y Puppet) y de los clientes de las API's de la nube (Python y Ruby son comúnmente usados para clientes de AWS, Azure o GCP).Si eres un/a desarrollador/a, te recomiendo especialmente aprender más sobre UNIX, Windows y fundamentos de la red. Aunque la nube abstrae muchas de las complicaciones de administrar un sistema, depurar fallos en el rendimiento de una aplicación lenta se consigue sabiendo cómo funcionan las cosas por detrás. He incluido algunos libros sobre este tema en la siguiente sección.
Práctica, Práctica, Práctica
Si esto te suena abrumador, no estás sola/o. Por suerte, existen un montón de pequeños proyectos donde puedes empezar tu aprendizaje. Uno de estos mini proyectos es el Servicio de Votos de Gary Stafford, una simple aplicación de votos basada en Java [5]. En Thoughtworks pedimos a nuestros candidatos coger un servicio de Github y ponerlo en una infraestructura de producción a través de un pipeline. Esto se puede combinar con la genial introducción a Ansible y CD [6] realizada por Max Griffith para aprender diferentes formas de cómo hacerlo.
Otra muy buena manera de familiarizarse con estas herramientas es seleccionar servicios populares y montarlos en una infraestructura usando solamente AWS y gestión de configuración. Primero, móntalo manualmente para tener una buena idea de qué hacer, y después mira cómo replicarlo usando solamente CloudFormation (o Terraform) y Ansible. Sorprendentemente, esta es una gran parte del trabajo que nosotros, las personas desarrolladoras de Infraestructura, hacemos para nuestros clientes en nuestro día a día. ¡Nuestros clientes consideran este trabajo altamente valioso!
¡Sigue atenta/o!
¡Con esto acaba la primera parte! En la siguiente parte de esta serie, vamos a ver algunos ejemplos de DevOps del día a día y qué se puede encontrar dentro de los equipos de organizaciones tanto pequeñas como grandes.Referencias:
[1] https://www.psychologytoday.com/blog/time-out/201401/getting-out-your-silo
[2] https://landing.google.com/sre/interview/ben-treynor.html
Traducción realizada por: Ana Tellería y Javier Molina
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.