Bier

"Tun Sie, was Ihr Bier besser schmecken lässt": In die Anwendungsleistung investieren, wenn es darauf ankommt

Apr 3, 2023 Mark Thomas

Jeff Bezos hielt 2008 eine berühmte Grundsatzrede auf der Y Combinator Startup School. Damals lag die Marktkapitalisierung von Amazon bei 22 Milliarden Dollar. Respektabel, sicherlich. Aber es war nur ein winziger Bruchteil des Billionen-Dollar-Giganten, zu dem Amazon später werden sollte. In seiner Präsentation vor den Startup-Hoffnungen forderte Bezos sein Publikum auf, "das zu tun, was Ihr Bier besser schmecken lässt".

Der Hintergrund? Bezos sprach über europäische Bierbrauereien im 20. Jahrhundert. Jahrhundert, die, wie viele andere Unternehmen zu dieser Zeit, die Elektrizität als neue Technologie einführten. Die ersten Brauereien, die Strom nutzten, mussten ihre eigenen Stromgeneratoren bauen, was arbeits- und kapitalintensiv war. Die Brauereien konnten die Elektrizität nutzen, um neue Werkzeuge und Maschinen anzutreiben, aber das war mit hohen Kosten verbunden.

Das änderte sich mit der nächsten Generation von Brauereien. Anstatt eigene Stromerzeugungsanlagen zu bauen, mieteten sie einfach Strom von Versorgungsunternehmen, was billiger und effizienter war. Infolgedessen verdrängten diese Brauereien die erste Generation, die ihre eigenen Stromgeneratoren gebaut hatte.

Bezos argumentierte, dass diese Lektion auch für Unternehmen heute gilt. Sie sollten sich auf das konzentrieren, was ein Unternehmen von anderen unterscheidet, und sich nicht von dem ablenken lassen, was es nicht tut. Kurz gesagt: "Konzentriere dich auf das, was dein Bier besser schmecken lässt". Im Jahr 2023 können wir mit ziemlicher Sicherheit sagen, dass es für Amazon jedenfalls gut genug funktioniert zu haben scheint.

Das Gebräu bearbeiten

Wir hier bei FloQast sind weder ein Bierunternehmen noch ein Amazon-Riese. Aber wir sind sicherlich ein benutzerorientiertes Unternehmen, das versucht hat, Bezos' Rat zu folgen und sich auf "unser Bier" zu konzentrieren. Wir haben versucht, dies auf verschiedene Weise in unserer Organisation zu tun:

  • Technik & Produkt: Wir entscheiden uns für "kaufen" statt "bauen", wenn es sinnvoll ist, und investieren sorgfältig und bewusst, wenn es nicht sinnvoll ist. Zum Beispiel betreiben wir unsere Infrastruktur auf AWS (lustigerweise das moderne Cloud-Äquivalent zu den alten Stromversorgern), investieren aber stark in technische Produktivität und Tools.
  • Erfolg / Unterstützung: Anstatt einen allgemeinen Supportdienst auszulagern, sollten Sie sich darauf konzentrieren, fantastische Mitarbeiter mit fundierten Buchhaltungskenntnissen und -erfahrungen einzustellen.
  • Gestaltung: Zu Beginn haben wir uns auf eine allgemeine Design-Bibliothek (Ye Old Bootstrap) verlassen und unsere eigene entwickelt, als es mehr Sinn machte

Wir haben das natürlich nicht immer perfekt gemacht, aber die starke Konzentration auf die Bedürfnisse der Nutzer und die Differenzierung des Unternehmens hat sich im Großen und Ganzen für uns bewährt. Wenn wir auf unsere Vergangenheit zurückblicken, können wir mit Sicherheit sagen, dass die Zeiten, in denen wir am meisten zu kämpfen hatten, die waren, in denen wir diesen Fokus verloren und uns im Unkraut verirrt haben, indem wir dachten: "Vielleicht baue ich nur eine Batterie selbst und nicht die ganze Anlage."

In Leistung investieren, wenn es darauf ankommt

Eine unerbittliche Konzentration auf Differenzierung ist nicht unbedingt einfach, auch wenn sie wichtig ist. Die Abwägungen zwischen "Build"- und "Buy"-Entscheidungen können sehr nuanciert sein. Sich ausschließlich auf eine Seite zu konzentrieren, kann gefährlich sein, insbesondere für eine technische Organisation. Letztendlich werden Sie sich mit der Beibehaltung von maßgeschneiderten Lösungen ("alles selbst bauen") begnügen oder nicht in der Lage sein, differenzierte Kundenanforderungen zu erfüllen ("alles kaufen"). Sie müssen sich auch über das Spektrum der Kompromisse im Klaren sein - wenn Sie so schnell wie möglich vorankommen, kann es auch schwierig werden, Funktionen zu liefern und Ihr Produkt weiterzuentwickeln.

