Loosely coupled, thightly coupled, microservices en monolithisch. Hoe is jouw software architectuur opgebouwd?

Als je zoekt naar beschrijvingen, definities of artikelen over software architectuur, DevOps of best practices voor software development kom je een hoop termen tegen die eigenlijk allemaal hetzelfde beschrijven. Maar wat betekenen ze nu eigenlijk? En hoe hebben ze invloed op je infrastructuur, development en de processen van jou als ISV?

 

Wesley Haakman, Intercept

Als je verder kijkt dan alle buzz-woorden  (denk aan Micro Services, Service Oriented Architecture en monolitisch) en je richt op de echte basisprincipes dan zijn er twee strategieën: Loosly coupled and tightly coupled architecturen. Hoewel veel artikelen zich richten op een loosely coupled architectuur kennen beide hun eigen voordelen, wat geheel afhangt van jouw software en de structuur van je organisatie. In dit artikel behandelen we het concept van beide strategieën en heb je achteraf een duidelijk beeld welke architectuur de meeste voordelen voor jouw organisatie oplevert.

Over het algemeen wil je als ISV minimaal één van de volgende voordelen behalen:
-            Korte time-to-market;
-            Flexibiliteit in ontwikkeling, platform en deployment;
-            Minimaliseren van risico’s bij het releasen van nieuwe updates of softwareversies
-            Niet gebonden of beperkt zijn tot specifieke architecturen / talen.

Er zijn meerdere manieren om dit te bereiken en het kiezen van de juiste software-architectuur is daar zeker een van. Wanneer je van plan bent jouw platform of applicatie te modernizeren met behulp van Microsoft Azure dan is het rehosten (of lift and shift) een van de meest gebruikelijke eerste stappen. Rehosting heeft in de meeste gevallen een minimale impact op jouw applicatie, maar het biedt wel direct een subset aan voordelen die Azure te bieden heeft. Echter zou jouw journey daar niet moeten stoppen. Als je van alle voordelen van Azure gebruik wil maken dan is de volgende stap het kijken naar refactoring (herstructureren) of rearchitecting één van de mogelijkheden.

De meeste ISVs zijn al meerdere jaren actief en zijn gestart met een traditionele applicatie waarbij alles wat nodig is voor de juiste performance in die ene applicatie gebouwd is, in één taal. Vaak is het ook het geval dat wanneer je een klein component van je applicatie wil updaten er de mogelijkheid is dat dit impact heeft op de gehele applicatie. Dit maakt het updaten van de applicatie dan ook spannend (duimen bij updates in de hoop dat het goed gaat). Dit zijn kenmerken van veel applicaties, ooit klein gestart en een natuurlijke groei van product en organisatie hebben hiertoe geleid. Dit is kenmerkend voor zogenaamde monolitische applicaties (ofwel, “tightly coupled”). Voor sommige organisaties functioneert dit prima, zeker in kleine teams en een meer statische omgeving.

Maar wat is het alternatief?
Overgaan naar een compleet andere architectuur is niet iets dat in een paar tellen gebeurd is. Het vergt een zorgvuldige planning, waarschijnlijk een aantal technische deep dives met Development en Operations, het opnieuw bekijken van je roadmap, het herzien van je development en release proces en uiteindelijk grondig testen. Maar het is het allemaal waard; een goed opgebouwde applicatie resulteert in meer controle, flexibiliteit, financiële voorspelbaarheid en minder zorgen. Het loskoppelen van de applicatie kan op verschillende manieren worden gedaan en kan in de loop van de tijd gerealiseerd worden.

Waarschijnlijk is een van de beste voorbeelden van het loskoppelen van je applicatie het toevoegen van een zogenaamde message que (of service bus). Hiermee creëer je een scheiding tussen twee componenten op communicatieniveau. Component A stuur een bericht en Component B haalt dit van een centrale plek op en samen vormen Component A, B en de message queue je applicatie.

Met decoupling bedoelen we dus het loskoppelen van componenten welke voorheen afhankelijk waren van elkaars functioneren.

Bijvoorbeeld: ‘’Component A’’ kan nog steeds berichten leveren en doordraaien zonder dat hij moet wachten op ‘’ Component B’’ om dit bericht te accepteren (mocht hij onbereikbaar zijn). Hierdoor wordt het mogelijk om “Component B” te updaten zonder dat dit direct impact heeft op het functioneren van “Component A”. Om dit in perspectief te plaatsen noemen we Component A ‘’orders’’ en Component B ‘’order verwerking’’.

Als we kijken naar een traditionele monolithische architectuur dan is het zo dat wanneer we veel orders binnenkrijgen de performance van het order systeem afhankelijk is van de snelheid waarmee een order verwerkt kan worden. De input (de bestelling) en verwerking van dit proces bestaat nu uit één component. Komen er veel orders binnen maar kunnen deze niet direct verwerkt worden, dan hebben we een “uitdaging”. Namelijk: Wanneer de orderverwerking onbereikbaar is of niet goed genoeg performed dan lopen we het risico dat er bestellingen niet geplaatst kunnen worden, dat zou natuurlijk zonde zijn.

Als we nu ons bestelsysteem zouden "ontkoppelen" en een berichten service (message queue) toevoegen, ontstaat er een situatie waarbij het bestelsysteem altijd de berichten kan afleveren ongeacht de beschikbaarheid of prestaties van het achterliggende systeem. Het onderhouden van de berichten service is vele malen eenvoudiger dan de logica binnen de applicatie en daarnaast zijn dergelijke diensten out of the box beschikbaar (denk aan Azure Service Bus of Event Grid).

We kunnen zelfs op en afschalen wanneer dit nodig is (bij veel bestellingen, denk aan black Friday). Daarnaast kunnen we individuele componenten updaten zonder dat de gehele applicatie hier last van heeft. Dit betekent weinig risico’s bij het updaten en meer betrouwbaarheid van de applicatie.



