Charity Majors, CTO y cofundadora de Honeycomb – Serie de entrevistas

Charity es una ingeniera de operaciones y fundadora accidental de startups en Honeycomb. Antes de esto, trabajó en Parse, Facebook (META ) y Linden Lab en infraestructura y herramientas para desarrolladores, y siempre parecía terminar dirigiendo las bases de datos. Es coautora de Database Reliability Engineering de O’Reilly, y ama la libertad de expresión, el software libre y el whisky de malta solo.

Eras la gerente de ingeniería de producción en Facebook (ahora Meta) durante más de 2 años, ¿cuáles fueron algunos de tus momentos destacados durante este período y cuáles son algunas de tus conclusiones clave de esta experiencia?

Trabajé en Parse, que era un backend para aplicaciones móviles, más o menos como Heroku para móviles. Nunca había estado interesada en trabajar en una gran empresa, pero nos adquirió Facebook. Una de mis conclusiones clave fue que las adquisiciones son realmente, realmente difíciles, incluso en las mejores circunstancias. El consejo que siempre doy a otros fundadores ahora es este: si vas a ser adquirida, asegúrate de tener un patrocinador ejecutivo y piensa muy bien si tienes alineación estratégica. Facebook adquirió Instagram no mucho antes de adquirir Parse, y la adquisición de Instagram no fue precisamente un éxito, pero al final fue muy exitosa porque tenían alineación estratégica y un fuerte patrocinador.

No tuve un tiempo fácil en Facebook, pero estoy muy agradecida por el tiempo que pasé allí; no creo que pudiera haber iniciado una empresa sin las lecciones que aprendí sobre estructura organizativa, gestión, estrategia, etc. También me dio un pedigrí que me hizo atractiva para los inversores de capital de riesgo, ninguno de los cuales me había dado la hora del día hasta ese punto. Estoy un poco molesta con esto, pero lo aceptaré.

¿Podrías compartir la historia de la creación de Honeycomb?

Definitivamente. Desde una perspectiva arquitectónica, Parse estaba por delante de su tiempo — estábamos utilizando microservicios antes de que existieran los microservicios, teníamos una capa de datos masivamente fragmentada, y como plataforma que servía a más de un millón de aplicaciones móviles, teníamos muchos problemas de multitenencia muy complicados. Nuestros clientes eran desarrolladores, y estaban constantemente escribiendo y subiendo fragmentos de código y nuevas consultas de, digamos, “calidad variable” — y simplemente teníamos que aceptarlo todo y hacer que funcionara, de alguna manera.

Estábamos a la vanguardia de una serie de cambios que desde entonces se han vuelto mainstream. Solía ser que la mayoría de las arquitecturas eran bastante simples, y fallaban repetidamente de maneras predecibles. Tenías una capa web, una aplicación y una base de datos, y la mayoría de la complejidad se encontraba en tu código de aplicación. Así que escribías controles de monitoreo para buscar esas fallas, y construías paneles de control estáticos para tus métricas y datos de monitoreo.

Esta industria ha visto una explosión en la complejidad arquitectónica en los últimos 10 años. Hemos explotado el monolito, así que ahora tienes desde varios servicios hasta miles de microservicios de aplicación. La persistencia políglota es la norma; en lugar de “la base de datos” es normal tener muchos diferentes tipos de almacenamiento, así como fragmentación horizontal, capas de caché, db-per-microservicio, cola, y más. Además de eso, tienes contenedores alojados en el servidor, servicios y plataformas de terceros, código sin servidor, almacenamiento en bloque, y más.

Lo difícil solía ser depurar tu código; ahora, lo difícil es averiguar dónde en el sistema está el código que necesitas depurar. En lugar de fallar repetidamente de maneras predecibles, es más probable que cada vez que te llamen, sea sobre algo que nunca has visto antes y que tal vez nunca vuelvas a ver.

Depurar estos problemas desde cero es increíblemente difícil. Con registros y métricas, básicamente tienes que saber lo que estás buscando antes de que puedas encontrarlo. Pero empezamos a alimentar algunos conjuntos de datos en una herramienta de FB llamada Scuba, que nos permitía cortar y dividir en dimensiones arbitrarias y datos de alta cardinalidad en tiempo real, y el tiempo que nos llevaba identificar y resolver estos problemas desde cero cayó como una roca, como de horas a… minutos! No era ni siquiera un problema de ingeniería, era un problema de soporte. Podías seguir el rastro de migas hasta la respuesta cada vez, clic, clic, clic.

