Het lijkt erop dat de piek van de hype voor microservices achter ons ligt. We lezen niet meer meerdere keren per week berichten “Hoe ik mijn monoliet naar 150 diensten heb verplaatst.” Nu hoor ik meer gezond verstand-gedachten: “Ik haat de monoliet niet, ik geef alleen om efficiëntie.” We hebben zelfs verschillende migraties waargenomen . Bij de overstap van één grote applicatie naar meerdere kleinere diensten zul je een aantal nieuwe problemen moeten oplossen. Laten we ze zo kort mogelijk opsommen.
Omgeving: van basischemie tot kwantummechanica
Het opzetten van een basisdatabase en -applicatie met een achtergrondproces was een vrij eenvoudig proces. Ik publiceer de leesmij op Github - en vaak werkt na een uur, hoogstens een paar uur, alles en start ik een nieuw project. Het toevoegen en uitvoeren van code, in ieder geval voor de initiële omgeving, gebeurt vanaf de eerste dag. Maar als we ons wagen aan microservices, schiet de initiële lanceringstijd omhoog. Ja, nu hebben we Docker met orkestratie en een cluster van K8-machines, maar voor een beginnende programmeur is dit allemaal veel ingewikkelder. Voor veel junioren is dit een last die werkelijk een onnodige complicatie is.
Het systeem is niet gemakkelijk te begrijpen
Laten we ons even concentreren op onze junior. Als er bij monolithische toepassingen een fout optrad, was het gemakkelijk om deze op te sporen en onmiddellijk door te gaan met het opsporen van fouten. Nu hebben we een service die praat met een andere service die iets in de wachtrij zet op een berichtenbus die 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 versie 11 draait, en Service E al wacht op versie 12. Dit is heel anders dan mijn standaard geconsolideerde logboek: ik moet een interactieve terminal/debugger gebruiken om te lopen stap voor stap door het proces. Debuggen en begrijpen zijn inherent moeilijker geworden.
Als er geen fouten kunnen worden opgespoord, zullen we ze misschien testen
Continue integratie en continue ontwikkeling worden nu gemeengoed. De meeste nieuwe apps die ik zie, maken en voeren automatisch tests uit bij elke nieuwe release en vereisen dat tests worden afgenomen en beoordeeld voordat ze worden geregistreerd. Dit zijn geweldige processen die niet mogen worden opgegeven en die voor veel bedrijven een grote verandering hebben betekend. Maar om de service echt te testen, moet ik nu een volledig werkende versie van mijn applicatie ophalen. Weet je nog die nieuwe ingenieur met het K8-cluster van 150 services? Welnu, nu zullen we ons CI-systeem leren hoe we al deze systemen kunnen oproepen om te verifiëren dat alles echt werkt. Dit is waarschijnlijk te veel moeite, dus we zullen elk onderdeel afzonderlijk testen: ik heb er vertrouwen in dat onze specificaties goed genoeg zijn, de API's schoon zijn en dat een servicefout geïsoleerd is en geen gevolgen heeft voor anderen.
Alle compromissen hebben een goede reden. Rechts?
Er zijn veel redenen om over te stappen op microservices. Ik heb dit zien gebeuren voor meer flexibiliteit, voor het opschalen van teams, voor prestaties en voor betere duurzaamheid. Maar in werkelijkheid hebben we tientallen jaren geïnvesteerd in instrumenten en praktijken om monolieten te ontwikkelen die blijven evolueren. Ik werk met professionals in verschillende technologieën. We praten meestal over schalen omdat ze tegen de limieten van een enkel Postgres-databaseknooppunt aanlopen. De meeste gesprekken gaan over .
Maar ik ben altijd geïnteresseerd in het leren kennen van hun architectuur. In welke fase van de transitie naar microservices bevinden ze zich? Het is interessant om te zien dat steeds meer ingenieurs zeggen blij te zijn met hun monolithische toepassing. Veel mensen zullen profiteren van microservices, en de voordelen zullen groter zijn dan de hobbels op het migratiepad. Maar persoonlijk, geef mij alstublieft mijn monolithische toepassing, een plek op het strand - en ik ben helemaal gelukkig.
Bron: www.habr.com