Creando un motor de innovación con observabilidad

♪♪ ♪♪ ♪♪ Mi nombre es Boris. Soy el fundador y CEO de Baseline. Lo que hacemos es observabilidad para arquitecturas sin servidor. Estoy seguro de que la mayoría de ustedes han escuchado la palabra sin servidor varias veces hoy, desde la charla de esta mañana hasta todas las demostraciones que han ocurrido desde entonces, y se pone mucho énfasis en cómo implementar código en la nube y demás, pero en realidad se dedica muy poco esfuerzo a cómo ejecutamos y mantenemos este código a lo largo del tiempo. Y esa es la solución que brindamos a las personas que adoptan arquitecturas sin servidor.

Pero lo que quiero hablar hoy, en realidad, es algo completamente diferente, es cómo internamente dentro del equipo de Baseline, hemos logrado crear lo que me gusta llamar un motor de innovación gracias a la observabilidad que tenemos. Entonces, en comparación con otras startups en etapas muy similares de vida, estamos en este punto en el que enviamos realmente, realmente, realmente rápido. Y quiero compartir con ustedes, no diría trucos, pero los métodos que aplicamos para poder enviar tan rápido. Entonces, lo primero es, ¿alguien aquí en la sala está lidiando con deuda técnica en su trabajo en este momento? Veo una mano, oh, wow. Casi toda la sala. ¿Alguien tiene pruebas inestables? ¿Alguien tiene canalizaciones de CI, CD que nunca funcionan cuando necesitas que funcionen? Nuevamente, casi todos. Y eso es lo que no me gusta. Cuando nos inscribimos para ser ingenieros de software, y para muchos de nosotros ingenieros de nube, lo que queríamos era crear cosas y ponerlas en manos de las personas y hacer que esa innovación suceda y ver cómo las personas interactúan con esas cosas que creamos y ponemos en la web. Pero nos quedamos día a día lidiando con deuda técnica, pruebas inestables, y todo eso, lo cual básicamente nos está frenando y evitando que innovemos todos los días.

Y hay esta pregunta que surge mucho en conferencias y conversaciones técnicas, ¿qué tan bien está funcionando tu equipo? Y esta pregunta, lo que realmente significa es, ¿cuánta innovación está enviando tu equipo todos los días? Y hasta hace muy poco, no había una forma real de responder esta pregunta, honestamente. La gente decía, oh, lo estamos haciendo bien, pero no había forma de cuantificarlo. Hasta las métricas Dora y el libro Accelerate. Espero que todos aquí lo hayan leído. Si no lo han hecho, por favor consigan una copia. Y nos dio un marco científico que podemos usar para poder decir, okay, estamos en los equipos de mejor rendimiento del 10%. Estamos en el 20% superior o estamos en el 10% inferior, y necesitamos hacer mucho trabajo para salir de ahí. Y para poder responder esa pregunta, hay algunas métricas que debemos medir. La primera es, ¿con qué frecuencia implementas, esa es tu frecuencia de implementación. La segunda es, ¿cuánto tiempo tarda el código en ponerse en marcha? Entonces, desde que un desarrollador escribe código en su editor de código localmente hasta que ese código está en producción y es utilizado por usuarios reales, ¿cuánto tiempo lleva eso? ¿Cuántas de tus implementaciones fallan? Entonces, cuando implementas, definitivamente a veces introduces defectos en producción. ¿Con qué frecuencia sucede eso? ¿Y cuánto tiempo se tarda en recuperarse de una interrupción? Entonces, cuando alguien introduce un defecto en producción, ¿cuánto tiempo tarda tu equipo en detectar que ocurrió ese defecto y finalmente solucionarlo, ya sea avanzando o retrocediendo? Y en Baseline, tenemos otra. Es una bonificación. Lo llamamos tiempo de desarrollo. Y es cuánto tiempo lleva desde la idea del cliente hasta la producción. Entonces, estoy aquí en una conferencia. He hablado con mucha gente, muchos expertos en sin servidor realmente. Y he aprendido mucho, he obtenido muchas ideas.

