5 diferencias básicas entre DevOps y SRE que debe conocer
Publicado: 2021-02-22El mundo de la tecnología de la información y el desarrollo de software a menudo combina DevOps con SRE para significar lo mismo. Sin embargo, hay grandes diferencias entre los dos. Si bien Site Reliability Engineering (SRE) ganó fuerza en los últimos años, DevOps ha existido por mucho más tiempo (incluso antes de que existiera el término DevOps).
En pocas palabras, DevOps y SRE son prácticas implementadas para entregar software más rápido. La única diferencia entre los dos está en sus enfoques; DevOps se enfoca en reducir el ciclo de vida del desarrollo de software y SRE se concentra en eliminar las debilidades del sistema para lograr el mismo propósito.
En este artículo, veremos las formas fundamentales en que DevOps y SRE se diferencian entre sí. Antes de hacer eso, comencemos por comprender qué son DevOps y SRE.
Tabla de contenido
¿Qué es DevOps?
En palabras de Gene Kim, autor de The DevOps Handbook y The Phoenix Project,
“DevOps es [el] conjunto de normas culturales y prácticas tecnológicas que [permite] el flujo rápido del trabajo planificado desde, entre otros, el desarrollo, pasando por las pruebas hasta las operaciones, al tiempo que preserva la confiabilidad, operación y seguridad de clase mundial. DevOps no se trata de lo que haces, sino de cuáles son tus resultados”.
Entonces, DevOps se enfoca principalmente en transformar las prácticas culturales dentro de una organización para acelerar el ciclo de vida de desarrollo de software (SDLC). No está dirigido a una persona, grupo o posición. DevOps tiene como objetivo fortalecer la colaboración entre las operaciones de tecnología de la información y los equipos de desarrollo de software.
Lo que hace y cómo lo hace no es importante; sólo se reconoce el resultado del proceso.
DevOps utiliza un conjunto de principios para intensificar la exposición de los equipos de ingeniería de software a los sistemas de producción y permite que el equipo de operaciones de TI eleve las discrepancias al equipo de desarrollo de manera más eficiente. De hecho, SRE juega un papel crucial en una organización DevOps al facilitar las pruebas proactivas, la velocidad, permitir la observación y mejorar la confiabilidad del servicio. DevOps alienta a todas las organizaciones centradas en DevOps a operar de acuerdo con los principios culturales descritos en su modelo CALMS.
¿Qué es SRE?
SRE, abreviatura de Site Reliability Engineering, es un término acuñado por el vicepresidente sénior de Google, Ben Treynor, a cargo de supervisar las operaciones técnicas.
Drew Farnsworth (de Green Lane Design) explica: “En general, me gusta pensar en SRE como un sistema en el que el desarrollo controla las operaciones. Este es un sistema en el que el entorno se divide en los componentes más básicos de la pila de TI y se implementa con las mejores prácticas integradas en el hardware”.
Esencialmente, el equipo de SRE con experiencia en desarrollo de software tiene la responsabilidad de resolver problemas en la producción del sistema mientras mantiene un equilibrio entre la velocidad de entrega y la confiabilidad del sistema. De esta manera, el enfoque SRE reúne al personal de desarrollo de software bajo roles de operaciones para aplicar prácticas de ingeniería estructuradas para defender las políticas de una organización.
Aseguran que los sistemas estén disponibles y funcionando de manera eficiente en todo momento para que los equipos de software desarrollen servicios técnicos para aumentar la confiabilidad del sistema. Es responsabilidad de los SRE identificar cualquier debilidad potencial antes de que se convierta en un problema importante.
DevOps vs SRE: principales diferencias entre DevOps y SRE
En la práctica, DevOps y SRE deben verse como disciplinas complementarias en las que los SRE, como parte de una estructura centrada en DevOps, se centran en mejorar la confiabilidad de sus servicios técnicos. Entonces, esencialmente no existe tal cosa como DevOps versus SRE.
Por lo tanto, lo que estamos haciendo en esta sección es evaluar las diferencias fundamentales entre DevOps y SRE.
Implementando el cambio
Para que las actualizaciones se realicen con frecuencia y los usuarios tengan acceso a tecnología más nueva y relevante, tanto DevOps como SRE tienen la intención de acelerar el ritmo. Sin embargo, DevOps avanza gradualmente, con precaución, mientras que SRE tiene en cuenta el costo de fallar para avanzar más rápido.
Ambos implementan herramientas de automatización y uso para lograr este propósito.
Considerar las fallas como normales
DevOps es enorme en aceptar fallas y considerarlas como opresión de aprendizaje. Por esa razón, fomenta una cultura sin culpa al aceptar que las fallas son parte del proceso y no se enfoca en hacer que los sistemas sean 100% tolerantes a fallas. Un ejemplo de esto es Netflix con su Simian Army.
La SRE, por su parte, apoya la autopsia sin culpa. El propósito detrás de esto es identificar la causa de la falla, asignar responsabilidades y trabajar para evitar fallas similares en el futuro. La cantidad de fallas que puede sufrir un sistema se incluye en el presupuesto de errores. Las métricas SLI, SLO y SLA determinan esto para reducir el costo de producción. Básicamente, SRE adopta prácticas proactivas de monitoreo y alerta para evitar una falla potencial.
Aprenda cursos de desarrollo de software en línea de las mejores universidades del mundo. Obtenga Programas PG Ejecutivos, Programas de Certificado Avanzado o Programas de Maestría para acelerar su carrera.
Automatización vs Innovación
DevOps otorga la máxima importancia a la automatización. En un entorno centrado en DevOps, esto se traduce en que los sistemas se automaticen tanto como sea posible, lo que da como resultado lanzamientos aburridos. Después de que un desarrollador haya confirmado el código, la mayoría de las siguientes actividades, si no todas, deben automatizarse.
Por lo tanto, la razón de DevOps para buscar CI/CD es desarrollar sistemas de alta calidad a una mayor velocidad.
Las razones de SRE para buscar CI/CD son diferentes, están dirigidas a reducir el costo de falla. Cualquier tarea común, genérica o repetitiva en operaciones como la implementación y las copias de seguridad se considera menos digna de atención. Por lo tanto, las SRE reservan una cantidad específica de tiempo para evitar el esfuerzo operativo. Esto se hace para que puedan realizar tareas más atractivas, como ejecutar o innovar nuevas tecnologías o actividades relacionadas con la arquitectura.
Pago: Proyectos DevOps para principiantes
Romper los silos organizacionales
Los desarrolladores y operadores entran en conflicto cuando se trata del proceso de implementación. Si bien los desarrolladores se beneficiarían de la implementación de funciones tan pronto como se codifican, la gente de operaciones se enfoca en hacer que los sistemas estén disponibles, lo que dificulta el proceso de implementación.
Tanto DevOps como SRE difieren en cómo eliminan los silos en una organización.
DevOps, como se explica en The DevOps Handbook, aborda este problema al incluir prácticas como operar en lotes más pequeños y administrar mejor las configuraciones.
Los SRE no solo tienen como objetivo optimizar el flujo entre equipos, sino también ayudar a los sistemas en producción. Lo hacen integrándose en los equipos como consultores y apoyando a los desarrolladores compartiendo la responsabilidad de ejecutar los sistemas. Así es como los SRE descomponen los silos en una organización.
Medición de una implementación exitosa
Las métricas de DevOps tienen que ver con la velocidad de las operaciones; esto incluye la frecuencia con la que se realizan las implementaciones, el tiempo que se tarda en hacerlo y la frecuencia con la que surgen problemas.
Según el informe de 2017 de Puppet y DORA, medir una implementación exitosa en DevOps depende de lo siguiente:
- la frecuencia con la que ocurren las implementaciones
- la duración del tiempo entre la confirmación de un código y su implementación
- la frecuencia con la que fallan las implementaciones
- el tiempo que se tarda en recuperarse de un error de implementación
Estos bucles de retroalimentación se implementan para ayudar a DevOps a mejorar la calidad del sistema al tiempo que facilitan un cambio en la experimentación.
SRE, por otro lado, trabaja en mejorar los sistemas teniendo en cuenta su confiabilidad. Considera las siguientes métricas clave para determinar una implementación exitosa:
- objetivo de nivel de servicio (SLO)
- indicador de nivel de servicio (SLI)
- acuerdo de nivel de servicio (SLA)
Las métricas mencionadas anteriormente son indicadores de la confiabilidad de un sistema. Estas métricas determinan de antemano si una versión de cambio llegará o no a producción.
En SRE, estas métricas de velocidad y calidad son útiles cuando se crea un presupuesto de errores y se mejora la confiabilidad de los sistemas en lugar de trabajar en nuevas características.
Leer: Salario del ingeniero DevOps en India
Conclusión
Google había publicado un libro electrónico sobre cómo implementan Site Reliability Engineering en sus sistemas de producción en el que Treynor explicó SRE como,
“SRE es lo que sucede cuando le pides a un ingeniero de software que diseñe un equipo de operaciones”.
Cuando se trata de cuán diferentes son DevOps y SRE, todo lo que necesita recordar es que SRE está impulsado por desarrolladores en lugar de un equipo de operaciones. Tanto el mantenimiento como la supervisión están mayoritariamente bajo el control de los desarrolladores. Eso es lo que diferencia principalmente a las dos disciplinas.
Si está interesado en obtener más información sobre Big DevOps, desarrollo de pila completa, consulte el programa Executive PG de upGrad & IIIT-B en desarrollo de software: especialización en desarrollo de pila completa, que está diseñado para profesionales que trabajan y ofrece más de 500 horas de capacitación rigurosa. Más de 9 proyectos y asignaciones, estado de exalumno de IIIT-B, proyectos finales prácticos prácticos y asistencia laboral con las mejores empresas.
