Reviews worden geschreven door medewerkers van de redactie of op persoonlijke titel door externe deskundigen.

Architectuurkeuzes uitstellen met Dapr

Dit artikel delen:

Developers worstelen bij het ontwerpen van nieuwe producten of diensten met de vraag: hoe kunnen we ontwerpkeuzes uitstellen tot we echt weten wat de juiste keuze is en ondertussen nog steeds werkende software ontwikkelen? Dapr (distributed application runtime) is een tool die dit probleem wil tackelen. Ik nam de proef op de som en ging aan de slag met deze 'oplossing'.

Als ontwikkelaar van microservices loop je tegen het probleem aan dat je in een vroeg stadium veel belangrijke keuzes gaat maken; ga je inzetten op een message bus of gebruik je directe http-connecties? Welke programmeertaal (of -talen) wil je gebruiken? Heb je een (relationele) database nodig om data op te slaan?

Vervolgens ben je ook nog eens onevenredig veel tijd kwijt aan operationele zaken; hoe configureer je deze diensten? Hoe laat je ze veilig met elkaar communiceren? Hoe draai je updates?

Techniek draaiende houden

"Er is voor developers geen tijd meer over om nieuwe functionaliteit te ontwikkelen"

Kortom, het gebruik van containers en een ingewikkelde software-infrastructuur maken dat je op een bepaald moment alleen nog maar bezig bent met het draaiend houden van de infrastructuur. Er is daardoor voor developers geen tijd meer over om nieuwe functionaliteit te ontwikkelen. Bovendien zullen alle vroegtijdige architectuurkeuzes de software onbedoeld met beperkingen opzadelen, waardoor de ontwikkelaars een deel van hun vrijheid verliezen.

Op basis van welke criteria worden deze ontwerpkeuzes dan gemaakt? Vaak op basis van de bestaande ervaring binnen het team, het beleid binnen het bedrijf en de verwachte serviceniveaus. De keuzes worden dus niet gebaseerd op wat het beste is voor het product, simpelweg omdat in het begin van je project nog onduidelijk is wat de juiste beslissingen zullen zijn.

Het beste zou dus zijn om dergelijke keuzes uit te stellen. De grote vraag is dus hoe je nog steeds werkende software kunt ontwikkelen terwijl je bepaalde keuzes uitstelt. Hoe kunnen we bijvoorbeeld ervoor zorgen dat we ons niet meteen vastleggen om data op te slaan in een S3 bucket bij AWS of een 'storage bucket' in de Google Cloud? Of hoe stellen we de keuze tussen cloud- en edge computing nog even uit?

De dunne lijn tussen framework en bibliotheek

Dapr (distributed application runtime) is een tool die dit probleem wil tackelen. Het is een open source product van Microsoft dat bedoeld is voor elke cloud en programmeertaal. Dapr noemt zichzelf een runtime, en bewandelt feitelijk de dunne lijn tussen het zijn van een framework (dat ten koste gaat van de flexibiliteit) en een bibliotheek (waarvoor weer specifieke taalimplementaties nodig zijn). 

Dapr bestaat uit een set van bouwstenen (zoals service invocation, state, pub/sub, bindings, actors en secrets) die toegankelijk zijn via standaard http- en grpc-api's die vanuit elke programmeertaal kunnen worden aangesproken. Voor elke bouwsteen zijn meerdere implementaties beschikbaar voor de vele toepassingen, diensten en clouds. Deze gebruiken allemaal hetzelfde api-eindpunt. Voor diegenen die geen ruwe http-communicatie willen schrijven, zijn er ook softwareontwikkeltools (sdk’s) beschikbaar voor de meest populaire programmeertalen, zoals .NET, Java, Go, Javascript, Python, Rust en C++.

Geen dure kostenpost

"Het is mogelijk de applicatie in verschillende configuraties in te zetten zonder hier ook maar een regel code voor te moeten schrijven"

Door de manier waarop je in Dapr je afhankelijkheden configureert staan deze nu helemaal los van de functionele code die je schrijft. Dus als je door voortschrijdend inzicht een andere database of message bus wilt gebruiken, is er geen wijziging in de bestaande code nodig. Zelfs niet als je van een lokale omgeving naar een cloudomgeving overgaat. Je bent ook niet gebonden aan een specifieke keuze. Het is mogelijk de applicatie in verschillende configuraties in te zetten zonder hier ook maar een regel code voor te moeten schrijven.

Dat de code niet aangepast hoeft te worden als de infrastructuur verandert, is een belangrijke besparing in tijd en geld. Je kan deze bij nieuwe inzichten immers meteen toepassen om de applicatie beter te maken zonder dat je gebukt gaat onder de gevolgen van eerdere aannames.

Potentie

Er bestaat geen ‘heilige graal’ als het gaat om softwareontwikkeling. De abstractie die de Dapr introduceert heeft ook zijn nadelen. Wat als je een koppeling met een product nodig hebt dat nog niet wordt ondersteund door Dapr? Of een bepaalde functie die je specifieke product ondersteunt, maar deze niet past in de generieke interface? Natuurlijk is Dapr open source, maar is de community bereid om haar tijd te investeren om jouw probleem op te lossen?

Maar met Microsoft als drijvende kracht, en gebouwd als open source, op basis van open standaarden en met het omarmen van meerdere clouds en de edge, heeft Dapr de potentie om een belangrijke tool te worden. Eentje die een antwoord geeft op het hierboven geschetste probleem, ongeacht de programmataal of cloudoplossing waarvoor je je applicatie wilt ontwikkelen.

Met elke drie weken een nieuwe versie van Dapr ziet het er tot nu toe veelbelovend uit. Hopelijk zien we in de toekomst meer applicaties die Dapr gebruiken en laat dit de community groeien.

Michaël Hompus, it-architect bij Info Support

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-05-29T15:13:00.000Z Michaël Hompus
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.