¿Cuál es la diferencia entre SRE y DevOps?
En este ensayo, intentamos demostrar por qué las siguientes son las respuestas apropiadas a las preguntas: ¿Qué debes elegir entre SRE y DevOps? ¿Es SRE aplicable solo en entornos cloud? ¿Cuál es exactamente la función del equipo de DevOps? ¿Son SRE y DevOps compatibles entre sí? ¿Requiere SRE codificación? ¿Es una idea inteligente seguir una carrera en DevOps? Las respuestas a todas estas preguntas pueden encontrarse en esta página.
Cuando se trata de desarrollo, lanzamiento y producción de software, las empresas pueden seleccionar SRE o DevOps. Sin embargo, un análisis exhaustivo de las diferencias y similitudes entre estos dos métodos puede ayudar a las empresas a seleccionar la estrategia más apropiada.
¿Qué es «DevOps»?
El desarrollo y las operaciones se unen en la práctica conocida como «DevOps». El propósito de DevOps es garantizar que el mismo equipo a cargo del desarrollo también sea responsable de mantener el código en producción.
La capacidad de evaluar las actualizaciones de aplicaciones antes de entregar el software está posibilitada por la entrega continua para los desarrolladores. Además de la entrega continua, DevOps abarca el desarrollo de software, el lanzamiento de nuevas versiones, las pruebas y la integración de esas nuevas versiones, la gestión de configuraciones y el monitoreo en tiempo real.
¿Qué es SRE?
La ingeniería de confiabilidad del sitio es lo que queremos decir cuando decimos SRE. La ingeniería de confiabilidad de software (SRE) es una asociación entre la ingeniería de software y las operaciones de sistemas. Uno de los objetivos de SRE es detectar y tomar medidas preventivas contra problemas que podrían resultar en tiempo de inactividad.
¿Qué es SRE en comparación con DevOps?
La Ingeniería de Confiabilidad de Sistemas es una amalgama de operaciones de sistemas e ingeniería de software.
La Ingeniería de Confiabilidad de Software (SRE) se ocupa de aspectos del desarrollo de software como la velocidad, la calidad, el diseño, la agilidad y la innovación. Además, SRE es responsable de las necesidades operativas como la mantenibilidad, la disponibilidad, la capacidad de mantenimiento y el rendimiento.
¿Cuál es la diferencia entre SRE y DevOps, comparados?
SRE vs. DevOps – Una Comparación Organizacional
En la mayoría de las empresas, muchos departamentos trabajan en el mismo producto. Sin embargo, el producto solo podría triunfar si estos departamentos cooperan.
Las diferencias que podrían surgir entre los miembros del equipo pueden resolverse con la asistencia de DevOps, que une a todos bajo un objetivo unificado. El propósito de la metodología DevOps es facilitar una gestión eficiente de los recursos en todos los departamentos de una organización.
Los SREs, por otro lado, no atacan directamente los silos, sino que animan a todos a discutir. Debido a esto, la propiedad de un producto se distribuye uniformemente en todos los empleados de la organización que trabajan en él.
SRE vs DevOps: Probando Fallos
Si el software no se prueba constantemente, las empresas son conscientes de que eventualmente se romperá en algún momento. DevOps emplea pruebas automatizadas para descubrir problemas y minimizar riesgos. DevOps garantiza que los equipos no cometan los mismos errores llevando a cabo esta práctica.
El fallo se investiga utilizando dos enfoques diferentes por los SREs, namely indicadores de nivel de servicio y objetivos de nivel de servicio. Los SLOs representan el porcentaje de éxito de los SLIs, que cuantifica la cantidad de fallos que ocurren por solicitud a lo largo del tiempo.
Medición del progreso entre SRE y DevOps
La efectividad de DevOps se evalúa utilizando estas cuatro métricas. Estos factores incluyen la cantidad de implementaciones, la cantidad de tiempo que lleva restaurar el servicio, la cantidad de tiempo necesario para prepararse para los cambios y el porcentaje de modificaciones exitosas.
Los SREs monitorean el progreso observando cuatro señales: tráfico, latencia, saturación y errores. Al medir, los desarrolladores tienen que tomar en consideración los estándares existentes que corresponden a cada estadística.
Organización del equipo en términos de SRE vs DevOps.
Ingenieros de confiabilidad del sitio con experiencia previa en desarrollo de software y operaciones son la columna vertebral de los equipos SRE.
Se pueden cubrir muchos roles diferentes dentro de un equipo de DevOps. Algunos ejemplos de estos roles incluyen analistas de calidad, desarrolladores de software, gerentes de lanzamiento, administradores de sistemas, propietarios de productos e ingenieros de confiabilidad de sistemas.
SRE versus DevOps: Herramientas
Los contenedores, los microservicios, la integración y despliegue continuos, la infraestructura como código, las pruebas de resistencia y los sistemas de monitoreo son algunas de las tecnologías que DevOps y SREs comparten. Otras herramientas incluyen pruebas de resistencia.
SRE versus DevOps: Enfoque
El objetivo principal de SRE es desarrollar aplicaciones que sean altamente confiables y muy escalables. Por lo tanto, las tareas de un SRE se centran principalmente en asegurar y mantener la confiabilidad de la aplicación en lugar de hacer modificaciones frecuentes.
DevOps, por otro lado, se ocupa principalmente de crear entornos de producción en los que los desarrolladores tienen un mayor control. El objetivo de DevOps es implementar pipelines de CI/CD en todas las fases del producto para facilitar el desarrollo ágil.
SRE vs. DevOps: Diferencias en la Forma en que se Implementa el Cambio
En lugar de lanzar actualizaciones a gran escala todas a la vez al software, DevOps realiza ajustes incrementales al producto con el tiempo. Cuando se hace esto, hay menos instancias de problemas en las aplicaciones de DevOps, y tienen una gestión de revisión superior.
Los SREs revierten los cambios rápida y frecuentemente para asegurar que el producto esté libre de errores. Los SREs evalúan las actualizaciones usando lanzamientos Canary antes de poner los cambios en producción. Además, el SRE debe equilibrar la confiabilidad con la frecuencia de las actualizaciones.
La automatización es un diferenciador clave entre SRE y DevOps.
SRE pretende deshacerse de las tareas aburridas determinando qué actividades ocupan más del cincuenta por ciento del tiempo de un ingeniero y luego eliminando esas actividades. Además, los SREs son responsables de preparar códigos específicos para una variedad de procesos y luego agregar esos códigos a un playbook.
Las estrategias automatizadas de DevOps permiten la creación de bucles de retroalimentación entre los equipos de desarrollo y operaciones. El propósito de la automatización que emplea DevOps es acelerar el proceso de impulsar cambios incrementales en aplicaciones que ya están en funcionamiento.
¿Cuáles son las Ventajas de Usar SRE?
Google desarrolló el modelo SRE con la intención de hacerlo más simple para que los desarrolladores se concentren en la velocidad a la que se agregan nuevas funciones y en la inventiva de esas funciones, mientras también permitía que los operadores del sistema se concentraran en mantener la consistencia y la estabilidad.
El concepto es adaptable a cualquier organización, y en los últimos años, ha habido un notable repunte en el interés de usarlo. Las empresas que han implementado el modelo SRE tienen anécdotas fascinantes que tienen muchos puntos en común, girando en torno a las ventajas de SRE y cómo han transformado esas prácticas en una influencia tangible y beneficiosa en sus negocios.
Cuando se ve a través del lente de un equipo de ingeniería, las ventajas de SRE son readily apparentes right desde el beginning. Históricamente, el enfoque principal de los equipos de ingeniería ha sido el desarrollo de aplicaciones y la capacidad de proporcionar nuevas funciones lo más rápido posible.
Evidentemente, un grupo contemporáneo y experimentado es aware que este es solo un componente de la ecuación. Entre otras actividades, asignar tiempo y esfuerzo al desarrollo de técnicas de prueba, procesos de integración y despliegue continuos, y la automatización en la nube contribuyen a la salud de un sistema de software.
El enfoque de ingeniería de confiabilidad de software (SRE) proporciona a los equipos principios de ingeniería de software que pueden aplicarse a sus operaciones de TI. Esto ayuda a los equipos a elevar el nivel de excelencia operacional. Debido a estos principios, podrían hacer mejoras en diversas áreas, incluyendo capacidad, rendimiento, disponibilidad y latencia. Las prácticas SRE son una disciplina que se centra en disminuir y eventualmente simplificar el proceso de operar y mantener soluciones de software.
Estas prácticas pueden abarcar una variedad de facetas que están presentes a lo largo de todo el ciclo de vida del software. En lugar de evitar cambios en su solución de software, un equipo que adopta con éxito las prácticas SRE cambiará su carga de trabajo operativo a las tareas de desarrollo del día a día, adoptando las complejidades de ingeniería que vienen con la escala y las nuevas funciones. Este cambio ocurrirá debido a la decisión del equipo de no evitar cambios en su solución de software. Visión de ingeniería unificada y coordinación entre los diversos equipos.
El enfoque de ingeniería de confiabilidad de software (SRE), cuando se aplica a varios equipos de ingeniería de software, da una visión de ingeniería cohesiva a la empresa. Esta visión de ingeniería unificada fomenta la cooperación, el intercambio de información y un lenguaje consistente en diversos equipos. A diferencia de la introducción de una nueva biblioteca de software o una herramienta de despliegue, la adopción efectiva de SRE no es solo responsabilidad del equipo de ingeniería de software. El negocio y otras partes interesadas que no están técnicamente orientadas impactan significativamente en la capacidad de habilitar y cultivar una cultura en la que la actitud SRE pueda florecer. Con una conversación entre todas las partes interesadas sobre qué significa la confiabilidad para la empresa, es esencial establecer una cultura en la que los equipos de ingeniería se sientan psicológicamente seguros para fallar y puedan aprender de sus errores.
Una conversación entre las partes interesadas comerciales y técnicas es la única manera de construir la alineación esencial para definir los diversos niveles de servicio, un concepto central en SRE, y comprender el esfuerzo y el impacto comercial conectados con cada nivel. Conceptos Cruciales para el Nivel de Servicio SRE Los siguientes son los conceptos principales de nivel de servicio SRE: Los Indicadores de Nivel de Servicio, abreviados como SLIs, son una o más métricas de confiabilidad cuantitativas de la solución de software vistas desde el punto de vista de sus clientes.
En un sistema basado en web, algunos ejemplos útiles son los códigos de estado HTTP y la latencia total de extremo a extremo. Los Objetivos de Nivel de Servicio, a menudo conocidos como SLOs, son uno o más objetivos que un SLI específico debe cumplir dentro de una cantidad predeterminada de tiempo. En el contexto de una solución web, esto puede significar esforzarse por un máximo del 1% de HTTP 5xx (error del servidor) cada mes o lograr una latencia de menos de 200 milisegundos para cada solicitud HTTP cada día.
Para calcular la confiabilidad, divide la cantidad de acciones exitosas (es decir, la cantidad de veces que funcionó correctamente) por el número total de acciones. Esto te dará el valor de confiabilidad. La cantidad de falta de confiabilidad que las diversas partes interesadas están listas para soportar se conoce como el presupuesto de error. En resumen, puede determinarse deduciendo el valor de confiabilidad del 100% del total.
Los conceptos de niveles de servicio SRE y los valores de confiabilidad y presupuesto de error asociados son extremadamente útiles para establecer ese lenguaje común en toda la organización. Esto crea un entendimiento compartido entre empresas, desarrolladores e ingenieros SRE sobre la definición de expectativas y responsabilidades. Aunque son fáciles de entender, los conceptos de nivel de servicio SRE y los valores de confiabilidad y presupuesto de error asociados son beneficiosos. Igualmente crucial, establecer un objetivo del 100% de confiabilidad es both romántico e incorrecto, ya que dificulta que el equipo innove, impide que el equipo aprenda de sus errores y ralentiza la velocidad a la que se lanzan nuevas funciones.
El Negocio en Sí mismo como una Fuente de Creación de Valor
El paradigma SRE provocó un cambio fundamental en cómo los ejecutivos de alto nivel en las empresas piensan sobre las tareas operativas y las prácticas de ingeniería de software. En el pasado, las partes interesadas del negocio solo consideraban valiosa la creación de nuevas funciones de ingeniería de software. Por otro lado, las operaciones subyacentes de TI y otras actividades han sido vistas como gastos molestos. Los líderes organizacionales iluminados en el desarrollo de software moderno entienden que se necesita más para valorar el desarrollo y el ajuste fino de un gran motor si se va a colocar en un chasis viejo y oxidado.
Son conscientes de este hecho porque se necesita más para valorar el desarrollo de un gran motor. Por lo tanto, es necesario considerar y asignar un valor apropiado a toda la solución de software en las diversas etapas de su vida útil. Ese valor se comprendió mejor después de adoptar una perspectiva SRE y el cambio de cultura y las ventajas concomitantes. Por ejemplo, la capacidad de la aplicación para escalar para satisfacer demandas de tráfico inesperadas en ocasiones especiales (como el Black Friday) tiene menos que ver con la lógica comercial de la aplicación y más con cómo se manejan y gestionan las operaciones del sistema. La escalabilidad es la capacidad de una solución de software para satisfacer demandas de tráfico inesperadas.
Otros ejemplos, como la optimización de costos en la nube o tener estrategias adecuadas de backup y recuperación ante desastres, que simultáneamente reducen costos y riesgos mientras aumentan la excelencia operativa, demostraron que las operaciones son (y deben tratarse como) un centro vital de creación de valor. Otros ejemplos incluyen:
Los ingenieros de confiabilidad del sitio son responsables de impulsar continuamente mejoras estructurales y poseen una rara combinación de talentos que son difíciles de encontrar: una comprensión exhaustiva de la tecnología y un enfoque en las necesidades de los clientes. Por lo tanto, intentar ahorrar gastos para un equipo SRE reduciendo el número de trabajadores o subcontratándolo es a menudo una mala decisión. Es esencial tener una comprensión firme del hecho de que solo algunas soluciones de software requieren un equipo o responsabilidades SRE especializadas.
Incluso en Google, la participación en los equipos SRE es voluntaria. Si el alcance de la solución o la etapa de madurez del proyecto no necesita ese grado de asistencia, el trabajo que debe hacerse para SRE puede ser propiedad e impulsado por el equipo de desarrollo. A pesar de esto, es esencial tener en cuenta que la actitud y las prácticas SRE todavía deben llevarse a cabo, y que esa cultura debe fomentarse.
Resumen
SRE y DevOps son lo mismo visto desde diferentes perspectivas.
SRE (Ingeniería de Confiabilidad del Sitio) y DevOps (Operaciones de Desarrollo) son herramientas que las empresas pueden usar para mejorar la comunicación entre sus equipos de desarrollo de software y operaciones. Sin embargo, las empresas deberían considerar usar DevOps si quieren acelerar el proceso de llevar su producto al mercado e incorporar actualizaciones mientras la producción está en marcha. Por otro lado, las empresas que desean la automatización de trabajos a gran escala deben usar SREs como su solución.
Prueba Prometteur Solutions si necesitas contratar a alguien con experiencia en DevOps o ingeniería de confiabilidad del sitio.
Prometteur Solutions permite a las empresas emplear ingenieros pre-evaluados de calidad Silicon Valley en tan solo tres a cinco días hábiles. De un grupo total de desarrolladores que numberan 2 millones en total.
Preguntas Frecuentes
¿Qué es «DevOps»?
El desarrollo y las operaciones se unen en la práctica conocida como «DevOps.»
¿Qué es SRE?
La ingeniería de confiabilidad del sitio es lo que queremos decir cuando decimos SRE. La ingeniería de confiabilidad de software (SRE) es una asociación entre la ingeniería de software y las operaciones de sistemas.
1. ¿Requiere SRE codificación?
Sí, la codificación es necesaria para los SREs. Los ingenieros especializados en confiabilidad del sitio trabajan para encontrar formas de hacer que los sistemas sean más confiables. Para lograr este objetivo, ocasionalmente es necesario adentrarse en el código fuente de un sistema, identificar el problema y frecuentemente proporcionar un parche de vuelta a la base de código.
2. ¿Es un trabajo en DevOps una opción inteligente?
En los últimos cinco años, ha habido un aumento del 40 al 50 por ciento en la demanda de DevOps.
3. ¿Qué lenguaje de programación es ideal para su uso en entornos DevOps?
Python es el lenguaje más popular para DevOps debido a la extensa cantidad de módulos de biblioteca que pueden llevar a cabo responsabilidades típicas. Los lenguajes utilizados para la programación están en el corazón del proceso de desarrollo para los sistemas de DevOps. Como resultado, las personas que trabajan en DevOps necesitan saber los lenguajes de programación apropiados que pueden usarse en estos tipos de sistemas.