Charity Majors, CTO & Co-Founder bij Honeycomb – Interview Serie

Charity is een ops-engineer en toevallig startup-oprichter bij Honeycomb. Voordat ze hier werkte, werkte ze bij Parse, Facebook (META ) en Linden Lab aan infrastructuur en ontwikkelaarstools, en kwam ze altijd terecht bij het beheren 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 eerder gewerkt aan een groot bedrijf, maar we werden overgenomen door Facebook. Een van mijn belangrijkste inzichten was dat overnames echt heel moeilijk zijn, zelfs in de beste omstandigheden. Het advies dat ik altijd geef aan andere oprichters, is dit: als je overgenomen gaat worden, zorg er dan voor dat je een executive sponsor hebt, en denk goed na over of je strategische uitlijning hebt. Facebook nam Instagram niet lang voor Parse over, en de overname van Instagram was niet zonder problemen, maar het was 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 geleerd heb over organisatiestructuur, management, strategie, enz. Het gaf me ook een reputatie die me aantrekkelijk maakte voor venture capitalists, die me voorheen nooit de tijd van de dag hadden gegeven. Ik ben een beetje chagrijnig over dit, maar ik zal het toch nemen.

Kunt u het verhaal achter de lancering van Honeycomb delen?

Zeker. Vanuit een architectonisch oogpunt was Parse zijn tijd ver vooruit — we gebruikten microservices voordat er microservices waren, we hadden een enorm gesegmenteerd datalayer, en als platform dat meer dan een miljoen mobiele apps bediende, hadden we veel echt ingewikkelde multi-tenantproblemen. Onze klanten waren ontwikkelaars, en ze schreven en uploaden constant willekeurige codefragmenten en nieuwe queries van, zullen we zeggen, “wisselende kwaliteit” — en we moesten het allemaal binnenlaten en laten werken, op de een of andere manier.

We waren aan de vooravond van een aantal veranderingen die sindsdien mainstream zijn geworden. Het was vroeger zo dat de meeste architectuur vrij simpel was, en dat ze op voorspelbare manieren faalden. Je had een weblaag, 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 metrics en monitoringgegevens.

Deze industrie heeft de afgelopen 10 jaar een explosie van architectonische complexiteit gezien. We hebben de monoliet opgeblazen, dus nu heb je overal van een paar services tot duizenden applicatiemicroservices. Polyglot persistence is de norm; in plaats van “de database” is het normaal om veel verschillende opslagtypen te hebben, evenals horizontale sharding, lagen van caching, db-per-microservice, queueing en meer. Bovenop dat alles heb je server-side gehoste containers, derdepartijdiensten en -platforms, 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 code die je moet debuggen. In plaats van 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.

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 ons liet snijden en hakken op willekeurige dimensies en high cardinality data in real-time, en de tijd die het ons kostte om deze problemen van scratch te identificeren en op te lossen, daalde als een steen, van uren naar… minuten? seconden? Het was geen engineeringprobleem meer, het was een supportprobleem. Je kon gewoon de trail van breadcrumbs naar het antwoord volgen, elke keer, klik-klik-klik.

Het was verbluffend. Deze enorme bron van onzekerheid en arbeid en ongelukkige klanten en 2 uur ‘s nachts pages… ging gewoon weg. Het was niet tot ons doorgedrongen hoeveel het onze manier van interactie met software had veranderd, totdat Christine en ik Facebook verlieten. Het idee om terug te gaan naar de slechte oude dagen van monitoringcontroles 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 enorme multitenant-platforms zouden kunnen hebben. Het was niet tot we bijna een jaar hadden gebouwd dat we begonnen te beseffen dat, oh wow, dit wordt eigenlijk een iedereen-probleem.

Voor lezers die hier niet bekend mee zijn, wat is specifiek een observability-platform en hoe verschilt het van traditionele monitoring en metrics?

Traditionele monitoring heeft drie zuilen: 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 dingen, probeer je 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 stuksgewijs, en meestal verwijzen deze tools naar problemen — 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 spoor, je kunt snijden en hakken, je kunt inzoomen op individuele aanvragen en uitzoomen naar het lange uitzicht. Omdat alles verbonden is, hoef je niet van tool naar tool te springen, gokken of vertrouwen op intuïtie. Moderne observability gaat niet alleen over hoe je je systemen bedient, maar ook over hoe je je code ontwikkelt. Het is de ondergrond die krachtige, strakke feedbackloops mogelijk maakt die je helpen om veel waarde aan 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 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 is aan het verliezen van zijn effectiviteit naarmate de complexiteit in onze systemen toeneemt 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-driven development, of ODD, waarbij je instrumenteert terwijl je gaat, snel implementeert, en dan naar je code in productie kijkt door de lens van de instrumentatie die je net hebt geschreven, en jezelf afvraagt: “doet het wat ik verwacht dat het doet, en ziet er iets anders… vreemd 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 in productie hebt gezien, met echte gebruikers op echte infrastructuur.