¿Cuánto tiempo pasa desde que tengo estas ideas hasta que se implementan en algún momento futuro? ¿Cuál es esa brecha de tiempo? Y así es como se ven los equipos innovadores. Todos los días, tienen bases sólidas, no tienen pruebas inestables, no tienen canalizaciones de CI/CD deficientes y siguen innovando, agregando bloques sobre lo que ya tienen, de manera que la innovación sucede todos los días.

Y para los equipos de bajo rendimiento, esto es lo que parece. Caos total, nadie sabe qué está sucediendo y todos los días, en lugar de enviar cosas a producción que realmente son útiles para sus usuarios y clientes, están solucionando problemas. Están luchando con las canalizaciones de CI/CD. Eso no es para lo que nos inscribimos y queremos alejarnos de esto.

Y cuando comienzas a alejarte de esto, es una profecía autocumplida. Esa es la expresión. Las implementaciones más pequeñas llevan a implementaciones más rápidas. Las implementaciones más rápidas llevan a un tiempo de detección más rápido. Un tiempo de detección más rápido lleva a un tiempo de recuperación más rápido. Y si sabes que puedes recuperarte rápidamente de las interrupciones, implementarás con más frecuencia, innovarás con más frecuencia.

Entonces, ¿cómo se ve todo esto en Baseline? Nuestra frecuencia de implementación es cuando quieras. Haces un cambio de error tipográfico en el frontend, haces un git push y se implementa. Pasamos todo el día trabajando en esta gran migración, y blah, blah, blah. Git push se implementa. No hay obstáculos para la implementación. Y eso es algo que debemos introducir más en nuestros ciclos de desarrollo. Porque esos obstáculos que introducimos, parecen ayudarnos a ser más productivos, pero en realidad solo están frenando a todos.

¿Cuál es nuestro tiempo medio de entrega de cambios? ¿Cuánto tiempo pasa desde que alguien escribe código en su editor de código hasta que ese código se implementa en producción? En realidad, eso depende de cuánto tiempo lleve la infraestructura como código. Utilizamos la infraestructura como código para administrar toda nuestra infraestructura, y cada vez que haces un git push, nuestra canalización de CI/CD recoge los artefactos, los construye y los implementa en la nube. Y el cuello de botella en nuestro proceso es en realidad esa implementación en la nube. Puede llevar unos dos minutos más o menos. Y la razón por la que podemos lograr esto es controvertida. Tenemos pruebas muy eficientes. No probamos por el simple hecho de probar. No tenemos suites de pruebas que tardan 15 minutos en probar botones, etc. Probamos el camino crítico de nuestro software y el resto lo descubriremos si hay algún problema gracias a la observabilidad que tenemos. Y lo segundo, probablemente aún más controvertido, no hacemos revisiones de código. Sé que a mucha gente no le gusta, escucho una sonrisa ahí.

No es algo que se escuche mucho, pero creo que la idea de las revisiones de código proviene de dos cosas. Son prácticas heredadas. Siempre hemos hecho revisiones de código, así que seguiremos haciéndolas. Y la segunda cosa... Gracias.

La segunda cosa es realmente el código abierto. La comunidad de código abierto. Cuando ejecutas una biblioteca de código abierto o un marco de código abierto, necesitas tener revisiones de código porque cualquiera puede hacer commits en tus repositorios. Necesitas tener procesos establecidos para asegurarte de que el código que se incluye en tu repositorio es lo que esperas. La calidad que esperas. Los estándares de seguridad que esperas. Pero dentro de un equipo, bueno, te contrataron en este equipo. Significa que confiamos en que puedes enviar código según los estándares de este equipo. ¿Por qué tenemos que bloquear a uno o dos ingenieros senior o de personal para que lean tu código, lo revisen cada vez? Cuando, seamos honestos entre nosotros, la gran mayoría de las cosas que se detectan en la etapa de revisión de código, los linters, las pruebas y todas esas cosas automatizadas pueden prevenir todo el proceso de revisión de código. Y lo que es más importante, a veces hay cosas que son realmente difíciles. Como escribir este código pero no estoy muy seguro de que esto sea lo que debería ir a producción. La forma en que manejamos eso dentro del equipo de Baseline es mediante la programación en pareja. Escribimos en Slack. Oye, chicos, estoy trabajando en esto. Es un poco difícil, alguien tiene un momento, dos personas, tres personas se unen a ti. Trabajan juntos durante tres, cuatro, seis horas todo el día, y envían un producto que no necesita pasar por una revisión de código. Así que hacemos programación en pareja, pero a pedido, en lugar de todo el tiempo.

