Systeemintegratie
Simplificatie is een HOAX

In de systeemintegratie en softwareontwikkeling in bredere zin is simplificatie een terugkomend gespreksonderwerp. Maar helaas is er geen magisch toverstokje beschikbaar. De afgelopen 10 jaar wordt er al gediscussieerd over API-gateways ter vervanging van de Enterprise Service Bus; NoSQL ter vervanging van Relationele databases; en REST en GraphQL ter vervanging van SOAP. Allemaal uit naam van simplificatie! Wanneer de Facebooks, Twitters en LinkedIns van deze wereld weer eens een superieure oplossing hebben gecreëerd voor hun probleem, wordt dit gelijk “gepushed” als de oplossing voor alle IT-problemen. Hierbij wordt meestal aan voorbij gegaan aan het feit dat we zelf een heel ander probleem willen oplossen. Ik zie persoonlijk nog steeds een plaats voor alle technieken die ik hier bovenstaand heb benoemd. Er wordt continu nieuw specialistisch gereedschap toegevoegd aan onze gereedschapskist. Dit gereedschap moeten we toepassen waar het in uitblinkt. Dit heeft niet veel met simplificatie te maken, het gaat om het kiezen van het juiste gereedschap voor de klus.

Slecht doordachte simplificatie-initiatieven leiden over het algemeen tot een ongestructureerd IT-landschap vol workarounds.

De regels veranderen

“Simplificatie” is mogelijk, maar er is altijd een trade-off. Je past de regels aan en zal de consequenties moeten ondervinden en accepteren om er succesvol gebruik van te kunnen maken. Over het algemeen, zal complexiteit die je ergens “verwijdert” ergens anders weer de kop opsteken. Mijn definitie van simplificatie is het beheersbaar maken van complexiteit met behoud van de benodigde “flexibiliteit”. Slecht doordachte simplificatie-initiatieven leiden over het algemeen tot een ongestructureerd IT-landschap vol workarounds.

Waarom zou ik een integratielaag implementeren als mijn applicatie API’s prima voldoen?

Service Oriented Architecture

Service Oriented Architecture bestaat alweer zo’n 20 jaar en is in die tijd uitgegroeid tot de meest succesvolle integratie architectuur. Toepassing leidt tot simplificatie van het IT-landschap, maar ook bij deze “simplificatie” zijn er nieuwe regels en wordt complexiteit verplaatst.
Voor het creëren van herbruikbare services moet er vooraf goed worden nagedacht over de te ontsluiten data en de businessprocessen die deze data gebruiken. Daarnaast moet je extra tooling neerzetten om de complexiteit en berichtstromen te beheersen. Zelfs na de eerste implementatie zal je problemen tegenkomen: Zo moet bij aanpassing van een herbruikbare service met meerdere afnemers veel afgestemd worden of er ontstaan meerdere versies van dezelfde service. Ook kan het voorkomen dat alle load wordt gecentraliseerd op de generiek service component.

Service Oriented Architecture implementeren

Een Service Oriented Architecture kun je op meerdere manieren opzetten, de Enterprise Service Bus en de API-gateway zijn de meest bekende implementaties. De overgang van ESB naar API gedreven architectuur wordt de laatste tijd gepromoot als simplificatie en in sommige situaties kan dit ook zeker het geval zijn. Echter vaak is dit vooral een kwestie van smaak en mode.
De populariteit van “REST” API komt voort uit de adoptie vanuit de front-end applicaties waar REST de de facto standaard is voor communicatie met de backend API’s/systemen. Backendsystemen bieden als een gevolg ook steeds vaker REST API’s aan waardoor de adoptie ook vanuit de “achterkant” verder wordt gesteund. Waar ik mij vanuit een architectuuroptiek wel zorgen over maak is het weglaten van een integratielaag uit naam van simplificatie. Waarom zou ik een integratielaag implementeren als mijn applicatie API’s prima voldoen?

Flexibility over optimization

Integratiecomponenten versus backend applicatie API’s

Afnemers direct aansluiten op de API’s van de backendapplicatie klinkt best mooi. De keten één component korter, één component minder te beheren, WINST! Vanuit een architectuuroptiek zouden alle alarmbellen af moeten gaan. De integratielaag heeft namelijk veel toegevoegde waarde! De integratiecomponenten zorgen voor flexibiliteit, ze dragen zorg voor de ontkoppeling en zijn daarmee de “enabler” voor migraties. Door je landschap te ontwerpen rondom je business in plaats van de applicaties voorkom je dat je vastgeroest raakt aan je applicatieleveranciers. Wanneer je gebruik maakt van het Frank!Framework heeft de integratiecomponent ook nog een andere belangrijke functie. Het geeft je een kijkluikje in de keten waardoor eventuele problemen kunnen worden ontdekt en opgelost.
Mijn conclusie is dat deze “simplificatie” je alle flexibiliteit ontneemt. Daarnaast zijn we ook weer terug op de plek waar we 20 jaar geleden zijn begonnen met Service Oriented Architecture. SOA Manifesto geeft mooi aan waar de focus zou moeten liggen: “Flexibility over optimization”.

Relationele databases versus NoSQL databases

