Jeremy Burton, CEO af Observe – Interview Serie

Jeremy Burton, CEO af Observe, er en erfaren virksomhedssoftwarechef med over 20 års ledelseserfaring på tværs af store teknologivirksomheder, herunder Dell Technologies (DELL ), EMC, Oracle (ORCL ) og VERITAS. Han har ledet globale hold i produktudvikling, marketing og strategisk M&A, og har bygget og skaleret forretninger inden for lagring, sikkerhed og SaaS. Burton var også med til at co-founde Oracle Technology Network, der voksede til millioner af medlemmer verden over, og sidder i øjeblikket i bestyrelsen for Snowflake og fungerer som rådgiver for McLarens Formel 1-hold.

Observe, der har hjemme i San Mateo, Californien, er en næste generations SaaS-observabilitetsplatform, der hjælper SRE-, DevOps- og ingeniørhold med at undersøge og optimere moderne distribuerede systemer. Bygget på Snowflakes datainfrastruktur, samler den logfiler, målinger og spor i ét enkelt, kontekst rigt dataset – hvilket giver holdene mulighed for at accelerere incidentrespons, identificere rodårsager og forbedre pålideligheden på tværs af komplekse cloud-miljøer.

Du har haft seniort ledelsesroller i globale kæmper som Dell, EMC og Oracle, og nu leder du en startup med Observe. Hvad motiverede dig til at forlade stabilitet og skala for at springe ud i at bygge noget fra bunden?

Jeg har været heldig i min karriere med at arbejde for nogle utrolige ledere, herunder Larry Ellison og Michael Dell. Jeg arbejdede med dem 20 eller 30 år inde i deres embedsperiode, men det, der gør dem bemærkelsesværdige, er, at de var der fra begyndelsen. De traf de tidlige produktbeslutninger, etablerede ruterne til markedet og fastsatte en kultur for langsigtede succes. Min rolle var at give inkrementelle forbedringer oven på de årtier af hårdt arbejde, de allerede havde gjort. Til sidst nåede jeg et punkt i min karriere, hvor jeg ville bevise for mig selv, at jeg også kunne bygge en virksomhed, tage et produkt til markedsgennemslag, etablere en salgsbevægelse og skabe en kultur, som jeg troede kunne trives over lang tid.

Observe positionerer sig selv som en ny kategori inden for observabilitet, der integrerer logfiler, analyser og overvågning i ét enkelt, samlet platform. Hvordan ser du, at denne tilgang gendefinerer rummet i forhold til legacy-spillere som Splunk og Datadog (DDOG )?

Det store problem, der møder legacy-værktøjer, er, at de ikke er bygget til skala. I samtaler med kunder har vi set gang på gang, at Splunk og Datadog bliver omkostningskrævende, når volumenet af telemetri vokser, og det er grundlæggende et problem med, hvordan legacy-værktøjer er arkitekteret.

Observe adskiller sig ved, at vores platform er bygget på en streaming data lake-arkitektur med åbne formater som Apache Iceberg. Det betyder, at vi kan frakoble beregning fra lagring, skalerer elastisk og levere observabilitet til en brøkdel af omkostningerne ved traditionelle systemer. Konkurrenter som Splunk afhænger stadig af monolitiske arkitekturer, der kræver planlægning af peak-kapacitet – og selv nye værktøjer som Datadog kræver data-niveauer, genopfyldning og genindexering for at holde omkostningerne under kontrol.

Vi fokuserer også på en samlet observabilitetsoplevelse. Logfiler, målinger, spor og begivenheder lever alle på ét sted, med ét enkelt forespørgselssprog og en viden graf, der automatisk kortlægger relationer mellem tjenester, brugere og begivenheder. Den kontekst er, hvad der gør fejlfinding hurtigere. I modsætning hertil har Splunk og Datadog separate backender til logfiler, målinger og spor, hvilket fører til langsommere analyser.

Til sidst har vi investeret massivt i AI-drevet fejlfinding. Vores O11y AI SRE kan tage imod naturlig sprogindtastning, generere hypoteser og guide ingeniører gennem incidentløsning, ikke kun alarmering. Og det er bygget til at udnytte vores viden graf, der giver den nødvendige kontekst for præcis fejlfinding. Det er et skridt beyond anomaly detection eller alarmering, som de fleste konkurrenter tilbyder i dag.