Nuestra tasa de fallos en los cambios es del 10%. Lo que significa que una de cada diez implementaciones introduce un defecto en producción. Aún así, es un número bastante bueno, pero debemos recordar que personalmente implemento de 20 a 30 veces al día. Somos un equipo de tres. No soy bueno en matemáticas. Son muchas implementaciones todos los días. Así que el 10% de esas implementaciones introduce un defecto en producción. Ahora, esos defectos, a veces, son errores tipográficos.

A veces son defectos peores que simples errores tipográficos, pero eso nos lleva a lo siguiente, que es nuestro tiempo de recuperación. Cuando un defecto llega a producción, ¿cuánto tiempo nos lleva detectar ese problema y solucionarlo? En promedio, menos de una hora. A veces son cinco minutos porque fue un error tipográfico, a veces un poco más porque fue un problema más grande. Pero confiamos en nuestra observabilidad para poder conocer estos defectos tan pronto que podemos solucionarlos antes de que realmente afecten a quienes están utilizando la aplicación en el mundo real.

Y nuestro tiempo de entrega también es importante. Este es mi favorito. Desde la percepción del cliente hasta la producción. Y la percepción del cliente puede ser cualquier cosa, una conversación, mirar nuestro panel analítico, una entrevista con el cliente, todo eso, desde la percepción hasta la producción, aproximadamente medio día, por lo general. Y lo genial de esto es que no tiene nada que ver con la capacidad de codificación. No tiene nada que ver con las credenciales. Todo se trata de la cultura de tu equipo. Todo se trata de la confianza que tienes en tus compañeros de equipo. Todo se trata de las herramientas que implementas para poder conocer estos defectos antes de que realmente afecten a los usuarios reales.

Y la pregunta que me hacen mucho es, ¿esto es para todos? Oh, Boris, sabes, estás en una pequeña startup. Está bien para ti lanzar a producción sin preocupaciones. No funcionará en ningún otro lugar. Y esta pregunta generalmente viene con todo eso. Ese enfoque no es escalable. ¿Qué pasa con las migraciones? Necesitas controles y verificaciones manuales en torno a la implementación. Necesitas control de calidad. ¿Qué pasa si rompes la producción? Bueno, lo que estoy escuchando en realidad es que no puedes tener una alta velocidad y software de calidad al mismo tiempo. Eso es lo que todas esas preguntas están diciendo, que es imposible avanzar rápido y no romper cosas. Y mi respuesta es sí, podemos hacerlo. Y podemos hacerlo con la cultura adecuada, los procesos adecuados y las herramientas adecuadas. Entonces, ¿cómo logramos esto en Baseline? Comienza con nuestra cultura empresarial. Esta es uno de los valores fundamentales de nuestra empresa, y esta es la versión suavizada porque no pudimos poner `jugar y descubrir` en nuestro sitio web. Tuvimos que conformarnos con `experimentar`. Pero la idea es muy simple. Estás experimentando, estás innovando. No conoces las respuestas a estas preguntas.

Hoy hubo una charla sobre ganchos asíncronos y cómo cambió de Worker a Node.js, etc. Pero estaban experimentando. Estaban innovando. Encontraron la primera solución que no era la correcta y ahora la están corrigiendo. Así es como se construye el software. Necesitas probar y descubrir si realmente funciona para las personas allá afuera.

El segundo es enviar monopatines. Nadie en nuestro equipo patina, tal vez una persona, pero el emoji de monopatín es el que más se usa en nuestro Slack. Y la razón es que enviamos monopatines. Y esto es lo que significa. Construimos la versión más pequeña posible de cualquier cosa. Lo ponemos en producción. Observamos cómo la gente react a ello y seguimos iterando hasta obtener este automóvil realmente elegante. O, a mitad de camino, nos damos cuenta de que en realidad a nadie le importa esta cosa que acabas de construir y enviar. Deséchalo. Elimínalo. No tiene sentido construir este automóvil realmente elegante, pasar seis meses, implementarlo una vez al mes y descubrir que fue completamente inútil un año después cuando podrías haber enviado la versión más pequeña e iterado sobre ella.