Fue alucinante. Esta enorme fuente de incertidumbre y esfuerzo y clientes infelices y llamadas a las 2 am… simplemente desapareció. No fue hasta que Christine y yo nos fuimos de Facebook que nos dimos cuenta de cuánto había transformado la forma en que interactuábamos con el software. La idea de volver a los malos viejos días de controles de monitoreo y paneles de control era simplemente impensable.

Pero en ese momento, honestamente pensamos que esto sería una solución de nicho — que resolvía un problema que podrían tener otras plataformas multitenantes masivas. No fue hasta que habíamos estado construyendo durante casi un año que empezamos a darnos cuenta de que, oh, esto en realidad se está convirtiendo en un problema para todos.

Para los lectores que no están familiarizados, ¿qué es específicamente una plataforma de observabilidad y cómo difiere de la monitorización y las métricas tradicionales?

La monitorización tradicional tiene tres pilares: métricas, registros y trazas. Normalmente necesitas comprar muchas herramientas para satisfacer tus necesidades: registro, trazado, APM, RUM, creación de paneles de control, visualización, etc. Cada una de estas está optimizada para un caso de uso diferente en un formato diferente. Como ingeniero, te sientas en el medio de todas estas, tratando de darles sentido. Revisas los paneles de control en busca de patrones visuales, copias y pegas IDs de los registros a las trazas y viceversa. Es muy reactivo y fragmentado, y normalmente te refieres a estas herramientas cuando tienes un problema — están diseñadas para ayudarte a operar tu código y encontrar errores.

La observabilidad moderna tiene una fuente de verdad única; eventos de registros estructurados arbitrariamente anchos. A partir de estos eventos, puedes derivar tus métricas, paneles de control y registros. Puedes visualizarlos en el tiempo como una traza, puedes cortar y dividir, puedes acercarte a solicitudes individuales y alejarte a la vista larga. Como todo está conectado, no tienes que saltar de herramienta en herramienta, adivinando o confiando en la intuición. La observabilidad moderna no se trata solo de cómo operas tus sistemas, se trata de cómo desarrollas tu código. Es el sustrato que te permite conectar bucles de retroalimentación poderosos y ajustados que te ayudan a enviar mucho valor a los usuarios rápidamente, con confianza, y a encontrar problemas antes de que los encuentren tus usuarios.

Eres conocida por creer que la observabilidad ofrece una fuente de verdad única en entornos de ingeniería. ¿Cómo se integra la IA en esta visión, y cuáles son sus beneficios y desafíos en este contexto?

La observabilidad es como ponerte gafas antes de lanzarte a la autopista. El desarrollo impulsado por pruebas (TDD) revolucionó el software a principios de la década de 2000, pero TDD ha ido perdiendo eficacia a medida que la complejidad se encuentra en nuestros sistemas en lugar de solo en nuestro software. Cada vez más, si quieres obtener los beneficios asociados con TDD, en realidad necesitas instrumentar tu código y realizar algo similar al desarrollo impulsado por la observabilidad, o ODD, donde instrumentas a medida que avanzas, despliegas rápidamente, y luego miras tu código en producción a través de la lente de la instrumentación que acabas de escribir y te preguntas: “¿Está haciendo lo que se supone que debe hacer, y hay algo más que parezca… extraño?”

Las pruebas solas no son suficientes para confirmar que tu código está haciendo lo que se supone que debe hacer. No lo sabes hasta que lo has visto funcionar en producción, con usuarios reales en infraestructura real.

Este tipo de desarrollo — que incluye la producción en bucles de retroalimentación rápidos — es (un poco contraintuitivamente) mucho más rápido, más fácil y más simple que confiar en pruebas y ciclos de despliegue más lentos. Una vez que los desarrolladores han intentado trabajar de esta manera, son famosos por no querer volver al lento y antiguo método de hacer las cosas.

Lo que me emociona de la IA es que cuando estás desarrollando con LLM, tienes que desarrollar en producción. La única forma de derivar un conjunto de pruebas es validando primero tu código en producción y trabajando hacia atrás. Creo que escribir software respaldado por LLM será una habilidad tan común como escribir software respaldado por MySQL o Postgres en unos años, y mi esperanza es que esto arrastre a los ingenieros a una mejor forma de vida.

