Waarom is een gedistribueerde applicatie-architectuur zo belangrijk?

Een digitale transformatie gaat vaak hand in hand met een met een cloudtransformatie. Om flexibel en wendbaar te kunnen zijn, is het moderniseren van het applicatielandschap een must. Maar welke architectuurstijlen kunnen hier nu voor ingezet worden?

Digitale transformatie staat bij veel organisaties tegenwoordig hoog op de agenda. Digitale toepassingen bereiden zich steeds meer uit en worden steeds belangrijker. Mede door de pandemie zijn digitale toepassingen in een enorme versnelling geraakt. Om aan alle verwachtingen te voldoen en om klaar te zijn voor de toekomst, is digitale transformatie voor veel organisaties geen keuze meer maar een must.

De cloud biedt voor veel organisaties een innovatief, schaalbaar en veilig platform om de digitale transformatie vorm te geven en te implementeren. Diensten kunnen eenvoudig afgenomen worden en applicaties kunnen gebruik maken van alle nieuwe en innovatieve services die beschikbaar gesteld worden vanuit de verschillende cloud providers. Maar om de applicaties goed te laten draaien op een cloudplatform, zijn in de meeste gevallen veel aanpassingen in de applicatie-architectuur nodig.

WAT IS EEN GEDISTRIBUEERDE APPLICATIE-ARCHITECTUUR?

De gedistibueerde applicatie-architectuur is niet nieuw. In 1970 werden de eerste gedistribueerde applicaties al ontwikkeld. Componenten van applicaties werden dan verspreid over verschillende systemen en devices. Historisch gezien waren gedistribueerde systemen en applicaties duur, complex te configureren en moeilijk te beheren. Tegenwoordig is deze vorm van architectuur helemaal ingeburgerd. Alle cloud providers maken gebruik van een gedistribueerd platform, waarmee verschillende services aan elkaar geknoopt worden. Om op een goede manier gebruik te kunnen maken van alle facetten en kracht die cloud providers te bieden hebben, zullen applicaties op een andere manier opgezet moeten worden: met behulp van een gedistribueerde applicatie-architectuur.

In een gedistribueerde applicatie-architectuur worden applicaties opgedeeld in verschillende services, zoals bijvoorbeeld een database service, een messaging service, verschillende APIs, een frontend en meer. Het grote voordeel hiervan is dat applicaties kunnen schalen, er een hogere beschikbaarheid is, de performance drastisch verbeterd kan worden, en de kosten omlaag kunnen. Daarnaast kunnen de verschillende services los van elkaar uitgerold worden, waardoor nieuwe functionaliteiten sneller in productie genomen kunnen worden en bugs sneller worden opgelost.

In dit artikel kijken we welke verschillende architectuurstijlen gebruikt worden om gedistribueerde cloudapplicaties te ontwikkelen.

VERSCHILLENDE ARCHITECTUUR-STIJLEN VOOR GEDISTRIBUEERDE APPLICATIES MICROSERVICE-ARCHITECTUUR

De microservice-architectuur is een architectuurstijl waarbij een applicatie bestaat uit meerdere services die samen een geheel vormen. De verschillende microservices kunnen onafhankelijk van elkaar deployed worden en worden gemodelleerd aan de hand van een businessdomein. Deze verschillende businessfunctionaliteiten worden dan met behulp van APIs aangeroepen. Een microservice is dan ook verantwoordelijk voor de volledige businessfunctionaliteit, dus ook de opslag en het aanroepen van de bijbehorende data. Bijvoorbeeld, een applicatie maakt gebruik van een winkelwagenfunctionaliteit. Deze winkelwagen is een aparte microservice, aanroepbaar door andere microservices door middel van een API. Deze microservice maakt gebruik van een eigen database voor het opslaan van de producten die in de winkelwagen geplaatst worden door de gebruiker.

De microservice-architectuur biedt een aantal voordelen:

• Autonome ontwikkelteams: Met behulp van een microservice-architectuur is het mogelijk om met kleinere en autonome teams te werken, in een Agile setting. Ieder team kan verantwoordelijk zijn voor één of meer microservices, zonder al te veel rekening te hoeven houden met andere onderdelen van de applicaties. Die teams zijn dan volldige verantwoordelijk voor de ontwikkeling, het in productie brengen en onderhouden van de microservices.

• Meer flexibiliteit in technologie: De autonome ontwikkelteams kunnen per microservice bepalen welke technologiestack er gebruikt gaat worden. Bij monolitische applicaties wordt de keuze voor de technologiestack en de programmeertaal van tevoren bepaald. Microservices zijn volledig verantwoordelijk voor een businessfunctionaliteit, volledig afgeschermd en aanroepbaar door APIs. Welke technologiestack en programmeertaal hier dan achter zit, is voor de service die de functionaliteit aanroept niet belangrijk. Zolang er via APIs gecommuniceerd kan worden merkt de aanroeper hier verder niets van.

• Snellere time-to-market: Het opsplitsen van applicaties in kleinere microservices biedt ook de mogelijkheid om nieuwe functionaliteiten en updates sneller in productie te nemen. Bij aanpassingen van de applicatie is het niet meer nodig om de volledige applicatie opnieuw uit te rollen; alleen de aangepaste microservices hoeven vervangen te worden. Door middel van Continuous Integration en Continious Deployment (CI/CD) is het zelfs mogeijk om dit proces volledig te automatiseren.

SERVICE MESH ARCHITECTUUR

