SRE vs DevOps

DevOps

Es la “Cultura”

Objetivo: “Permitir que los desarrolladores sean responsables de su código”

• Antes: El desarrollador se desentendía de su aplicación cuando estaba en producción.
• Ahora: El desarrollador hace su deploy y es responsable de su código, tiene que asegurarse que se haga bien el deploy y que funcione sin ningún problema y si hay algún problema volver atrás.

SRE (Site Reliability Engineer) = SysAdmin

Es el “Puesto” Laboral

Es el encagado de brindar todas las herramientas para que el desarrollador pueda aplicar la “cultura” DevOps sin problemas (que funcione todo bien)

DevOps: Desarrolladores y SysAdmin

Los desarrolladores lo que quieren es tirar todas sus features (actualizar su código) lo más rápido posible encambio, los SysAdmin no quieren que haya cambios (porque es más fácil administrar entornos estables).

Por lo tanto el objetivo DevOps es aceitar la friccion entre ambos, aplicando 5 puntos (CALMS):

1. Reducir Fricción: brindar herramientas a los desarrolladores para que puedan aplicar sus cambios de la forma mas limpia posible (sin romper nada)

2. Aceptar Fallos: los fallos son normales. Ej: se puede aceptar un porcentaje de fallos por aplicacion.

3. Implementar cambios gradualmente. Ej: utilizar “feactures flags”. Los Feactures Flags es una libreria que la agregas a tu código y te permite activar esas feactures a una porción del tráfico, y es muy facil modificar dicho porcentaje si lo queres cambiar. Ej: si tiras una nueva feature, le asignas un 1% del tráfico y si ves que anda todo bien, vas aumentando el porcentaje gradualmente (a través de una herramienta que es externa a tu código). Son simples valores booleanos que nos permite utilizar con algúni condicional para mostrar o esconder una sección, así de simple.

4. Crear herramientas para automatización: Los SRE crean y consiguen herramientas para que los desarrolladores puedan trabajar. Ej: bots de deploy o herramientas de monitoreo que estos puedan usar facilmente

5. Métricas (el más importante): necesitas medir todo lo que puedas. Ej: los errores, el tráfico, el cambio, la latencia. Todas estas métricas las necesitamos para saber cómo están funcionando las aplicaciones. Si una aplicación anda bien le permitis hacer más deploys, encambio si anda mal le quitas deploys