Charity Majors, CTO y Co-Fundadora de Honeycomb – Serie de Entrevistas

Charity es una ingeniera de operaciones y fundadora accidental de Honeycomb. Antes de esto, trabajó en Parse, Facebook 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 escocés de malta.

Usted fue la Gerente de Ingeniería de Producción en Facebook (ahora Meta) durante más de 2 años, ¿cuáles fueron algunos de los aspectos destacados de este período y cuáles son algunas de las conclusiones clave que sacó 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 fuimos adquiridas por Facebook. Una de las conclusiones clave que saqué 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 camino de rosas, pero al final fue muy exitosa porque tenían alineación estratégica y un patrocinador sólido.

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 inversionistas 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ía 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 multiarrendamiento complicados. Nuestros clientes eran desarrolladores, y estaban constantemente escribiendo y subiendo fragmentos de código arbitrarios 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 manera predecible. Tenías una capa web, una aplicación y una base de datos, y la mayoría de la complejidad estaba ligada a tu código de aplicación. Así que escribías controles de monitoreo para vigilar 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 tipos de almacenamiento diferentes, así como fragmentación horizontal, capas de caché, db-per-microservicio, cola y más. Además, tienes contenedores alojados en el servidor, servicios y plataformas de terceros, código sin servidor, almacenamiento de bloques 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 manera predecible, 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.

Ese era el estado en el que estábamos en Parse, en Facebook. Todos los días, toda la plataforma se iba abajo, y cada vez era algo diferente y nuevo; una aplicación diferente que llegaba a los primeros 10 en iTunes, un desarrollador diferente que subía una consulta mala.

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 a 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! segundos! Ya no era un problema de ingeniería, era un problema de soporte. Podías seguir el rastro de migas de pan 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… se esfumó. No fue hasta que Christine y yo dejamos Facebook que nos dimos cuenta de cuánto había transformado la forma en que interactuábamos con el software. La idea de regresar a los malos viejos días de controles de monitoreo y paneles de control era simplemente impensable.

¿Podría explicar a 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 famosos: métricas, registros y trazas. Por lo general, necesitas comprar muchas herramientas para satisfacer tus necesidades: registro, seguimiento, APM, RUM, panel de control, visualización, etc. Cada una de estas herramientas está optimizada para un caso de uso diferente en un formato diferente. Como ingeniero, te sientas en el medio de todas estas herramientas, 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 por lo general se refiere a estas herramientas cuando tienes un problema — están diseñadas para ayudarte a operar tu código y encontrar errores y fallas.

La observabilidad moderna tiene una sola fuente de verdad; eventos de registro 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 general. 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 poderosas y estrechas bucles de retroalimentación 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.

¿Es conocida por creer que la observabilidad ofrece una sola fuente de verdad 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 irte volando por la autopista. El desarrollo dirigido por pruebas (TDD) revolucionó el software a principios de la década de 2000, pero el TDD ha ido perdiendo eficacia a medida que la complejidad se ha ido ubicando en nuestros sistemas en lugar de solo en nuestro software. Cada vez más, si quieres obtener los beneficios asociados con el TDD, en realidad necesitas instrumentar tu código y realizar algo similar al desarrollo de 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 esperaba que hiciera y hay algo más que parezca… raro?”

Las pruebas solas no son suficientes para confirmar que tu código está haciendo lo que se supone que debe hacer. No sabes que hasta que has visto cómo se cocina 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, fácil y simple que confiar en pruebas y ciclos de despliegue más lentos. Una vez que los desarrolladores han probado trabajar de esta manera, son famosos por no querer regresar al lento y viejo modo 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 en que puedes 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 arrastra a los ingenieros pataleando y gritando hacia una mejor forma de vida.

Ha expresado preocupación por la deuda técnica creciente debido a la revolución de la IA. ¿Podría 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 empiezas a lanzar código a producción porque se compila o pasa pruebas, estás creando un iceberg masivo de problemas técnicos futuros 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 en que realmente puedes confirmar que tu software está haciendo lo que esperas que haga y se está comportando de la manera que 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 buenos y utilizables de cosas usando los SDK de AWS y las API, 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 definitivamente inventará basura con regularidad.

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

Sí, por supuesto. Nuestro asistente de consulta 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 tu telemetría, 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 consulta 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 deja dentro de ella. La mayoría de las personas encuentran 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ía 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 basado en marcas de tiempo… en lugar de eso, los datos están todos conectados. No tienes que adivinar, puedes simplemente preguntar.

Los datos se vuelven valiosos gracias al 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 almacenarás estos ricos datos contextuales, 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 es extraña o 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 diferenciamos. Así que estás como “esta burbuja es extraña” y te decimos inmediatamente “es diferente en xyz maneras”. Tanta 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 esta ID de aplicación, con una carga útil grande… por ahora probablemente sabes exactamente qué está mal y por qué.

No se trata solo del dato unificado, aunque eso es una parte enorme de ello. También se trata de cómo manejamos la alta cardinalidad de datos 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?

Esto es uno de los otros grandes cambios desde la última generación de herramientas de observabilidad hasta la nueva. En el pasado, los sistemas, la aplicación y los datos comerciales estaban todos aislados en herramientas diferentes. Esto es absurdo — cada pregunta interesante que quieras hacer sobre 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 estemos trabajando en las cosas correctas, de que nuestros usuarios tengan una gran experiencia, de que estemos 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 curso muy rápido. Cuanto más visibilidad tengas sobre lo que tus usuarios están haciendo con tu código, mejor y más fuerte ingeniero puedes ser.

¿Hacia dónde ve 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 rápidos y estrechos, para que puedan desarrollar con confianza y rapidez 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 entendamos 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 va incorporando cada vez más, es más importante que nunca que nos hagamos responsables de un estándar humano de comprensión y administración.

Desde la perspectiva de la observabilidad, veremos niveles crecientes de sofisticación en la canalización de datos — utilizando el aprendizaje automático y técnicas de muestreo sofisticadas para equilibrar el valor con el costo, para mantener tanto detalle como sea posible sobre eventos atípicos 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 deben visitar Honeycomb.