Charity Majors, CTO & Co-Founder at Honeycomb – Interview Series

Charity is een ops engineer en toevallig startup oprichter bij Honeycomb. Voordat ze daar werkte, was ze werkzaam bij Parse, Facebook en Linden Lab op het gebied van infrastructuur en ontwikkelaarstools, en belandde ze altijd bij het beheer van databases. Ze is co-auteur van O’Reilly’s Database Reliability Engineering, en houdt van vrijheid van meningsuiting, vrije software en single malt scotch.

U was de Production Engineering Manager bij Facebook (nu Meta) voor meer dan 2 jaar, wat waren enkele van uw highlights uit deze periode en wat zijn enkele van uw belangrijkste inzichten uit deze ervaring?

Ik werkte aan Parse, dat een backend was voor mobiele apps, een soort Heroku voor mobiel. Ik had nooit interesse gehad om voor een groot bedrijf te werken, maar we werden overgenomen door Facebook. Een van mijn belangrijkste inzichten was dat overnames echt heel moeilijk zijn, zelfs in de allerbeste omstandigheden. Het advies dat ik andere oprichters nu altijd geef, is dit: als je overgenomen gaat worden, zorg er dan voor dat je een uitvoerend sponsor hebt, en denk goed na over of je strategische uitlijning hebt. Facebook had ongeveer tegelijkertijd met Parse ook Instagram overgenomen, en de overname van Instagram was niet zonder problemen, maar uiteindelijk heel succesvol omdat ze wel strategische uitlijning hadden en een sterke sponsor.

Ik had het niet gemakkelijk bij Facebook, maar ik ben heel dankbaar voor de tijd die ik daar doorgebracht heb; ik weet niet of ik een bedrijf had kunnen starten zonder de lessen die ik daar geleerd heb over organisatiestructuur, management, strategie, enz. Het gaf me ook een soort van status die me aantrekkelijk maakte voor venture capitalists, die me daarvoor nooit de tijd van de dag hadden gegeven. Ik ben een beetje chagrijnig over dit laatste, maar ik zal het toch maar nemen.

Kunt u het verhaal achter de lancering van Honeycomb delen?

Zeker. Vanuit een architectonisch perspectief was Parse zijn tijd ver vooruit — we gebruikten microservices voordat er microservices waren, we hadden een enorm geshard database-laag, en als platform dat meer dan een miljoen mobiele apps bediende, hadden we heel veel ingewikkelde multi-tenant problemen. Onze klanten waren ontwikkelaars, en die schreven en uploaden constant willekeurige codefragmenten en nieuwe queries van, zullen we zeggen, “wisselende kwaliteit” — en wij moesten het allemaal binnen zien te krijgen en laten werken, op de een of andere manier.

We stonden aan de vooravond van een aantal veranderingen die sindsdien mainstream zijn geworden. Het gebruikelijke architectuurpatroon was vroeger vrij simpel, en dat faalde herhaaldelijk op voorspelbare manieren. Je had meestal een web-laag, een applicatie en een database, en de meeste complexiteit zat in je applicatiecode. Dus schreef je monitoringcontroles om naar die fouten te kijken, en bouwde je statische dashboards voor je metrische en monitoringgegevens.

Deze industrie heeft de afgelopen 10 jaar een explosie van architecturale complexiteit meegemaakt. We hebben de monoliet opgeblazen, dus nu heb je overal van een paar services tot duizenden applicatiemicroservices. Polyglot persistentie is de norm; in plaats van “de database” is het normaal om meerdere opslagtypen te hebben, evenals horizontaal sharding, lagen van caching, db-per-microservice, wachtrijen en meer. Bovenop dat alles heb je server-side hosted containers, diensten en platforms van derden, serverless code, block storage, en meer.

Het moeilijke deel was vroeger het debuggen van je code; nu is het moeilijke deel het vinden van de plek in het systeem waar de code zit die je moet debuggen. In plaats van herhaaldelijk op voorspelbare manieren te falen, is het waarschijnlijker dat elke keer dat je wordt gepaged, het om iets gaat dat je nog nooit eerder hebt gezien en misschien nooit meer zult zien.

Dat was de situatie bij Parse, op Facebook. Elke dag ging het hele platform naar beneden, en elke keer was het om iets anders en nieuws; een andere app die de top 10 op iTunes bereikte, een andere ontwikkelaar die een slechte query uploadde.

