Shoprocket's Reis naar Microservices: Deel 1

Een paar maanden in mijn baan bij Shoprocket en ik begon gefrustreerd te raken. We hadden een PHP-applicatie waaraan ons kleine team van slimme ontwikkelaars werkte, verspreid over de hele wereld. Waarom raakte ik gefrustreerd? Voor mijn gevoel leidden bugfixes tot meer bugs, het integreren van nieuwe functies was niet zo eenvoudig als het kon zijn, en de implementaties waren zeldzaam en stressvol. De reden voor deze problemen: sterk gekoppelde code.

We hadden een monolithische applicatie en bijna onze hele codebase bevond zich in één Github-repository. Updates of fixes voor één functie gebeurden vaak op verschillende plaatsen. Voor testen hadden we een peer review-proces, waarbij ten minste twee andere ontwikkelaars moesten goedkeuren op een branch voordat deze zou worden samengevoegd met de master en geïmplementeerd. Dit betekende dat wanneer bugs erin wisten te sneaken, het vaak moeilijk was om de brekende wijzigingen te lokaliseren. En zodra we dat deden, ondergingen de fixes hetzelfde proces en moest de hele applicatie opnieuw worden geïmplementeerd.

Als een enthousiaste jonge ontwikkelaar die altijd op zoek was naar het nieuwe, dacht ik dat microservices deze architecturale stijl al onze problemen zou oplossen. Er is geen formele definitie van microservices, maar uit mijn onderzoek begreep ik dat microservice-architectuur een manier is om softwareapplicaties te ontwerpen als gedistribueerde systemen van onafhankelijke diensten, elk sterk gespecialiseerd en met een eigen levenscyclus. Voor lezers die een meer gedetailleerde introductie tot het concept willen, raad ik het uitstekende artikel van Martin Fowler aan.

Er waren veel aspecten van microservices die mijn interesse wekten, maar twee in het bijzonder: Ten eerste het idee om de applicatie op te splitsen in diensten met zeer strikte grenzen. Dit verkleint de kans dat logica die specifiek is voor één zakelijke context tussen componenten lekt, omdat de interfaces tussen grenzen zorgvuldig moeten worden gepland. Het is niet zo simpel als lokale functieaanroepen maken; Ten tweede kan elke component zijn eigen onafhankelijke levenscyclus hebben. Dit stelt teams in staat om verantwoordelijkheid te nemen voor hun code en een technologiestack te gebruiken die het beste past bij de individuele dienst. Bovendien maakt het fijnere controle over de applicatie mogelijk, omdat wijzigingen naar één dienst tegelijk kunnen worden uitgerold en teruggedraaid zonder de rest van de applicatie te beïnvloeden als er iets misgaat.

Dus, ik was overtuigd. Shoprocket zou de monoliet opsplitsen! Dit is de eerste in een korte serie blogposts die deze reis volgen. Mijn hoop is dat lezers die een vergelijkbare transitie plannen of meemaken, kunnen leren van onze successen en mislukkingen en zich beter voorbereid voelen om deze uitdaging in hun eigen projecten aan te gaan.

Mijn eerste uitdaging was niet technisch, maar menselijk. Ik moest het idee verkopen aan de rest van het team. Ze leken nieuwsgierig, maar deelden niet hetzelfde enthousiasme en waren terughoudend om ontwikkeluren op te geven in deze vroege fase van het leven van ons product. Gelukkig wilde de CTO dat ik naar ons sessiebeheer keek en greep ik de kans door hem ervan te overtuigen dat ik een sessiedienst kon opsplitsen.

Terugkijkend was dit misschien een slechte keuze van component voor een eerste dienst. Ons product omvat een javascript-plugin die e-commerce op elke website mogelijk maakt. We beschouwen sessies als een resource, waarbij sessie-informatie wordt opgeslagen in de database voor gedetailleerde analyse van KPI's zoals winkelwagentjes die worden verlaten. Echter, deze resource is niet zo tastbaar als iets als bestellingen of artikelregels. Bovendien gebruikten we de sessie resource bij bijna elke wijziging in de applicatietoestand. Dit betekende dat de dienst onvermijdelijk communicatief zou zijn met de rest van de applicatie, iets wat ik niet had voorzien, maar wat mijn taak moeilijk maakte.

