Si bien los marcos de JavaScript van y vienen, se ha estado gestando un cambio en los últimos años que cambiará permanentemente lo que significa ser un desarrollador moderno: cómo nuestro código pasa de nuestras computadoras portátiles a la naturaleza. La adopción generalizada de contenedores, microservicios y orquestación ha hecho que sea más fácil que nunca tomar una pequeña parte de software y ponerlo en vivo frente a los usuarios y, al hacerlo, impulsar un montón de tareas cómodas (depuración, creación de perfiles) en territorio incómodo: producción.
Odio ser portador de malas noticias (en realidad no), pero la realidad para los desarrolladores es que se está volviendo más complicado garantizar que el código que escribes sigue funcionando. Asumir la responsabilidad operativa del código que escribe se está convirtiendo en una parte cada vez más importante de la función del desarrollador, incluso cuando «dónde se ejecuta» se aleja cada vez más de «donde se escribió».
La primera ola de DevOps incorporó principalmente a la gente de Operaciones que aprendió a desarrollar: «automatizar todo» a través del código. La segunda ola, naturalmente, ahora se trata de que la gente de desarrollo aprenda a operar: ahora, somos dueños de la ejecución de nuestro código en producción. Pero mientras que las dos olas cambiantes generalmente se unen en equipos de DevOps multifuncionales, la «comprensión de la producción» históricamente ha tenido un fuerte sesgo de Operaciones.
En realidad, es casi irónico: las tendencias recientes en las abstracciones de plataformas han convertido todo en código . (¡Hola, sin servidor! Y gracias, Heroku.) Lo que eso debería haber significado es que entender lo que está sucediendo en producción sería más fácil para los desarrolladores, no más difícil. Echemos un vistazo a por qué ese no ha sido el caso y cómo debería ser en su lugar.
Desarrolladores de Shoehorning en Ops: ¿Qué podría salir mal?
Las organizaciones líderes en ingeniería de software piden cada vez más a los desarrolladores que sean dueños de su código en producción . Se les pide a los ingenieros de software que se unan a las rotaciones de guardia , con diferentes niveles de soporte.
Y, sin embargo, las herramientas convencionales de «supervisión de la producción» son intrínsecamente hostiles a la forma en que los desarrolladores piensan y trabajan con su código. Los enfoques tradicionales para comprender la «producción» están vinculados a la infraestructura subyacente de una aplicación. Los gráficos de datos como la utilización de la CPU, el rendimiento de la red o la carga de la base de datos son formas muy centradas en la infraestructura de comprender el mundo. El hecho de que las líneas sigan difuminando entre los desarrolladores y las operaciones no significa que simplemente nos transfiramos a modelos mentales anteriores del mundo; el objetivo de DevOps no es simplemente intercambiar responsabilidades. El objetivo de cambiar a DevOps es aprovechar al máximo las diversas habilidades, antecedentes y mentalidades que componen estos nuevos equipos multifuncionales.
Las herramientas tradicionales de monitoreo de producción se escribieron mucho antes de la era de DevOps: hablan el lenguaje de Ops, no de Devs. Desafortunadamente, eso establece una barrera de entrada artificial para que los desarrolladores piensen en la producción como un lugar de su propiedad . No hemos hecho nada para ayudar a los desarrolladores a ver su mundo tal como existe en producción. Los desarrolladores a menudo reciben un tablero lleno de gráficos de rendimiento de lectura / escritura de Cassandra, recuentos de subprocesos y tamaños de memoria, como si eso los indujera de alguna manera al club de la propiedad de producción.
Claro, esas métricas y gráficos se ven geniales, pero a menudo no hay forma de conectar esa información con el código, la lógica comercial o las necesidades del cliente que son el mundo del desarrollo de software. Cuando ocurren problemas, existe un gran salto mental que existe entre ver esa información y relacionarla con «lo que realmente sucedió». E incluso si ese salto se puede hacer de alguna manera, ciertamente no hay ningún camino que conduzca a la reproducción de ningún fenómeno observado, y mucho menos a escribir el código para solucionarlo.
El salto cognitivo que las herramientas tradicionales de monitoreo de producción requieren que los desarrolladores realicen no recibe mucha atención, porque así es simplemente como se hacen las cosas para los ingenieros de operaciones. En algunos rincones de la ingeniería, hay una satisfacción presumida de que los desarrolladores ahora tienen que dar ese salto. ¡Sientan nuestro dolor, desarrolladores! ¿Cómo no sabe que cuando ambas líneas tienen una tendencia descendente y ese gráfico se vuelve rojo, significa que su aplicación se ha quedado sin memoria? Bienvenidos a la producción.
Esa actitud arrogante refuerza la hostilidad reflejada por el enfoque adoptado por las herramientas de control tradicionales. En la práctica, ese enfoque conduce inadvertidamente a situaciones en las que los desarrolladores simplemente siguen las rutas de navegación y hacen todo lo posible para replicar patrones de depuración de producción que no comprenden completamente. Culturalmente, crea un foso entre los enfoques que Ops valora y los enfoques que Dev valora, y refuerza la ilusión de que la producción es un lugar hostil para los desarrolladores.
Mejorar los comportamientos de los desarrolladores existentes
En cambio, un enfoque más acogedor es aprovechar lo que los desarrolladores hacemos de forma natural cuando depuramos: permítanos comparar rápidamente nuestro resultado esperado con el resultado real (por ejemplo, este código debe manejar 10K solicitudes / seg, pero parece que solo maneja 100 solicitudes / seg. ). Los desarrolladores comparten esta parte del viaje de investigación con sus compañeros de Operaciones. Sin embargo, donde los patrones de operaciones y desarrollo se desvían es cuando se busca comprender por qué ocurre esa desviación.
Nota del patrocinadorHoneycomb proporciona Observability para que todos los equipos de ingeniería de software aprendan, depuren y mejoren los sistemas de producción para deleitar a los usuarios finales y eliminar el esfuerzo. Con los desarrolladores de Honeycomb codifican con confianza, la eficiencia del operador aumenta, la calidad de vida mejora y el negocio crece.
Para los desarrolladores, comparamos lo «esperado» con lo «real» todo el tiempo en las suites de prueba. Investigar fallas en las pruebas significa profundizar en el código, recorrer la lógica y cuestionar nuestras suposiciones. Ser capaz de capturar metadatos de nivel de lógica empresarial en producción (a menudo de alta cardinalidad, a menudo en muchas dimensiones) es un requisito básico para poder aprovechar la experiencia de los desarrolladores para los problemas de producción.
Necesitamos un caso de prueba replicable específico. Ser capaz de aprovechar la especificidad de los atributos personalizados como ID de usuario, ID de partición, etc., es lo que permite que la producción se sienta como una extensión de los flujos de trabajo de desarrollo y prueba, a diferencia de un nuevo entorno hostil y extraño.
Un enfoque de desarrollo para la producción
Con la llegada de PaaS, IaaS y sin servidor, nuestro mundo está abstrayendo cada vez más la infraestructura. Eso allanó el camino para ambas oleadas de DevOps y ha dejado espacio para redefinir las prioridades. Para los equipos de desarrollo de software que poseen la ejecución de su código en producción, eso significa que han cambiado hacia la alineación de su definición de operación exitosa con lo que en última instancia es importante para el negocio: si los usuarios de ese software están teniendo una buena experiencia para el cliente.
Ese cambio funciona muy bien para los desarrolladores que están acostumbrados a tener funciones, puntos finales, ID de clientes y otros identificadores de nivel empresarial que viven naturalmente en sus diversas pruebas. Esos tipos de identificadores solo seguirán volviéndose más críticos cuando se investigue y se comprenda el comportamiento de los sistemas de producción. (En contraste, los sistemas de monitoreo tradicionales se enfocan en el comportamiento agregado de un sistema general y casi nunca incluyen este tipo de identificadores).
Todas las preguntas que los desarrolladores deberían hacer sobre la producción se reducen a dos formas básicas:
- ¿Mi código se está ejecutando en primer lugar?
- ¿Mi código se comporta como se esperaba en producción?
Como desarrollador en un mundo con implementaciones frecuentes, las primeras cosas que quiero saber sobre un problema de producción son: ¿Cuándo comenzó a suceder? ¿Qué construcción está, o estuvo, en vivo? ¿Qué cambios de código eran nuevos en ese momento? ¿Y hay algo especial en las condiciones en las que se ejecuta mi código?
La capacidad de correlacionar alguna señal con una versión específica o una versión de código es algo que está en juego para los desarrolladores que buscan asimilar la producción. No es coincidencia que el «ID de compilación» sea precisamente el tipo de «fuente ilimitada» de metadatos que las herramientas de monitoreo tradicionales advierten contra la inclusión. En los sistemas de monitoreo basados en métricas, hacerlo se compromete con un conjunto de métricas capturadas en aumento infinito, lo que impacta negativamente en el rendimiento de ese sistema de monitoreo Y con el “beneficio” adicional de pagarle a su proveedor de monitoreo sustancialmente más por ello.
Los indicadores de características, y la explosión combinatoria de posibles parámetros cuando se cruzan varios indicadores de características en vivo, arrojan llaves adicionales para responder a la Pregunta 1. Y, sin embargo, los indicadores de características llegaron para quedarse; por lo que nuestras herramientas y técnicas simplemente tienen que subir de nivel para admitir este mundo definido de manera más flexible.
La pregunta 2, por otro lado, es la misma pregunta que nos hacemos cada vez que ejecutamos un conjunto de pruebas: «¿La ejecución real de mi código coincide con lo que espero?» Las mismas señales que nos son útiles cuando investigamos un caso de prueba fallido son las que nos ayudan a comprender, reproducir y resolver problemas identificados en producción.
Un enfoque de desarrollador para depurar prod significa poder aislar el impacto del código por punto final, por función, por tipo de carga útil, por estado de respuesta o por cualquier otro metadato arbitrario utilizado para definir un caso de prueba. Los desarrolladores deberían poder tomar esas piezas y comprender la carga de trabajo del mundo real que manejan sus sistemas, y luego ajustar su código en consecuencia .
El camino a seguir: un producto apto para desarrolladores
El futuro de las carreras de desarrollo no se trata de tener diferentes formas personalizadas de abordar la depuración de su entorno de producción. DevOps se trata de aprovechar al máximo sus nuevos equipos multifuncionales y, afortunadamente, cuando se trata de usar herramientas para obtener respuestas a las preguntas que le interesan en producción, existe la oportunidad de que todos estén en la misma página. Ya sea que su equipo se etiquete a sí mismo como Devs, Ops, Devops o SRE, todos pueden usar herramientas que hablen el mismo idioma.
En el mundo abstracto de hoy, lleno de instancias efímeras, contenedores momentáneos y funciones sin servidor, las métricas de infraestructura clásicas se están volviendo obsoletas rápidamente. Esto está sucediendo tan rápido que incluso cuestiona el futuro de las carreras de operaciones . Es necesario un enfoque fundamentalmente mejor para comprender la producción, para todos.
Un buen primer paso es cambiar el enfoque de las métricas como la CPU y la memoria y, en su lugar, adoptar las métricas RED como la señal principal del estado del servicio. Eso puede reducir sustancialmente la barrera de entrada a la producción para la mayoría de los desarrolladores. Luego, los desarrolladores pueden armarse con los metadatos necesarios para comprender el impacto de cualquier gráfico, etiquetando esas métricas con ID de cliente, punto final de API, tipo de recurso, acción del cliente, etc. para codificar y realizar pruebas.
Un paso mejor es la razón por la que la observabilidad ha experimentado una explosión en popularidad. Observabilidad no es sinónimo de seguimiento . La observabilidad adopta un enfoque basado en eventos que aún le permite incorporar métricas de infraestructura para comprender el comportamiento de sus sistemas de producción . Es un enfoque completamente diferente para el mundo de monitoreo centrado en operaciones que permite comprender el comportamiento de los sistemas de producción de manera que los hagan accesibles a ingenieros de todos los orígenes.
El futuro de las carreras de desarrollo debe definirse luchando por comprender las correlaciones entre las herramientas de monitoreo tradicionales y dónde se relaciona con su código. Al romper con las herramientas de monitoreo tradicionales, el futuro de las carreras de desarrollo se convierte en uno en el que comprender lo que está sucediendo en prod se siente tan natural como comprender por qué el código falló en sus entornos de desarrollo o prueba.
Durante la última década y el cambio, como industria, todos nos hemos vuelto realmente buenos tomando código y enviándolo al usuario. Después de todo, esa era la promesa de Heroku: conectar de forma sencilla y mágica un entorno de producción al flujo de trabajo natural de un desarrollador. Y debido a esto – por lo mucho más cerca que hemos traído de producción al entorno de desarrollo – el conjunto de habilidades desarrollador tiene que seguir la misma trayectoria … o arriesgarse a quedarse atrás.