Has expresado preocupación por la deuda técnica creciente debido a la revolución de la IA. ¿Podrías explicar los tipos de deuda técnica que la IA puede introducir y cómo Honeycomb ayuda a gestionar o mitigar estas deudas?

Estoy preocupada por la deuda técnica y, quizás más importante, la deuda organizativa. Uno de los peores tipos de deuda técnica es cuando tienes software que no es bien entendido por nadie. Lo que significa que cada vez que tienes que extender o cambiar ese código, o depurarlo o arreglarlo, alguien tiene que hacer el trabajo duro de aprenderlo.

Y si pones código en producción que nadie entiende, hay una muy buena posibilidad de que no se escribió para ser entendible. El buen código se escribe para ser fácil de leer y entender y extender. Utiliza convenciones y patrones, utiliza nombres y modularización consistentes, equilibra DRY y otras consideraciones. La calidad del código es inseparable de lo fácil que es para las personas interactuar con él. Si simplemente lanzas código a producción porque se compila o pasa pruebas, estás creando un iceberg masivo de problemas técnicos para ti mismo.

Si has decidido enviar código que nadie entiende, Honeycomb no puede ayudar con eso. Pero si te importa enviar software limpio e iterable, la instrumentación y la observabilidad son absolutamente esenciales para ese esfuerzo. La instrumentación es como la documentación más el informe de estado en tiempo real. La instrumentación es la única forma de confirmar realmente que tu software está haciendo lo que esperas que haga, y se está comportando como tus usuarios esperan que se comporte.

¿Cómo utiliza Honeycomb la IA para mejorar la eficiencia y la eficacia de los equipos de ingeniería?

Nuestros ingenieros utilizan la IA mucho internamente, especialmente CoPilot. Nuestros ingenieros más juniors informan que utilizan ChatGPT todos los días para responder preguntas y ayudarles a entender el software que están construyendo. Nuestros ingenieros más seniores dicen que es genial para generar software que sería muy tedioso o molesto de escribir, como cuando tienes un archivo YAML gigante que llenar. También es útil para generar fragmentos de código en lenguajes que no sueles usar, o desde la documentación de la API. Como puedes generar algunos ejemplos realmente geniales y útiles de cosas usando los SDK y API de AWS, ya que se entrenó en repositorios que tienen un uso real de ese código.

Sin embargo, cada vez que dejas que la IA genere tu código, tienes que pasar por él línea por línea para asegurarte de que esté haciendo lo correcto, porque absolutamente generará basura en la regularidad.

¿Podrías proporcionar ejemplos de cómo las características impulsadas por la IA, como tu asistente de consultas o la integración con Slack, mejoran la colaboración en equipo?

Sí, seguro. Nuestro asistente de consultas es un gran ejemplo. Utilizar constructores de consultas es complicado y difícil, incluso para usuarios avanzados. Si tienes cientos o miles de dimensiones en tus telemetrías, no siempre puedes recordar de memoria qué son los más valiosos. Y ni siquiera los usuarios avanzados recuerdan los detalles de cómo generar ciertos tipos de gráficos.

Así que nuestro asistente de consultas te permite hacer preguntas utilizando lenguaje natural. Como “¿Cuáles son los puntos finales más lentos?” o “¿Qué pasó después de mi última implementación?” y genera una consulta y te mete en ella. La mayoría de las personas encuentran que es difícil componer una nueva consulta desde cero y fácil de ajustar una existente, así que te da una ventaja.

Honeycomb promete una resolución más rápida de incidentes. ¿Podrías describir cómo la integración de registros, métricas y trazas en un tipo de datos unificado ayuda en la depuración y resolución de problemas más rápidas?

Todo está conectado. No tienes que adivinar. En lugar de mirar que este panel de control parece tener la misma forma que ese panel de control, o adivinar que este pico en tus métricas debe ser el mismo que este pico en tus registros en función de las marcas de tiempo… en lugar de eso, los datos están todos conectados. No tienes que adivinar, simplemente puedes preguntar.

Los datos se vuelven valiosos por el contexto. La última generación de herramientas funcionaba eliminando todo el contexto en el momento de la escritura; una vez que has descartado el contexto, nunca puedes recuperarlo.