Med andre ord: Vi er omkostningseffektive, vi er samlede, og vi er åbne. Disse tre egenskaber er, hvad kunder konsekvent fortæller os, adskiller Observe fra legacy-spillere som Splunk og nyere etablerede som Datadog.

Du har overværet milliard-dollar-operationer og leder nu en startup. Hvordan overfører du erfaringer om effektivitet, agility eller innovation fra store virksomheder – og hvad gør du ikke?

Det er modsat, hvad man skulle tro, men succesfulde store virksomheder gør et lille antal ting rigtig godt, og de forstår hvert enkelt detalje. De, der flåder, gør for meget, og alt degenererer til middelmådighed.

I en startup fokuserer du på ét ting ad gangen og besætter dig med hvert enkelt detalje. Der er ikke nok finansiering til at gøre mere end det. Som følge heraf er det, der gør startups så intense, at du kan gå konkurs, hvis du ikke kan løse problemerne hurtigt nok. Derfor må du træffe beslutninger hurtigere, frigive hurtigere, fejle hurtigere og lære hurtigere. Oven i det hele må du gøre alt det med færre mennesker.

Alligevel er den mest befriende aspekt af en startup, at du ikke har en etableret produkt, forretningsmodel eller rute til markedet. Det betyder, at du har frie tøjler til at træffe nye antagelser om alle disse ting. Det er ikke tilfældet i en stor virksomhed. For eksempel kan du ikke bryde forretningsmodellen med et nyt disruptivt produkt. Selv om du teknisk set kunne bygge det, ville CFO’en og Wall Street ikke lade dig maksimere dets potentiale. Det er derfor, startups ofte vinder, selv om de teoretisk set ikke skulle have nogen chance.

Du har også været bestyrelsesmedlem i Snowflake i næsten et årti. Hvad har du lært af Snowflakes rejse, der informerer din strategi i Observe?

Snowflake angreb et gammelt problem med en ny arkitektur. De byggede deres teknologi på en enkel, men kraftfuld idé, og disruptede et massivt marked, der var bogstaveligt talt fastlåst af legacy-leverandører. Der er to lektioner her: Spil i markeder, der er massive, og du kan bygge en massiv virksomhed. Desuden må du have en radikalt anderledes tilgang end de etablerede spillere, så kunden kan se enorme fordele ved at flytte.

Observabilitetsmarkedet, vi angriber, er massivt, $30 mia. og voksende. Vi har løst observabilitetsproblemet på en meget unik måde: Ved at udnytte en data lake-fundament, elastisk beregning og åbne formater. Det lover at give kunderne en orden af størrelse forbedring i både fejlfindingshastighed og samlede omkostninger.

Du har været dybt involveret i produktudvikling, marketing og storstilet M&A. Hvordan påvirker det din prioritering af vækststrategier i Observe?

I de tidlige dage af en startup er det ret enkelt: Du bygger et fantastisk produkt og prøver at sælge det. Det er vækststrategien. Det siges, at min karriere er ret ensidigt rettet mod virksomhedssoftware og løsning af komplekse problemer for store virksomheder, så det er måske ikke overraskende, at Observe er fokuseret lige præcis på det!

Basert på min erfaring tror jeg, at for at bygge en stor observabilitetsvirksomhed, må du løse problemet for de største virksomheder i verden. Det er problemet med petabyte-data, tusindvis af brugere og tusindvis af applikationer. Der er mange observabilitetsvirksomheder, men kun få kan vinde i den verden, og jeg sikrer mig, at Observe kan.

Observabilitet er blevet kritisk, da moderne distribuerede applikationer bliver mere komplekse. Hvor ser du de største udfordringer og muligheder for virksomheder i de næste 3-5 år?

Den største udfordring i dag er skala. Kubernetes, mikrotjenester og nu AI-arbejdsbelastninger producerer data-volumener, der overvælder traditionelle værktøjer. Pålideligheden af disse værktøjer falder, når omkostningerne stiger, og det er simpelthen ikke bæredygtigt; en ny arkitektur er nødvendig.

