¿Qué es DevOps? Una introducción completa

DevOps está un tema de tendencia popular para aumentar la productividad de las empresas, sea cual sea tu sector. Cada día más empresas trabajan para llevar este modelo disruptivo a sus organizaciones.

DevOps tiene un objetivo principal que Lograr: la integración continua con la entrega continua.

Al hacerlo, los procesos de desarrollo y operaciones se vuelven más rápidos y eficientes en recursos. Las empresas pueden ahorrar dinero mientras producen más productos de software de alta calidad para consumo o uso interno.

En este artículo introductorio, explicaremos los conceptos básicos de DevOps, incluyendo cómo hemos llegado hasta aquí, las mejores prácticas, las topologías clave y los beneficios más comunes de un entorno DevOps.

¿Qué es DevOps?

Tradicionalmente, en la industria de TI, los empleados pertenecían al equipo de desarrollo o 'dev'. Un equipo separado conocido como operaciones de TI u 'Ops' trabajaba para dar soporte a TI.

Los equipos de desarrollo y operaciones tenían liderazgo, responsabilidades y objetivos separados que alcanzar. En muchas empresas, los equipos trabajaban en plantas separadas y rara vez se comunicaban. Esta cultura de 'silos' llevaba a una mala comunicación y colaboración entre estos equipos—una barrera rígida entre ellos que solo podían salvar cuando era absolutamente necesario.

El gran cambio de cultura organizativa de DevOps rompió con éxito esta mentalidad de silos, acortando la brecha entre los equipos de Dev y Ops al convertirlos:

Trabajar juntos
Compartir responsabilidades
Asume la propiedad total del software que entregan a lo largo de su ciclo de vida

Hoy en día, el DevOps está ampliamente adoptado por la industria de TI, incluyendo a las principales empresas tecnológicas como Amazon, Facebook, Google, Netflix y BMC Software. Más recientemente, las empresas son estudiando cómo difundir los principios de DevOps en toda la organización, más allá de la TI.

Integración continua

Entrega continua

Cómo se desarrolló DevOps

Antes del año 2000, la mayoría de las industrias de TI adoptaron el modelo clásico en cascada, un enfoque lineal para el desarrollo de software.

Los desarrolladores tuvieron que dedicar mucho tiempo a desarrollar e integrar piezas pesadas de código.
Los ingenieros de QA y los equipos de operaciones, que trabajaban en silos, dedicaban más tiempo a probar el código.

¿El resultado? Un largo, a veces de años, intervalo entre lanzamientos de software, con correcciones frecuentes de errores y parches de software desplegados entre cada versión.

Con el establecimiento de la metodología de software Agile, las industrias de TI pasaron a desarrollar software de forma iterativa y lo lanzaron frecuentemente en producción. La Integración Continua (CI) y la Entrega Continua (CD) son algunas de las principales técnicas adaptadas en este modelo para la entrega rápida de software. (En breve analizaremos estos conceptos.)

Por ello, DevOps promovió la colaboración fluida entre los equipos de desarrollo y operaciones en cada paso del ciclo. Así que podemos afirmar con seguridad que DevOps tiene sus raíces en la metodología Ágil.

(Conoce más sobre la historia de DevOps.)

Cultura DevOps

Al hacer la transición a una cultura DevOps, las organizaciones deben cambiar dos componentes importantes:

Sus métodos tradicionales de funcionamiento
Su mentalidad

Generalmente, en una cultura DevOps, tanto los equipos de Dev como de Operaciones trabajan de forma colaborativa mediante una comunicación frecuente.

En algunas organizaciones, los ingenieros DevOps pueden realizar tanto desarrollo como operaciones. No limitan sus responsabilidades al alcance definido en su puesto. Más bien, siempre comparten las responsabilidades con otros equipos, considerando todo el ciclo de vida del desarrollo como parte de sus responsabilidades.

Estos ingenieros buscan aumentar la productividad y la calidad del servicio para ofrecer el máximo valor a sus clientes.

Por supuesto, DevOps no se trata solo de comunicación y colaboración. Las mejores prácticas de DevOps son orientadas a ayudar a te lanzar software con frecuencia y con la mejor calidad. Priorizando la alta eficiencia, DevOps fomenta la utiliza generalizada de herramientas para automatiza tareas manuales.

Echemos un vistazo a las prácticas comunes y herramientas relacionadas de cualquier cultura DevOps.

Tradicionalmente, los desarrolladores actualizaban manualmente su código y luego lo probaban manualmente.

