Get best of the week

¿Quién es DevOps y cuándo no es necesario?



El tema DevOps se ha vuelto muy popular en los últimos años. Muchos sueñan con unirse, pero, como lo demuestra la práctica, a menudo solo por el nivel de los salarios.

Algunos indican DevOps en sus CV, aunque no siempre conocen y entienden la esencia del término. Alguien cree que habiendo estudiado Ansible, GitLab, Jenkins, Terraform y similares (la lista se puede continuar a su gusto), se convertirá inmediatamente en una "debilidad". Esto, por supuesto, no es así.

Durante los últimos años, he estado involucrado principalmente en la implementación de DevOps en varias compañías. Antes de eso, trabajó durante más de 20 años en puestos de administrador de sistemas a director de TI. Ahora: ingeniero principal de DevOps en Playgendary.

Quien es DevOps


La idea de escribir un artículo surgió después de otra pregunta: "¿Quién es DevOps?". Todavía no hay un término establecido de qué o quién es. Algunas de las respuestas ya están en este video . Primero, destacaré los puntos principales, y luego compartiré mis observaciones y pensamientos.

DevOps no es un especialista que pueda contratar, ni un conjunto de utilidades, ni un departamento de desarrollo con ingenieros.

DevOps es una filosofía y metodología.

En otras palabras, este es un conjunto de prácticas que ayuda a los desarrolladores a interactuar activamente con los administradores del sistema. Es decir, conectar e integrar procesos de trabajo entre sí.

Con el advenimiento de DevOps, la estructura y las funciones de los especialistas se mantuvieron igual (hay desarrolladores, hay ingenieros), pero las reglas para la interacción han cambiado. Borrosa las fronteras entre departamentos.

Los objetivos de DevOps se pueden describir de tres maneras:

  • El software debe actualizarse regularmente.
  • El software debe hacerse rápidamente.
  • El software debe implementarse convenientemente y en poco tiempo.

DevOps no tiene una sola herramienta. Configurar, entregar y explorar varios productos no significa que DevOps haya aparecido en la empresa. Hay muchas herramientas y todos participan en diferentes etapas, pero sirven a un objetivo común.


Y esto es solo una parte de las herramientas de DevOps.

Durante más de 2 años he estado entrevistando a personas para el puesto de ingeniero de DevOps y me he dado cuenta de lo importante que es comprender claramente la esencia del término. He acumulado experiencias específicas, observaciones y pensamientos que quiero compartir.

De la experiencia de la entrevista, veo la siguiente imagen: los especialistas que consideran DevOps un trabajo generalmente tienen malentendidos con sus colegas .

Hubo un vívido ejemplo. Un joven llegó a la entrevista con un montón de palabras inteligentes en el currículum. En los últimos tres lugares de trabajo, tenía 5-6 meses de experiencia. Dejó dos startups porque "no despegaron". Pero en cuanto a la tercera compañía, dijo que nadie lo entiende: los desarrolladores escriben código en Windows, y el director obliga a este código a "envolverse" en un Docker normal e incrustado en una tubería de CI / CD. El tipo contó muchas cosas negativas sobre su trabajo actual y sus colegas. Quería responder: "Entonces no venderás el elefante".

Luego le hice una pregunta, que es una de las primeras en mi lista para cada candidato.

- ¿Qué significa DevOps para ti personalmente?
- ¿Generalmente o cómo lo percibo?

Estaba interesado en su opinión personal. Él conocía la teoría y el origen del término, pero estaba muy en desacuerdo con ellos. Pensó que DevOps era una publicación. Aquí yace la raíz de sus problemas. Al igual que otros profesionales con la misma opinión.

Los empleadores, habiendo escuchado sobre la "magia de DevOps", quieren encontrar una persona que venga y cree esta "magia". Y los solicitantes de la categoría "DevOps - este puesto" no entienden que con este enfoque no podrán cumplir con las expectativas. Y, en general, DevOps escribió en su currículum, porque esta es una tendencia y pagan mucho por ello.

Metodología y filosofía DevOps


La metodología es teórica y práctica. En nuestro caso, el segundo. Como mencioné anteriormente, DevOps es un conjunto de prácticas y estrategias utilizadas para lograr los objetivos establecidos. Y en cada caso, dependiendo de los procesos comerciales de la empresa, puede diferir significativamente. Lo que no lo hace mejor o peor.

La metodología DevOps es solo un medio para lograr sus objetivos.

Ahora sobre cuál es la filosofía de DevOps. Y esta es probablemente la pregunta más difícil.

Es bastante difícil formular una respuesta breve y sucinta, porque aún no se ha formalizado. Y dado que los partidarios de la filosofía DevOps están más involucrados en la práctica, simplemente no hay tiempo para filosofar. Sin embargo, este es un proceso muy importante. Y directamente relacionado con actividades de ingeniería. Incluso hay un campo especializado de conocimiento: la filosofía de la tecnología .

