Waarom microservices misschien klaar zijn als monolieten wraak nemen

De verschuiving naar microservices begon begin jaren 2010 in een stroomversnelling te komen, toen technologiebedrijven de beperkingen van monolithische architecturen onderkenden. Echter, veel bedrijven zoals Amazon (Prime Video), Invision, Istio en Segment keren terug naar monolithische architecturen. In dit artikel wordt onderzocht waarom veel organisaties falen bij de overstap naar een microservices-architectuur.

Wat is een monoliet?

Een monolithische architectuur is eenvoudig: de gebruiker vraagt ​​om gegevens en alle bedrijfslogica en gegevens bevinden zich binnen één enkele service. Monolithische systemen worden echter geconfronteerd met uitdagingen, zoals beperkte schaalbaarheid, problemen met het implementeren van updates en een kwetsbaarheid voor single points of Failure.

Om dit aan te pakken hebben veel organisaties geprobeerd over te stappen naar een op microservices gebaseerde architectuur om voordelen als abstractie en inkapseling, snellere implementatie, eenvoudiger onderhoud en nauwere afstemming van elke service op het teameigendom te benutten.

Waarom microservices?

In een ideale microservices-architectuur opereert elk bedrijfsdomein als zijn eigen onafhankelijke dienst met zijn eigen database. Deze opzet biedt voordelen zoals betere schaalbaarheid, flexibiliteit en veerkracht. Beschouw het onderstaande diagram.

De realiteit

Recente trends laten echter zien dat veel bedrijven hiervan afstappen en vasthouden aan een monolithische architectuur. Dit komt omdat het moeilijk is om dit niveau van harmonie in de echte wereld te bereiken. De werkelijkheid ziet er vaak uit als onderstaand schema.

Het is bekend dat het migreren naar een microservice-architectuur complexe interacties tussen services, circulaire oproepen en data-integriteitsproblemen veroorzaakt en, om eerlijk te zijn, het bijna onmogelijk is om de monoliet volledig kwijt te raken. Laten we bespreken waarom sommige van deze problemen optreden nadat ze naar de microservices-architectuur zijn gemigreerd.

Onjuiste domeingrenzen

In het ideale scenario zou een enkele dienst een of meer complete bedrijfsdomeinen moeten omvatten, zodat elk domein op zichzelf staat binnen een dienst. Een domein mag nooit over meerdere diensten worden verdeeld, omdat dit kan leiden tot onderlinge afhankelijkheid tussen diensten. Het volgende diagram laat zien hoe een enkele service een of meer volledige domeinen kan bevatten om duidelijke grenzen te behouden.

In complexe systemen in de echte wereld kan het definiëren van domeingrenzen een uitdaging zijn, vooral wanneer gegevens traditioneel op een specifieke manier zijn geconceptualiseerd. Het volgende diagram laat zien hoe systemen in de echte wereld er vaak uitzien in een microservice-architectuur wanneer grenzen niet vooraf zijn gedefinieerd of ingenieurs nieuwe services toevoegen zonder rekening te houden met domeingrenzen.

Als domeinen niet goed gedefinieerd zijn, neemt de afhankelijkheid van andere diensten toe, wat tot meerdere problemen leidt:

• Circulaire afhankelijkheden of buitensporige oproepen: wanneer diensten onderling afhankelijk zijn, vereisen ze frequente gegevensuitwisseling.
• Problemen met de gegevensintegriteit: Een enkel domein verdeeld over services zorgt ervoor dat diep gekoppelde gegevens over meerdere services worden verdeeld.
• Vaag teameigendom: meerdere teams moeten mogelijk samenwerken op overlappende domeinen, wat tot inefficiëntie en verwarring leidt.

Diep gekoppelde data en functionaliteit

In een monolithische architectuur slaan clients vaak aangewezen interfaces over en hebben ze rechtstreeks toegang tot de database, omdat het afdwingen van inkapseling moeilijk is in een enkele codebase. Dit kan ertoe leiden dat ontwikkelaars sluiproutes nemen, vooral als interfaces onduidelijk of ingewikkeld lijken. Na verloop van tijd ontstaat er een web van clients die nauw verbonden zijn met specifieke databasetabellen en bedrijfslogica.

Bij de overstap naar een microservices-architectuur moet elke client worden bijgewerkt om met de nieuwe service-API’s te kunnen werken. Omdat klanten echter zo gebonden zijn aan de bedrijfslogica van de monoliet, vereist dit dat hun logica tijdens de migratie opnieuw wordt vormgegeven.

Het ontwarren van deze afhankelijkheden zonder de bestaande functionaliteit te verbreken kost tijd. Sommige clientupdates worden vaak uitgesteld vanwege de complexiteit van het werk, waardoor sommige clients na de migratie nog steeds de monolith-database gebruiken. Om dit te voorkomen kunnen ingenieurs nieuwe datamodellen in een nieuwe dienst creëren, maar bestaande modellen in de monoliet behouden. Wanneer modellen nauw met elkaar verbonden zijn, leidt dit ertoe dat gegevens en functies verdeeld worden tussen services, wat leidt tot meerdere oproepen tussen services en problemen met de gegevensintegriteit.

Gegevensmigratie

Datamigratie is een van de meest complexe en risicovolle elementen van de overstap naar microservices. Het is essentieel om alle relevante data nauwkeurig en volledig over te zetten naar de nieuwe microservices. Veel migraties stoppen in dit stadium vanwege de complexiteit, maar succesvolle datamigratie is de sleutel tot het realiseren van de voordelen van microservices. Veel voorkomende uitdagingen zijn onder meer:

• Gegevensintegriteit en -consistentie: Fouten tijdens de migratie kunnen leiden tot gegevensverlies of inconsistenties.
• Gegevensvolume: Het overbrengen van grote hoeveelheden gegevens kan veel middelen in beslag nemen en tijdrovend zijn.
• Downtime en bedrijfscontinuïteit: Gegevensmigratie kan downtime vereisen, waardoor de bedrijfsactiviteiten mogelijk worden verstoord. Een soepele transitie met minimale impact voor de gebruiker is cruciaal.
• Testen en valideren: Er zijn rigoureuze tests nodig om ervoor te zorgen dat gemigreerde gegevens accuraat en volledig zijn en goed presteren in de nieuwe service.

Conclusie

De microservices-architectuur ziet er misschien aantrekkelijk uit, maar de transitie van een monoliet is een uitdaging. Veel bedrijven komen vast te zitten in een middensituatie, waardoor de systeemcomplexiteit toeneemt, wat problemen met de gegevensintegriteit, circulaire afhankelijkheden en onduidelijk teameigenaarschap veroorzaakt. Het onvermogen om de volledige voordelen van microservices in de echte wereld te benutten is de reden dat veel bedrijven terugkeren naar een monolithische aanpak.

Supriya Lal is de technische leider van de groep voor de organisatie van het handelsplatform bij Yelp.