Het debuggen van deze problemen van scratch is ontzettend moeilijk. Met logs en metrics moet je eigenlijk al weten waar je naar zoekt voordat je het kunt vinden. Maar we begonnen wat datasets in een FB-tool genaamd Scuba te voeren, dat het ons mogelijk maakte om op willekeurige dimensies en high cardinality data in real-time te snijden en te hakken, en de tijd die het ons kostte om deze problemen van scratch te identificeren en op te lossen, daalde als een rots, van uren naar… minuten? seconden? Het was geen engineeringsprobleem meer, het was een supportprobleem. Je kon gewoon de broodkruimels volgen naar het antwoord, elke keer, klik-klik-klik.

Het was verbluffend. Deze enorme bron van onzekerheid en ellende en ongelukkige klanten en 2 uur ‘s nachts pages… ging gewoon weg. Het was niet tot het moment dat Christine en ik Facebook verlieten dat het tot ons doordrong hoeveel het onze manier van interactie met software had veranderd. Het idee om terug te gaan naar de oude, slechte manier van monitoren en dashboards was gewoon ondenkbaar.

Maar op dat moment dachten we eerlijk gezegd dat dit een niche-oplossing zou zijn — dat het een probleem oploste dat andere grote multitenant-platforms misschien hadden. Het was niet tot we bijna een jaar hadden gebouwd dat we begonnen te beseffen dat, oh wow, dit eigenlijk een iedereen-probleem aan het worden was.

Kunt u voor lezers die onbekend zijn met het onderwerp uitleggen wat een observability-platform precies is en hoe het verschilt van traditionele monitoring en metrics?

Traditionele monitoring heeft beroemde drie pijlers: metrics, logs en traces. Je moet meestal veel tools kopen om aan je behoeften te voldoen: logging, tracing, APM, RUM, dashboarding, visualisatie, enz. Elk van deze is geoptimaliseerd voor een ander gebruiksscenario in een ander formaat. Als engineer zit je in het midden van al deze tools, proberend om er wijs uit te worden. Je bladert door dashboards op zoek naar visuele patronen, je kopieert en plakt IDs van logs naar traces en terug. Het is heel reactief en gefragmenteerd, en meestal verwijzen naar deze tools wanneer je een probleem hebt — ze zijn ontworpen om je te helpen bij het bedienen van je code en het vinden van bugs en fouten.

Moderne observability heeft een enkele bron van waarheid; willekeurig brede, gestructureerde log-gebeurtenissen. Vanuit deze gebeurtenissen kun je je metrics, dashboards en logs afleiden. Je kunt ze visualiseren over tijd als een trace, je kunt snijden en hakken, je kunt inzoomen op individuele requests en uitzoomen naar het bredere beeld. Omdat alles met elkaar verbonden is, hoef je niet van tool naar tool te springen, gokken of intuïtie te gebruiken. Moderne observability gaat niet alleen over hoe je je systemen bedient, het gaat over hoe je je code ontwikkelt. Het is het substraat dat het mogelijk maakt om krachtige, strakke feedback-lussen op te zetten die je helpen om veel waarde voor gebruikers te leveren, met vertrouwen, en problemen te vinden voordat je gebruikers dat doen.

U staat bekend om uw overtuiging dat observability een enkele bron van waarheid biedt in engineeringsomgevingen. Hoe past AI in deze visie, en wat zijn de voordelen en uitdagingen ervan in deze context?

Observability is als het opzetten van je bril voordat je de snelweg op gaat. Test-driven development (TDD) revolutioneerde software in de vroege 2000er jaren, maar TDD verliest zijn effectiviteit naarmate de complexiteit in onze systemen zit in plaats van alleen in onze software. Steeds vaker moet je, als je de voordelen van TDD wilt behalen, je code instrumenteren en iets doen dat lijkt op observability-gedreven ontwikkeling, of ODD, waarbij je instrumenteert terwijl je gaat, snel deployt, en dan naar je code in productie kijkt door de lens van de instrumentatie die je net hebt geschreven en jezelf vraagt: “doet het wat ik verwacht dat het doet, en ziet er iets anders… raar uit?”

Tests alleen zijn niet genoeg om te bevestigen dat je code doet wat het zou moeten doen. Je weet pas of dat zo is als je het hebt zien bakken in productie, met echte gebruikers op echte infrastructuur.

Deze manier van ontwikkelen — die productie omvat in snelle feedback-lussen — is (enigszins tegenintuïtief) veel sneller, gemakkelijker en eenvoudiger dan vertrouwen op tests en langzamere deploy-cycli. Zodra ontwikkelaars op deze manier hebben gewerkt, zijn ze beroemd onwillig om terug te gaan naar de oude, langzame manier van doen.

