Stevey's Tirade over de Platformen van Google

Om een kort voorproefje te geven: het wervingsproces van Amazon is fundamenteel gebrekkig omdat teams zelf mensen aannemen; hierdoor is de lat voor aanname ongelooflijk inconsistent tussen de verschillende teams, ondanks diverse pogingen om dit gelijk te trekken. Hun operationele gang van zaken is een chaos; ze hebben geen echte SRE's (Site Reliability Engineers) en laten engineers vrijwel alles doen, waardoor er nauwelijks tijd overblijft voor het programmeren — hoewel dit per groep verschilt. Ze geven geen steek om liefdadigheid, hulp aan behoeftigen of bijdragen aan de gemeenschap. Hun faciliteiten zijn grauwe 'cube farms' zonder dat er een cent is uitgegeven aan decoratie of gemeenschappelijke vergaderruimtes. De betaling en secundaire arbeidsvoorwaarden zijn slecht, al is dat recentelijk verbeterd door lokale concurrentie van Google en Facebook. Maar ze hebben geen van onze extra's; ze proberen enkel de bedragen in het aanbodvoorstel te matchen, en dat is alles. Hun codebase is een ramp, zonder enige engineeringstandaarden, behalve wat individuele teams zelf besluiten in te voeren.

Om eerlijk te zijn hebben ze wel een mooi systeem voor versiebeheer van bibliotheken (versioned-library system) dat we zouden moeten overnemen, en een goed publish-subscribe systeem waar wij geen equivalent voor hebben. Maar voor het grootste deel hebben ze gewoon een verzameling slechte tools die state machine-informatie lezen en schrijven in relationele databases. We zouden het meeste ervan niet eens aannemen als het gratis was.

Ik denk dat het pubsub-systeem en hun library-shelf systeem twee van de in totaal drie dingen zijn die Amazon beter doet dan Google. Je zou kunnen argumenteren dat hun neiging om vroeg te lanceren en razendsnel te itereren ook een sterk punt is, maar daar kun je over discussiëren. Ze prioriteren een vroege lancering boven alles, inclusief retentie en engineeringdiscipline, zaken die op de lange termijn wel degelijk van belang blijken. Hoewel dit hen concurrentievoordeel heeft gegeven op de markt, heeft het genoeg andere problemen veroorzaakt om het minder dan een absolute overwinning te maken.

Er is echter één ding dat ze écht goed doen, wat bijna alle politieke, filosofische en technische blunders compenseert.

Jeff Bezos is een beruchte micromanager. Hij managet elke pixel van de retailsite van Amazon. Hij nam Larry Tesler aan, de Chief Scientist van Apple en waarschijnlijk de meest gerespecteerde expert in mens-computerinteractie ter wereld, om vervolgens drie jaar lang alles wat Larry zei te negeren totdat Larry uiteindelijk — wijzerwijs — het bedrijf verliet. Larry voerde uitgebreide bruikbaarheidsstudies uit en bewees buiten elke twijfel dat niemand die website kon begrijpen, maar Bezos kon die pixels niet loslaten; al die miljoenen betekenisvolle pixels op de landingspagina waren als zijn eigen kostbare kinderen. Dus ze staan er nog steeds, en Larry is weg.

Micromanagement is overigens niet het derde punt dat Amazon beter doet dan wij. Ik bedoel, ja, ze micromanagen heel effectief, maar ik zou het niet als een kracht noemen. Ik schets dit alleen om de context te bieden voor wat er vervolgens gebeurde. We hebben het hier over iemand die op publieke bijeenkomsten serieus heeft beweerd dat mensen hém zouden moeten betalen om bij Amazon te werken. Hij deelt kleine gele plaknotities uit met zijn naam erop, om mensen eraan te herinneren "wie het bedrijf runt" wanneer ze het niet met hem eens zijn. De man is een regelrechte... nou ja, Steve Jobs, denk ik. Alleen zonder het gevoel voor mode of design. Bezos is superintelligent, begrijp me niet verkeerd; hij laat gewone controlfreaks simpelweg overkomen als stoned hippies.

