¿Qué es DevOps? La guía definitiva

¿Cómo funciona DevOps?

DevOps es una metodología destinada a mejorar el trabajo durante todo el ciclo de vida del desarrollo de software. Puede visualizar un proceso de DevOps como un bucle infinito, que comprende estos pasos: planificar, codificar, construir, probar, lanzar, implementar, operar, monitorear y –a través de comentarios– planificar, lo que restablece el bucle.

Idealmente, DevOps significa que un equipo de TI escribe software que cumple perfectamente con los requisitos del usuario, lo implementa sin pérdida de tiempo y se ejecuta de manera óptima en el primer intento. Las organizaciones utilizan una combinación de cultura y tecnología para lograr este objetivo.

Para alinear el software con las expectativas, los desarrolladores y las partes interesadas se comunican sobre el proyecto, y los desarrolladores trabajan en pequeñas actualizaciones que se implementan de forma independiente unas de otras.

Para evitar tiempos de espera, los equipos de TI utilizan canalizaciones de CI/CD y otras automatizaciones para mover el código de un paso de desarrollo e implementación a otro. Los equipos revisan los cambios inmediatamente y pueden hacer cumplir políticas para garantizar que las versiones cumplan con los estándares.

Es fácil escribir software rápidamente; escribir software que funcione es otra historia. Para implementar un buen código en producción, los seguidores de DevOps utilizan contenedores u otros métodos para hacer que el software se comporte de la misma manera desde el desarrollo hasta las pruebas y la producción. Implementan cambios individualmente para que los problemas sean rastreables. Los equipos dependen de la gestión de la configuración para lograr entornos de alojamiento e implementación consistentes. Los problemas que descubren en las operaciones en vivo conducen a mejoras en el código, a menudo a través de una investigación post mortem intachable y canales de retroalimentación continua.

Los desarrolladores pueden admitir el software en vivo, lo que les impone la responsabilidad de abordar las consideraciones de tiempo de ejecución. Los administradores de operaciones de TI pueden participar en las reuniones de diseño de software, ofreciendo orientación sobre cómo utilizar los recursos de manera eficiente y segura. Cualquiera puede contribuir a realizar autopsias sin culpa. Cuanto más colaboren y compartan habilidades estos especialistas, más podrán fomentar una cultura DevOps. 

¿Qué problemas resuelve DevOps?

Cada empresa enfrenta sus propios desafíos, pero los problemas comunes incluyen lanzamientos que demoran demasiado, software que no cumple con las expectativas y TI que limita el crecimiento empresarial.

Sin tiempos de espera, procesos manuales y revisiones prolongadas, un proyecto DevOps pasa más rápido de los requisitos al software en vivo. Los tiempos de ciclo más cortos pueden evitar que los requisitos cambien para que el producto entregue lo que los clientes desean.

DevOps resuelve problemas de comunicación y prioridad entre especializaciones de TI. Para crear software viable, los equipos de desarrollo deben comprender el entorno de producción y probar su código en condiciones realistas. Una estructura tradicional coloca a los equipos de desarrollo y operaciones en silos. Esto significa que los desarrolladores están satisfechos cuando su código ofrece funcionalidad y, si el lanzamiento falla en producción, depende del equipo de operaciones solucionar los problemas.

Con una cultura DevOps, los desarrolladores no recurren a la respuesta "funcionó en mi máquina" cuando surge un problema. Los cambios implementados en la producción son pequeños y reversibles. Además, todo el equipo entiende los cambios, lo que simplifica enormemente la gestión de incidencias.

Con un proceso más rápido desde la idea hasta el software real, las empresas pueden aprovechar las oportunidades del mercado. De esta forma, DevOps proporciona una ventaja competitiva a las empresas.

La evolución de DevOps

A Patrick Debois, consultor de desarrollo de software, se le atribuye la creación del término DevOps en 2009 al nombrar una conferencia DevOps Days. DevOps abordó una deficiencia de la metodología de desarrollo de software ágil: el desarrollo de código rápido e iterativo no necesariamente conducía a una implementación de código rápida e iterativa.