Entonces, uno de los otros pilares clave es el desarrollo impulsado por la observabilidad. ¿Alguien aquí está familiarizado con los conceptos de desarrollo impulsado por la observabilidad? Solo unas pocas manos. Genial. Así que voy a empezar diciéndote qué es realmente la observabilidad, y tengo un video corto aquí. Pero antes de reproducir el video, no vengo de un fondo de ingeniería de software. Estudié ingeniería aeroespacial y me sorprendió bastante cuando me mudé al software hace unos años y me di cuenta de que la gente realmente no tenía idea de lo que sus sistemas estaban haciendo en producción. La gente no sabía cuántos nodos tenían. La gente no sabía cómo los usuarios experimentaban sus aplicaciones. Y la razón por la que me sorprendió fue esta. Así que esta soy yo hace unos años, más joven y delgada, trabajando en drones. Volábamos esos drones, los llenábamos con la mayor cantidad de instrumentación posible. Recopilábamos la mayor cantidad de data posible sobre la trayectoria de vuelo y la velocidad del aire y todas las cosas que puedas imaginar sobre ese drone volando. Y cuando aterrizaba, sacaba las cosas, sacaba la tarjeta SD, la conectaba a mi computadora.

Y a partir de esos datos, podría decirte absolutamente todo lo que le sucedió a esta aeronave mientras volaba. No necesitaba volver a volar la aeronave por cualquier motivo, porque los datos me estaban diciendo todo. Y lo que es más importante, con esos datos, podría construir modelos que predecirán cómo se comportará la aeronave en nuevos escenarios que no formaron parte de este vuelo.

Imagina entonces cuando me uní, comencé a ser un ingeniero de software y la gente decía, oh, no sabemos, necesitamos agregar registros. Como, ¿qué quieres decir con que necesitas agregar registros? ¿Por qué no tenías registros desde el principio? ¿Por qué no tenías trazas desde el principio? No es algo que haces al final. Tu función no está completa hasta que tengas un monitoreo adecuado, una observabilidad adecuada, paneles de control, consultas y alertas sobre esa función específica que acabas de construir. Ese no es el botón correcto. Y de eso se trata la observabilidad. La observabilidad te permite hacer preguntas arbitrarias a tus sistemas y obtener respuestas sin cambios de código. Esa es la parte crítica, porque ese problema puede ocurrir en condiciones tan raras que en realidad no puedes reproducirlo. Deberías poder saber exactamente qué sucedió sin cambiar el sistema que estaba en producción en primer lugar. Entonces, ¿qué es el desarrollo impulsado por la observabilidad? Creo que voy a repetirme un poco. La observabilidad como parte de tu ciclo de desarrollo. Entonces, cuando escribes código, necesitas instrumentarlo. No envías código que no esté instrumentado. En segundo lugar, instrumenta activamente tu aplicación. Básicamente lo mismo. Y lo último un poco más controvertido, pruebas en producción. Mucha gente quiere poder replicar todo localmente. Eso está genial, pero cuando estás construyendo sistemas distribuidos, especialmente con arquitecturas serverless, muchos de los problemas que ocurrirán son comportamientos emergentes que serán extremadamente difíciles de reproducir localmente.

Imagina tener ese avión que estaba volando e intentar reproducir las condiciones de ráfaga que ocurren en el aire justo en la estación terrestre. Eso sería prácticamente imposible. Es lo mismo con los sistemas distribuidos en la nube. Esta es una de mis citas favoritas, la observabilidad sin acción es solo almacenamiento. Mucha gente tiene Elasticsearch que recopila todos los registros y están contentos con eso. Estás pagando por almacenamiento. Si no estás utilizando esos datos, si no estás consultando esos datos todos los días para comprender tus sistemas, solo estás pagando por almacenamiento. No estás pagando por observabilidad. Y lo más importante para poder innovar rápidamente es construir bucles de retroalimentación estrechos. Y sí, voy a tomar un ejemplo para explicar cómo funciona eso.

