Microservices @ Uber - the tradeoffs

Microservices zijn hot, je kunt geen krant, IT-gerelateerde blog of nieuws website openslaan zonder over dit onderwerp te lezen. Verschillende (grote) organisaties maken de transitie naar een architectuur waarin het grote, logge systeem wordt opgeknipt in verschillende kleine services. Hoewel we geneigd zijn om ons te focussen op de positieve kanten van een bepaald concept, kent ook het implementeren van microservices de nodige uitdagingen.

Ook bij Uber, misschien wel de meest succesvolle start-up van de laatste jaren, bestaat het applicatielandschap uit microservices. Matt Ranney, Chief Systems Architect, geeft tijdens QCon New York een overzicht van de uitdagingen die Uber heeft gekend in het implementeren van een microservices architectuur.

Context
Het gebruik van microservices is bij Uber eerder standaard dan revolutionair. De eerste versie van het Uber platform bestond uit een tiental microservices. In de jaren daarna groeide het landschap exponentieel, tot in maart 2016 de 1.000 werd aangetikt. Momenteel staat de teller op ruim 1.200 microservices, dus de groei is er nog lang niet uit.

Waarom microservices?
De reden om microservices te implementeren bij Uber lijkt vanzelfsprekend. Het geeft een grote flexibiliteit in het ontwikkelen, uitrollen en aanpassen van verschillende onderdelen van het platform. Zeker bij een organisatie als Uber, waar verschillende teams werken aan een enorme set aan webservices, is dit een belangrijk voordeel. Het snel kunnen uitrollen van een webservice, onafhankelijk van andere teams en services, is enorm waardevol. Het heeft de time to market bij Uber in relatief korte tijd significant weten te verkleinen.

Helaas kent het gebruik van microservices ook een (groot) aantal uitdagingen. In het verhaal dat Ranney geeft, is de positieve kant van het verhaal welgeteld 2 minuten aan bod gekomen. Na deze 2 minuten geeft Ranney in een enkele quote feilloos weer waar de grootste kwetsbaarheid ligt van microservices:

Our platform is most reliable in the weekend; for then there are no developers working on it.

Vergankelijkheid door onafhankelijkheid
De eerder genoemde onafhankelijkheid van de verschillende teams zorgt meteen voor een van de grootste uitdagingen bij Uber. Hoe houd je een organisatie met verschillende teams goed op elkaar afgestemd, terwijl elk team op eigen houtje services kan uitrollen en aanpassen? De vraag stellen is hem beantwoorden, want dat kan alleen als de teams goed op elkaar zijn afgestemd en van elkaar weten hoe er gewerkt wordt en wat er gebeurt. Hierbij onderscheidt Ranney de volgende uitdagingen:

• Hoe zorgen we ervoor dat een ander team jouw webservices kan uitrollen?
• Door verschillende teams onafhankelijk te laten werken, ontstaat er cultuurfragmentatie.
• Het is erg moeilijk om te switchen van teams, door het verschil in werkwijze, cultuur en gebruikte technieken.
• Het delen van code is moeilijk, wat de efficiëntie niet ten goede komt.
• De teams krijgen alle ruimte, waardoor niet gezamenlijk wordt gereflecteerd op vooroordelen en voorkeuren die binnen elk team bestaan. De teams kunnen hun services opzetten zoals ze zelf willen.
• Het is bijzonder moeilijk het platform als geheel te verbeteren, omdat elk team daar afzonderlijk invloed op uitoefent en verschillende werkwijzen en tooling gebruikt. Hoe ga je performance meten als de tooling en technieken niet op elkaar aansluiten?
• De teams krijgen niet alleen een functionele rol, maar ook een politieke. Omdat de belangen van de teams niet altijd overeenkomen, wordt het op den duur een politiek spel. Hoe ga je een team ervan overtuigen dat een complex onderdeel van het systeem binnen hun services moet worden geïmplementeerd, terwijl dat niet in het belang is van dat team?
• Het oplossen van een probleem wordt minder belangrijk, want waarom zouden we een complex probleem oplossen, als we er ook gewoon een andere service bij kunnen plakken die het probleem niet oplost, maar er omheen werkt?