Op een dag vaardigde Jeff Bezos een mandaat uit. Dat doet hij constant, en mensen rennen dan als mieren die met een rubberen hamer worden platgeslagen. Maar op één gelegenheid — rond 2002, plus minus een jaar — kwam hij met een mandaat dat zo extreem, zo enorm en zo overweldigend was, dat al zijn andere mandaten in vergelijking ermee leken op ongevraagde bonussen.

Zijn Grote Mandaat luidde ongeveer als volgt:

1. Alle teams zullen vanaf nu hun data en functionaliteit blootstellen via service-interfaces.
2. Teams moeten met elkaar communiceren via deze interfaces.
3. Er is geen andere vorm van interprocescommunicatie toegestaan: geen direct linken, geen directe leesacties van de datastore van een ander team, geen gedeeld-geheugenmodel en absoluut geen achterdeurtjes. De enige toegestane communicatie is via service-interface calls over het netwerk.
4. Het maakt niet uit welke technologie ze gebruiken: HTTP, Corba, Pubsub, custom protocollen — dat is irrelevant. Bezos maakt het niet uit.
5. Alle service-interfaces, zonder uitzondering, moeten vanaf de basis zo worden ontworpen dat ze externaliseerbaar zijn. Dat wil zeggen dat het team moet plannen en ontwerpen om de interface beschikbaar te kunnen stellen aan ontwikkelaars in de buitenwereld. Geen uitzonderingen.
6. Iedereen die dit niet doet, wordt ontslagen.
7. Bedankt; een fijne dag nog!

(Die laatste is natuurlijk een grapje; Bezos geeft absoluut niets om je dag).

Punt 6 was echter zeer reëel, dus men ging aan de slag. Bezos stelde een paar 'Chief Bulldogs' aan om de inspanningen te overzien en de voortgang te bewaken, onder leiding van Uber-Chief Bear Bulldog Rick Dalzell. Rick is een ex-Army Ranger, West Point Academy graduate, ex-bokser, ex-Chief Torturer/CIO bij Walmart, en een grote, vriendelijke maar angstaanjagende man die het woord "hardened interface" vaak gebruikte. Rick was zelf een wandelende, pratende 'hardened interface', dus overbodig gezegd: iedereen maakte enorme vooruitgang en zorgde dat Rick daarvan op de hoogte was.

In de loop van de volgende coupleuren transformeerde Amazon intern naar een service-georiënteerde architectuur (SOA). Tijdens deze transformatie leerden ze enorm veel. Er bestond al veel documentatie over SOA's, maar op de schaal van Amazon was dat ongeveer zo nuttig als Indiana Jones vertellen dat hij links en rechts moet kijken voordat hij de straat oversteekt. Het development-personeel van Amazon deed onderweg veel ontdekkingen. Een klein voorbeeld hiervan:

• Pager escalation wordt veel moeilijker: een ticket kan door 20 service calls springen voordat de eigenlijke eigenaar is geïdentificeerd. Als elke stap bij een team terechtkomt met een responstijd van 15 minuten, kan het uren duren voordat het juiste team op de hoogte is, tenzij je veel scaffolding, metrics en reporting bouwt.
• Elk peer-team wordt plotseling een potentiële DOS-aanvaller: niemand kan echt vooruitkomen totdat er zeer strikte quota's en throttling zijn ingesteld in elke ownzonderlijke service.
• Monitoring en QA zijn hetzelfde: dat denk je pas wanneer je een grote SOA bouwt. Wanneer je service zegt "oh ja, ik ben oké", kan het best zijn dat het enige dat nog functioneert de kleine component is die weet hoe hij in een vrolijke droid-stem moet zeggen "ik ben oké, roger roger, over and out". Om te weten of de service echt reageert, moet je individuele calls doen. Dit probleem herhaalt zich recursief totdat je monitoring uitgebreide semantische controles uitvoert op al je services en data, waarna het ononderscheidbaar is van geautomatiseerde QA. Het zijn dus twee uiteinden van hetzelfde spectrum.
• Service-discovery mechanisme: als je honderden services hebt en je code MOET communiceren via deze services, dan kun je geen enkele vinden zonder een service-discovery mechanisme. En dat kan niet zonder een service-registratie mechanisme, wat op zijn beurt weer een service is. Amazon heeft daarom een universeel serviceregister waar je programmatisch kunt uitzoeken welke services er zijn, wat hun API's zijn en of ze momenteel up-and-running zijn (en waar).
• Debugging: het oplossen van problemen in de code van iemand anders wordt veel moeilijker, en is basisstelsel onmogelijk tenzij er een universele standaardmanier is om elke service in een debugbare sandbox te draaien.

Dit is slechts een klein voorbeeld. Er zijn tientallen, misschien honderden individuele lessen die Amazon organisch moest ontdekken. Door de organisatie in services onder te verdelen, leerden teams elkaar niet te vertrouwen op dezelfde manier als ze externe ontwikkelaars niet zouden mogen vertrouwen.

Deze inspanning was nog gaande toen ik in het midden van 2005 overstapte naar Google, maar het was al vrij ver gevorderd. Vanaf het moment dat Bezos zijn edict uitvaardigde tot aan mijn vertrek, was Amazon cultureel getransformeerd in een bedrijf dat alles vanuit een 'services-first' perspectief bekijkt. Het is nu fundamenteel voor hoe ze alle ontwerpen benaderen, inclusief interne ontwerpen voor zaken die misschien nooit extern zichtbaar worden.