Deze ontwikkelingsmethode — die productie omvat in snelle feedbackloops — is (enigszins tegenintuïtief) veel sneller, gemakkelijker en eenvoudiger dan vertrouwen op tests en langzamere implementatiecycli. 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 LLM’s ontwikkelt, je in productie moet ontwikkelen. De enige manier om een set tests te krijgen is door eerst je code in productie te valideren en terug te werken. Ik denk dat het schrijven van software met LLM’s 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 bezorgdheid 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 het 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 om schoon, iterabel software geeft, zijn instrumentatie en observability absoluut essentieel voor die inspanning. Instrumentatie is als documentatie plus real-time staat rapportage. Instrumentatie is de enige manier om echt te 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 ChatGPT elke dag gebruiken om vragen te beantwoorden en hen te helpen de software te begrijpen die ze bouwen. 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 enorm 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 behulp van de AWS SDK’s en API’s, omdat het getraind is op repos met echte gebruikers van die code.

Maar elke keer dat je AI laat genereren, moet je het regel voor regel doorlopen om te controleren of het de juiste dingen doet, omdat het absoluut rommel zal hallucineren.

Kunt u voorbeelden geven van hoe AI-geactiveerde functies zoals uw queryassistent of Slack-integratie teamcollaboratie verbeteren?

Ja, zeker. Onze queryassistent is een geweldig voorbeeld. Het gebruik van querybuilders 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 zijn. En zelfs power users vergeten de details van hoe ze bepaalde soorten grafieken kunnen genereren.

Dus onze queryassistent laat je vragen stellen met behulp van natuurlijke taal. Bijvoorbeeld, “wat zijn de langzaamste eindpunten?”, of “wat gebeurde er na mijn laatste implementatie?” 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 te bewerken, dus het geeft je een voorsprong.

Honeycomb belooft snellere oplossing van incidenten. Kunt u uitleggen hoe de integratie van logs, metrics en traces in een unified data type helpt bij snellere debugging en probleemoplossing?

Alles is verbonden. Je hoeft niet te gokken. In plaats van naar een dashboard te kijken dat eruitziet als hetzelfde als een ander dashboard, of te gokken dat een piek in je metrics hetzelfde is als een 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 is waardevol gemaakt door context. De vorige generatie tooling werkte door alle context weg te halen bij het schrijven; eenmaal je de context hebt weggegooid, kun je die nooit meer terugkrijgen.

En ook: met logs en metrics moet je weten waar je naar zoekt voordat je het kunt vinden. Dat is niet waar van moderne observability. Je hoeft niets te weten, of 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 bubbel rond alles kunt trekken wat je vreemd of interessant vindt, en we berekenen alle dimensies binnen de bubbel versus buiten de bubbel, de baseline, en sorteren en diffen ze. Dus je bent als “deze bubbel is vreemd” en we vertellen je onmiddellijk, “het is anders op xyz manieren”. Zo veel debugging komt neer op “hier is iets waar ik me zorgen over maak, maar waarom maak ik me daar zorgen over?” Wanneer je onmiddellijk kunt identificeren dat het anders is omdat deze aanvragen 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 is niet alleen over het unified data, trouwens — hoewel dat een groot deel ervan is. Het is ook over hoe moeiteloos we high cardinality data aanpakken, zoals unieke id’s, winkelwagen-id’s, app-id’s, 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 systemen, 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 behalen 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 koers corrigeren. Hoe meer zicht je hebt op wat je gebruikers met je code doen, hoe beter en sterker een engineer je kunt zijn.

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

Observability is steeds meer over het mogelijk maken van teams om strakke, snelle feedbackloops te koppelen, 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 nu AI steeds meer in het spel komt, is het meer dan ooit belangrijk dat we onszelf houden aan een menselijke standaard van begrijpelijkheid en beheersbaarheid.

Vanuit een observability-perspectief zullen we een toenemend niveau van sofisticatie zien in de datapipeline — met behulp van machine learning en geavanceerde samplingtechnieken om waarde versus kosten in evenwicht te brengen, om zoveel mogelijk detail te behouden over outlier-gebeurtenissen en belangrijke gebeurtenissen, en samenvattingen van de rest op te slaan tegen zo laag mogelijke kosten.

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 welke acties je moet ondernemen. Van alles wat ik heb gezien, is dit een dure droom. Valse positieven zijn ontzettend kostbaar. 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, moeten Honeycomb bezoeken Honeycomb.