Wat me opwindt over AI is dat, als je met LLMs ontwikkelt, je in productie moet ontwikkelen. De enige manier waarop je een set tests kunt afleiden, is door eerst je code in productie te valideren en dan terug te werken. Ik denk dat het schrijven van software met LLMs net zo gewoon zal worden als het schrijven van software met MySQL of Postgres in een paar jaar, en mijn hoop is dat dit ontwikkelaars naar een beter leven sleept.

U heeft uw zorgen geuit over de toenemende technische schuld als gevolg van de AI-revolutie. Kunt u uitleggen welke soorten technische schulden AI kan introduceren en hoe Honeycomb helpt bij het beheren of mitigeren van deze schulden?

Ik maak me zorgen over zowel technische schuld als, misschien nog belangrijker, organisatorische schuld. Een van de slechtste soorten technische schuld is wanneer je software hebt die niet goed begrepen wordt door iemand. Wat betekent dat elke keer dat je die code moet uitbreiden of veranderen, of debuggen of repareren, iemand het harde werk moet doen om het te leren.

En als je code in productie zet die niemand begrijpt, is de kans groot dat het niet geschreven is om begrijpelijk te zijn. Goede code is geschreven om gemakkelijk te lezen en te begrijpen en uit te breiden. Het gebruikt conventies en patronen, het gebruikt consistente benaming en modularisatie, het vindt een balans tussen DRY en andere overwegingen. De kwaliteit van code is onlosmakelijk verbonden met hoe gemakkelijk het is voor mensen om er mee om te gaan. Als je code in productie zet die niemand begrijpt, kan Honeycomb daar niet mee helpen. Maar als je wel zorgdraagt om schone, iterable software te schrijven, zijn instrumentatie en observability absoluut essentieel voor die inspanning. Instrumentatie is als documentatie plus real-time statusrapportage. Instrumentatie is de enige manier waarop je echt kunt bevestigen dat je software doet wat je verwacht dat het doet, en zich gedraagt zoals je gebruikers verwachten dat het zich zal gedragen.

Hoe gebruikt Honeycomb AI om de efficiëntie en effectiviteit van engineeringsTeams te verbeteren?

Onze engineers gebruiken AI veel intern, vooral CoPilot. Onze junior engineers melden dat ze elke dag ChatGPT gebruiken om vragen te beantwoorden en hen te helpen de software die ze bouwen te begrijpen. Onze senior engineers zeggen dat het geweldig is voor het genereren van software die zeer saai of vervelend zou zijn om te schrijven, zoals wanneer je een grote YAML-bestand moet invullen. Het is ook handig voor het genereren van codefragmenten in talen die je niet gewoonlijk gebruikt, of van API-documentatie. Je kunt bijvoorbeeld geweldige, bruikbare voorbeelden van dingen genereren met de AWS SDK’s en API’s, omdat het getraind is op repos die echte gebruiken van die code.

Maar elke keer dat je AI laat genereren, moet je het line by line doorlopen om er zeker van te zijn dat het de juiste dingen doet, omdat het absoluut rommel zal hallucineren.

Kunt u voorbeelden geven van hoe AI-gebaseerde functies zoals uw query-assistent of Slack-integratie team-samenwerking verbeteren?

Ja, zeker. Onze query-assistent is een geweldig voorbeeld. Het gebruik van query-bouwers is ingewikkeld en moeilijk, zelfs voor power-users. Als je honderden of duizenden dimensies in je telemetrie hebt, kun je niet altijd onthouden wat de meest waardevolle heten. En zelfs power-users vergeten de details van hoe je bepaalde soorten grafieken genereert.

Dus onze query-assistent laat je vragen stellen met behulp van natuurlijke taal. Bijvoorbeeld, “wat zijn de langzaamste endpoints?”, of “wat gebeurde na mijn laatste deploy?” en het genereert een query en zet je erin. De meeste mensen vinden het moeilijk om een nieuwe query van scratch te maken en gemakkelijk om een bestaande aan te passen, dus het geeft je een voorsprong.

Honeycomb belooft een snellere oplossing van incidenten. Kunt u uitleggen hoe de integratie van logs, metrics en traces in een unified data-type helpt bij het sneller debuggen en oplossen van problemen?

Alles is verbonden. Je hoeft niet te gokken. In plaats van naar dashboards te kijken die eruitzien als hetzelfde patroon, of te gokken dat deze piek in je metrics hetzelfde is als deze piek in je logs op basis van tijdstempels… in plaats daarvan is de data allemaal verbonden. Je hoeft niet te gokken, je kunt gewoon vragen.