Nog een mooi voorbeeld van een gepolitiseerde discussie is de verschuiving van Relationele databases naar de NoSQL databases. Hier geldt weer hetzelfde verhaal. Als je de voordelen wilt benutten zal je de nadelen moeten begrijpen en accepteren. NoSQL kan de perfecte oplossing zijn voor de businessprocessen van Facebook of Twitter maar in veel gevallen is een relationele database nog steeds de best passende oplossing. Wat is nu het verschil? Op de relationele manier ontwerp je je database rondom je data. Tegenover de NoSQL aanpak waarbij je de database ontwerpt met de vraag van de afnemer als uitgangspunt. Relationele databases zijn gericht op dataconsistentie en het voorkomen van redundantie. De querytaal (SQL) geeft de afnemer de mogelijkheid om de door hem benodigde data te onttrekken. NoSQL databases zijn geoptimaliseerd voor performance en lineair schaalbaar. Hierdoor zijn ze duidelijk in het voordeel met grote datasets. Een nadeel is dat de databaseontwikkelaar verantwoordelijk wordt gemaakt voor de dataconsistentie. Conclusie: Maak een keuze op basis van het op te lossen probleem. Beide “gereedschappen” excelleren maar op andere onderdelen.

* NoSQL zijn er in vele soorten van “key-value store” tot “document store” dus bij een keuze voor NoSQL is het belangrijk om ook daar binnen de juiste oplossing te kiezen

Welke mogelijkheden brengt een queue in je integratielandschap?

Queueing versus REST HTTP

Één van de laatste trends in systeemintegratie is de verschuiving van ESB naar API-gateway, ofwel de overstap van queueing naar REST HTTP. Dit lijkt natuurlijk een snelle simplificatie want je kan je queues en alle omliggende infrastructuur opruimen. Maar ook hier is het verstandig om te begrijpen wat je weggooit en welke regels er veranderen. Alleen met deze kennis kan je een gedegen migratieplan opstellen. Wat brengt een queue ons en wat hebben we daarvan nodig?

Persistency / Reliability / Message order
Reliability houdt in dat je berichten over een keten heen kan doorsturen zonder dat het bericht kwijt kan raken of dat een bericht dubbel verwerkt wordt, ook wel “Exactly once delivery” genoemd. Op een queue wordt dit bereikt door een combinatie van persistentie en transactionele verwerking. Als je een vergelijkbaar patroon over http wilt realiseren zal je maatregelen in zowel de verzendende als de ontvangende applicatie moeten nemen. Kwijtraken van berichten zal voorkomen kunnen worden met een retry mechanisme met persistentie in de verzender. Dubbele berichten kunnen worden voorkomen met een duplicate check.

 

Load balancing, Throttling
Als een serviceprovider (een van de nodes) klaar is om een bericht te verwerken vraagt deze aan de queue om het eerstvolgende bericht. De component kan zelf bepalen of het klaar is voor een nieuw bericht. Ook bij het schalen hoeft de nieuwe component slechts contact te zoeken met de queue en kan gelijk aan de slag. In een http wereld zal er minimaal één extra component nodig zijn. Een loadbalancer of een API-gateway.

Queueing

Een queue zorgt ook voor een tijdsonafhankelijkheid tussen de verzender en de ontvanger van een bericht, er ontstaat een wachtrij voor berichten maar de verzender hoeft in veel scenario’s niet op een antwoord te wachten.

Authorization
De meeste queueing implementaties hebben de mogelijkheid om autorisatie toe te voegen. In de HTTP-wereld verschuift deze functionaliteit naar de backend of de API-gateway.

Is dit een reden om niet over te stappen naar de API driven Architectuur? Nee zeker niet, ik probeer hiermee aan te geven dat je zelf  goed moet nadenken om een overwogen beslissing te kunnen maken.

Voorbeeld Exactly once pattern

Simplificatie gaat over het beheersen van de complexiteit met behoud van je flexibiliteit.

De weg naar “simplificatie” in systeemintegratie

Simplificatie start met de implementatie van een architectuur en tooling die samen de complexiteit in je landschap kunnen managen. Daarnaast is het van groot belang om wel overwogen keuzes te maken. Een gedetailleerd beeld te hebben van de impact. Maar vooral de consequenties te accepteren voordat je stappen onderneemt. Simplificatie gaat over het beheersen van de complexiteit met behoud van je flexibiliteit.

Eerste, bepaal hoeveel flexibiliteit jouw organisatie nodig heeft om je business processen te ondersteunen. De prijs die je betaalt voor flexibiliteit is complexiteit. Probeer daarom zo veel mogelijk te standaardiseren, van service definitie tot de ontwikkelde code. Dit zorgt ervoor dat de realisatie vlotter verloopt en de kosten van beheer en onderhoud een beheersbaar blijven.

Tweede, zet jouw business centraal en niet de backend applicaties die je gebruikt. Maar voor mij het aller belangrijkste: bepaal de lange termijn visie en doelen en vertaal deze in een toekomst vaste architectuur.

Derde, ga stap voor stap te werk, agile zoals ze dat nu noemen, maar begin altijd met een plan. De grootste fout die gemaakt wordt is het te snel willen te gaan. Of erger in een grote stap naar je target proberen te gaan. Een Agile approach geeft je de ruimte om technical debt te voorkomen. Maar geeft je vooral tijd om koppeling voor koppeling om te leggen en langzaam toe te werken naar het perfecte plaatje. Bovendien heb je tijdens je migratie op deze manier de kans om je landschap op te ruimen. Bij een Big Bang migratie wordt onder druk vaak ook de “rommel” mee gemigreerd.

Realiseer je dat het glimmende nieuwe systeem van vandaag de legacy van morgen is. Houd je aan de regels van Service Oriented Architecture. Voorkom “tightly coupled” componenten. Maak je klaar voor de volgende migratie.

Jeroen Jansen
van Rosendaal
Founder & Architect

Neem contact op voor een gratis adviesgesprek

E-book: De 10 principes van systeemintegratie toegepast

Ebook thumbnail

Wij zijn ervan overtuigd dat data- en systeemintegratie niet ingewikkeld is en we hanteren daarvoor 10 principes.
Ben je benieuwd? Download ons e-book en kom erachter!

Download e-book