Wir haben kürzlich einige Erfahrungen mit diesem Bereich gemacht, und zwar in Form einer schleichenden Leistungsverschlechterung. Wir stellten fest, dass wichtige Latenzmetriken (API-Antwortzeit, UI-Zeit bis zur Interaktivität usw.) im Laufe der Zeit langsam angestiegen waren, bis zu einem Punkt, an dem einige Benutzer dies zu bemerken begannen. Das Bier fing an, ein bisschen zu sehr nach Bud Light zu schmecken.

Also haben wir reagiert. Wir haben uns entschieden, die Dringlichkeit der Leistungsverbesserung zu erhöhen, anstatt das Problem über mehrere Quartale hinweg anzugehen. Wir sind uns bewusst, dass wir uns oft besser differenzieren können, wenn wir uns auf die Vollständigkeit und Korrektheit von Funktionen konzentrieren, anstatt auf Optimierungen. Aber in diesem Fall waren die Verlangsamungen so spürbar, dass sie unseren Kernbereich der Differenzierung beeinträchtigten.

Durch die Schaffung von Dringlichkeit und Fokus konnten wir die Teams befähigen und ihnen ermöglichen, sich direkter auf das Problem zu konzentrieren. Außerdem haben wir das Problem für die gesamte technische Organisation zugänglich gemacht - schließlich ist jeder für die Leistung verantwortlich. Wir konzentrierten uns auf die Verringerung der Latenzzeit unserer Systeme in einigen Schlüsselbereichen:

  • Datenbank:
    • Überprüfen Sie erneut Abfragen, die eine bessere Indizierung erfordern könnten.
    • Umstellung auf eine Lesestrategie, die sekundäre Datenbankknoten gegenüber primären bevorzugt
    • Einführung eines unternehmensweiten Lunch-and-Learn-Programms zur Verbesserung der langfristigen Datenbankkenntnisse
  • API :
    • Zwischenspeicherung: Durch die Zwischenspeicherung bestimmter Netzwerkaufrufe konnte die Netzwerklatenz erheblich verringert werden.
    • Komprimierung: Wir haben festgestellt, dass bestimmte API-Komponenten nicht automatisch die GZIP-Komprimierung verwenden. Durch die Aktivierung dieser Funktion konnten wir die über die Leitung gesendeten Daten um das 10-fache oder mehr reduzieren
  • UI:
    • Verringerung der Größe der FloQast-Kernbibliotheken
    • Reduzierung der HTTP-Wasserfallsequenzen, die die Interaktivität verzögerten
    • Verringerung der Gesamtgröße des FloQast-Client-Codes
    • Untersuchung von Möglichkeiten zur weiteren Entlastung von Skripten Dritter

An den Bemühungen waren fast alle Ingenieurteams von FloQast beteiligt, und unsere Hauptanstrengungen dauerten etwa einen Monat lang. Am Ende konnten wir die Latenzzeit bei allen FloQast-Anwendungen erheblich reduzieren, und in Zukunft sind weitere Verbesserungen zu erwarten.

In die Ferne starren

Wenn wir darüber nachdenken, sind wir ziemlich zufrieden mit dem Gleichgewicht, das wir gefunden haben. Indem wir in die Leistung investieren, wenn es wirklich darauf ankommt, können wir viele der Fallstricke vermeiden, die sich aus den Extremen des Kompromisses zwischen Optimierung und Vollständigkeit der Funktionen ergeben. Es gibt einen riesigen Haufen wertvoller Funktionen, die wir nie auf den Markt gebracht hätten, wenn wir die Leistung jahrelang zu unserem obersten Ziel erklärt hätten. Es gibt _auch_ eine beträchtliche Anzahl von Nutzern, die unsere Produkte nicht verwenden würden, wenn wir es völlig versäumt hätten, über Geschwindigkeit und Leistung nachzudenken. Der Schlüssel ist, sich immer wieder zu fragen: "Schmeckt das Bier dadurch besser?" und sich auf die Freude der Benutzer und die Differenzierung über alles andere zu konzentrieren.

Mark Thomas

Mark ist ein Software-Ingenieur bei FloQast. Er genießt guten Kaffee, ein solides Gif und schöne Systeme.



Zurück zu Blog