Además: con registros y métricas, tienes que saber lo que estás buscando antes de que puedas encontrarlo. Eso no es cierto de la observabilidad moderna. No tienes que saber nada, o buscar nada.

Cuando estás almacenando estos datos contextuales ricos, puedes hacer cosas con ellos que parecen mágicas. Tenemos una herramienta llamada BubbleUp, donde puedes dibujar una burbuja alrededor de cualquier cosa que creas que sea extraña o que podría ser interesante, y calculamos todas las dimensiones dentro de la burbuja versus fuera de la burbuja, la línea de base, y las ordenamos y las diferenciamos. Así que estás como “esta burbuja es extraña” y te decimos inmediatamente “es diferente en xyz maneras”. Mucha depuración se reduce a “aquí hay algo que me importa, pero ¿por qué me importa?” Cuando puedes identificar inmediatamente que es diferente porque estas solicitudes provienen de dispositivos Android, con este ID de compilación particular, utilizando este paquete de idioma, en esta región, con este ID de aplicación, con una carga útil grande… para ahora probablemente ya sabes exactamente qué está mal y por qué.

No se trata solo de los datos unificados, aunque eso es una gran parte de ello. También se trata de cómo manejamos los datos de alta cardinalidad de manera tan fluida, como IDs únicos, IDs de carrito de compras, IDs de aplicación, nombres y apellidos, etc. La última generación de herramientas no puede manejar datos ricos como ese, lo que es bastante increíble cuando lo piensas, porque los datos ricos y de alta cardinalidad son los más valiosos e identificativos de todos.

¿Cómo se traduce la mejora de la observabilidad en mejores resultados comerciales?

Esta es una de las otras grandes transiciones desde la generación anterior de herramientas de observabilidad hasta la nueva. En el pasado, los sistemas, las aplicaciones y los datos comerciales estaban todos aislados en herramientas diferentes. Esto es absurdo — cada pregunta interesante que quieras hacer sobre los sistemas modernos tiene elementos de todos ellos.

La observabilidad no se trata solo de errores, o de tiempo de inactividad, o de interrupciones. Se trata de asegurarse de que estamos trabajando en las cosas correctas, de que nuestros usuarios están teniendo una gran experiencia, de que estamos logrando los resultados comerciales que nos proponemos. Se trata de construir valor, no solo de operar. Si no puedes ver hacia dónde vas, no puedes moverte muy rápido y no puedes corregir el rumbo muy rápido. Cuanto más visibilidad tengas en lo que están haciendo tus usuarios con tu código, mejor y más fuerte ingeniero puedes ser.

¿Hacia dónde crees que se dirige el futuro de la observabilidad, especialmente en lo que respecta a los desarrollos de la IA?

La observabilidad es cada vez más sobre permitir que los equipos conecten bucles de retroalimentación ajustados y rápidos, para que puedan desarrollar rápidamente, con confianza, en producción, y desperdiciar menos tiempo y energía.

Se trata de conectar los puntos entre los resultados comerciales y los métodos tecnológicos.

Y se trata de asegurarse de que entendemos el software que estamos poniendo en el mundo. A medida que el software y los sistemas se vuelven cada vez más complejos, y especialmente a medida que la IA se vuelve cada vez más parte de la mezcla, es más importante que nunca que nos mantengamos a nosotros mismos a un estándar humano de comprensión y gestión.

Desde una perspectiva de observabilidad, veremos niveles crecientes de sofisticación en la canalización de datos — utilizando técnicas de aprendizaje automático y muestreo sofisticadas para equilibrar el valor versus el costo, para mantener la mayor cantidad de detalles posible sobre eventos fuera de lo común y eventos importantes, y almacenar resúmenes del resto de manera tan económica como sea posible.

Los vendedores de IA están haciendo muchas afirmaciones exageradas sobre cómo pueden entender tu software mejor que tú, o cómo pueden procesar los datos y decirles a tus humanos qué acciones tomar. Desde todo lo que he visto, esto es un sueño caro. Los falsos positivos son increíblemente costosos. No hay sustituto para entender tus sistemas y tus datos. La IA puede ayudar a tus ingenieros con esto. Pero no puede reemplazar a tus ingenieros.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Honeycomb.