Creando un motor de innovación con observabilidad

Rate this content
Bookmark

Cómo Baseline creó una cultura donde es posible moverse rápido, romper lo menos posible y recuperarse de las fallas de manera elegante. La cultura está técnicamente respaldada por Node.js, Arquitecturas Orientadas a Eventos (EDAs) y Observabilidad (o11y).

27 min
14 Apr, 2023

Video Summary and Transcription

Baseline proporciona observabilidad para arquitecturas sin servidor y ha creado un motor de innovación dentro de su equipo. Miden el rendimiento del equipo utilizando métricas Dora y el libro Accelerate. Baseline enfatiza la importancia de los fundamentos, las pruebas simplificadas y la implementación rápida. Practican el desarrollo impulsado por la observabilidad e incorporan la observabilidad como parte de su ciclo de desarrollo. Baseline cree en la construcción de una cultura que fomenta la propiedad y democratiza la producción.

Available in English

1. Introducción a Baseline y el Motor de Innovación

Short description:

Mi nombre es Boris. Soy el fundador y CEO de Baseline. Brindamos observabilidad para arquitecturas sin servidor. Hoy quiero compartir cómo hemos creado un motor de innovación dentro de nuestro equipo. Enviamos rápidamente y discutiré los métodos que aplicamos. La pregunta de qué tan bien está funcionando un equipo ahora puede ser respondida utilizando las métricas Dora y el libro Accelerate. Medimos la frecuencia de implementación, el tiempo para poner en marcha, las fallas de implementación, el tiempo de recuperación de interrupciones y el tiempo de desarrollo.

♪♪ ♪♪ ♪♪ 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.

2. Insights to Production and Deployment Process

Short description:

Los equipos innovadores tienen bases sólidas, sin pruebas inestables ni canalizaciones de CI/CD deficientes. Los equipos de bajo rendimiento experimentan caos y pierden tiempo solucionando problemas en lugar de enviar. Las implementaciones más pequeñas permiten una detección y recuperación más rápidas. Baseline no tiene obstáculos para la implementación y realiza pruebas de manera eficiente. El cuello de botella es la implementación en la nube. No prueban todo y no hacen revisiones de código.

¿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í.

3. Code Reviews and Change Failure Rate

Short description:

Las revisiones de código han sido una práctica heredada y son comunes en la comunidad de código abierto. Sin embargo, dentro de un equipo, se deposita confianza en los miembros del equipo para enviar código según los estándares del equipo. La mayoría de los problemas detectados en las revisiones de código se pueden prevenir mediante procesos automatizados como linters y pruebas. Para tareas más desafiantes, el equipo de Baseline practica la programación en pareja a pedido. Su tasa de fallos en los cambios es aproximadamente del 10%, con uno de cada diez implementaciones que introduce defectos en producción.

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.

4. Defect Recovery Time and Culture

Short description:

Nuestro tiempo de recuperación para defectos en producción es inferior a una hora. Desde la percepción del cliente hasta la producción, lleva aproximadamente medio día. Todo se trata de la cultura, la confianza y las herramientas dentro del equipo. Muchos se preguntan si este enfoque funciona para todos y si es posible tener una alta velocidad y software de calidad al mismo tiempo. La respuesta es sí, con la cultura adecuada, los procesos adecuados y las herramientas adecuadas.

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.

5. Innovation and Observability-Driven Development

Short description:

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. El segundo es enviar monopatines. Construimos la versión más pequeña posible de cualquier cosa. Lo ponemos en producción. Observamos cómo reacciona la gente 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.

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.

6. Desarrollo impulsado por la observabilidad

Short description:

La observabilidad te permite hacer preguntas arbitrarias a tus sistemas y obtener respuestas sin cambios de código. El desarrollo impulsado por la observabilidad consiste en incorporar la observabilidad como parte de tu ciclo de desarrollo. Necesitas instrumentar tu código y activamente instrumentar tu aplicación. Las pruebas en producción son controvertidas, pero necesarias para construir sistemas distribuidos. La observabilidad sin acción es solo almacenamiento. Construir bucles de retroalimentación estrechos es fundamental para una rápida innovación.

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.

7. Customer Call and Deploying to Production

Short description:

Así que esto fue hace aproximadamente un mes, mes y medio. Tuve una llamada con un cliente y me dijo que a veces DynamoDB limita el rendimiento de mis funciones Lambda. Es difícil para mí saberlo. Thomas envió la primera versión de la función al día siguiente. Todo falla todo el tiempo, pero no podemos tener ingenieros con miedo de implementar en producción. No tenemos tiempo para la observabilidad porque estamos demasiado ocupados. Construye una cultura que fomente la propiedad, democratiza la producción, instrumenta todo, haz preguntas directamente a producción, construye tu motor de innovación.

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.

QnA

Measuring Lead Time and Testing Approach

Short description:

Medimos el tiempo de entrega en el nivel más pequeño posible, enviando la versión más pequeña de una idea a producción en unos pocos días. El libro de métricas mencionado se llama Accelerate. Ejecutamos pruebas de extremo a extremo antes de implementar en producción, utilizando un conjunto de pruebas que se ejecuta cada vez. Implementamos pequeñas funciones sin servidor, lo que facilita las pruebas en aislamiento. Con el desarrollo basado en tronco, el riesgo de deuda técnica aumenta con el tiempo.

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.

Branches, Code Reviews, and Defects

Short description:

Mi experiencia con ramas y todo eso siempre es una pesadilla. 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. Idea interesante sobre no tener revisiones de código. Te permite avanzar mucho más rápido. Una de cada diez implementaciones introduce un defecto en producción, pero rara vez afectan la experiencia. Los defectos son muy localizados debido a nuestra infraestructura desacoplada. 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.

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.

Consideraciones para Industrias Reguladas

Short description:

En industrias reguladas como la salud y la banca, las prácticas pueden diferir debido a regulaciones estrictas. Sin embargo, para industrias sin tales regulaciones, es importante enfocarse en lo que funciona mejor para su industria específica en lugar de seguir ciegamente las prácticas de la industria.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Top Content
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.