Het lijkt erop dat de piek van de microservices-hype voorbij is. We lezen niet langer wekelijks berichten over "Hoe ik mijn monoliet naar 150 services migreerde". Nu hoor ik redelijkere gedachten: "Ik heb geen hekel aan de monoliet, ik geef alleen om efficiëntie." We hebben zelfs een paar migraties gezien. Bij de overstap van één grote applicatie naar meerdere kleinere services moet u een aantal nieuwe problemen oplossen. Laten we ze zo kort mogelijk opsommen.
Installatie: Van basischemie tot kwantummechanica
Het opzetten van een eenvoudige database en applicatie met een achtergrondproces was een vrij eenvoudig proces. Ik publiceerde een readme op Github en vaak binnen een uur, hooguit een paar uur, was alles up and running en startte ik een nieuw project. De code up and running krijgen, althans voor de initiële omgeving, was op dag één al gedaan. Maar toen we ons waagden aan microservices, schoot de initiële opstarttijd omhoog. Ja, we hebben nu Docker met orkestratie en een cluster van K8-machines, maar voor een beginnende programmeur is dit allemaal een orde van grootte complexer. Voor veel junioren is het een last die eigenlijk onnodig complex is.
Het systeem is niet gemakkelijk te begrijpen
Laten we even naar onze junior kijken. Bij monolithische applicaties was het, als er een fout optrad, gemakkelijk om die op te sporen en direct te debuggen. Nu hebben we een service die communiceert met een andere service, die iets in de wachtrij plaatst op de berichtenbus, die weer een andere service verwerkt – en dan treedt er een fout op. We moeten al deze stukjes samenvoegen om er uiteindelijk achter te komen dat service A op versie 11 draait en service E al versie 12 verwacht. Dit is heel anders dan mijn standaard geconsolideerde log: ik moet een interactieve terminal/debugger gebruiken om het proces stap voor stap te doorlopen. Debuggen en begrijpen is inherent moeilijker geworden.
Als we ze niet kunnen debuggen, kunnen we ze misschien wel testen.
Continue integratie en continue ontwikkeling worden tegenwoordig steeds gebruikelijker. De meeste nieuwe apps die ik zie, maken en voeren automatisch tests uit bij elke nieuwe release, en vereisen dat tests worden goedgekeurd en beoordeeld voordat ze worden goedgekeurd. Dit zijn fantastische processen die niet mogen worden verlaten, en ze hebben voor veel bedrijven een grote verandering teweeggebracht. Maar om een service daadwerkelijk te testen, moet ik nu een volledige productieversie van mijn app opzetten. Herinner je je die nieuwe engineer nog met het K8-cluster van 150 services? Nou, nu gaan we ons CI-systeem leren hoe we al die systemen moeten opzetten om te testen of alles daadwerkelijk werkt. Dat is waarschijnlijk te veel werk, dus testen we elk onderdeel afzonderlijk: ik heb er vertrouwen in dat onze specificaties goed genoeg zijn, de API schoon is en dat een servicefout geïsoleerd is en geen gevolgen heeft voor anderen.
Elk compromis heeft een goede reden, toch?
Er zijn veel redenen om over te stappen op microservices. Ik heb het zien gebeuren voor wendbaarheid, voor het opschalen van teams, voor prestaties, voor betere veerkracht. Maar de realiteit is dat we decennia hebben geïnvesteerd in monolithische tools en werkwijzen die zich blijven ontwikkelen. Ik werk met professionals in verschillende technologieën. We praten meestal over opschaling omdat ze tegen de beperkingen van één Postgres-databaseknooppunt aanlopen. Een groot deel van het gesprek gaat over .
Maar ik ben altijd nieuwsgierig naar hun architectuur. Waar ze staan in hun traject naar microservices? Het is interessant om te zien dat steeds meer engineers zeggen dat ze tevreden zijn met hun monolithische app. Voor velen zullen microservices nuttig zijn en de voordelen zullen opwegen tegen de obstakels. Maar geef mij mijn monolithische app, een plek aan het strand, en ik ben perfect tevreden.
Bron: www.habr.com
