Het lijkt erop dat de piek van de hype rondom microservices achter ons ligt. We lezen niet meer meerdere keren per week artikelen als 'Hoe ik mijn monolith naar 150 services heb gemigreerd'. Nu hoor ik vaker zinnige opmerkingen zoals: 'Ik haat geen monolith, ik geef gewoon om efficiëntie.' We hebben zelfs een paar migraties gezien van microservices terug naar monolithen. Bij de overstap van één grote applicatie naar meerdere kleinere diensten moet je een aantal nieuwe problemen aanpakken. Laten we ze zo kort mogelijk opsommen.

Installatie: van basische chemie naar kwantummechanica

Het instellen van een basisdatabase en een applicatie met een achtergrondproces was een vrij duidelijk proces. Ik publiceer een readme op Github – en vaak binnen een uur of maximaal twee, werkt alles en begin ik met een nieuw project. Het toevoegen en uitvoeren van code, althans voor de initiële omgeving, gebeurt op de eerste dag. Maar als we de sprong naar microservices wagen, schiet de tijd voor de initiële opzet door het dak. Ja, we hebben nu Docker met orkestratie en een cluster van K8-machines, maar voor een beginnende programmeur is dit een orde van grootte moeilijker. Voor veel junioren is dit een last die echt onnodige complexiteit met zich meebrengt.

Het systeem is moeilijk te doorgronden

Laten we even stilstaan bij onze junior. Bij monolithische applicaties was het eenvoudig om een fout te traceren en direct over te gaan tot debugging. Nu hebben we een service die met een andere service communiceert, die iets in de wachtrij plaatst op een berichtenbus, die een andere service verwerkt – en dan doet zich de fout voor. We moeten al deze onderdelen bij elkaar verzamelen om uiteindelijk te ontdekken dat service A draait op versie 11, terwijl service E al op versie 12 wacht. Dit verschilt sterk van mijn standaard gecompileerde logboek: ik moet een interactieve terminal/debugger gebruiken om het proces stap voor stap door te nemen. Debugging en begrip zijn in wezen moeilijker geworden.

Als we niet kunnen debuggen, zullen we ze misschien testen

Continuous integration and continuous development are becoming commonplace. Most new applications I see automatically create and run tests with each new release, requiring those tests to pass and be reviewed before deployment. These are excellent processes that should not be abandoned; they have been a significant shift for many companies. However, to truly test the service, I need to set up a full working version of my application. Remember that new engineer with a K8s cluster of 150 services? Well, now we will teach our CI system how to bring all these systems up to verify that everything really works. This is probably too much effort, so we will just test each part in isolation: I am confident that our specifications are good enough, APIs are clean, and service failures are isolated and won’t affect others.

Every compromise has a valid reason. Right?

There are many reasons to transition to microservices. I have seen this done for greater flexibility, team scaling, performance improvements, and to ensure better operational resilience. But in reality, we have invested decades in the tools and practices for developing monoliths, which continue to evolve. I work with professionals across various technologies. Usually, we talk about scaling because they are hitting the limits of a single Postgres database node. Most of the conversations revolve around scaling the database.

But I am always curious about their architecture. At what stage of migrating to microservices are they? It is interesting to see more engineers say they are satisfied with their monolithic application. For many, microservices will provide benefits, and the advantages will outweigh the bumps on the migration road. But personally, I would like my monolithic application—with a spot on the beach—and I would be completely happy.

Bron: habr.com