La Integración Continua (CI) están una práctica DevOps en la que los desarrolladores frecuentemente fusionan sus cambios de código en el repositorio central. Luego, el código se está compilado automáticamente y se ejecutan pruebas automatizadas contra son el código compilado.

El objetivo principal de esto está identificar rápidamente los errores para mejorar la calidad del software.

En Continuous Delivery (CD), los cambios de código fusionados son compilan y despliegan automáticamente en un entorno de pruebas. Luego, son se ejecutan pruebas automatizadas sobre el código desplegado para identificar cualquier error y permitir que los desarrolladores los corrijan con antelación.

Normalmente, el código se están desplegado progresivamente en diferentes entornos de prueba, donde alcanza un mayor nivel de calidad mediante un procedimiento automatizado estándar antes de desplegarse en producción. La entrega continua garantiza que el equipo siempre disponga de un código listo para el desarrollo.

Herramientas CI/CD como Jenkins, Bamboo, Travis, TeamCity y muchas otras ayudan a automatizar estas tareas.

(Explora CI/CD y si el despliegue continuo encaja.)

Pruebas continuas

La práctica de Pruebas Continuas ayuda a identificar riesgos potenciales lo antes posible en todas las etapas del ciclo de vida del desarrollo para minimizar el impacto en los usuarios finales.

Por ejemplo, cuando el código se están desplegados para construir servidores, se ejecutarán pruebas unitarias automatizadas para identificar cualquier error en el código. Si las pruebas unitarias son falladas, la compilación será rechazada y el feedback se están enviado al desarrollador para revisar el código. Así, el código se desplegará en el entorno QA para pruebas funcionales solo si la compilación supera las pruebas unitarias.

Selenium, Travis y Appium son algunas de las herramientas populares de pruebas continuas en la industria de TI.

Monitorización continua

La aplicación, infraestructura, middleware y redes serán monitorizadas continuamente para su rendimiento, cualquier defecto o seguridad y cumplimiento. Para identificar problemas, la mayoría de las empresas supervisa métricas como:

Uso de CPU y memoria
Espacio en disco
Actividades con clientes
Políticas de seguridad

Al poner en práctica la monitorización continua, siempre te alertarán de cualquier problema en entornos desde las pruebas hasta la producción, lo que te ayudará a garantizar una alta disponibilidad.

Entre las herramientas populares de Monitorización Continua se encuentran Nagios, Sensu, Prometheus y muchas más.

Infraestructura como código

La infraestructura como código (IaC) están una práctica en la que la infraestructura —máquinas virtuales, balanceadores de carga, redes, etc.— son configurada y gestionada usando código en lugar de configurar y gestionar manualmente esos recursos. Esto se ha convertido en una práctica esencial de DevOps en organizaciones que específicamente han pasado a plataformas en la nube.

Por ejemplo, Amazon Web Services (AWS) proporciona APIs para interactuar programáticamente con su infraestructura en la nube. La utiliza de código para Define configuración ayuda a estandarizar el proceso, permitiéndoles desplegar rápidamente recursos en la nube.

Microservicios

A diferencia de las arquitecturas monolíticas tradicionales, en la arquitectura de microservicios una única aplicación se está construida como un conjunto de pequeños servicios o componentes. Estos servicios separados tienen su propia funcionalidad y su comunicación se realiza a través de una interfaz ligera o una API.

Como arquitectura ampliamente adaptada en la cultura DevOps, los microservicios:

Promover la gestión independiente de los recursos dentro de los diferentes componentes.
Mejorar la disponibilidad del sistema evitando un único punto de fallo, ya que no están afectados a otros componentes cuando uno está estrellado.
Permitir que los equipos de DevOps añadan componentes adicionales con diferentes funcionalidades sin afectar a otros componentes.

(Entiende las mejores prácticas en microservicios.)

Topologías de DevOps

La forma en que se practican son DevOps depende en gran medida de la organización. Según Matthew Skelton y Manual Pais, las organizaciones adoptan diferentes tipos de topologías o estructuras de equipo para que el DevOps prospere. Define 9 tipos de topologías de la siguiente manera.

Prácticas DevOps

Colaboración Dev & Ops

Esta es la estructura ideal de equipos DevOps donde los equipos de Dev y Ops colaboran de forma fluida. Por ejemplo:

Los desarrolladores se toman en serio las tareas de los equipos de operaciones, recibiendo sus aportaciones cuando es necesario.
Los equipos de Operaciones Obtén una buena comprensión de las tareas que los equipos de desarrollo realizan rutinariamente.

