door: OutSystems MVP Paul Schmeddes
“Hoe maak je een losjes gekoppelde architectuur in een complexe omgeving?”
Wanneer je betrokken bent bij een groot OutSystems-project om een omvangrijk maatwerksysteem te vervangen met honderden (300+) modules en veel integraties, dan is een goede architectuur extra belangrijk. Die moet op zo’n manier zijn opgezet dat de impact van het wijzigen van een ‘library module’ minimaal is. Behalve het toepassen van het 4-laags canvas model en het groeperen van modules (in functionele componenten per laag) kan ook een architectuur met microservices worden toegepast.
In een microservices architectuur worden frontend applicaties losjes gekoppeld aan de integratieservices (backend) die de bedrijfsdatabases en externe services integreren. Zo’n losse koppeling minimaliseert de impact van wijzigingen in de backend. In dit artikel wordt de services architectuur uitgewerkt en geïllustreerd met een voorbeeld. De integratie met externe systemen waarbij gebruik wordt gemaakt van extensies of het consumeren van services komt aan de orde, samen met de voor- en nadelen van de microservices architectuur.
De microservices architectuur bestaat uit twee infrastructuren:
Extern API-niveau
Dit niveau is een samenstelling van API's die de services beschikbaar stelt aan externe gebruikers. Het is enkel een technische proxy voor de echte diensten, geïmplementeerd op de microservices infrastructuur. Dit niveau vertaalt die services naar API’s voor externe systemen.
Core services
Dit niveau implementeert de services, met alle bedrijfsregels en entiteiten.
Integratieservices
Integratieservices maken verbinding met backendsystemen en bedrijfsdatabases met behulp van extensies of (consumerende) API's.
Applicatie- of eindgebruikerslaag
OutSystems applicaties consumeren de services en blokken van de kern- en bibliotheekservices lagen.
Extended services
De uitbreiding van de core services door het cachen van data in lokale entiteiten en het beschikbaar stellen van herbruikbare blokken voor meer flexibiliteit.
Integratieservices
Dit is een extra laag die ik heb toegevoegd aan het model, wat wordt geconsumeerd door Extended Services. Het benut API’s die beschikbaar gesteld worden door microservices of externe systemen en biedt façade server actions. Zo’n façade maakt gebruikers onafhankelijk van eventuele wijzigingen in de onderliggende services. Dit verkleint de impact van een versie-upgrade of de overstap naar een compleet nieuwe service. De façade losse koppelingen mogelijk.
In dit voorbeeld hebben we de OutSystems Movie Database-applicatie (OSMDb) aangepast om de architectuur te implementeren.
Het doel van deze wijzigingen is om te illustreren hoe een losjes gekoppelde architectuur te maken is door de lagen Core en Integration Services los te koppelen van de frontendlagen. Dit minimaliseert het effect van veranderingen in deze lagere lagen. De afbeelding hieronder toont het toepassingslandschap zoals beschreven in de volgende secties.
De MovieTheater API-module definieert het servicecontract en maakt de publieke services voor MovieTheater_CS. Dit zorgt voor de ontkoppeling van de implementatiedetails van de core service.
De MovieDomain API definieert het contract en maakt de publieke services voor Movie_CS. Dit zorgt voor de ontkoppeling van de implementatiedetails van de core service.
Dit is de OutSystems Movie Database-toepassing. Zie de oefeningen van OutSystems Web Applications voor een overzicht van de toepassing. Voor deze versie worden de Cinema- en Movie entiteiten niet in de cache opgeslagen. Daardoor worden alle Cinema- en Movie-aggregaten vervangen door bijbehorende serveracties. Het nadeel is dat we de paginering en kolommensortering verliezen. Dit kan worden opgelost door paginering en een aangepaste sortering toe te voegen aan de API's. Meestal is geen paginering nodig, maar is een filter op je resultaten voldoende.
Dit is de oorspronkelijke OSMDb Core Services-laag zonder de Cinema-entiteit.
Movie Extended services combineert de resultaten van de Movie Domain API's en TheMovieDb API.
De entiteit Movie wordt als ‘alleen lezen’ beschikbaar gesteld en wordt gebruikt als dummy-entiteit. Er worden geen gegevens bewaard in deze entiteit. Door een entiteit te gebruiken in plaats van een structuur, kunnen we een cachingmechanisme toevoegen. Als caching wordt toegepast, kunnen we ook profiteren van de queryoptimalisatie van het platform. Het cachingmechanisme wordt uitgewerkt in een ander artikel.
De MovieGetById Server Action roept bijvoorbeeld de FilmGetById en de TMDB_GetMoviePosterPath façade serveracties aan om een verbeterd filmrecord te bieden.
Gebruikt de MovieTheater_API’s en publiceert façade serveracties met behulp van de OSMDb corporate data model (CDM) Cinema structuur.
Gebruikt de Film_API services en publiceert façade server acties.
CDM_Film: Genormaliseerde structuur onafhankelijk van de API-structruur.
Gebruikt de TheMovieDB API en publiceert een façade serveractie.
Het toepassen van een microservices architectuur heeft voor- en nadelen. Je moet ze goed wegen bij de beslissing om deze architectuur te implementeren of niet. Dit zijn de voor-en nadelen:
Voordelen
Nadelen
Blockchain technologie krijgt – na de financiële wereld – de komende jaren veel invloed op onze manier van leven en werken. Steeds meer nieuwe blockchain toepassingen worden al zichtbaar. Vooral de organisatorische implementatie is nog een uitdaging.
Door de hoge druk op onderhoud van bestaande systemen komen veel IT-afdelingen nauwelijks toe aan strategisch belangrijker taken, zoals innovatie en creatieve projecten voor het moderniseren van bedrijfsprocessen.Dat blijkt uit recent Amerikaans onderzoek, dat ook voor Nederlandse IT-afdelingen heel herkenbaar is. Dagelijks terugkerende taken lijken steeds zwaarder te wegen en gaan ten koste van het strategisch innoveren van IT-processen voor de langere termijn. Maar uiteindelijk heeft dát meer rendement voor de business. Hoe komt een IT-afdeling uit deze spagaat?
Volg ons