Simultáneamente con la profundización de lo ágil en las operaciones, los administradores de TI se irritaron con pasos de gestión de cambios a veces laboriosos y demasiado complejos en el marco de ITIL. ITIL defiende la TI estable, confiable y predecible, mientras que lo ágil aboga por la colaboración y el cambio. DevOps tocó la fibra sensible de personas de ambos lados. De hecho, las organizaciones pueden utilizar tanto ITIL como DevOps, especialmente si adoptan la nube.

El concepto de DevOps se popularizó luego con el libro The Phoenix Project en 2013. The Phoenix Project utiliza una narrativa ficticia para ilustrar problemas endémicos y ayudar a los gerentes de TI a comprender los conceptos y beneficios de la colaboración y las tecnologías compartidas.

Los primeros defensores de DevOps incluyeron estos actores clave:

• Debois y su colaborador Andrew Clay Shafer;
• los autores de The Phoenix Project, Gene Kim, Kevin Behr y George Spafford;
• Paul Hammond y John Allspaw, pioneros influyentes en Flickr;
• los pioneros de la entrega continua Jez Humble y Dave Farley;
• el defensor de la contenedorización John Willis; y
• organizadores del Informe Sobre el Estado de DevOps, incluidas Alanna Brown y Nicole Forsgren.

A medida que DevOps se hizo popular, las organizaciones formalizaron sus enfoques. El minorista Target creó el método de formación DevOps Dojo, por ejemplo. Los proveedores promocionaron capacidades que habilitan DevOps en herramientas, desde chatbots de colaboración hasta suites de CI/CD integradas en servicios en la nube. "Ingeniero de DevOps" pronto surgió como título de trabajo.

DevOps continúa evolucionando, a medida que la inteligencia artificial emerge para ayudar en todo, desde la creación de código hasta la gestión de incidentes. La IA para DevOps (o AIOps ) significa una automatización más inteligente y tiempos de espera aún más cortos, incluso traducciones perfectas de las necesidades empresariales a la oferta tecnológica, pero aún quedan muchas barreras antes de que esto se convierta en realidad.

Si bien DevOps ha alcanzado un estatus generalizado, no todos los que lo adoptan están totalmente convertidos a DevOps. Muchos confían en un enfoque DevOps para proyectos de TI que generan ingresos, donde ven un retorno de la inversión en herramientas y habilidades de vanguardia. Para muchos servicios de TI internos que son relativamente estables y maduros, DevOps no ofrece beneficios significativos.

Metodologías, principios y estrategias

DevOps está asociado con el desarrollo de software ágil porque los profesionales ágiles promovieron DevOps como una forma de extender la metodología a la producción. El enfoque incluso ha sido etiquetado como una contracultura a las prácticas de gestión de servicios de TI defendidas en ITIL. DevOps no tiene un marco oficial.

Para perfeccionar sus estrategias, las organizaciones deben comprender los contextos relacionados de DevOps, el desarrollo ágil y en cascada, la ingeniería de confiabilidad del sitio (SRE) y SysOps, e incluso las variaciones dentro de DevOps.

DevOps versus Cascada. El desarrollo en cascada comprende una serie de pasos y puertas en una progresión lineal hacia la producción. Sus fases son requisitos, análisis, diseño, codificación e implementación, pruebas, operación e implementación, y mantenimiento. En los equipos de cascada, el desarrollo prueba el código nuevo en un entorno aislado para garantizar la calidad (QA) y –si se cumplen los requisitos– libera el código a las operaciones para su uso en producción. Las operaciones de TI implementan varias versiones a la vez, con controles exhaustivos. El soporte es responsabilidad de las operaciones. 

Los enfoques de cascada generan largas esperas entre las versiones de software. Debido a que los equipos de desarrollo y operaciones trabajan por separado, los desarrolladores no siempre son conscientes de los obstáculos operativos que impiden que el código funcione según lo previsto.