Over het algemeen is dit wat er bedoeld wordt wanneer we het hebben over loosly coupled architectuur of microservices. We willen dat verschillende componenten onafhankelijk van elkaar functioneren en ze hoeven van elkaar zelfs niet te weten dat ze bestaan. In feite willen we dat elke service een standaard interface heeft waarmee andere services kunne gebruiken en mee kunnen communiceren. Bijvoorbeeld HTTP REST API’s. Ongeacht de taal waarin het component is geschreven of platform waarop het ‘’gedeployed’’.

Natuurlijk is het ontkoppelen van je applicatie zoveel meer dan dit, maar de principes blijven hetzelfde. Het biedt flexibiliteit, schaalbaarheid en meer controle over je architectuur.

Ga los op Azure
Stel je besluit om deze weg in te slaan en afscheid te nemen van de traditionele monolithische architectuur, wat biedt Microsoft Azure dan en hoe gaat dit je helpen

Microsoft Azure biedt een zeer uitgebreide reeks functies waarmee je jouw softwarearchitectuur kunt ontkoppelen, waarvan het merendeel zich bevindt binnen de serverless propositie. De principes achter de serverless architectuur op Azure is dat je niet langer focust op infrastructuur, of het platform. Je concentreert je op ontwikkeling, biedt jouw klant nieuwe functies en betaal je alleen voor de daadwerkelijk consumptie (er wordt pas iets in rekening gebracht zodra de componenten daadwerkelijk worden gebruikt).

Er zijn veel functies op Azure die je kunnen helpen. Wij belichten hieronder de functies die je kunnen helpen bij het ontkoppelen van de software.

Azure-functions
Je kunt bijvoorbeeld besluiten om sommige verwerkingen over te dragen aan Azure Functions, die worden geleverd met standaard HTTP-triggers en eindpunten zodat je alleen de daadwerkelijke verwerking hoeft te focussen. Je factureert alleen op basis van verbruik. Als er niets te verwerken is; geen kosten.

Logische apps
We hebben ook de mogelijkheid om Logic-apps te gebruiken en interface met populaire SaaS-applicaties met behulp van de out-of-the-box-connectoren of om een ​​beetje intelligentie aan Cognitive Services door te geven. En ... volledig configureerbaar via een grafische gebruikersinterface, geen code vereist. 

Azure Service Bus & Event Grid
Zoals eerder benoemd: Een van de gemakkelijkste manieren om te ontkoppelen is om te beginnen met message queuing of event triggers. Azure Service Bus en Event Grid helpen je hierbij. Waar Azure Service Bus je functioneel zal voorzien zoals eerder in dit artikel is vermeld (betrouwbare message queing) biedt Event Grid een aantal andere mogelijkheden.

Met Event Grid kun je events door je omgeving heen routeren op basis van zogenaamde topics en subscriptions. Op basis van triggers worden ontvangen events doorgezet naar de volgende stap in je applicatie. In veel architecturen zien we deze platforms als het 'centrum' voor communicatie.

Databases
Databases zijn ook beschikbaar binnen de serverless propositie op Azure. De meesten mensen zijn al bekend met de Platform as a Service database als Azure SQL en MySQL on Azure SQL. Hoewel Azure SQL zijn eigen use cases heeft, is Azure CosmosDB een goed alternatief (als het bij jouw model past) Dit is een zeer schaalbare database met een lage latency en uitermate geschikt voor de inzet in meerdere regio’s.

Cognitive Services
Hoewel Cognitive Services niet altijd een use case heeft binnen de traditionele applicaties en in de meeste gevallen enige kennis van Artificial Intelligence en Machine Learning vereist, zijn er zeker onderdelen binnen dit portfolio welke je kunnen helpen om ingewikkelde logica te uit besteden aan Azure. Functies zoals tekstanalyse (taal, sentiment) spraakherkenning en search-API's zijn via API's kant-en-klaar beschikbaar en vereisen minimale inspanningen om te implementeren.

Voordelen voor ISV's
Voor jou als ISV zal loosely coupled je op verschillende manieren helpen. Wanneer je niet alleen afhankelijk bent van één monolithische applicatie zullen onderhoud en updates van de applicatie niet meer zo spannend zijn. In plaats daarvan kun jij je meer richten op ontwikkeling, nieuwe functies aan je diensten toevoegen en waarde toevoegen aan het product op een eenvoudigere, beter beheersbare manier. Meerdere teams kunnen aan verschillende diensten werken (denk eraan om interfacing te standaardiseren!) zonder elkaar te hinderen. Je kunt verschillende componenten van de  softwarearchitectuur bijwerken zonder impact op andere services, waardoor er uiteindelijk een kortere time to market ontstaat.

Ten tweede kun je nu verschillende delen van de applicatie schalen wanneer dat nodig is, waardoor alleen de kosten voor die ene service toenemen (bijvoorbeeld "orderverwerking"). Als je ook besluit om "serverless" te gaan, heeft dit een grote impact op de financiële situatie omdat je dan daadwerkelijk op basis van consumptie een rekening zal ontvangen.

Daarnaast geef je de ontwikkelaars meer vrijheid doordat zij in elke taal code kunnen schrijven. Maar probeer dit wel te beperken om te voorkomen dat je straks met een te groot portfolio aan development talen opgescheept zit.

Betekent dit dat tightly coupled of monolothic architecturen ouderwets zijn? Nee, het is echt afhankelijk van de complexiteit van je software, de business doelen en schaalbaarheidseisen. Echter, over het algemeen zien we dat de voordelen van de ontkoppeling de investering meer dan waard zijn.

Gerelateerde berichten