En mi universidad no había tal materia, tuve que estudiar todo yo mismo sobre la base de materiales que pude encontrar en los años 90. El tema es opcional para la educación en ingeniería, de ahí la falta de formalización de la respuesta. Pero aquellas personas que están seriamente inmersas en DevOps, comienzan a sentir una especie de "espíritu" o "exhaustividad inconsciente" de todos los procesos de la empresa.

Traté de formalizar algunos de los "postulados" de esta filosofía. Resultó lo siguiente:

  • DevOps no es algo independiente, que se puede distinguir en un área separada de conocimiento o actividad.
  • La metodología DevOps debe ser guiada por todos los empleados de la empresa que planifican sus actividades.
  • DevOps afecta a todos los procesos dentro de la empresa.
  • DevOps existe para reducir el tiempo dedicado a cualquier proceso dentro de la empresa para garantizar el desarrollo de sus servicios y la máxima comodidad del cliente.
  • DevOps, en lenguaje moderno, es la posición proactiva de cada empleado de la empresa, con el objetivo de reducir los costos de tiempo y mejorar la calidad de los productos de TI que nos rodean.

Creo que mis "postulados" son un tema aparte para el debate. Pero ahora hay algo sobre lo que construir.

¿Qué hace DevOps?


La palabra clave aquí es comunicación. Hay muchas comunicaciones, cuyo iniciador debería ser el mismo ingeniero DevOps. ¿Porqué es eso? Porque es filosofía y metodología, y solo entonces conocimiento de ingeniería.

No puedo hablar sobre el mercado laboral occidental con 100% de certeza. Pero sé mucho sobre el mercado DevOps en Rusia. Además de cientos de entrevistas, durante el último año y medio participé en cientos de preventas técnicas para el servicio "Implementación de DevOps" para grandes empresas y bancos rusos.

En Rusia, DevOps sigue siendo un tema muy joven, pero que ya es tendencia. Hasta donde sé, solo en Moscú la escasez de tales especialistas en 2019 ascendió a más de 1000 personas. Y la palabra Kubernetes para empleadores es casi como un trapo rojo para un toro. Los adherentes de esta herramienta están listos para usarla incluso cuando no es necesaria y económicamente no es viable. Un empleador no siempre comprende en qué casos es más apropiado usarlo, y con una implementación adecuada, el mantenimiento de un clúster de Kubernetes es 2-3 veces más costoso que implementar una aplicación utilizando un esquema de clúster convencional. Úselo donde realmente lo necesita.



Implementar DevOps en términos de dinero es costoso. Y se justifica solo donde brinda beneficios económicos en otras áreas, y no por sí solo.

Los ingenieros de DevOps, de hecho, son pioneros: son los primeros en introducir esta metodología en la empresa y desarrollar procesos. Para que esto sea exitoso, el especialista debe interactuar constantemente con empleados y colegas en todos los niveles. Como suelo decir, todos los empleados de la empresa deberían participar en el proceso de implementación de DevOps: desde una empleada de limpieza hasta un CEO. Y este es un requisito previo. Si el miembro más joven del equipo no sabe y entiende qué es DevOps y por qué se realizan ciertas acciones organizacionales, entonces una implementación exitosa fallará.

Además, el ingeniero DevOps necesita usar un recurso administrativo de vez en cuando. Por ejemplo, para superar la "resistencia del medio ambiente", cuando el equipo no está listo para aceptar las herramientas y la metodología de DevOps.

El desarrollador debe escribir solo código y pruebas. Para hacer esto, no necesita una computadora portátil súper potente en la que desplegará y respaldará localmente toda la infraestructura del proyecto. Por ejemplo, el front-end mantiene en su computadora portátil todos los elementos de la aplicación, incluida la base de datos, el emulador S3 (minio) y más. Es decir, pasa mucho tiempo manteniendo esta infraestructura local y está luchando solo con todos los problemas de dicha solución. En lugar de desarrollar código para el frente. Tales personas pueden resistir fuertemente cualquier cambio.

Pero hay equipos que, por el contrario, están felices de presentar nuevas herramientas y métodos, y participan activamente en este proceso. Aunque incluso en este caso, la comunicación entre el ingeniero DevOps y el equipo no se ha cancelado.

Cuando no se necesita DevOps


Hay situaciones en las que no se necesita DevOps. Esto es un hecho, debe ser entendido y aceptado.

En primer lugar, esto se aplica a cualquier empresa (especialmente a las pequeñas empresas), cuando sus ganancias no dependen directamente de la presencia o ausencia de productos de TI que brinden servicios de información a los clientes. Y aquí no estamos hablando del sitio web de la compañía, ya sea una "tarjeta de visita" estática o con bloques de noticias dinámicos, etc.

Se requiere DevOps cuando la satisfacción de su cliente y su deseo de volver a usted dependen de la disponibilidad de estos servicios de información para interactuar con el cliente, su calidad y orientación.