El modelo DevOps alinea los esfuerzos de desarrollo, control de calidad y operaciones de TI con menos puertas y un flujo de trabajo más continuo. Por ejemplo, algunas de las responsabilidades del equipo de operaciones pasan del proceso de entrega de aplicaciones al equipo de desarrollo. Las operaciones de TI proporcionan comentarios para mejorar el código. En lugar de pasos cerrados, DevOps se basa en procesos de desarrollo continuo, integración continua, entrega y monitoreo continuos.

DevOps versus desarrollo ágil. Agile es un enfoque de desarrollo de software definido en el “Manifiesto ágil”. Los equipos ágiles se centran en ciclos rápidos e incrementales de creación y entrega de código, conocidos como sprints. Cada sprint se repite sobre el anterior, lo que hace que el software sea muy flexible y adaptable a los requisitos cambiantes. Es posible que la visión original de un proyecto se pierda a lo largo de este ciclo.

DevOps surgió del éxito del enfoque ágil en mejorar la velocidad de desarrollo, y la comprensión de que las desconexiones entre los equipos de desarrollo y operaciones –así como entre TI y el lado comercial de la organización– obstaculizaron significativamente la entrega del software ágil a los usuarios.

En un flujo de trabajo exclusivamente ágil, los equipos de desarrollo y operaciones tienen objetivos y liderazgo separados. Cuando una organización utiliza DevOps y Agile juntos, tanto los equipos de desarrollo como de operaciones administran el código durante todo el ciclo de vida de desarrollo de software. Si bien el trabajo ágil suele formalizarse con un marco, como Scrum, DevOps no tiene un marco.

DevOps versus SRE. La ingeniería de confiabilidad del sitio surgió al mismo tiempo que Agile y DevOps. Iniciado a principios de la década de 2000 en Google, es esencialmente un enfoque centrado en la programación y la automatización del ciclo de vida del desarrollo de software. Los problemas deben resolverse de manera que se impida que vuelvan a ocurrir. Se deben minimizar las tareas rutinarias.

La caja de herramientas de SRE se asemeja mucho a la de DevOps. Ambas disciplinas apuntan a la mejora continua. Los ingenieros de SRE y DevOps buscan abolir los silos entre el desarrollo y las operaciones. Si bien DevOps también puede extenderse a las partes interesadas del negocio, SRE generalmente permanece dentro de los límites de los procesos de TI. 

DevOps versus SysOps. SysOps normalmente denota que un administrador de TI o un equipo de TI gestiona la implementación de producción y el soporte para una gran aplicación distribuida, como un producto SaaS. Al igual que los que adoptan DevOps, los equipos de SysOps deben estar versados ​​en automatización y computación en la nube, así como en otras tecnologías que permitan que las aplicaciones funcionen bien a gran escala. Los equipos de SysOps solucionan interrupciones e incidentes de TI, monitorean problemas de rendimiento, hacen cumplir las reglas de seguridad y optimizan las operaciones.

También se centran en la alta disponibilidad, la tolerancia a fallos, la seguridad y el rendimiento, al igual que otros administradores de TI. Si bien es probable que los profesionales de SysOps utilicen algunas herramientas de desarrollo y comprendan los procesos de desarrollo, su trabajo no está tan entrelazado con el desarrollo como en un trabajo de DevOps. Sin embargo, los roles SysOps pueden existir dentro de organizaciones DevOps y SRE.

DevSecOps versus BizDevOps versus GitOps. Algunas organizaciones amplían el alcance de DevOps para incluir otras funciones o departamentos. En DevSecOps, la planificación, los análisis, las pruebas y las revisiones de seguridad se producen continuamente a lo largo del ciclo de DevOps. BizDevOps se centra en conectar ejecutivos, propietarios de aplicaciones y otras partes interesadas del negocio con el equipo técnico, que desarrolla, prueba y respalda el software. Si bien se puede decir que más colaboración es mejor que menos, estos colaboradores deben compartir aportes efectivos, oportunos y precisos.