What about the system?
Naast de organisatorische uitdagingen die Uber heeft gekend, is ook op het technische vlak het een en ander aan te merken op het gebruik van microservices. Het Uber platform wordt wereldwijd door miljoenen mensen gebruikt en is daarmee gevoelig als het gaat om veiligheid, beschikbaarheid en performance. Dat alleen al is reden om verschrikkelijk goed na te denken over hoe het platform vormgegeven dient te worden. Ranney vertelt in zijn verhaal over de volgende uitdagingen:

• Een systeem met een groot aantal services, waar meerdere teams aan werken, wordt al snel erg complex en onoverzichtelijk.
• De snelheid van het platform wordt bepaald door de zwakste schakel. De services die achterlopen op dit gebied, maken het gehele systeem kwetsbaar.
• Debugging, tracing en logging van het systeem is erg moeilijk, aangezien de services vaak verschillend zijn opgezet en de tooling niet met alle services overweg kan.
• Het oplossen van een bug of “outage” wordt steeds moeilijker. De fout kan in een van de 1.200 services zitten. Logging en tracing wordt steeds belangrijker.
• Bij Uber kan het load testen alleen op de productieomgeving worden gedaan, wat niet alleen risico’s met zich meebrengt, maar ook de metrieken omtrent gebruik, logging en tracing in de war schopt.
• Laten we open source toe? Hoeveel vrijheid geven we de teams in het kiezen van de technieken en het implementeren van third party software?
• “Old stuff still has to work!”
• Hoe gaan we een SLA opstellen, met zoveel verschillende componenten die allemaal invloed hebben op beschikbaarheid, stabiliteit en performance?

Klagen of slagen?
Het is erg makkelijk om een overzicht te geven van de uitdagingen die er zijn, zonder teveel in te gaan op de oplossingen. Hier schiet het verhaal van Ranney toch wel wat tekort. Wat vooral duidelijk wordt is dat Uber een behoorlijke slag heeft gemaakt in het wegnemen van de problemen en uitdagingen, maar het wordt niet helemaal duidelijk hoe ze dat hebben gedaan. Wel geeft Ranney een aantal adviezen voor organisaties die te maken hebben met microservices of overwegen hiermee aan de slag te gaan:

• “Performance doesn’t matter, until it does”. Focus vanaf het begin op de performance, want zodra het een probleem wordt, is het eigenlijk al te laat.
• Gebruik vanaf het begin tracing en logging. Doe het niet voor jezelf, maar wel voor de mensen die met het systeem moeten werken en het moeten onderhouden. Sla hier ook weer niet in door, want met 1.200 microservices kan een uitgebreide logging leiden tot terabytes aan logdata.
• Maak een uitgebreid testplan en vergeet niet de “failure tests”. Niemand vindt het leuk, maar het moet wel gebeuren. Doe het meteen in het begin en sterker nog: “make it part of your paradigm!”
• Zorg ervoor dat iedereen het belang van de organisatie boven het belang van het team stelt en het belang van het team boven het belang van de persoon zelf. Dit is een absolute voorwaarde om een groot landschap met verschillende autonome teams tot een succesvol platform te brengen.

“Everything is a tradeoff, try to make them intentionally”
Zorg ervoor dat je de voor- en nadelen van een microservices architectuur goed tegen elkaar afweegt, en maak vervolgens een bewuste keuze. Zorg er ook voor dat een afweging je niet overkomt, maar dat je deze bewust maakt. Met deze woorden besluit Ranney zijn verhaal over microservices bij Uber. Hiermee wordt duidelijk dat er geen panklare oplossing is voor de uitdagingen die een microservices architectuur met zich meebrengt, maar dat het vooral een kwestie is van het in lijn brengen van de verschillende teams, zonder daarbij concessies te doen op de autonomie van die teams. Een uitdaging an sich, in dat opzicht zijn de medewerkers van Uber net gewone mensen.

Share this