Vroeger was het simpel: je had front end, back end, en database. En toch is dit verre van optimaal. Hoe ziet een architectuur eruit die gebruik maakt van moderne principes en technologieën?

Er zijn heel wat mogelijkheden te overwegen wanneer men de architectuur van een applicatie bepaalt. Dit is nog eens extra het geval wanneer het een applicatie betreft die niet alleen staat, maar op allerlei manieren zal moeten integreren met andere applicaties en diensten, zowel binnen als buiten de eigen organisatie. In een tweedelige blogreeks bespreken we een aantal mogelijkheden die ons worden geboden door een aantal architecturale principes en technologieën, die ik reeds eerder samenvatte als de “Vortex van Enablers“.

In dit eerste deel bespreken we de bovenste regionen van de moderne applicatie architectuur. Alles wat met de interactie met de buitenwereld te maken heeft, zoals clients en 3rd party systemen (die vaak gewoon ook als clients kunnen worden beschouwd). In de volgende blog zal het dan gaan over de meer interne systemen. We beginnen hier met een terugblik op de traditionele 3-tier architectuur.

De 3-tier Architectuur

De 3-tier architectuur kennen we ondertussen stilaan. De verschillende “tiers” die er kunnen bestaan, en de geschiedenis ervan, werden reeds uitvoerig beschreven in de blog Van N-tier naar Microservices.

Deze stilaan verouderde architectuur kent een aantal problemen, niet in het minst qua herbruikbaarheid en integratiemogelijkheden. Zo komt men vaak in de problemen wanneer men nieuwe manieren van interactie wil toevoegen, zoals een mobiele app, of, waarom niet, een conversational interface. Een ander euvel is integratie: wanneer de data nodig is voor andere toepassingen, blijkt de op zichzelf ontworpen 3-tier applicatie vaak te incompatibel, en is men gedwongen de integratie via de data te doen. Dit door ofwel de database te koppelen aan meerdere applicaties via opengestelde fluxen, of d.m.v. het creëren van een duplicaat van de data, dat men dan om de zoveel tijd zal moeten updaten via één of ander ETL mechanisme. Een groot probleem is daarbij ook vaak dat de data semantisch sterk is gekoppeld aan de specifieke applicatiecontext.

Verderop in deze blogreeks gaan we bekijken hoe het beter kan, met een modernere architectuur. Uiteraard is dit echter geen zwart-wit verhaal. De beschreven voorbeeldoplossing zal op een behoorlijk verregaande manier verschillen van de traditionele oplossing, maar er zijn uiteraard ook allerlei tussenoplossingen en middenweg-scenario’s te bedenken. Een zeer eenvoudig voorbeeld is bijvoorbeeld het koppelen van de verschillende tiers binnen zo’n verouderde architectuur via RESTful APIs (zie Fig. 2). Dit is een vaak broodnodige upgrade, die nu reeds op veel plaatsen wordt toegepast. Het is een goed begin, maar meestal nog onvoldoende om de flexibiliteit en herbruikbaarheid te bereiken die we beogen met een echte modernisering.

De Moderne Architectuur, Deel 1

De moderne architectuur bestaat uit de culminatie van een aantal belangrijke architecturale principes, zoals Restful API‘s, Event-Driven Architecture (EDA) en MicroServices, waarover ik reeds meerdere blogs heb geproduceerd (Al deze technologieën maken ook deel uit van de Vortex van Enablers). In de laatste, over Services in alle Maten, gaf ik reeds een uitgebreid, zei het vaag blijvend, voorbeeld over hoe een API (een op clients gericht product !) kan worden geïmplementeerd door een combinatie van (interne) microservices, die met elkaar kunnen communiceren via REST en EDA.

Laten we nu iets concreter ingaan op hoe een modern gebouwde applicatie kan worden gebouwd gebruik makende van deze technologieën. Een dergelijke applicatie staat echter nooit alleen, dus we beschouwen deze samen met zijn onmiddellijke omgeving, bestaande uit clients, maar ook andere applicaties en diensten.