Tegenwoordig doen ze dit niet eens meer uit angst om ontslagen te worden (al zijn ze dat nog steeds wel, want werken voor de 'Dread Pirate Bezos' is zo'n leven). Ze kiezen voor services omdat ze hebben ingezien dat het de juiste weg is. Er zijn zonder twijfel voor- en nadelen aan de SOA-aanpak, maar over het geheel genomen is het correct omdat SOA-gestuurd ontwerp Platformen mogelijk maakt.

Dat was natuurlijk waar Bezos op doelde met zijn edict. Hij gaf niet om het welzijn van de teams of de technologieën die ze gebruikten; hij realiseerde zich simpelweg veel eerder dan de meeste Amazonians dat Amazon een platform moest worden.

Je zou niet direct denken dat een online boekwinkel een uitbreidbaar, programmeerbaar platform moet zijn, toch? Nou, het eerste grote inzicht van Bezos was dat de infrastructuur die ze hadden gebouwd voor het verkopen en verzenden van boeken getransformeerd kon worden tot een uitstekend herbruikbaar computing-platform. Zo ontstonden Amazon Elastic Compute Cloud (EC2), Amazon Elastic MapReduce (EMR) en de Amazon Relational Database Service (RDS), en een hele reeks andere services op aws.amazon.com. Deze services vormen de backends voor zeer succesvolle bedrijven, waarvan Reddit mijn persoonlijke favoriet is.

Het andere grote inzicht was dat hij niet altijd het juiste product kan bouwen. Ik denk dat Larry Tesler een snaar raakte bij Bezos toen hij zei dat zijn moeder die verdomde website niet kon gebruiken. Het maakt niet uit wiens moeder hij bedoelde, want iemands moeder kan die website simpelweg niet gebruiken. Zelfs ik, die er meer dan vijf jaar werkte, vind de website angstaanjagend overweldigend. Ik heb geleerd mijn ogen een beetje te ontfocussen en me alleen te concentreren op de miljoenen pixels in het midden van de pagina boven de vouw.

Ik weet niet precies hoe Bezos tot dit inzicht kwam — dat hij niet één product kan bouwen dat voor iedereen perfect is — maar hij snapt het nu. Er is een formele naam voor dit fenomeen: Accessibility (Toegankelijkheid). En dat is het belangrijkste in de computerwereld. Het allerbelangrijkste.

Als je nu denkt: "Hè? Bedoelt hij toegankelijkheid voor blinde en dove mensen?", dan ben je niet de enige. Er zijn veel mensen voor wie dit idee geen 'Accessibility' heeft, waardoor het nog niet is doorgedrongen. Wanneer software — of een idee — niet toegankelijk is voor iemand om welke reden dan ook, dan is dat de schuld van de software of de communicatie van het idee. Het is een Accessibility-fout.

Zoals alles wat belangrijk is in het leven, heeft Accessibility een boze tweelingbroer genaamd Security (Beveiliging). En die twee zijn constant met elkaar in conflict. Maar ik zou beargumenteren dat Accessibility belangrijker is dan Security, want als je Accessibility op nul zet, heb je helemaal geen product; terwijl je bij een Security-score van nul nog steeds een redelijk succesvol product kunt hebben, zoals het PlayStation Network.

Ik zou hier een dik boek over kunnen schrijven, maar ik zal deze tirade nooit gepubliceerd krijgen als ik nu niet afrond.

Dat laatste punt is dat Google platformen niet goed beheerst. Wij begrijpen platformen niet. We 'snappen' ze niet. Een enkeling wel, maar zij vormen de minderheid. Dit is me de afgelopen zes jaar pijnlijk duidelijk geworden. Ik had gehoopt dat concurrentiedruk van Microsoft, Amazon en recenter Facebook ons collectief wakker zou schudden om universele services te gaan bouwen — niet op een ad-hoc manier, maar zoals Amazon het deed: in één keer, serieus, zonder shortcuts en als topprioriteit.

Maar nee. Het staat ergens op de tiende of vijftiende plaats van prioriteit. Er zijn een paar teams die het idee serieus nemen, maar de meeste teams denken er helemaal niet over na, of slechts in zeer geringe mate. Het is al een enorme uitdaging om teams zover te krijgen dat ze zelfs maar een minimale service aanbieden voor programmatic access tot hun data en berekeningen. De meesten denken dat ze producten bouwen. En een minimale service is een trieste service. Als je kijkt naar de lessen van Amazon, zie je dat onze huidige tools (zoals Stubby) dit niet out-of-the-box oplossen. Stubby is prima, maar het is alsof je losse onderdelen krijgt terwijl je een auto nodig hebt.

Een product is nutteloos zonder platform. Nauwkeuriger gezegd: een product zonder platform zal altijd worden vervangen door een equivalent product mét platform.

Google+ is een schoolvoorbeeld van ons complete onvermogen om platformen te begrijpen, van de hoogste directieniveaus tot de laagste medewerkers. We snappen het allemaal niet. De gouden regel van platformen is: Eat Your Own Dogfood (gebruik je eigen producten). Het Google+ platform was een trieste afterthought. We hadden bij de lancering helemaal geen API, en voor zover ik weet was er later slechts één meager API-call beschikbaar. Een teamlid vertelde me daarover bij de lancering en ik vroeg: "Is dat dan de Stalker API?" Ze keek chagrijnig en zei: "Ja." Ik grapte, maar het was waar; de enige API-call die we boden was om iemands stream op te halen.

Microsoft begrijpt de 'Dogfood'-regel al twintig jaar. Het is onderdeel van hun cultuur. Je geeft je ontwikkelaars geen minderwaardig product terwijl jijzelf iets beters gebruikt. Dat is simpelweg het opofferen van lange-termijn platformwaarde voor korte-termijn successen. Platformen draaien om langetermijndenken.

Google+ was een reflex, een studie in kortetermijndenken, gebaseerd op de onjuiste aanname dat Facebook succesvol is omdat ze een geweldig product hebben gebouwd. Dat is niet de reden. Facebook is succesvol omdat ze een hele constellatie van producten mogelijk maakten door anderen het werk te laten doen. Hierdoor is Facebook voor iedereen anders: sommigen besteden al hun tijd aan Mafia Wars, anderen aan Farmville. Er zijn duizenden kwalitatieve 'time sinks' beschikbaar, dus er is voor iedereen iets.

Ons Google+ team keek naar de markt en zei: "Goh, het lijkt erop dat we wat games nodig hebben. Laten we iemand inhuren om wat games voor ons te schrijven." Zie je hoe fundamenteel fout die gedachte is? We proberen te voorspellen wat mensen willen en dat vervolgens aan hen te leveren. Dat kun je niet betrouwbaar doen. Er zijn maar heel weinig mensen in de geschiedenis van computing die dat konden. Steve Jobs was er één. Wij hebben hier geen Steve Jobs.

Larry Tesler heeft Bezos misschien overtuigd dat hij geen Steve Jobs was, maar Bezos realiseerde zich dat hij dat niet hoefde te zijn om iedereen de juiste producten te bieden: interfaces en workflows waar ze zich prettig bij voelden. Hij hoefde alleen maar externe ontwikkelaars in staat te stellen dit te doen, en het zou automatisch gebeuren.

Ik verontschuldig me bij degenen voor wie dit allemaal overduidelijk is. Want ja, het is ongelooflijk overduidelijk. Maar we doen het niet. We snappen Platformen niet, en we snappen Accessibility niet. Die twee zijn in feite hetzelfde, want platformen lossen accessibility op. Een platform is accessibility.

Microsoft begrijpt het. Dat is verrassend, want ze begrijpen eigenlijk weinig, maar ze begrijpen platformen omdat ze begonnen als een platformbedrijf. Ze hebben dertig jaar ervaring. Als je naar msdn.com gaat, zul je versteld staan van de enorme hoeveelheid API-calls. Hun platform is gigantisch. Te groot zelfs, want ze kunnen niet ontwerpen voor geen meter, maar ze doen het tenminste.

Amazon begrijpt het. AWS is ongelooflijk. Als je ernaar kijkt, is het gênant dat wij niets van dat niveau hebben. Apple begrijpt het ook; ze hebben weliswaar gesloten keuzes gemaakt rond hun mobiele platform, maar ze begrijpen accessibility en de kracht van externe ontwikkeling. En hun API's zijn veel cleaner dan die van Microsoft.

Facebook begrijpt het ook, en dát is wat me zorgen baart. Dat is waarom ik deze tirade schrijf. Ik haat bloggen, maar Google is mijn thuis, dus ik dwing deze ongemakkelijke familie-interventie af omdat ik wil dat Google succesvol is. Als je naar developers.google.com gaat, zie je het verschil. Het ziet eruit alsof een neefje uit de vijfde klas het heeft opgezet als schoolopdracht.

Begrijp me niet verkeerd: het dev-rel team heeft waarschijnlijk moeten VECHTEN om zelfs dit kleine beetje extern beschikbaar te krijgen. Zij begrijpen platformen wel, maar ze strijden heroïsch in een omgeving die op zijn best platform-apathisch is, en op zijn slechtst openlijk vijandig tegenover het idee. Van buitenaf gezien ziet developers.google.com er kinderlijk uit. Waar zijn de Maps API's? Sommige dingen zijn slechts 'labs'-projecten. De API's die ik aanklikte waren armzalig; het was 'dogfood', maar dan van slechte kwaliteit. Vergeleken met onze interne API's is het niets.

Dit is een cultureel probleem. Intern is er eigenlijk een oorlog gaande tussen de underdog-minderheid van 'Platformers' en de machtige, gefinancierde en zelfverzekerde 'Producters'. Teams die succesvol hebben geïnternaliseerd dat ze vanaf de basis programmeerbare platformen moeten zijn (zoals Maps en Docs), zijn underdogs. Het is voor hen moeilijk om financiering te krijgen omdat het niet in onze cultuur past. De financiering van Maestro is een lullig ding vergeleken met het gigantische Microsoft Office programming platform; het is een pluizig konijntje tegenover een T-Rex.

Ironisch genoeg was Wave een geweldig platform, rust zij in vrede. Maar iets een platform maken garandeert geen instant succes. Een platform heeft een 'killer app' nodig. Facebook zelf (de muren, vrienden, etc.) is de killer app voor het Facebook Platform. Het zou een enorme fout zijn om te denken dat de Facebook App zo succesvol had kunnen zijn zonder het Facebook Platform.

Mensen zeggen vaak dat Google arrogant is. Als Googler irriteert dat me, want we zijn over het algemeen 99% arrogantievrij. Maar wanneer we de positie innemen dat wij weten hoe we het perfecte product voor iedereen moeten ontwerpen, dan zijn we dwazen. Er bestaat geen perfect product voor iedereen.

Zo eindigen we met een browser die je niet toestaat om de standaard lettergrootte in te stellen. Dat is een belediging voor Accessibility. Naarmate ik ouder word, word ik echt slechtziend. Lettertype-selectie wordt dan een kwestie van leven of dood: het kan je volledig uitsluiten van een product. Maar het Chrome-team is hier ronduit arrogant; ze willen een 'zero-configuration' product bouwen en zeggen in feite "zoek het maar uit" als je blind of doof bent. Druk maar voor de rest van je leven op Ctrl-+ bij elk bezoek aan elke pagina.

Het probleem is dat we door en door een Product Company zijn. We hebben een succesvol product gebouwd met een breed publiek — onze zoekmachine — en dat enorme succes heeft ons bevooroordeeld. Amazon was ook een productbedrijf, maar daar was een externe kracht nodig om Bezos te laten inzien dat ze een platform nodig hadden: hun verdwijnende marges. Hij zat in het nauw en moest een uitweg vinden. Hij had engineers en computers... als hij die maar kon monetiseren. Zo ontstond AWS.

Het probleem waar we voor staan is enorm, want het zal een dramatische cultuurverandering kosten om in te halen. We doen geen interne service-georiënteerde platformen, en we doen geen externe. Dit betekent dat het "niet snappen" endemisch is in het hele bedrijf: de PM's snappen het niet, de engineers snappen het niet, de productteams snappen het niet. Zelfs als individuen het wel snappen, maakt dat niets uit tenzij we het behandelen als een noodsituatie waarbij iedereen moet helpen. We kunnen niet blijven lanceren en doen alsof we er later magisch mooie extensibele platformen van maken. Dat hebben we geprobeerd en het werkt niet.

De Gouden Regel van Platformen, "Eat Your Own Dogfood", kan worden herformuleerd als: "Begin met een Platform, en gebruik dat vervolgens voor alles." Je kunt het er niet later gewoon aan vastschroeven. Als je het uitstelt, kost het tien keer zoveel werk als wanneer je het vanaf het begin correct doet. Je kunt niet sjoemelen. Je kunt geen geheime achterdeurtjes hebben voor interne apps om speciale prioriteitstoegang te krijgen. De moeilijke problemen moeten vooraf worden opgelost.

Ik zeg niet dat het te laat is, maar hoe langer we wachten, hoe dichter we bij 'Te Laat' komen.

Ik weet niet goed hoe ik dit moet afsluiten. Ik heb alles gezegd wat ik wilde zeggen. Deze post was zes jaar in de maak. Mijn excuses als ik niet zachtaardig genoeg was of als ik een product of persoon verkeerd heb voorgesteld. Maar we moeten dit nu echt goed gaan doen.