Así que esto fue hace aproximadamente un mes, mes y medio. Tuve una llamada con un cliente y hablé con este chico y me dijo: `oye, esto es genial, pero en mis funciones Lambda, normalmente puedo ejecutarlas, pero a veces DynamoDB, espero que la gente esté familiarizada con DynamoDB, es una base de datos en Amazon Web Services, a veces limita el rendimiento`. Y es bastante difícil para mí saber que se limitó. Eso fue un miércoles por la tarde, alrededor de las 4 o 5 p.m., cuando tuve esa llamada.

Dejé un mensaje en Slack y dije, él estaba aún más emocionado, blah blah blah blah blah. Y Thomas, que está en nuestro equipo, dijo: `sé lo que voy a enviar mañana`. Eso fue a las 6 p.m. un día. Al día siguiente, a las 5:42 p.m., tenía la primera versión de esa función enviada. Solo funcionaba para DynamoDB, ninguno de los otros servicios de AWS, pero lo implementamos en producción y pudimos obtener comentarios al respecto. Y ahora estamos iterando en ello, agregando otros servicios y mejorando eso.

Oh, digo que se me acaba el tiempo. Bueno, la cosa es que todo falla todo el tiempo. No todo es bonito, lo implementas en producción y funciona. Falla todo el tiempo. Pero lo que no podemos permitir es que las personas tengan miedo de implementar en producción. Eso es lo que no podemos tener. Tan pronto como un ingeniero tiene miedo de implementar en producción, hemos fallado como equipo.

Oh, una cosa que escucho mucho es: `oh, Boris, eso es genial, pero no tenemos tiempo para la observabilidad porque tenemos todas estas otras cosas que hacer`. Y esto es lo que escucho. Estamos demasiado ocupados, porque estamos usando eso para trabajar cuando podríamos estar usando eso en su lugar. Y no importa cuánto trabajes con esto, siempre serás más lento que si usas las ruedas reales.

Entonces, para resumir. Construye una cultura que fomente una mayor propiedad por parte de tus ingenieros. Democratiza la producción para todo tu equipo. Instrumenta absolutamente todo. Obtén todas tus respuestas haciendo preguntas directamente a producción, en lugar de tratar de adivinar las cosas. Construye tu motor de innovación y pasa menos tiempo gestionando la deuda técnica.

Eso es todo por mi parte. Gracias por recibirme. ¿Mides el tiempo de entrega a nivel de tarea o a nivel de EPIC del proyecto?

Oh, lo medimos en cada cosa que llega a producción, en el nivel más pequeño posible. Así que no trabajamos en grandes EPICs que tardan un mes en construirse. Enviamos la versión más pequeña posible de eso. Tenemos esta cosa que llamamos `scope hammering`. Entonces, cuando alguien tiene una idea, en realidad tomamos esa idea y decimos, ¿cuál es la versión más pequeña de esto que puede ir a producción en los próximos días? Y seguimos reduciendo el alcance de esa idea hasta que tenemos algo en lo que confiamos que estará en producción en unos pocos días. Y en eso es en lo que trabajamos en lugar de tratar de construir algo un poco más grande.

Genial. La siguiente pregunta debería ser muy rápida de responder. ¿Cuál es el nombre o el libro de métricas que mencionaste?

Oh, Accelerate. No recuerdo el nombre de los autores. Pero si buscas Accelerate, es un nombre muy largo, cómo mejorar tu ciclo de desarrollo o algo así, encontrarás el libro.

Muy bien. Gracias. ¿Ejecutan pruebas de extremo a extremo en algunas áreas? Si es así, ¿cuándo las ejecutan? ¿En solicitudes de extracción o utilizando un cronograma?

Oh, eso es muy interesante. Dado que implementamos tan a menudo, no necesitamos programadores para hacer cosas así. Por lo tanto, cada vez que algo se implementa, se ejecuta el conjunto de pruebas que tenemos antes de que llegue a producción. Y en cuanto a las pruebas de extremo a extremo, lo que hacemos en realidad es muy interesante. Implementamos funciones sin servidor muy pequeñas. Entonces, las funciones sin servidor hacen exactamente una cosa, no dos cosas, solo una cosa muy simple. Esto significa que probar esa función en aislamiento es relativamente fácil, porque simplemente dices, estos son los datos de entrada, ¿qué espero como salida? Hay muy, bueno, las llamadas a la base de datos y las llamadas a la caché, todo eso lo marcamos. Pero las pruebas en sí son muy simples.