• Front-Facing API Ecosystem

  

  Fig. 3: Symbolisch: De Front End APIs

   

  We beginnen ons verhaal bij de Front End. Dit betekent dat we de modernisering van de eigenlijke client en gebruikers-interface (UI) in deze blog buiten beschouwing laten. Dit betekent echter niet dat daar geen evoluties zouden zijn, of dat de architectuur van een “app” zelf geen modernisering zou behoeven.

  Naar de clients en de buitenwereld toe, zijn APIs de belangrijkste evolutie van de voorbije jaren. Meer en meer zal men APIs zélf gaan aanbieden als product naar derde partijen toe, en eveneens naar andere applicaties en diensten binnen de eigen onderneming. Daarbovenop komt nog dat er een proliferatie is geweest aan verschillende kanalen via dewelke een applicatie kan worden gebruikt. Dit zorgt ervoor dat de front end meer en meer een product op zich wordt, dat zich vooral moet bezighouden met het aanbieden van de nodige faciliteiten voor alle mogelijke vormen van interactie met de buitenwereld, en vooral niet met enige andere zaken, zoals de business logica zelf.

  Omdat het een goed principe is om alles zo modulair mogelijk te maken (hoe kleiner de aparte componenten, hoe makkelijker men ze afzonderlijk kan aanpassen, of zelfs vervangen via het rip-and-replace principe), bekomt men zo uiteindelijk een volledig ecosysteem van gerelateerde APIs, elk bevoegd voor het afhandelen van een bepaald type interactie met de buitenwereld. De API die achter de traditionele web app staat, zal aldus verschillen van de API die gebruikt wordt voor 3rd party clients. Afhankelijk van hoe sterk de verschillen zijn, kan men er al dan niet voor opteren om achter al deze APIs nog een verenigende API te plaatsen, die zaken zal bevatten die door alle extern gerichte APIs kunnen worden (her-)gebruikt. Een uitgebreid voorbeeld zien we in Figuur 4 (vele andere voorbeelden zijn mogelijk; zo zou de mobiele app ook met de webserver kunnen communiceren).

  

  Fig. 4: Een uitgebreid voorbeeld van de “voorkant” van een applicatie. Hier is gekozen om één algemene API te voorzien voor alle aanvragen die vanaf de buitenwereld op de applicatie afkomen, ondersteund door een aantal andere componenten, die zich specialiseren in het afhandelen van verkeer, specifiek afkomstig van: externe partijen die via RESTful API contact willen leggen; een desktop applicatie, die rechtstreeks met de algemene API communiceert; een mobiele app, die via een mobile backend API werkt; en een web-applicatie, waarvan de webserver met de algemene API communiceert. Al deze API’s of applicaties worden geïmplementeerd door één of meerdere microservices. Gele pijlen stellen RESTful communicatie voor, de oranje pijlen zijn specifieke communicatie tussen webserver en -client.

Beschouwingen

Wanneer men het voorbeeld bekijkt, zou men kunnen zeggen dat het er ingewikkelder uitziet dan vroeger, toen dit nog gewoon “de bovenste tier” was. Schijn bedriegt echter: de APIs worden nu gedragen door gespecialiseerde microservices die met elkaar samenwerken. Dit gedistribueerd systeem heeft uiteraard zijn eigen complexiteit, maar de oorspronkelijke tier had die ook in zekere mate: alleen was ze daar geïnternaliseerd binnen één monolithische component.

Verder zijn er heel wat voordelen verbonden aan de nieuwe architectuur: microservices, die via APIs communiceren, kan men veel sneller aanpassen of zelfs herontwikkelen. Hierdoor kan men sneller reageren op veranderende noden van de business. Daarenboven heeft het ook technische voordelen: de communicatie is nu gestandaardiseerd over http, waardoor (soms onverwachte) integraties een stuk soepeler kunnen worden geïmplementeerd. Bovendien kan men microservices apart schalen, en kan het systeem als geheel zich dus veel elastischer gedragen, afhankelijk van de belasting die het ondervindt. Ten slotte zijn microservices het ideale complement van containers: de basis bouwsteen van een moderne Cloud infrastructuur. Typisch zal men één microservice op één container uitrollen.

In het vervolg zullen we zien hoe commando’s (zaken die de toestand van de applicatie kunnen veranderen) en query’s (zaken die informatie opvragen uit applicaties) uit deze bovenste regionen naar de verder liggende backends worden gestuurd en daar worden behandeld. Daar zal ook de kracht van Event Driven Architecture tot zijn recht komen.