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
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
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
De echte achitectuurkeuze is natuurlijk of je een DB of message bus gebruikt en niet welke. Zo te lezen gaat dapr daarbij niet helpen.
Ik moest hier eens even diep over nadenken, over wat ik er nu van vond, van Dapr. Aan de ene kant lost zo’n raamwerk natuurlijk weinig tot niks op voor mensen die al weten wat ze aan het doen zijn. En als je niet weet wat je doet dan gaat Dapr dat ook niet oplossen. Voorts is natuurlijk het probleem van ieder raamwerk dat het, om een nuttige abstractie te kunnen zijn, complexiteit moet verbergen, maar dat kan nu net de complexiteit zijn die je nodig hebt voor je echt ingewikkelde “use case” (is daar overigens een goed Nederlands woord voor?).
Ik vetrouw het die muiters van Microsoft wel toe om iets degelijks in elkaar te knutselen, dat is het probleem niet. Ik ben alleen zo bang dat mensen die er niks van begrijpen met Dapr gaan wapperen en dat als bezem gaan gebruiken om andere, betere, ideeën voor het onderhavige probleem van tafel te vegen. Als puntje bij paaltje komt kan natuurlijks niets Diep Nadenken vervangen. Maar als dat Diepe Nadenken dan vervolgens tot een oplossing komt waar Dapr naadloos in past, dan is er natuurlijk niks mis mee. Maar maak het gebruik van dergelijke hulpmiddelen toch vooral geen dogma!