Un ejemplo sorprendente es un banco bien conocido. La empresa no cuenta con las oficinas habituales de los clientes, el flujo de trabajo se lleva a cabo por correo o mensajería, y muchos empleados trabajan desde casa. La empresa dejó de ser solo un banco y, en mi opinión, se convirtió en una empresa de TI con tecnologías desarrolladas de DevOps.

Se pueden encontrar muchos otros ejemplos y conferencias en las grabaciones de reuniones temáticas y conferencias. Visité personalmente algunos de ellos, esta es una experiencia muy útil para aquellos que desean desarrollarse en esta dirección. Aquí hay enlaces a canales de YouTube con buenas conferencias y materiales sobre DevOps:


Ahora mire su negocio y piense en esto: ¿cuánto dependen su empresa y sus ganancias de los productos de TI que proporcionan interacción con el cliente?

Si su empresa vende pescado en una tienda pequeña y el único producto de TI son dos configuraciones 1C: Enterprise (Contabilidad y UNF), entonces no tiene sentido hablar de DevOps.

Si trabaja en una gran empresa comercial e industrial (por ejemplo, produce rifles de caza), entonces vale la pena considerarlo. Puede tomar la iniciativa y transmitir a su gerencia las perspectivas para implementar DevOps. Bueno, al mismo tiempo, lidera este proceso. Una actitud proactiva es uno de los postulados importantes de la filosofía DevOps.

El tamaño y el volumen de la facturación financiera anual no es el criterio principal para determinar si su empresa necesita DevOps.

Imagine una gran empresa industrial que no interactúa directamente con los clientes. Por ejemplo, algunos fabricantes de automóviles y empresas automotrices. Ahora no estoy seguro, pero, por mi experiencia pasada, durante muchos años toda la interacción con los clientes se realizó por correo electrónico y por teléfono.

Sus clientes son una lista limitada de concesionarios de automóviles. Y un especialista del fabricante está vinculado a cada uno. Todo el flujo de trabajo interno ocurre a través de SAP ERP. Los empleados internos, de hecho, son clientes del sistema de información. Pero la gestión de esta IP se lleva a cabo por medios clásicos de gestión de sistemas de clúster. Lo que excluye la posibilidad de usar prácticas de DevOps.

De ahí la conclusión: para tales empresas, la implementación de DevOps no es algo críticamente importante, si recordamos los objetivos de la metodología desde el principio del artículo. Pero no excluyo que algunas herramientas DevOps sean utilizadas por ellos hoy.

Por otro lado, hay muchas pequeñas empresas que desarrollan software utilizando la metodología, filosofía, prácticas y herramientas de DevOps. Y creen que los costos de implementar DevOps son costos que les permiten competir efectivamente en el mercado de software. Se pueden ver ejemplos de tales empresas aquí .

El criterio principal para comprender si se necesita DevOps: la importancia de sus productos de TI para la empresa y los clientes.

Si el principal producto rentable de la empresa es el software, necesita DevOps. Y no es tan importante si gana dinero real con la ayuda de otros bienes. Esto también incluye tiendas en línea o aplicaciones móviles con juegos.

Cualquier juego existe gracias a la financiación: directa o indirecta de los jugadores. En Playgendary, estamos desarrollando juegos móviles gratuitos en los que participan más de 200 personas directamente. ¿Cómo usamos DevOps?

Sí, tal como se describió anteriormente. Me comunico constantemente con desarrolladores y evaluadores, realizo capacitación interna para el personal y las herramientas de la metodología DevOps.

Ahora estamos utilizando Jenkins activamente como una herramienta de canalizaciones de CI / CD para ejecutar todas las canalizaciones de ensamblaje con Unity y luego implementarlas en App Store y Play Market. Más de la caja de herramientas clásica:

  • Asana - para gestión de proyectos. Integración configurada con Jenkins.
  • Google Meet: para videollamadas.
  • Slack: para comunicaciones y varias alertas, incluidas las notificaciones de Jenkins.
  • Atlassian Confluence: para documentación y trabajo en grupo.

En un futuro próximo, presentaremos el análisis de código estático utilizando SonarQube y realizaremos pruebas de interfaz de usuario automatizadas con herramientas Selenium en la etapa de Integración continua.

En lugar de una conclusión


Quiero terminar con el siguiente pensamiento: para convertirme en un ingeniero de DevOps de alta calificación, es vital aprender a comunicarse animadamente con las personas.

El ingeniero DevOps es un jugador de equipo. Y de ninguna otra manera. La iniciativa de comunicarse con sus colegas debe provenir de él mismo y no bajo la influencia de ninguna circunstancia. El especialista de DevOps debería ver y ofrecer la mejor solución para el equipo.

Y sí, la implementación de cualquier solución requerirá mucha discusión, y al final incluso puede cambiar. Al desarrollar, ofrecer e implementar de manera independiente sus ideas, dicha persona tiene un valor creciente tanto para el equipo como para el empleador. Lo que, en última instancia, se refleja en el monto de su remuneración mensual o en forma de bonos adicionales.

More articles:


All Articles