Naast het feit dat een microservice-architectuur heel veel voordelen biedt, maakt het een applicatielandschap vaak veel complexer. Vooral voor grotere applicaties kan deze architectuur resulteren in een groot aantal microservices, die ook allemaal met elkaar moeten communiceren, beveiligd moeten worden, en moeten worden beheerd. Een service mesh biedt functionaliteiten om dit eenvoudiger te maken.

Het biedt een proxy die naast de applicatie draait, met behulp van een sidecar pattern. De proxy scheidt de applicatie en businessfunctionaliteit van het netwerkgedeelte, waardoor de ontwikkelaars zich alleen maar op de businessfunctionaliteit hoeven te richten. De service mesh neemt dan de taken voor netwerking, monitoring, security, en load-balancing over. Deze taken kunnen dan ook apart van de businessfunctionaliteit beheerd worden.

EVENT DRIVEN ARCHITECTUUR

Een event driven architectuur wordt gebruikt om in realtime op gebeurtenissen in applicaties te reageren. Deze events worden getriggerd door een actie in een bepaalde microservice. Het event wordt naar een service bus of een event hub gestuurd en van daaruit opgepakt door een andere microservice die op basis van de inhoud van het event vervolgstappen onderneemt. Een voorbeeld hiervan kan zijn: een gebruiker plaatst een nieuwe bestelling op een site. Dit triggert een event, en dit event wordt naar een service bus gestuurd. Op deze service bus zijn een aantal microservices aangesloten, zoals de winkelwagen microservice. Op basis van het event wordt de winkelwagen-microservice getriggerd en voert de volgende stap van de business-flow uit.

In de praktijk zullen deze stijlen vaak in combinatie met elkaar gebruikt worden om cloudapplicaties te ontwikkelen.  In het volgende onderdeel gaan we kijken wat de cloud providers zelf bieden om gedistribueerde cloudapplicaties te ontwikkelen.

CLOUD BEST PRACTICES EN DESIGN PATTERNS

De verschillende cloud providers, zoals Google, AWS en Azure, bieden architecten en ontwikkelaars best practices en patterns aan waar gebruik van gemaakt kan worden om schaalbare, beschikbare, veilige, duurzame en kosteneffectieve applicaties te ontwikkelen. Als je deze verschillende patterns naast elkaar legt, zul je zien dat er heel veel overeenkomsten zijn. Bij alle drie de cloud providers zijn de best-practices en patterns gericht op het migreren en bouwen van hybride en cloud workloads en applicaties. De verschillende cloud providers bieden het volgende aan:

• Google biedt architecten en ontwikkelaars het Google Cloud Architecture Framework aan. Dit framework biedt best practices op het gebied van het ontwerpen en ontwikkelen van systemen en applicaties op het Google Cloudplatform. Het biedt ook patterns voor het ontwikkelen van beveiligde, schaalbare, betrouwbare, beschikbare systemen en applicaties. Daarnaast biedt het ook patterns en best practices om op een kosteneffectieve manier toepassingen te ontwikkelen en te laten draaien in de Google Cloud.

• AWS biedt het Well-Architected Framework aan. Ook hier zijn patterns en best practices opgenomen om op het AWS-platform betrouwbare, veilige, kosteneffectieve en duurzame workloads te ontwerpen en ontwikkelen op de AWS cloud.

• Microsoft Azure biedt ook het Well-Architected framework aan. Dit vertoont veel overeenkomsten met dat van AWS en Google. Ook daar worden best practices en patterns beschikbaar gesteld om applicaties en workloads te ontwerpen en te implementeren die succesvol op het Azure cloudplatform kunen draaien.

Naast een solide applicatie-architectuur en de inzet van best practices en patterns die door de verschillende cloud providers beschikbaar gesteld worden, is er nog een laatste onderdeel dat belangrijk is voor een succesvolle, digitale transformatie: het automatiseren van testen en deployments van applicaties in een cloud omgeving.

Trends en innovatie op het gebied van gedistribueerde applicatie-architectuur Met de enorme groei aan digitale apparaten, applicaties en clouddiensten, zal het aantal applicaties die gebruik maken van een gedistribueerde applicatie-architectuur de komende jaren enorm toenemen.

IDC VOORSPELT HET VOLGENDE:

Tegen 2024 zal er bij de meerderheid van de legacyapplicaties geïnvesteerd zijn in modernizering. Bij 65% van de applicaties zullen cloudservices gebruikt worden om functionaliteit uit te breiden of om inefficiënte code te vervangen.

De meeste organisaties zijn zich ervan bewust dat een ‘lift en shift-migratie’ naar een virtuele machine in de cloud geen voordeel op gaat leveren, op het gebied van schaalbaarheid, flexibiliteit en kosten. Gedeeltelijke of complete herbouw zal dan ook steeds vaker voor komen.

Met de groei van een gedistribueerd applicatielandschap zal ook de behoefte aan monitoring tools en service meshes enorm toenemen de komende jaren.

De komende jaren zullen organisaties ook meer gaan investeren in het automatisch testen en uitrollen van applicaties. Om wendbaar en klaar voor de toekomst te zijn, zullen nieuwe applicaties en functionaliteiten ook sneller gereleased moeten worden. Om dit succesvol te kunnen doen, is het belangrijk om zoveel mogelijk stappen in dit proces te automatiseren. Tegenwoordig is het ook noodzakelijk om overal en altijd te denken aan veiligheid en beveiliging. Security zal in alle lagen ingebouwd moeten worden, dus ook in de applicatielaag en tijdens de uitrol van applicaties. DevSecOps (wat staat voor staat voor Development, Security en Operations) zal dan ook een enorme vlucht gaan nemen de komende jaren.