Otra variación de DevOps, o una facción diferente del mismo movimiento, es GitOps. GitOps, llamado así por su enfoque en el repositorio del mismo nombre y la tecnología de control de versiones, propugna el control de fuente declarativo sobre el código de infraestructura y aplicaciones. Todo lo relacionado con el software –desde los requisitos de funciones, hasta el entorno de implementación– proviene de una única fuente de verdad.

Beneficios y desafíos de DevOps

Los beneficios de DevOps incluyen lo siguiente:

• menos silos y mayores comunicaciones entre grupos de TI;
• tiempo de comercialización más rápido para el software;
• mejora rápida basada en la retroalimentación;
• menos tiempo de inactividad;
• mejora de todo el proceso de entrega de software mediante compilaciones, validaciones e implementación;
• trabajo menos doméstico, gracias a la automatización;
• procesos de desarrollo simplificados a través de una mayor responsabilidad y propiedad del código en el desarrollo; y
• roles y habilidades más amplios.

Sin embargo, los desafíos de DevOps abundan:

• cambios organizacionales y departamentales de TI, incluidas nuevas habilidades y roles laborales;
• herramientas y plataformas costosas, incluida la capacitación y el apoyo para utilizarlas de manera efectiva;
• desarrollo y proliferación de herramientas informáticas;
• automatización innecesaria, frágil o insegura;
• escalar DevOps en múltiples proyectos y equipos;
• implementación más riesgosa debido a una mentalidad de falla rápida y generalización del trabajo versus especialización;
• cumplimiento normativo, especialmente cuando se requiere separación de roles; y
• nuevos cuellos de botella.

Adopción de DevOps

Las transformaciones de DevOps no ocurren de la noche a la mañana. Muchas empresas comienzan con un proyecto piloto, una aplicación sencilla en la que pueden familiarizarse con nuevas prácticas y herramientas. Para la adopción de DevOps a gran escala, intente avanzar por etapas. 

Inicialmente, DevOps puede significar un compromiso por parte de los equipos de desarrollo y operaciones de TI para comprender las preocupaciones y los límites tecnológicos que existen en cada etapa del proyecto de software. Acuerde los KPI para mejorar, como tiempos de ciclo más cortos o menos errores en producción. Sienta las bases para procesos continuos mediante la comunicación entre roles laborales.

Evaluar las herramientas existentes para el desarrollo y las operaciones de TI. Identifique deficiencias, como un paso que siempre se maneja manualmente o una herramienta sin API para conectarse con otras herramientas. Considere la posibilidad de estandarizar un proceso de DevOps para toda la empresa. Con un canal, los miembros del equipo pueden pasar de un proyecto a otro sin necesidad de volver a capacitarse. Los especialistas en seguridad pueden reforzar la canalización y se facilita la gestión de licencias. La desventaja de este enfoque es que los equipos de DevOps renuncian a la libertad de utilizar lo que mejor les funcione.

La organización ahora cuenta con una mentalidad DevOps, métricas para rastrear el éxito y herramientas capaces. Centrarse en las mejores prácticas, el intercambio de conocimientos y el desarrollo de habilidades para seguir mejorando. Optimice las herramientas y las tecnologías, identificando obstáculos y brechas que afectan sus KPI.

Las organizaciones pueden utilizar el modelo de madurez de DevOps como guía para su adopción:

• Inicial. Los equipos están aislados; el trabajo es reactivo y se realiza con opciones de herramientas y procesos ad hoc.
• Definido. Un proyecto piloto define un enfoque DevOps, procesos y herramientas básicos. Es una prueba de concepto.
• Administrado. La organización amplía la adopción de DevOps con las lecciones aprendidas del piloto. Los resultados del piloto son repetibles con diferentes miembros del personal y tipos de proyectos.
• Medido. Con procesos y herramientas implementados, los equipos comparten conocimientos y perfeccionan prácticas. La automatización y la conectividad de herramientas aumentan y los estándares se hacen cumplir a través de políticas.
• Optimizado. Se produce una mejora continua. DevOps podría evolucionar hacia diferentes conjuntos de herramientas o procesos para adaptarse a los casos de uso. Por ejemplo, las aplicaciones orientadas al cliente tienen una mayor frecuencia de lanzamiento y las aplicaciones de gestión financiera siguen las prácticas de DevSecOps.

Herramientas de desarrollo y operaciones

DevOps es una mentalidad, no un conjunto de herramientas. Pero es difícil hacer algo en un equipo de TI sin las herramientas adecuadas. En general, los profesionales de DevOps dependen de una canalización de CI/CD, contenedores y alojamiento en la nube. Las herramientas pueden ser distribuciones de tecnología de código abierto, propietarias o compatibles. 

Repositorios de código. Los repositorios de código fuente controlados por versiones permiten que varios desarrolladores trabajen en el código. Los desarrolladores revisan el código y pueden volver a una versión anterior del código si es necesario. Estas herramientas mantienen un registro de las modificaciones realizadas al código fuente. Sin seguimiento, los desarrolladores pueden tener dificultades para seguir qué cambios son recientes y qué versiones del código están disponibles para los usuarios finales.

En una canalización de CI/CD, un cambio de código confirmado en el repositorio de control de versiones activa automáticamente los siguientes pasos, como un análisis de código estático o pruebas unitarias y de compilación. Las herramientas para la gestión del código fuente incluyen Git y GitHub.

Depósitos de artefactos. El código fuente se compila en un artefacto para realizar pruebas. Los repositorios de artefactos permiten resultados basados ​​en objetos y controlados por versiones. La gestión de artefactos es una buena práctica por las mismas razones que la gestión del código fuente controlada por versiones. Ejemplos de repositorios de artefactos incluyen JFrog Artifactory y Nexus Repository.

Motores de canalización CI/CD. CI/CD permite a los equipos de DevOps validar y entregar aplicaciones al usuario final con frecuencia a través de la automatización durante el ciclo de vida de desarrollo. La herramienta de integración continua inicializa procesos para que los desarrolladores puedan crear, probar y validar código en un repositorio compartido tantas veces como sea necesario sin trabajo manual. La entrega continua amplía estos pasos automáticos a través de pruebas a nivel de producción y configuraciones para la gestión de lanzamientos. La implementación continua va un paso más allá e invoca pruebas, configuración y aprovisionamiento, así como capacidades de monitoreo y posibles reversiones. Las herramientas comunes para CI, CD o ambos incluyen Jenkins, GitLab y CircleCI. 

Contenedores. Los contenedores son tiempos de ejecución aislados para software en un sistema operativo compartido. Los contenedores proporcionan una abstracción que permite que el código funcione de la misma manera en diferentes infraestructuras subyacentes, desde el desarrollo hasta las pruebas y la puesta en escena, y luego hasta la producción. Docker es el software de creación de contenedores más conocido, mientras que Microsoft ofrece opciones específicas de contenedores de Windows. Los orquestadores de contenedores –como Kubernetes y las distribuciones comerciales de Kubernetes Red Hat OpenShift y Amazon Elastic Kubernetes Service– implementan, escalan y mantienen contenedores automáticamente.

Gestión de configuración. Los sistemas de gestión de la configuración permiten que TI aprovisione y configure software, middleware e infraestructura en función de un script o una plantilla. El equipo de DevOps puede configurar entornos de implementación para lanzamientos de código de software y aplicar políticas en servidores, contenedores y máquinas virtuales a través de una herramienta de gestión de configuración. Los cambios en el entorno de implementación se pueden controlar y probar en versión, de modo que los equipos de DevOps puedan administrar la infraestructura como código. Las herramientas de gestión de configuración incluyen Puppet y Chef.