For at gøre sagen værre vil vi i de næste par år se mere kode skrevet, hjulpet af AI-kodningsværktøjer, end på noget tidspunkt i historien. Den kode er ikke perfekt, og på et tidspunkt vil den fejle. Området for vækst ligger i at spørge sig selv: Hvordan fejlfinder du kode, som ingen skrev? Og/eller, mens kodningsværktøjer kan se på kode og fikse fejl, kan de virkelig se, hvordan applikationen opfører sig i produktion og finde den problematiske kode? Det er en massiv mulighed for observabilitetsleverandører i fremtiden.

Mange hold kæmper med værktøjs-sprawl, hvor de bruger separate systemer til logfiler, målinger og spor. Hvordan hjælper Observe med at forenkle den oplevelse for ingeniør- og DevOps-hold i praksis?

I stedet for at jonglere med tre eller fire værktøjer giver Observe kunderne en enkelt platform at bruge. En virksomheds logfiler, målinger, spor og alarmer lever alle i samme system og er forbundet med en viden graf. Viden grafen giver brugerne kontekst, der giver mulighed for at bore og svinge uhindret på tværs af logfiler, målinger og spor for at accelerere fejlfinding. Det reducerer den tid, de har brug for at tilbringe med at hoppe fra platform til platform, og giver dem i stedet mulighed for at afsløre et problem uden data-eksport eller kontekstskift.

Kan du dele et konkrekt eksempel på, hvordan Observe har hjulpet en kunde med at løse et stort problem – noget, der ville have været svært eller umuligt med traditionelle observabilitetsværktøjer?

Capital One bruger Observe til at fremhæve statussen for kritiske kunderejser ved at korrelerer og berige telemetri-data med relevant forretningskontekst. De indtager hundredvis af terabyte telemetri pr. dag, herunder logfiler, målinger, spor, ændringsposter, VPC-flow-logs og AWS-konfigurationsdata. Observe giver Capital One en samlet platform til end-to-end-observabilitet, så udviklere og SRE’er kan udføre interaktiv incidentrespons og fejlfinding.

Hvad er rollen for maskinlæring eller AI bag scenen i Observe, og hvordan hjælper det kunder med at fremhæve indsigt hurtigere eller automatisk at opdage problemer?

Maskinlæring har en broget historie i observabilitet, fordi virksomheds-miljøer er indrengende støjende, og det er meget svært at producere en model, der ikke resulterer i tusindvis af anomalier. Generativ AI er en meget anden teknologi og vil have en langt mere gennemgående indvirkning.

Vi tror, at AI vil ændre måden, ingeniører interagerer med observabilitetsværktøjer på. Først og fremmest vil de kunne tale direkte med deres observabilitetsdata i naturligt sprog, mens de sidder i deres IDE, og halvdelen af vores brugere i fremtiden måske aldrig logger ind eller lærer Observe! Anden, AI-agenter vil være til stede under “fredstid” for at scanne telemetri og lede efter potentielle problemer, der måske vil resultere i en incident. AI-agenter bliver ikke trætte eller kede af det og kan udføre arbejde, som mennesker simpelthen er ude af stand til at gøre. Til sidst vil AI-agenter under “krigstid” hjælpe ingeniører og SRE’er med den kurs, de skal følge for at løse problemet.

Din Formel 1-inspirerede ledelsesstil betoner mental styrke og læring fra fejl. Hvordan har den perspektiv påvirket din tilgang til at bygge Observe og lede holdet gennem både sejre og udfordringer?

Success i F1 er avlet ved hjælp af data til at guide fremtidige beslutninger, både for chaufføren og bilen. Når en F1-bil når slutningen af sæsonen, er 90% af delene blevet erstattet, og den er 2 sekunder hurtigere rundt om banen.

I Observe må vi have samme mindset for at lykkes. Vi frigiver, vi måler, vi lytter, vi tilpasser os hurtigt. Jeg forestiller mig, at 90% af vores produkt er anderledes i dag end blot et par år siden. Denne tilgang kræver en masse disciplin og en masse ydmyghed, og det er ikke let at høre dårlige nyheder gang på gang. Alligevel, hvis du handler på tilstrækkelig mange dårlige nyheder, bliver de langsomt til gode nyheder, og ARR accelererer. Det er ikke magi, det er logik!

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Observe.