Data wordt waardevol gemaakt door context. De vorige generatie tooling werkte door alle context weg te halen bij het schrijven; eenmaal je die context hebt weggegooid, kun je hem nooit meer terugkrijgen.

Ook: met logs en metrics moet je weten waar je naar zoekt voordat je het kunt vinden. Dat is niet waar bij moderne observability. Je hoeft niets te weten, je hoeft niet te zoeken.

Wanneer je deze rijke contextuele data opslaat, kun je dingen doen die als magie aanvoelen. We hebben een tool genaamd BubbleUp, waarbij je een bubble kunt tekenen rond alles wat je vreemd of interessant vindt, en we berekenen alle dimensies binnen de bubble versus buiten de bubble, de baseline, en sorteren en diffen ze. Dus je bent als “deze bubble is vreemd” en we vertellen je meteen, “het is anders op xyz-manieren”. Zo veel debuggen komt neer op “hier is iets waar ik me zorgen over maak, maar waarom maak ik me daar zorgen over?” Wanneer je meteen kunt identificeren dat het anders is omdat deze requests van Android-apparaten komen, met deze specifieke build-ID, met deze taalpakket, in deze regio, met deze app-ID, met een grote payload… tegen die tijd weet je waarschijnlijk al precies wat er mis is en waarom.

Het gaat niet alleen over de unified data, hoewel dat een groot deel ervan is. Het gaat ook over hoe moeiteloos we high cardinality data aanpakken, zoals unieke IDs, winkelwagen-IDs, app-IDs, eerste/laatste namen, enz. De vorige generatie tooling kan deze rijke data niet aan, wat eigenlijk ongelofelijk is als je erover nadenkt, omdat rijke, high cardinality data de meest waardevolle en identificerende data van allemaal is.

Hoe vertaalt het verbeteren van observability zich in betere bedrijfsresultaten?

Dit is een van de andere grote verschuivingen van de vorige generatie naar de nieuwe generatie van observability-tooling. In het verleden waren systeem-, applicatie- en bedrijfsdata allemaal afgescheiden van elkaar in verschillende tools. Dit is absurd — elke interessante vraag die je wilt stellen over moderne systemen heeft elementen van alle drie.

Observability gaat niet alleen over bugs, of downtime, of uitval. Het gaat over ervoor zorgen dat we aan de juiste dingen werken, dat onze gebruikers een geweldige ervaring hebben, dat we de bedrijfsresultaten bereiken die we nastreven. Het gaat over waarde bouwen, niet alleen opereren. Als je niet kunt zien waar je naartoe gaat, kun je niet snel bewegen en kun je niet snel bijsturen. Hoe meer zicht je hebt in wat je gebruikers met je code doen, hoe beter en sterker een engineer je kunt zijn.

Waar ziet u de toekomst van observability naar toe gaan, vooral met betrekking tot AI-ontwikkelingen?

Observability gaat steeds meer over het mogelijk maken van teams om strakke, snelle feedback-lussen op te zetten, zodat ze snel, met vertrouwen, in productie kunnen ontwikkelen, en minder tijd en energie verspillen.

Het gaat over het verbinden van de stippen tussen bedrijfsresultaten en technologische methoden.

En het gaat over ervoor zorgen dat we de software die we de wereld insturen begrijpen. Naarmate software en systemen steeds complexer worden, en vooral als AI steeds meer in het spel komt, is het belangrijker dan ooit dat we onszelf verantwoordelijk houden voor een menselijke standaard van begrijpelijkheid en beheersbaarheid.

Vanuit een observability-perspectief zullen we een toenemend niveau van sofisticatie zien in de data-pipeline — het gebruik van machine learning en geavanceerde sampling-technieken om waarde versus kosten in balans te brengen, om zoveel mogelijk detail over outlier-gebeurtenissen en belangrijke gebeurtenissen te behouden en samenvattingen van de rest zo goedkoop mogelijk op te slaan.

AI-leveranciers maken veel overdreven claims over hoe ze je software beter kunnen begrijpen dan jij, of hoe ze de data kunnen verwerken en je vertellen wat je moet doen. Van alles wat ik heb gezien, is dit een dure droom. Valse positieven zijn ontzettend duur. Er is geen vervanging voor het begrijpen van je systemen en je data. AI kan je engineers helpen met dit! Maar het kan je engineers niet vervangen.

Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen Honeycomb bezoeken.