Creando un motor de innovación con observabilidad

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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

This talk has been presented at Node Congress 2023, check out the latest edition of this JavaScript Conference.

FAQ

Baseline es una empresa fundada por Boris, enfocada en proporcionar observabilidad para arquitecturas sin servidor. Ofrece soluciones para ejecutar y mantener código en la nube de forma eficiente, ayudando a las empresas a superar los desafíos de la deuda técnica y las pruebas inestables.

Baseline alcanza una alta frecuencia de implementación al permitir implementaciones continuas sin obstáculos significativos. Utilizan infraestructura como código para manejar la implementación, lo que permite cambios rápidos y eficientes, además de no realizar revisiones de código, lo que acelera el proceso.

Baseline utiliza varias métricas clave, como la frecuencia de implementación, el tiempo desde el desarrollo hasta la producción, la tasa de fallos en los cambios y el tiempo de recuperación de interrupciones. Estas métricas ayudan a evaluar cuánta innovación está enviando el equipo y cuán eficientemente manejan los problemas.

Baseline no realiza revisiones de código porque confían en la capacidad y los estándares de sus desarrolladores. Consideran que las revisiones de código son prácticas heredadas que pueden ralentizar el proceso de desarrollo sin aportar beneficios significativos, prefiriendo en su lugar la programación en pareja a pedido.

El desarrollo impulsado por la observabilidad en Baseline implica asegurar que cada parte del código esté adecuadamente instrumentada para monitorear su comportamiento en producción sin necesidad de cambios adicionales. Esto permite realizar ajustes basados en datos en tiempo real y responder rápidamente a los problemas.

Baseline fomenta la innovación permitiendo la implementación rápida de ideas en producción y utilizando pruebas en producción para iterar rápidamente sobre las funcionalidades. Priorizan la construcción de versiones mínimas viables y utilizan la observabilidad para ajustar y mejorar continuamente.

Boris Tane
Boris Tane
27 min
14 Apr, 2023

Comments

Sign in or register to post your comment.
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.

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

Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Node Congress 2022Node Congress 2022
26 min
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
Cargadores ESM: Mejorando la carga de módulos en Node.js
JSNation 2023JSNation 2023
22 min
Cargadores ESM: Mejorando la carga de módulos en Node.js
Top Content
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Node Congress 2022Node Congress 2022
34 min
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Top Content
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
Diagnostics de Node.js listos para usar
Node Congress 2022Node Congress 2022
34 min
Diagnostics de Node.js listos para usar
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
El Estado de Node.js 2025
JSNation 2025JSNation 2025
30 min
El Estado de Node.js 2025
The speaker covers a wide range of topics related to Node.js, including its resilience, popularity, and significance in the tech ecosystem. They discuss Node.js version support, organization activity, development updates, enhancements, and security updates. Node.js relies heavily on volunteers for governance and contribution. The speaker introduces an application server for Node.js enabling PHP integration. Insights are shared on Node.js downloads, infrastructure challenges, software maintenance, and the importance of update schedules for security.
Compatibilidad con Node.js en Deno
Node Congress 2022Node Congress 2022
34 min
Compatibilidad con Node.js en Deno
Deno aims to provide Node.js compatibility to make migration smoother and easier. While Deno can run apps and libraries offered for Node.js, not all are supported yet. There are trade-offs to consider, such as incompatible APIs and a less ideal developer experience. Deno is working on improving compatibility and the transition process. Efforts include porting Node.js modules, exploring a superset approach, and transparent package installation from npm.

Workshops on related topic

Masterclass de Node.js
Node Congress 2023Node Congress 2023
109 min
Masterclass de Node.js
Top Content
Workshop
Matteo Collina
Matteo Collina
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.

Nivel: intermedio
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source como nuestra oferta en la Nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). 
En esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.
Construyendo un Servidor Web Hiper Rápido con Deno
JSNation Live 2021JSNation Live 2021
156 min
Construyendo un Servidor Web Hiper Rápido con Deno
Workshop
Matt Landers
Will Johnston
2 authors
Deno 1.9 introdujo una nueva API de servidor web que aprovecha Hyper, una implementación rápida y correcta de HTTP para Rust. El uso de esta API en lugar de la implementación std/http aumenta el rendimiento y proporciona soporte para HTTP2. En este masterclass, aprende cómo crear un servidor web utilizando Hyper en el fondo y mejorar el rendimiento de tus aplicaciones web.
0 a Auth en una Hora Usando NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 a Auth en una Hora Usando NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada.
Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones
Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña.
Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña
Requisitos previos- IDE de tu elección- Node 18 o superior
GraphQL: De Cero a Héroe en 3 horas
React Summit 2022React Summit 2022
164 min
GraphQL: De Cero a Héroe en 3 horas
Workshop
Pawel Sawicki
Pawel Sawicki
Cómo construir una aplicación GraphQL fullstack (Postgres + NestJs + React) en el menor tiempo posible.
Todos los comienzos son difíciles. Incluso más difícil que elegir la tecnología es desarrollar una arquitectura adecuada. Especialmente cuando se trata de GraphQL.
En este masterclass, obtendrás una variedad de mejores prácticas que normalmente tendrías que trabajar en varios proyectos, todo en solo tres horas.
Siempre has querido participar en un hackathon para poner algo en funcionamiento en el menor tiempo posible, entonces participa activamente en este masterclass y únete a los procesos de pensamiento del instructor.
Dominando Node.js Test Runner
TestJS Summit 2023TestJS Summit 2023
78 min
Dominando Node.js Test Runner
Workshop
Marco Ippolito
Marco Ippolito
Node.js test runner es moderno, rápido y no requiere bibliotecas adicionales, pero entenderlo y usarlo bien puede ser complicado. Aprenderás a utilizar Node.js test runner a su máximo potencial. Te mostraremos cómo se compara con otras herramientas, cómo configurarlo y cómo ejecutar tus pruebas de manera efectiva. Durante la masterclass, haremos ejercicios para ayudarte a sentirte cómodo con el filtrado, el uso de afirmaciones nativas, la ejecución de pruebas en paralelo, el uso de CLI y más. También hablaremos sobre trabajar con TypeScript, hacer informes personalizados y la cobertura de código.