Muy bien, muy interesante. Accidentalmente archivé uno. Lo estoy volviendo a archivar ahora. Y sí, con el desarrollo basado en tronco, noté que hay un mayor riesgo de crear mucha deuda técnica. Por lo general, se muestra después de siete años de desarrollo rápido. ¿Cuál es tu experiencia al respecto?

Bueno, la empresa no tiene siete años todavía, así que no puedo responder eso. Pero la forma en que trabajamos es enviarlo a la rama principal.

Esto es muy personal y subjetivo, diría yo, pero mi experiencia con ramas y todo eso siempre es una pesadilla. Tenemos múltiples repositorios. Tenemos un equipo muy pequeño, pero tenemos fácilmente 100 repositorios. Es muy raro que tu envío a principal realmente choque con el envío de otra persona a principal. Así que simplemente envía a principal.

De acuerdo, genial, el que accidentalmente archivé, ahora es tu turno. Idea interesante sobre no tener revisiones de código. ¿Has medido si esto funciona bien para el negocio a largo plazo? ¿Cómo sabes que no está empeorando las cosas?

Oh, interesante. Creo que fue una decisión consciente para nosotros no tener revisiones de código y no tener muchas revisiones de código. Creo que fue una decisión consciente para nosotros no tener revisiones de código y cuando los chicos se unen, cada vez que alguien se une al equipo, dicen `Dios mío, no puedo trabajar en este entorno`. Y tres semanas después, dicen `Dios mío, revisiones de código, ¿quién inventó eso?`. Simplemente porque te permite avanzar mucho más rápido. No tenemos números cuantitativos que podamos compartir porque comenzamos la empresa con esa filosofía. No cambiamos a eso y podemos comparar el ritmo. Pero desde mi experiencia personal en posiciones anteriores, definitivamente es mucho, mucho más rápido.

De acuerdo, hay una pregunta relacionada con eso. Un segundo. Oh, esa es interesante. Entonces, mencioné que una de cada diez implementaciones, aproximadamente, una de cada diez implementaciones introduce un defecto en producción. Pero muy rara vez esos defectos realmente afectan la experiencia, ¿verdad? La forma en que está estructurada nuestra infraestructura está tan desacoplada que, y eso es lo que obtienes casi de inmediato con la arquitectura sin servidor. Si trabajas con arquitectura sin servidor, típicamente tendrás una arquitectura mucho más desacoplada. Y como resultado de eso, los defectos son muy localizados. Muy rara vez un defecto afectará a un gran número de usuarios. Entonces, la mayoría de las veces, somos nosotros quienes informamos a los clientes, `oye, hubo este problema durante diez minutos, no pudiste, no sé, ver tus paneles`, pero nadie abrió su panel durante esos diez minutos. Así que está bien. Estoy seguro de que, ya sabes, puede haber ocasiones en las que tengamos algo de rotación. Pero esa es una decisión que tomamos. Estamos dispuestos a tener rotación de algunos usuarios siempre y cuando podamos innovar todos los días y ganar más usuarios de los que estamos perdiendo. ¿De acuerdo? Sí, hay más preguntas relacionadas con lo que se ha discutido hasta ahora. Tal vez dos más.

Sí. ¿Cambiarías algo en tus prácticas si trabajaras en la industria de la salud o la banca? Oh, sí. Entonces, una gran advertencia en todo esto, estamos construyendo observabilidad. Correcto, no estamos manejando el dinero de las personas. No estamos manejando los registros de salud de las personas. Estoy seguro de que en industrias reguladas esto será muy, muy diferente. Pasé un tiempo muy corto en una startup regulada y realmente lo odié por lo lento que era. Bueno, si estás en ese espacio, no sé. Pero si estás en un espacio donde no tienes esas regulaciones sobre tu cabeza, no apliques los mismos principios que ellos aplican simplemente porque esos principios son mejores prácticas. Haz lo que funcione para tu industria en lugar de copiar lo que, ya sabes, el resto de la industria hace. Sí, muy bueno. Sí, el último. ¿Has intentado implementar un marco de trabajo espacial en lugar de las métricas de DORA? ¿Algún comentario? No, solo DORA. De acuerdo, muchas gracias, Boris. Saludos.