Entornos de nube. Las organizaciones DevOps a menudo adoptan simultáneamente la infraestructura de la nube porque pueden automatizar su implementación, escalamiento y otras tareas de administración. AWS y Microsoft Azure se encuentran entre los proveedores de nube más utilizados. Muchos proveedores de nube también ofrecen servicios de CI/CD.

Supervisión. Además, las herramientas de monitoreo permiten a los profesionales de DevOps observar el rendimiento y la seguridad de las versiones de código en sistemas, redes e infraestructura. Pueden combinar el seguimiento con herramientas de análisis que proporcionen inteligencia operativa. Los equipos de DevOps utilizan estas herramientas juntas para analizar cómo los cambios en el código afectan el entorno general. Las opciones son amplias, pero incluyen New Relic One, Dynatrace, Prometheus, Datadog y Splunk.

Canalizaciones de DevOps basadas en la nube. Los proveedores de nube pública ofrecen conjuntos de herramientas DevOps nativas para usar con cargas de trabajo en sus plataformas. Una lista incompleta incluye AWS CodePipeline y CloudFormation, Azure DevOps and Pipelines y Google Cloud Deployment Manager. Quienes adoptan la nube tienen la opción de utilizar estos servicios preintegrados o ejecutar herramientas de terceros. Por ejemplo, una organización puede utilizar HashiCorp Terraform o CloudFormation para crear plantillas de infraestructura como código para sus cargas de trabajo de AWS.

Modelos como servicio. Por último, DevOps como servicio es un modelo de entrega para un conjunto de herramientas que facilita la colaboración entre el equipo de desarrollo de software de una organización y el equipo de operaciones de TI. En este modelo de entrega, el proveedor reúne un conjunto de herramientas y maneja las integraciones para cubrir sin problemas el proceso general de creación, entrega y mantenimiento del código.

Habilidades de desarrollo y operaciones

A menudo se dice que DevOps es más una filosofía o una cultura de TI colaborativa que una descripción de trabajo o un conjunto de habilidades estrictamente definido. Debido a que el área es tan amplia, los puestos de DevOps se adaptan mejor a los generalistas de TI que a los especialistas.

El rol de ingeniero de DevOps no corresponde a una sola carrera profesional. Los profesionales pueden ingresar al puesto desde una variedad de orígenes. Por ejemplo, un desarrollador de software puede adquirir habilidades en operaciones, como la configuración de la infraestructura de alojamiento, para convertirse en ingeniero de DevOps. De manera similar, un administrador de sistemas con conocimientos de codificación, secuencias de comandos y pruebas puede convertirse en ingeniero de DevOps.

Muchas ofertas de trabajo de DevOps requieren conocimientos de contenedores, nube y CI/CD, así como habilidades interpersonales. Es posible que un ingeniero de DevOps también necesite cambiar procesos y resolver problemas organizacionales para lograr resultados comerciales.

Otros títulos que se encuentran a menudo en organizaciones DevOps incluyen los siguientes:

• desarrollador de infraestructura;
• ingeniero de confiabilidad del sitio;
• ingeniero de compilación y lanzamiento;
• desarrollador full-stack;
• especialista en automatización; e
• ingeniero de plataformas CI/CD.

La mayoría de los trabajos de DevOps de nivel básico requieren un título en informática o un campo relacionado que cubra codificación, pruebas de control de calidad y componentes de infraestructura de TI. Los puestos de nivel superior pueden requerir títulos avanzados en arquitectura de sistemas y diseño de software. Las personas en esta trayectoria profesional también deberían ampliar sus conocimientos a través de libros de DevOps y conectarse con otros miembros de la comunidad a través de blogs y conferencias.

No existen certificaciones de DevOps reconocidas en toda la industria como las hay para marcos formalizados como ITIL. IBM Red Hat ofrece certificación DevOps, mientras que DevOps Institute tiene opciones neutrales para los proveedores para niveles que van desde conocimiento fundamental hasta experto.