Nadat ik mijn baas overtuigd had, versnelde ik mijn onderzoek naar microservices. Afgezien van het eerder genoemde artikel vond ik Sam Newman’s ‘Building Microservices’ een onschatbare bron. Ik zal beide vaak in mijn berichten vermelden.

In zijn boek raadt Newman aan om eerst een bestaande applicatie te herstructureren in modules die de begrensde contexten van het domein weerspiegelen. Zodra de ontwikkelaars tevreden zijn, kunnen modules worden opgesplitst in hun eigen diensten. De reden hiervoor is dat het veel gemakkelijker is om modules op te splitsen en opnieuw te schrijven als hun grenzen slecht gekozen zijn dan om hele diensten op te splitsen en opnieuw te schrijven, met al hun extra code en persistente resources. Maar, vanwege tijdsdruk en mijn verlangen om een component van mijn eigen te bouwen, ging ik verder met de eerste dienst.

Ik koos voor een stack die slechts marginaal anders was dan de ene die we gebruikten voor onze monoliet en begon met bouwen. De bouw zelf verliep vrij snel en het kostte enkele weken om een standalone applicatie met een REST API te produceren. Pas daarna begonnen de echte uitdagingen.

Ik moest de dienst laten communiceren met de monoliet. Het was op dit punt dat ik leerde hoe sterk gekoppeld sessiebeheer was met de rest van de code. Het kostte me een tijd om bestaande functieaanroepen af te breken en deze om te zetten in API-aanroepen. Dit was lastig. Aangezien de sessiedienst en de monoliet hun eigen databaseschema's hadden, moest ik elke logica in de monoliet herschrijven die sessie-resources uit de oude database gebruikte, waarbij ik de gegevens aanpaste aan de applicatiegrens om de compatibiliteit met clients zoals onze javascript-plugin te behouden.

Het integreren van de dienst met onze bestaande applicatie kostte langer dan het schrijven van de dienst zelf en dit omvatte niet veel van de extra overhead die microservices normaal met zich meebrengen, zoals service discovery, logging en monitoring. Bovendien, vanwege de sterke koppeling, werden wijzigingen aangebracht in veel gebieden van de code. Aangezien het team in deze periode aan verschillende gebieden van de code parallel werkte, zou het veel meer werk hebben gekost om de wijzigingen samen te voegen en de sessiedienst in productie te krijgen.

De dienst zou binnenkort in productie kunnen gaan, maar ik voel nu dat ik Newman’s advies had moeten volgen en mijn inspanningen had moeten besteden aan het modulariseren van onze bestaande applicatie. Het voordeel van het hebben van één dienst die op zichzelf staat is marginaal. Het echte voordeel zal komen van het opsplitsen van het geheel, althans in grofkorrelige diensten, die zo min mogelijk communiceren. Dit vereist zeer goed doordachte componentgrenzen, en we zijn daar nog niet.

Ik blijf overtuigd van het idee van microservices, en ik beschouw mijn poging om een dienst af te splitsen als een succesvol experiment. Ik heb veel geleerd over applicatiearchitectuur en domeinmodellering in het proces, en mijn begrip van REST-principes verbeterd, onder andere. Deze hebben een directe impact gehad op andere gebieden van onze code.

Voor lezers die willen overstappen, zou ik zeker zoveel mogelijk over het onderwerp willen lezen en het werk uitstellen totdat je zeer zeker bent van je bestaande codebase en je domeinmodel. Er zijn andere manieren om stabiliteit en veerkracht in een monolithische applicatie in te voeren. Testgedreven ontwikkeling en geautomatiseerde eenheids- en functionele tests helpen enorm. Horizontale schaling helpt ook om implementaties iets soepeler te maken.

Shoprocket zal verder gaan op zijn reis naar microservices. We kijken ernaar uit om je meer te vertellen in deel 2!