Responsabilidades de operaciones totalmente compartidas

Implementada en Facebook y Netflix, esta topología consiste en equipos de desarrollo con equipos de Operaciones integrados en ellos. te solo Ve una pequeña separación entre desarrolladores y operaciones.

Esto es más adecuado para empresas que tienen aplicaciones web únicas.

Operaciones como infraestructura como servicio

Esta topología es adecuada para organizaciones con diferentes o múltiples servicios que son alojados en plataformas en la nube, pero que aún cuentan con un departamento tradicional de Operaciones de TI que están poco probables a cambiar. Su equipo de Operaciones está similar a Infraestructura como Servicio (IaaS).

DevOps como servicio externo

Algunas organizaciones pueden no tener la experiencia necesaria o no puedan permitirse contar con un equipo de operaciones separado. Aquí, los equipos de desarrollo pueden Obtén soporte de un proveedor de servicios que puede gestionar las responsabilidades de los aspectos operativos del software.

Equipos DevOps con fecha de caducidad

Esta estructura funciona como un equipo temporal que trabaja para unir a los equipos de Desarrollo y Operaciones. Ese equipo temporal quedará obsoleto tras alcanzar el objetivo predefinido.

Equipo de defensa de DevOps

Esta topología es más adecuada para equipos que tienden a distanciarse. El equipo de defensa facilita a los grupos de desarrollo y operaciones, manteniéndolos implicados y informándolos continuamente sobre las prácticas DevOps.

Equipo SRE

Adaptada en Google, esta topología consiste en un equipo de Ingeniería de Fiabilidad del Sitio (SRE). Los desarrolladores deben aportar pruebas de que su software está conforme a los estándares, y el equipo SRE puede rechazarlo si se demuestra lo contrario.

(Compara con los equipos de SRE y Operaciones.)

Colaboración impulsada por contenedores

La contenedorización están la práctica de encapsular el despliegue de una aplicación y los requisitos en tiempo de ejecución en un contenedor. Esto elimina algunas dependencias de colaboración entre los equipos de desarrollo y operaciones.

Esta estructura es adecuada para una organización que tiene una cultura de ingeniería sólida.

(Conoce más sobre cómo gestionar código y contenedores.)

Colaboración entre desarrolladores y DBA

Algunas organizaciones que tienen múltiples aplicaciones conectadas con grandes bases de datos centrales han experimentado con esta topología. La estructura está en que los roles de especialización de bases de datos (DBA) tanto en los equipos DBA como en los de Desarrollo son integrados, ayudando a tender puentes entre ambas partes.

Beneficios clave de DevOps

Las organizaciones que adoptan la cultura DevOps Ve mejoras en muchos aspectos de su proceso de entrega de software, incluyendo:

Mejorar la comunicación y la colaboración entre equipos
Mejora de la eficiencia y productividad organizativa
Aumento de la velocidad de las versiones de software
Maximizar la satisfacción del cliente (tus clientes ahora reciben software de alta calidad)
Garantizar la disponibilidad y fiabilidad del sistema gracias a una detección de amenazas e incidentes más rápida y temprana
Promover la innovación, gracias al compartir diferentes ideas entre equipos

En este vídeo, David Rizzo, vicepresidente de Ingeniería de Producto en BMC Software, y David Kennedy, arquitecto de soluciones, comparten cómo Compuware evolucionó hacia DevOps para aumentar la innovación, Reduce defectos evitables y mejorar MTTR.

DevOps está más allá de un modelo de negocio

Debido a su naturaleza abstracta, es difícil Define DevOps en solo un par de frases. Como dije antes, DevOps no es solo un modelo de negocio, sino un cambio cultural para integrar y automatizar los procesos de desarrollo y operaciones de software en un único flujo de trabajo unificado, centrado en el lanzamiento rápido de software de alta calidad que satisfaga los requisitos del cliente.

DevOps alcanza su excelencia integrando las mejores prácticas definidas en cada paso del ciclo de vida del desarrollo de software. Las organizaciones son obligadas a identificar la topología de equipo que mejor se adapta a ellas en DevOps para aspirar a largo plazo.

Cuando se adopta correctamente, la cultura DevOps puede aportar enormes beneficios para las organizaciones en cuanto a lanzamientos exitosos de software.

Lecturas relacionadas

Guía de DevOps

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.

Orquestación de flujos de trabajo

Simplificación de Mainframe

Destinos populares

¿Qué es DevOps? Una introducción completa