De voordelen van het gebruik van EDA zijn legio. Maar hoe gebruik je nu eigenlijk EDA in de praktijk? Wat als je al een enorm ecosysteem van toepassingen hebt die enkel en alleen via synchrone communicatie worden geïntegreerd en je nog nagenoeg geen business Events publiceert? In deze blog-post stellen we een methode voor om een applicatie te laten evolueren om meer Events te gaan publiceren.

Binnen de instellingen van de Sociale Zekerheid groeit het besef dat Event Driven Architecture (EDA) erg nuttig kan zijn als onderdeel van de integratiestrategie (we hebben hierover reeds uitvoerig geblogd en de belangrijkste voordelen zijn ook samengevat in ons webinar van november). We hebben in ons IT ecosysteem echter al een enorm groot aantal systemen en applicaties die hier nog niet noodzakelijk van gebruik maken. Het zou zonde zijn als we ons voor EDA enkel zouden focussen op nieuwe toepassingen – de belangrijkste business Events in het ecosysteem worden waarschijnlijk al gecapteerd door reeds bestaande diensten. Maar hoe kunnen we er dan voor zorgen dat deze Events effectief via EDA technologie – als effectieve IT Events – worden gepubliceerd en beschikbaar worden in het ecosysteem voor subscribers?

In deze blog zullen we een mogelijke stap voor stap benadering bekijken, waarmee we reeds bestaande toepassingen meer Event-Driven kunnen maken. Niet alleen maar door ze stelselmatig meer Events te laten publiceren (al zal dit een logische eerste stap zijn), maar ook door ze hun eigen Events te laten gebruiken.

Een noodzakelijke disclaimer hier, is dat het Event-Driven maken van toepassingen niet het enige is dat zal moeten gebeuren om te evolueren naar een ecosysteem met een ruim en matuur gebruik van EDA. Wat dit allemaal zou moeten inhouden (b.v. het opzetten van een goede Event Broker), staat momenteel nog ter discussie in onze innovatiewerkgroep, al kunnen we daaromtrent uiteraard onze mening geven in een toekomstige blog-post…

Fase 1: Event-Publicatie, “Na de Feiten”

De eerste stap in het refactoren van een bestaande toepassing is meteen ook de belangrijkste voor het ecosysteem: het publiceren van Events. We moeten dit in eerste instantie als een zuivere toevoeging aan de functionaliteiten beschouwen, zonder enige impact op de reeds bestaande. Daarom zullen we een Event pas publiceren “na de feiten”, i.e. nadat alle zaken die normaal gezien door de toepassing worden gedaan, reeds zijn uitgevoerd.

Laten we kijken hoe we dit kunnen doen voor één Event (we kunnen dit uiteraard herhalen om de toepassing meerdere Events te laten publiceren). Beschouw het (informele) sequentiediagram in Fig. 1: een bepaald commando komt binnen in de toepassing (normaal gezien via een API), en er is besloten dat dit aanleiding geeft tot het voorkomen van een bepaald business Event; we willen dit Event dan ook publiceren als gevolg van het ontvangen commando. De toepassing doet reeds ander werk (“Internal Work”) als gevolg van het commando, en het commando moet worden beschouwd als een transactie (zoals we zien in “Command Transaction”).

Om het Event te publiceren met een minimale impact op de werking van de toepassing, zullen we het (via het “EDA Subsystem”) publiceren nadat we de transactie hebben vervolledigd. In de praktijk zal dit b.v. kunnen door (bínnen de transactie) een extra taak in de toepassing te creëren in een aparte thread, die pas wordt uitgevoerd nadat de transactie is afgewerkt (de “publicatietaak”). Het creëren van deze taak zal een zo eenvoudig mogelijke instructie zijn in de programmatie, met een veel kleinere kans op falen dan het effectieve uitvoeren van de taak, en kunnen we daarom dus veilig binnen de transactie doen.

Wanneer dan, achteraf, de publicatietaak effectief wordt uitgevoerd, zal dit door het EDA subsysteem gebeuren, en zullen we dan effectief het Event publiceren (in eerste instantie kan dit als “mock”: een operatie zonder enig effect, later zullen we het Event effectief aanbieden aan de Event Broker). Aldus komt het Event terecht in het ecosysteem en kan men het nuttig beginnen gebruiken.

Fase 2: Event-Publicatie, “In Transactie”

In fase 1 hebben we, om een zo min mogelijke impact te hebben op de performantie en kans op falen van de transactie, een nogal gekunstelde manier moeten gebruiken om het Event te publiceren búiten de transactie om. Een logische volgende stap is dan ook om het publiceren van het Event onderdeel te laten uitmaken van de transactie. Bijgevolg zullen we dan ook garanderen dat, indien de transactie volledig wordt uitgevoerd, het Event ook wordt gepubliceerd. Dit kan een garantie zijn van groot belang voor de Event subscribers verderop in het ecosysteem, vanaf nu kan men erop rekenen dat álle Events van dat type de revue zullen passeren.

Beschouw nu Fig. 2: het verschil met de vorige tekening is niet groot: we zien nu dat het EDA subsysteem wordt opgeroepen tijdens het uitvoeren van het normale werk als gevolg van het binnenkomende commando. Wanneer het Event is gepubliceerd én het andere werk is uitgevoerd, kan de transactie worden afgewerkt. Publicatie van het Event betekent dat we bevestiging hebben gekregen van de Event Broker dat het goed door deze is ontvangen, maar uiteraard niet noodzakelijk reeds naar de subscribers is gestuurd. Dit is net één van de voordelen van de asynchrone communicatie binnen EDA.

Bij deze fase moeten we er wel op letten dat we op een zeer betrouwbare Event Broker kunnen rekenen. Vermits deze online moet zijn om het Event in ontvangst te nemen tíjdens de transactie, zou de transactie worden geblokkeerd indien er daarbij een fout optreedt. Men zou dit als een nadeel kunnen beschouwen, maar we moeten er aan denken dat het Event kan worden gebruikt als plaatsvervanger van het eventuele rechtstreeks oproepen van alle subscribers, indien deze tijdig op de hoogte moeten worden gebracht van wat er wordt beoogd met het uitvoeren van de transactie. Indien men tijdens het verwerken van het commando normaal gezien beroep deed op achterliggende APIs van andere systemen, kan men deze andere systemen nu in plaats daarvan inschrijven op het Event, waardoor deze API calls niet meer hoeven gebeuren en onze toepassing dus niet langer afhankelijk is van de achterliggende. Op deze manier vermínderen we de kans op falen van de transactie indien de Event Broker betrouwbaarder wordt gemaakt dan de andere achterliggende systemen.

Fase 3: Event-First Programming, Transactioneel

Tot nu toe waren onze wijzigingen in de oorspronkelijke toepassing vrij conservatief: het doel was een reeds bestaand systeem Events te laten publiceren ten voordele van het grotere ecosysteem (we zagen daarbij dat dit in principe kan leiden tot het verminderen van het gebruik van APIs van andere systemen en op die manier tot minder afhankelijkheden).

Vanaf fase 3 zullen we echter ook de eigen toepassing gebruik laten maken van de eigen Events, alvorens, als gevolg van het ontvangen van deze Events, het normale werk te doen. Dit noem ik Event-First programming, en het laat toe om een standaard stramien te hebben om te reageren op binnenkomende informatie: alle belangrijke wijzigingen komen nu binnen via Events. Dat betekent dat we op dezelfde manier zullen reageren op de eigen Events, als op andere Events van het ecosysteem, komende van andere toepassingen.

Beschouw Fig. 3: om de transactie (voor het commando) op te volgen, voeren we een extra controller in. Als eerste stap wordt er nu een Event gepubliceerd als gevolg van het binnenkomende commando. Het EDA subsysteem zal dit Event publiceren, en óók de applicatie zelf (naast eventuele andere in het ecosysteem), zullen er zich voor inschrijven. Wanneer het Event dan opnieuw binnenkomt in de applicatie ten gevolge van de subscription, wordt het effectieve werk uitgevoerd dat de applicatie moet doen ten gevolge van het commando. Om de transactie, ten slotte, te kunnen beëindigen, moet de controller worden ingelicht wanneer het werk is gedaan. Hier zijn we vrij om dit opnieuw via een Event te doen, of op een andere manier (gebruik makend van een of ander bestaand mechanisme voor communicatie tussen threads dat wordt aangeboden door de programmeertaal).

Indien we deze fase voor een toepassing volledig implementeren (i.e. toepassen op álle binnenkomende commando’s), kunnen we de toepassing verder gaan modulariseren volgens het principe van CQRS (Command & Query Responsability Segregation). Dit wil zeggen dat modules die reageren op commando’s apart zullen staan van modules die reageren op queries.

Als u heeft opgemerkt dat het een beetje raar is dat we via een extra controller gaan wachten op een bericht dat het werk, als gevolg van ons Event, is gedaan en we onze transactie nu kunnen beëindigen, dan heeft u gelijk: we hebben deze fase eerder als illustratie ingevoegd om het contrast met de volgende fase te verduidelijken. Maar het lijkt ons eerder aangeraden om fase 3 over te slaan en onmiddellijk gebruik te maken van Eventual Consistency!

Fase 4: Eventual Consistency

Tot nu toe hielden we sterk vast aan de transactionaliteit van het uitvoeren van ons binnenkomende commando. Eigenlijk is dit een kunstmatig opgelegde beperking, die ons ervan weerhoudt maximaal in te zetten op de availability van het ecosysteem (zie: CAP theorema). In fase 4 zullen we gaan vertrouwen in het concept Eventual Consistency: we gaan het commando als uitgevoerd beschouwen, van zodra we zeker zijn dat ons Event is gepubliceerd. We gaan er dan van uit dat de toestand van de applicatie (en, per extensie, van het volledige ecosysteem), na verloop van tijd (“eventually”) consistent zal worden en alle nodige zaken zijn gebeurd als gevolg van het commando (ook in andere toepassingen!). Typisch zal deze tijd redelijk kort zijn; we laten enkel de mogelijkheid open dat het langer kan duren, omdat we het falen van een achterliggend systeem nu kunnen toelaten (zie ook het PACELC theorema).

Beschouw nu Fig. 4: eigenlijk doen we hier hetzelfde als in Fig. 3, maar dan met een vereenvoudiging: er hoeft geen feedback meer te komen van “Internal Work” naar de “Controller” voor het commando. Deze laatste zal nu simpelweg het commando als uitgevoerd beschouwen wanneer het Event is verstuurd (we hadden de extra controller eigenlijk terug weg kunnen laten). Met deze manier van werken verkrijgen we het meeste voordeel uit EDA voor de eigen applicatie (het voordeel voor het ecosysteem kregen we reeds in fase 1).

Besluit

In deze blog-post lieten we een mogelijke, stapsgewijze evolutie zien van een computerprogramma dat bij het uitvoeren van een commando een business Event zou moeten publiceren. In de eerste fases wordt de impact geminimaliseerd; in latere fases wordt de toepassing zelf meer Event Driven gemaakt. Het spreekt voor zich dat deze manier van werken niet de enige goede is, en dat men ook niet steeds álle stappen hoeft te zetten.

We beseffen dat de vier fases zeer verboos zijn gedocumenteerd in dit schrijven; voor programmeurs kan dit nogal overbodig lijken. Maar we richten deze blog ook op niet-programmeurs, zodat voor hen een tipje van de sluier wordt gelicht over hoe programmeurs moeten nadenken over het echte binnenwerk van een toepassing, en hoe dit in verband staat met de communicatie op schaal van het ecosysteem waarbinnen een toepassing opereert.

Het publiceren van herbruikbare business Events is cruciaal voor een groot IT ecosysteem, waarbij integraties, louter op basis van APIs, op langere termijn voor een verminderde resiliëntie en agility kunnen zorgen. Een goed evenwicht tussen integraties via zowel synchrone als asynchrone communicatie, waarbij EDA als evenwaardig wordt beschouwd aan API, leidt tot het meest gezonde ecosysteem van applicaties.

Cet article a été traduit du néerlandais. Les liens peuvent pointer vers des sources en néerlandais.

Dans un article précédent, nous avons discuté de manière générale du potentiel de l’IA générative dans le Software Development Lifecycle. Examinons maintenant la question du point de vue du développeur : quel est l’état d’avancement de la génération de code et que devons-nous encore prendre en compte ? Pour faire court : les assistants IA ou les plugins pour IDE sont une aubaine pour ceux qui savent en faire bon usage, mais comme tous les systèmes d’IA, ils présentent aussi des inconvénients.

Avant-propos

Une partie de cette hype en termes d’IA générative est propulsée par des modèles de langages puissants – les grands modèles de langue ou LLM. Depuis la sortie du GPT-3 en 2020, ces modèles parviennent à écrire des textes normaux d’une certaine longueur. De là, il n’y a qu’un pas vers les langages de programmation. En effet, ils ont aussi une syntaxe et une sémantique.

Dans la pratique, il existe de nombreuses variantes de modèles de langue, chacun ayant ses forces et ses faiblesses, en fonction des choix faits par les créateurs pour les entraîner, et en fonction des données d’entraînement qui les sous-tendent. Testez vous-même certains des modèles open source existants sur votre propre ordinateur via l’outil GPT4All (voir également notre quick review de cet outil).

Le code informatique consiste en une collection de fichiers texte. Rien n’empêche un modèle de langue d’essayer de prédire les différents tokens (= unités grammaticales) qui composent le code, plutôt que des mots. Cependant, contrairement au texte brut, le code a beaucoup moins de tolérance à l’erreur : la moindre faute d’orthographe ou la plus petite variation peut invalider un morceau de code ou lui faire exécuter quelque chose de complètement différent.

Pourtant, aujourd’hui, les plus grands modèles de langue, tels que GPT-3.5 et les versions ultérieures, peuvent produire d’eux-mêmes des morceaux de code informatique tout à fait corrects en réponse à une requête. Cette fonctionnalité est due à la quantité massive de textes sur lesquels ils sont formés, notamment de nombreux tutoriels, articles de blog, questions et réponses provenant de forums de développeurs populaires tels que StackOverflow, et code documenté provenant de repositories de code publics tels que Github.

Canards en plastique bavards

Depuis Socrate, le dialogue est un moyen efficace de parvenir à de nouvelles perspectives. Ce n’est pas pour rien que le rubber ducking est une méthode de correction de bugs qui revient dans tous les cours de génie logiciel. Il existe entre-temps plusieurs plugins qui mettent à disposition une interface de chat alimentée par l’IA dans l’IDE même (par exemple ceux pour VS Code, beaucoup d’autres peuvent être trouvés via les marketplaces pour VS Code ou IntelliJ IDEA). Si ces plugins utilisent un service cloud externe, il vous suffit d’entrer votre propre clé API.

Un cadre de dialogue avec une dynamique de questions-réponses peut être bien utilisé pour générer des morceaux de code relativement autonomes, sans trop de dépendances externes. En général, pour obtenir le meilleur résultat, il faut pouvoir énoncer facilement toutes les conditions préalables et les hypothèses nécessaires dans le dialogue lui-même, de manière à ce qu’il s’inscrive dans la fenêtre contextuelle du modèle de langue. Les use cases comprennent entre autres :

• La génération from scratch d’une version initiale du code ou d’un fichier de configuration
• La génération de fonctions ou de procédures relativement courtes à partir d’une description
• La génération de code snippets autonomes : requêtes SQL, expressions régulières…
• Demande de modification d’un morceau de code ou d’un fichier de configuration
• Correction de bugs : recherche d’erreurs dans un code qui ne fonctionne pas, poser des questions sur une erreur
• Faire expliquer ce qu’un morceau de code fait

Les plus grands modèles de langue disposent de fenêtres contextuelles de plusieurs milliers de mots dans lesquelles il est possible d’insérer toutes les informations nécessaires. Un modèle de langue open source plus petit, installé localement sur du matériel moins puissant, sera sans aucun doute moins performant. Voici quelques exemples de conversations avec GPT-4 d’OpenAI, qui montrent qu’il est possible d’aller très loin avec quelques questions bien ciblées (cliquez sur l’image pour obtenir la pleine résolution) :

Complétion de code sous stéroïdes

Au cours du développement, un développeur travaille sur de nombreux fichiers dans un IDE. À des endroits aléatoires de ces fichiers, le code doit être modifié, supprimé ou écrit. L’édition de code existant de cette manière n’a pas grand-chose à voir avec le dialogue ; en fait, nous préférerions utiliser l’auto-complétion avancée dans ce cas. Les modèles de langue peuvent également faire l’affaire, mais les modèles les plus appropriés sont plutôt ceux formés aux tâches de “remplir au milieu” – et qui peuvent donc prendre en compte le code présent avant et après l’endroit que l’on édite.

Après la sortie de GPT-3, OpenAI a travaillé avec Microsoft (qui possède Github) pour créer un modèle de langue spécialisé, formé exactement pour ce use case. Cette variante a été nommée Codex, et le premier outil à l’utiliser a été Github CoPilot. Depuis, nous en sommes à plusieurs versions, mais les plugins pour VSCode et IntelliJ fonctionnent toujours de la même manière : via un raccourci clavier dans l’éditeur, on peut utiliser CoPilot pour récupérer diverses suggestions, générées par Codex, qui pourraient correspondre à l’endroit où se trouve le curseur.

D’après notre expérience actuelle, le contexte pris en compte est généralement limité au contenu (partiel) du fichier édité. Cela implique évidemment le téléchargement vers le modèle de langue – veillez donc à respecter les directives en matière de confidentialité lorsque vous utilisez un service externe. Pour l’instant, nous semblons obtenir de meilleurs résultats dans les projets de programmation composés de quelques gros fichiers, tels que les pages web avec JavaScript en ligne, ou Jupyter Notebooks en Python, où il y a souvent un gros fichier à parcourir qui contient à la fois la documentation, le code et l’output. En revanche, dans les projets comportant de nombreux petits fichiers, il semble plus difficile de générer de bonnes suggestions, et il est plus important de disposer d’une documentation supplémentaire dans le fichier édité afin que le modèle de langue puisse puiser dans suffisamment d’informations contextuelles.

L’une des alternatives les plus intéressantes au modèle commercial Github CoPilot est StarCoder, un modèle open source issu de l’initiative BigCode HuggingFace et ServiceNow. Bien que la performance soit moindre que CoPilot, ils font la différence dans de nombreux autres domaines qui peuvent être des obstacles dans des contextes commerciaux ou publics :

• Entraînés sur un dataset public : The Stack. Bien qu’il ait été collecté par scraping, il ne contient que du code avec des licences logicielles permissives, et les développeurs peuvent, s’ils le souhaitent, toujours faire retirer leur code du dataset.
• Comprend un outil de vérification de plagiat, qui permet de vérifier que les suggestions générées n’ont pas été copiées mot pour mot à partir des données d’apprentissage (éventuellement protégées par des droits d’auteur).
• Pourvu d’un filtre d’informations sensibles, qui détecte les adresses électroniques, les clés API et les adresses IP (pas exact à 100 %).
• Contient des instructions pour installer localement, ainsi qu’un plugin VSCode. Un plugin IntelliJ a entre-temps également été développé par un tiers.
• Le modèle standard a une taille de 15 milliards de paramètres et nécessite au moins 60 GB de RAM ou autant de mémoire GPU (en fonction de l’utilisation ou non d’un GPU) pour être utilisé. Il existe également de plus petits modèles à 7, 3 ou 1 milliard de paramètres, ainsi que des versions quantisées utilisant des types de données à 4 bits, sans grande perte de précision.

Plusieurs autres systèmes ont vu le jour cet été et ont obtenu de bons résultats dans de nombreux benchmarks : WizardLM et sa variante spécifique WizardCoder, qui est désormais considéré comme le nec plus ultra de l’open source, et PanGu-Coder, avec lequel Huawei s’est également lancé dans le monde des assistants IA pour le code. 

Au cœur de l’action

Le StarCoder paper offre un bel aperçu du fonctionnement d’un modèle de langue pour le code.
Ce n’est certainement pas comme si vous pouviez “brancher” votre propre codebase pour obtenir des suggestions adaptées. Si vous voulez vraiment affiner le modèle (et vous ne ferez cet énorme effort que si vous n’y arrivez pas avec des modifications astucieuses du prompt), il y a beaucoup de choses à faire, du prétraitement des données d’entraînement au post-traitement de l’output brut du modèle de langue. Ne vous attendez pas non plus à ce que le réglage fin soit trop élevé : StarCoder l’a fait pour Python, mais n’a obtenu que quelques points de pourcentage d’amélioration par rapport au modèle global qui pourrait traiter tous les langages de programmation. Le peaufinage est difficile et il n’y a aucune garantie de succès ; il y a même un risque d’overfitting, ce qui pourrait dégrader les résultats.

L’étape la plus importante est probablement la collecte et le nettoyage des données. Ces données sont constituées de code, mais tous les codes ne sont pas inclus : vous devez également être autorisé à utiliser le code (licences) et, de préférence, l’avoir aussi correct que possible et écrit dans le langage de programmation que vous souhaitez soutenir. Le code est également collecté à partir des issue trackers et du commit history. En outre, un filtrage additionnel peut être effectué pour supprimer les (quasi-)doublons, et des pondérations peuvent être attribuées ici et là pour maintenir l’équilibre : un peu moins de poids pour le code “boilerplate”, et/ou un peu plus pour les repositories très populaires qui sont susceptibles d’être de meilleure qualité. Le code source peut contenir des informations sensibles qui doivent être rendues anonymes ou supprimées au préalable, pour éviter qu’elles ne soient divulguées ou suggérées (adresses IP, mots de passe, identifiants, adresses électroniques, coordonnées…). Tout cela, bien sûr, de préférence aussi automatiquement que possible.

Le code source se compose non seulement de code, mais aussi de descriptions, de commentaires et d’autres informations. Dans une étape de formatage, le code est donc enrichi par l’ajout de métadonnées et de tokens supplémentaires qui rendent explicites certaines structures implicites. Cela peut avoir des conséquences : si tout ce prétraitement a été effectué sur l’ensemble des données d’apprentissage, le modèle résultant ne fonctionnera correctement sur de nouvelles données que s’il a subi le même prétraitement. Ainsi, les plugins éditeur qui souhaitent utiliser un tel modèle peuvent, pour obtenir un bon résultat, devoir d’abord effectuer un prétraitement similaire sur le code qu’ils souhaitent envoyer au modèle de langue.

Exactitude et autres benchmarks

Comme c’est le cas pour les LLM, il ne peut y avoir de garantie concluante de l’exactitude ou de l’exhaustivité de ce qu’un tel plugin présente, tant sur le plan syntaxique que sur le plan sémantique. Cette précision est évidemment importante : un morceau de code généré ne doit pas seulement être syntaxiquement correct et compiler sans faille, mais aussi être sémantiquement significatif et s’exécuter correctement. La métrique “pass@x” est devenue une mesure importante à cet égard. Elle exprime en pourcentage si un modèle de langue pour une mission donnée peut passer avec succès les tests correspondants après X tentatives. “pass@1” est le pourcentage pour lequel le modèle de langue utilisé pour la première fois a pu générer la bonne réponse, “pass@10” est le pourcentage pour lequel au moins 1 tentative sur 10 a été correcte.

Dans le monde de l’IA générative, il existe un besoin général de pouvoir comparer les nouveaux modèles, qui apparaissent désormais presque quotidiennement, avec le meilleur de la technologie. Il n’y a donc pas de pénurie de benchmarks, et de nouveaux modèles plus importants apparaissent régulièrement. Des résumés utiles sont les “leaderboards”, qui montrent en temps réel quels modèles représentent l’état actuel de la technique selon une série de benchmarks. L’étape peut changer chaque semaine. Voici quelques leaderboards généraux intéressants :

• Papers with Code : l’état de l’art dans diverses tâches d’intelligence artificielle, avec des documents d’accompagnement.
• Stanford HELM : analyse comparative d’un large éventail de tâches en se focalisant sur le “human reasoning” (raisonnement humain).
• LMsys.org FastChat : se concentre sur les capacités chatbot.
• HuggingFace OpenLLM leaderboard.
• LLM-Leaderboard.

En ce qui concerne le code, il existe des benchmarks qui fonctionnent plus ou moins comme un concours de programmation. L’idée est de confier un ensemble de tâches au modèle de langue, d’évaluer les résultats automatiquement et de mesurer le “pass@1” et, si possible, d’autres paramètres. Souvent, il s’agit de “remplir la fonction” : à partir d’une description de l’input, de l’output et d’un function header, le contenu de la fonction doit être généré. L’inconvénient est que ce type de problème n’est parfois pas très représentatif de celui auquel est confronté le développeur lambda. Parmi les initiatives intéressantes, on peut citer :

• HuggingFace Big Code Models leaderboard (uniquement LLM publics).
• Microsoft CodeXGLUE : évaluation de diverses sous-tâches selon des méthodes connues de Natural Language Processing. Ce leaderboard semble dépendre de contributions volontaires et est quelque peu incomplet.
• Papers with Code a des sections séparées pour la génération de code, la création de documents, la synthèse de programmes entiers et la correction de bugs.
• Le HumanEval dataset et MBPP dataset : problèmes de programmation typique (Python).
• Le DS-1000 dataset : ensemble de problèmes de data processing / data science concrets.
• HumanEval-X ou MultiPL-E : versions multilingues de HumanEval, mesurant les performances dans plusieurs langages de programmation.

Bien entendu, le fait qu’un morceau de code généré survive aux tests ne signifie pas qu’il s’agit d’un code sécurisé ou qu’il respecte les “best practices”. Entre-temps, il existe de nombreux exemples connus de code généré qui s’avère sensible aux “buffer overflows”, à l’injection SQL et à d’autres risques classiques. Le benchmark de sécurité “Asleep at the Keyboard” consiste en 89 scénarios de génération de code basés sur la liste MITRE top-25 vulnerability. Starcoder paper montre que même les meilleurs modèles génèrent encore du code non sécurisé dans 40 % de ces scénarios. En outre, il ne semble guère y avoir de différence entre les meilleurs modèles et les autres – le choix d’un meilleur modèle semble garantir des résultats syntaxiquement plus corrects, mais pas encore un code plus sûr. Il est donc possible que nous devions nous pencher sur les données d’apprentissage elles-mêmes, où le code non sécurisé devrait être encore mieux filtré. Quoi qu’il en soit, il convient de rappeler que l’utilisation de code généré dans un projet doit impérativement s’accompagner d’une solide politique de test et d’acceptation.

Performance

En ce qui concerne plus particulièrement les exigences computationnelles, le leaderboard Huggingface OpenLLM-perf et les benchmarks sur le site web TextSynth Server constituent des sources intéressantes. Ce dernier montre quelques chiffres de performance utiles pour ceux qui envisagent un hébergement par leurs propres moyens. Ceux qui n’ont pas de GPU peuvent compter sur une vitesse de 12 tokens par seconde avec le modèle LLaMa2 de 13 milliards de paramètres, avec un processeur de serveur EPYC 7313 relativement haut de gamme. Dans un code informatique, un token ne représente parfois qu’un seul caractère, de sorte qu’à cette vitesse, il faut parfois attendre une dizaine de secondes pour obtenir une suggestion de complétion de code. La dernière carte graphique RTX-4090 peut le faire 7 fois plus vite, mais pas encore au point de l’exprimer en millisecondes.

Les besoins en mémoire sont proportionnels au nombre de paramètres d’un modèle, et la vitesse de génération inversement proportionnelle. À titre d’approximation, on peut supposer qu’un modèle comportant 13 milliards de paramètres doit également effectuer 13 milliards de calculs pour chaque token de sortie, même s’il ne comporte qu’un seul caractère. En outre, si chaque paramètre est un nombre de 32 bits, il faut au moins 52 Go de stockage et autant de mémoire (V)RAM. Une “quantization“, arrondissant les paramètres à 8 bits ou même à 4 bits, peut réduire proportionnellement ce besoin en mémoire.

GPT4All permet de l’essayer sur votre propre matériel. Cela donne une idée de l’énorme puissance de calcul qu’OpenAI, Microsoft Azure ou Amazon AWS déploient pour que leurs modèles, dont beaucoup sont encore plus grands que les LLM disponibles en libre accès, fonctionnent aussi vite qu’ils le proposent. On parle d’investissements de milliards de dollars en matériel informatique, si importants qu’ils déstabiliseraient le marché mondial.

Même les solutions open source sont loin d’être légères, en dépit des grandes initiatives d’optimisation. On peut en tout cas supposer que le déploiement local n’est possible que sur du matériel récent et puissant. Actuellement, on ne peut pas s’attendre à ce qu’une installation locale sur un ordinateur portable de bureau moyen offre une expérience fluide à l’utilisateur.

Productivité

Internet regorge de contes de fées sur le développeur 10x, et les gourous de l’IA générative aimeraient vous faire croire que cette technologie peut élever n’importe quel programmeur à ce niveau. La réalité est plus nuancée. Les développeurs ne passent pas 100 % de leur temps à écrire du code, pas plus que les médecins ne passent 100 % de leur temps à rédiger des ordonnances. La majorité des développeurs passe moins d’une heure par jour à coder. Le reste de leur temps est consacré à l’analyse, à la lecture, à l’apprentissage, aux tâches de maintenance, à la communication, etc. Jusqu’à présent, cette réflexion et cette consultation avec les collègues ne sont pas comprimées par l’emploi de LLM.

Il est difficile de trouver des chiffres précis sur la productivité parce qu’elle est difficile à définir et donc à mesurer. Une première estimation utile provient de Google même, qui a examiné le temps d’itération (de la connaissance du problème à la solution). Avec une première version de son propre assistant de complétion de code par l’IA, l’entreprise a pu constater un gain de temps de 6 %. Github affirme que le codage pur peut être environ 55 % plus rapide avec son CoPilot – bien qu’il précise dans le même temps que l’intervalle de confiance à 95 % de sa mesure est de [21 %-89 %]. En outre, l’adoption d’un outil n’apporte aucune valeur ajoutée si elle n’est pas accompagnée d’un parcours pour apprendre à l’utiliser de manière optimale (tout comme aujourd’hui encore, de nombreux employés de bureau perdent du temps avec Office en raison d’une connaissance ou d’une expérience insuffisante de tous les types de références, de formules et de raccourcis).

Le code généré fournit une solution initiale rapide, mais cette solution doit encore être comprise par le programmeur. Un score “pass@1” de 50 % signifie que la moitié des bouts de code générés nécessitent encore des ajustements manuels avant de passer les tests unitaires – sans parler de l’optimalité ou de la sécurité. Le code généré peut être complexe et utiliser des constructions qui dépassent le niveau de connaissance du programmeur. Le code généré est donc plus difficile à maintenir et à corriger que le code écrit manuellement. Un code généré qui n’a pas été correctement examiné et testé ajoute une dette technique considérable à un projet.

L’utilisation de plugins qui vont jusqu’à générer des blocs entiers de code et de documentation en un claquement de doigts (ou un peu plus lentement) n’est une bonne idée que si plusieurs autres aspects du processus d’ingénierie logicielle sont en ordre : des normes élevées doivent être maintenues dans tous les domaines en termes de stratégie de test, de code reviews, de documentation de code et de savoir-faire des développeurs.

Confidentialité

Les entreprises et les gouvernements ont rarement le luxe d’utiliser n’importe quel modèle de langue. Il existe non seulement des barrières contractuelles, mais aussi des questions de confidentialité, en particulier lors de l’utilisation du cloud. Après tout, on n’obtient une bonne suggestion de modèle de langue qu’en introduisant suffisamment d’informations au préalable. Ne pas tout mettre en place en interne implique inévitablement de donner à un tiers l’accès à vos données.

Le degré d’ouverture et de licence peut varier considérablement – à un extrême, tout est en “boîte noire” et uniquement accessible via le cloud/API (c’est là que vous trouverez OpenAI, Anthropic, Cohere et la plupart des autres start-ups établies). Celles-ci promettent dans les versions Enterprise parfois plus de garanties – mais vous n’avez pas d’autre choix que de les croire sur parole. À l’autre extrême, tout est en “open access” (libre accès) et sous licence permissive. Entre les deux, une entreprise peut également construire un modèle de langue en libre accès sur un dataset fermé. Au moins un de ces datasets a depuis été divulgué comme contenant des ebooks illégalement copiés et protégés par le droit d’auteur, ce qui constituera sans aucun doute un argument de poids dans le recours collectif intenté contre Meta sur ce sujet. Les ensembles de données des Code LLM Salesforce CodeGen et Tsinghua CodeGeeX ne sont pas non plus publics.

Transparence, licences, options de déploiement, prix, taille et scalabilité… l’importance relative de toutes ces caractéristiques dictera les outils que vous pourrez utiliser. Ceux qui souhaitent une transparence maximale seront souvent limités aux LLM en Open Access. Certaines licences ouvertes limitent en outre l’utilisation à des fins non commerciales. La nécessité d’accéder à des données de formation ou la facilité d’héberger soi-même une instance sur site limitent davantage les choix.

Conclusion

Les outils basés sur le dialogue (chatGPT et autres) peuvent vous être utiles en tant que développeur pour, entre autres, les tâches suivantes :

• Initialiser un projet/fichier/classe/configuration : créer une première version de quelque chose
• Correction de bugs et modification sous forme de questions-réponses
• Morceaux de code relativement indépendants

Les outils qui complètent le code ou remplissent le code manquant (type Github Co-Pilot) sont utiles, entre autres, pour :

• Compléter du code à partir d’exemples déjà réalisés
• Documenter le code
• Apporter des modifications au milieu d’un fichier plus volumineux

Pour un développeur, l’environnement de développement optimal est quelque chose de tout à fait personnel et chacun aura sa propre préférence. À notre avis, ces deux façons d’obtenir des suggestions de code sont quelque peu complémentaires, et une combinaison intelligente des deux peut permettre d’obtenir les meilleurs gains de productivité. Dans le même temps, nous tenons à dire qu’une gestion de projet saine, avec une attention portée à la qualité du code, aux tests, aux révisions, à la documentation, etc. est indispensable.

Le monde de l’IA est en pleine effervescence. De nouveaux modèles d’IA pouvant servir de base aux plugins IDE sont ajoutés avec une grande régularité. Pour les industries où la confidentialité du code est importante, les variantes open source sont très intéressantes. Même si les benchmarks montrent qu’ils sont encore moins performants aujourd’hui que les dernières initiatives commerciales basées sur le cloud, nous pouvons nous attendre à ce que de meilleures versions apparaissent à l’avenir. De nombreux efforts sont déjà déployés pour créer des modèles pouvant fonctionner sur du matériel grand public (certes haut de gamme).

P.S.

Quelques heures après la publication de cet article, HuggingFace annonce la venue de SafeCoder : une solution d’entreprise pour les assistants de codage basés sur LLM qui peut être déployée sur site. Huggingface fournit le tout dans des conteneurs qui peuvent être installés dans un data center propre et fournir des endpoints privés, ainsi que des plugins compatibles avec les principaux IDE. D’autres frameworks de déploiement général existent depuis un certain temps, notamment Seldon, BentoML et KServe, qui peuvent également héberger des LLM, TextSynth Server et GPT4All peuvent fonctionner comme des endpoints d’API. Cependant, vous avez toujours besoin de plugins pour les utiliser dans l’IDE lui-même, et pour effectuer les traitements préalables et postérieurs nécessaires – et s’ils ne sont pas fournis, vous devez en créer un vous-même ou modifier un plugin existant.

P.P.S.

Ces derniers mots à peine écrits, Meta a lancé CodeLLama, une variante de LLaMa 2 spécifiquement entraînée pour le code. Les médias sociaux suggèrent qu’il est possible de faire tourner la version originale avec 34 milliards de paramètres sur un ordinateur équipé de 4 GPU RTX3090 avec 24 GB de VRAM chacun, générant environ 20 tokens par seconde. Il est sans doute plus facile d’essayer la version de chat en ligne. Les versions quantisées suivront sans doute très prochainement, et nous attendons les premiers benchmarks sur les différents leaderboards.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

In een vorig artikel bespraken we op algemene wijze het potentieel van generatieve AI in de software development lifecycle. Laat ons nu eens kijken vanuit het standpunt van de developer: wat is de stand van zaken wat betreft het genereren van code, en waar moeten we nog rekening mee houden? Lang verhaal kort: AI-assistenten of -plugins voor IDEs zijn een zegen voor wie ze goed kan aanwenden, maar komen, zoals alle AI-systemen, ook met de nodige caveats.

Vooraf

De hype qua generatieve AI wordt onder andere gestuwd door krachtige taalmodellen – Large Language Models of LLMs. Zeker sinds GPT-3 uitkwam in 2020, slagen die erin om normaal uitziende teksten te schrijven van enige lengte. Van daar is het maar een korte sprong naar programmeertalen – die hebben immers ook een syntax en semantiek.

In de praktijk bestaan er talloze varianten van taalmodellen, die elk hun sterktes en zwaktes hebben, al naargelang de keuzes die de makers hebben gemaakt bij het trainen ervan, en al naargelang de trainingsdata die eraan ten grondslag liggen. Probeer bijvoorbeeld zelf enkele van de bestaande open source modellen uit op je eigen computer via de tool GPT4All (zie ook onze korte review van deze tool).

Computercode bestaat uit een collectie van tekstbestanden. Niets verhindert dat een taalmodel, in plaats van woorden, de verschillende tokens ( = grammaticale eenheden) waaruit code bestaat, probeert te voorspellen. In tegenstelling tot gewone tekst is er bij code echter veel minder ruimte voor fouten: de kleinste spelfout of variatie kan een stuk code ongeldig maken of iets helemaal anders laten uitvoeren.

Toch kunnen de allergrootste taalmodellen, zoals GPT-3.5 en later, vandaag uit eigen beweging vrij correcte stukken computercode produceren in een antwoord op een vraag. Deze functionaliteit is het gevolg van de massieve hoeveelheid tekst waarop ze getraind zijn, waaronder talloze tutorials, blogartikels, vragen en antwoorden uit populaire developerfora zoals StackOverflow, en gedocumenteerde code uit publieke code repositories zoals Github.

Babbelende badeentjes

Al sinds Socrates is de dialoog een beproefde manier om tot nieuwe inzichten te komen. Niet voor niets is rubber ducking een methode voor debugging die ter sprake komt in elke cursus software engineering. Er bestaan ondertussen verschillende plugins die een AI-powered chat-interface in de IDE zelf beschikbaar stellen (bvb deze voor VS Code , vele andere kunnen gevonden worden via de marketplaces voor VS Code of IntelliJ IDEA). Als die gebruikmaken van een externe cloud-dienst moet je daarbij enkel nog je eigen API-key ingeven.

Een dialogerende setting met een vraag-antwoord dynamiek kan goed aangewend worden voor het genereren van relatief op zichzelf staande stukken code, zonder te veel externe afhankelijkheden. In het algemeen kan je stellen dat je, voor het beste resultaat, alle noodzakelijke randvoorwaarden en aannames gemakkelijk in de dialoog zelf moet kunnen vermelden, zodat het binnen het context-venster van het taalmodel past. De use cases omvatten onder andere:

• From scratch genereren van een eerste versie van code of een configuratiebestand
• Genereren van relatief korte functies of procedures aan de hand van een beschrijving
• Genereren van op zichzelf staande code snippets: SQL queries, reguliere expressies, …
• Vragen om een aanpassing aan een stuk code of een configuratiebestand
• Debugging: fouten zoeken in niet-werkende code, vragen stellen over een error
• Laten uitleggen wat een stuk code doet

De grootste taalmodellen hebben ondertussen contextvensters van duizenden woorden waarin je alle nodige informatie kwijt kan. Een kleiner open-source taalmodel, lokaal geïnstalleerd op minder krachtige hardware, zal ongetwijfeld minder goed presteren. Enkele voorbeelden van conversaties met OpenAI’s GPT-4 staat hieronder – hieruit blijkt dat je al heel ver kan geraken met een paar welgemikte vragen (klik voor de volledige resolutie):

Code completion on steroids

Tijdens het ontwikkelen werkt een developer aan talloze bestanden in een IDE. Op willekeurige plekken in die bestanden moet er code aangepast, verwijderd of geschreven worden. Het bewerken van bestaande code op deze manier heeft weinig te maken met dialogeren, eigenlijk willen we hier eerder een geavanceerde auto-complete inzetten. Ook dat kunnen taalmodellen goed, maar de meest geschikte modellen zijn eerder diegene die getraind zijn op “fill in the middle” taken – en die dus rekening kunnen houden met de aanwezige code voor én na de plek die men aan het bewerken is.

Na het uitbrengen van GPT-3, werkte OpenAI samen met Microsoft (dat Github bezit) aan een gespecialiseerd taalmodel dat voor exact deze use case werd getraind. Deze variant werd Codex genoemd, en de eerste tool die ervan gebruikmaakte was Github CoPilot. Ondertussen zijn we al enkele versies verder, maar de plugins voor VSCode en IntelliJ werken nog op dezelfde manier: via een sneltoets in de editor kan men via CoPilot verschillende suggesties opvragen, gegenereerd door Codex, die zouden kunnen passen op de plek van de cursor.

Voor zover onze ervaring vandaag reikt, is de context die daarbij in rekening wordt genomen vandaag meestal beperkt tot (stukken van) de inhoud van het bewerkte bestand. Daarbij wordt uiteraard code geüploaded naar het taalmodel – let dus zeker op richtlijnen qua confidentialiteit bij gebruik van een externe dienst. Vooralsnog lijken we betere resultaten te krijgen bij programmeerprojecten die bestaan uit weinig grote bestanden, zoals webpagina’s met inline JavaScript, of Jupyter Notebooks in Python, waarbij vaak sprake is van 1 groot bestand dat doorlopen wordt waarin zowel de documentatie, de code als de output staat. In projecten met vele kleine bestandjes daarentegen, lijkt het moeilijker om goede suggesties te genereren, en is het belangrijker dat er extra documentatie aanwezig is in het geëditeerde bestand zodat er voldoende contextuele informatie is die het taalmodel kan aangrijpen.

Een van de interessantere alternatieven voor het commerciële Github CoPilot is StarCoder, een open source model van het BigCode initiatief van HuggingFace en ServiceNow. De performantie is weliswaar minder dan CoPilot, maar zij maken op vele andere vlakken, die mogelijk dealbreakers zijn in commerciële of publieke context, het verschil:

• Getraind op een open dataset: The Stack. Deze is weliswaar via scraping verzameld, maar bevat alleen code met permissieve softwarelicenties, en developers kunnen desgewenst alsnog hun code eruit laten verwijderen.
• Bevat een plagiaat-check tool, waarmee je kan controleren of de gegenereerde suggesties niet verbatim uit de (mogelijk copyrighted) trainingsdata zijn overgenomen.
• Voorzien van filter van gevoelige informatie, die emailadressen, API keys en IP adressen detecteert (niet 100% accuraat).
• Voorzien van instructies om het lokaal te installeren, evenals een VSCode plugin. Een IntelliJ plugin werd ondertussen ook ontwikkeld door een derde partij.
• Het standaardmodel is 15 miljard parameters groot en vergt minstens 60GB RAM of evenveel GPU memory (afhankelijk van of een GPU benut wordt of niet) om te kunnen gebruiken. Ondertussen bestaan ook kleinere modellen met 7, 3 of 1 miljard parameters, evenals “quantized” versies die gebruikmaken van 4bit datatypes zonder veel accuraatheidsverlies.

Deze zomer zagen nog enkele andere systemen het licht die goed scoren op vele benchmarks: WizardLM en de specifieke variant ervan WizardCoder, dat ondertussen wordt beschouwd als de open source state-of-the-art, en PanGu-Coder, waarmee ook Huawei zich heeft gelanceerd in de wereld van AI-assistants voor code. 

Achter de schermen

De StarCoder paper geeft een goed zicht op de werking van een taalmodel voor code. Het is zeker niet zo dat je je eigen codebase kan “inpluggen” om suggesties te krijgen die daarop zijn toegespitst. Als je echt zou willen finetunen (en die enorme inspanning doe je in principe alleen maar als je er niet raakt met slimme aanpassingen aan de prompt), komt er heel wat bij kijken, van preprocessing van de trainingsdata tot postprocessing van de rauwe output van het taalmodel. Leg de verwachtingen van finetuning ook niet te hoog: StarCoder deed het voor Python, maar haalde hooguit enkele procentpunten verbetering in vergelijking met het algemene model dat met alle programmeertalen overweg kon. Finetunen is moeilijk en er is geen garantie op succes; er bestaat zelfs een risico op overfitting wat tot slechtere resultaten kan leiden.

De belangrijkste stap daarbij is waarschijnlijk het verzamelen en schoonmaken van data. Die data bestaat uit code, maar niet alle code komt in aanmerking: je moet de code ook mogen gebruiken (licenties), en je hebt ze liefst zo correct mogelijk en geschreven in de programmeertaal die je wenst te ondersteunen. Code wordt ook verzameld uit issue trackers en commitgeschiedenis. Daarnaast kan je nog extra filteren om (bijna-)duplicaten te verwijderen, en wil je misschien hier en daar gewichten toekennen om de balans te bewaren: wat minder gewicht voor boilerplate code, en/of wat meer voor erg populaire repositories die waarschijnlijk van hogere kwaliteit zijn. Broncode kan gevoelige informatie bevatten die eerst geanonymiseerd of verwijderd moet worden, om te voorkomen dat die lekt of wordt gesuggereerd (IP adressen, paswoorden, identifiers, emailadressen, contactgegevens, …). Dit alles natuurlijk liefst zo automatisch mogelijk.

Broncode bestaat niet alleen uit code maar ook uit beschrijvingen, commentaren en andere informatie. In een formatteringsstap wordt de code daarom nog verrijkt, door het toevoegen van metadata en bijkomende tokens die bepaalde impliciete structuren expliciet maken. Dit kan implicaties hebben: als al deze preprocessing op de hele trainingsdataset is gebeurd, dan zal het resulterende model pas goed werken op nieuwe data als die dezelfde preprocessing heeft ondergaan. Het is dus mogelijk dat editorplugins die willen gebruikmaken van zo’n model, om een goed resultaat te bekomen, eerst gelijkaardige preprocessing moeten uitvoeren op de code die ze naar het taalmodel willen sturen.

Correctheid en andere benchmarks

Typisch voor LLMs, kan er geen sluitende garantie worden gegeven op de correctheid of volledigheid van wat zo’n plugin je voorschotelt, zowel syntactisch als semantisch. Die correctheid is uiteraard van belang: een stuk gegenereerde code moet niet alleen syntactisch correct zijn en foutloos compileren, maar ook semantisch betekenisvol zijn en goed runnen. De “pass@x” metriek is daarbij uitgegroeid tot belangrijke graadmeter. Ze drukt uit als een percentage, of een taalmodel voor een bepaalde opdracht na X pogingen de bijhorende testen succesvol kan passeren. “pass@1” is het percentage dat het taalmodel van de eerste keer het juiste antwoord heeft kunnen genereren, “pass@10” is het percentage waarbij minstens 1 van 10 pogingen correct was.

Er is een algemene nood in de wereld van generatieve AI om nieuwe modellen, die ondertussen bijna dagelijks verschijnen, te kunnen vergelijken met de state-of-the-art. Aan benchmarks is er dus geen gebrek, en er verschijnen er geregeld ook nieuwe en grotere. Handige samenvattingen zijn de “leaderboards”, die real-time tonen welke modellen de huidige state-of-the-art vertegenwoordigen volgens een waaier aan benchmarks. Het podium kan wekelijks veranderen. Enkele interessante algemene leaderboards zijn:

• Papers with Code: state-of-the-art in verschillende AI taken, voorzien van begeleidende papers
• Stanford HELM: benchmarkt een breed scala aan taken met focus op “human reasoning”
• LMsys.org FastChat: focus op chatbot-vaardigheden
• HuggingFace OpenLLM leaderboard
• LLM-Leaderboard

Specifiek voor code zijn er benchmarks die min of meer werken zoals een programmeerwedstrijd. Het idee is om een set opdrachten te geven aan het taalmodel, de resultaten automatisch te evalueren, en de “pass@1” en zo mogelijk enkele andere metrieken te meten. Vaak neemt dat een “fill in the function”-vorm aan: gegeven een beschrijving van input en output en een functieheader, moet de inhoud van de functie gegenereerd worden. Een nadeel is dat dit soort problemen soms weinig representatief is voor dat waarmee de doorsnee developer wordt geconfronteerd. Interessante initiatieven zijn onder andere:

• HuggingFace Big Code Models leaderboard (enkel open LLMs)
• Microsoft CodeXGLUE: evaluatie van verschillende subtaken volgens methodes bekend uit Natural Language Processing. Hun leaderboard lijkt af te hangen van vrijwillige contributie en enigszins onvolledig.
• Papers with Code heeft aparte secties voor genereren van code , genereren van documentatie, synthese van hele programma’s en bugfixing
• De HumanEval dataset en MBPP dataset: typische programmeerproblemen (Python)
• De DS-1000 dataset: een set van concrete data science / data processing problemen
• HumanEval-X of MultiPL-E: multi-language versies van HumanEval, meet performantie in meerdere programmeertalen

Dat een gegenereerd stuk code de testen overleeft betekent natuurlijk nog niet dat het ook veilige code is of “best practices” volgt. Er zijn ondertussen voorbeelden genoeg bekend van gegenereerde code die vatbaar blijkt te zijn voor buffer overflows, SQL injection, en andere klassieke risico’s. De “Asleep at the Keyboard” security benchmark bestaat uit 89 code generation scenario’s gebaseerd op de MITRE top-25 vulnerability lijst. Uit de Starcoder paper blijkt dat zelfs de beste modellen in 40% van deze scenario’s toch nog onveilige code genereren. Ook lijkt er nauwelijks verschil te merken tussen de beste modellen en de rest – een beter model kiezen lijkt wel te zorgen voor syntactische correctere resultaten, maar vooralsnog niet voor veiliger code. Mogelijk moet daarom eens gekeken worden naar de trainingsdata zelf, waar onveilige code nog beter uitgefilterd zou moeten worden. In ieder geval moeten we op dit moment adviseren: het gebruik van gegenereerde code in een project moet absoluut gepaard gaan met een robuust beleid inzake testing en acceptatie.

Performantie

Specifiek wat betreft computationele vereisten, zijn het Huggingface OpenLLM-perf leaderboard en de benchmarks op de website van TextSynth Server interessante bronnen. Die laatste toont enkele cijfers over performantie, die handig zijn voor wie met het idee speelt om het zelf te gaan hosten. Wie het zonder GPU doet, kan met het LLaMa2 model van 13 miljard parameters rekenen op een snelheid van 12 tokens per seconde, gegeven een relatief high-end EPYC 7313 serverprocessor. Een token in computercode is soms maar 1 karakter, dus aan dat tempo moet je soms een tiental seconden wachten op een code completion suggestie. De recentste RTX-4090 grafische kaart kan het 7x sneller, maar nog steeds niet zo snel dat je het in milliseconden zou uitdrukken.

De geheugenvereisten zijn evenredig met het aantal parameters van een model, en de generatiesnelheid omgekeerd evenredig. Als een grove benadering mag je aannemen dat een model van 13 miljard parameters, ook 13 miljard berekeningen moet maken voor elk output token, zelfs al is het maar 1 karakter lang. Daarnaast vereist het, als elke parameter een 32-bit getal is, minstens 52GB opslagruimte en evenveel (V)RAM-geheugen. Een “quantization“, die de parameters afrondt naar 8-bit of zelfs 4-bit, kan die geheugenvereiste evenredig doen dalen.

GPT4All laat toe het zelf eens te proberen op je eigen hardware. Dit geeft een idee van de enorme rekenkracht die OpenAI , Microsoft Azure, of Amazon AWS inzetten om hun modellen, die veelal nog groter zijn dan de beschikbare Open Access LLMs, zo snel te kunnen doen draaien als zij dat aanbieden. Er wordt gesproken van investeringen van miljarden dollars in hardware, zodanig groot dat ze de wereldwijde markt destabiliseren.

Zelfs open source oplossingen zijn allesbehalve lightweight te noemen, ondanks verregaande initiatieven tot optimalisatie. Je mag er alleszins van uitgaan dat het lokaal deployen alleen maar haalbaar is op recente en krachtige hardware. Een vlotte user experience kan je momenteel nog niet verwachten van een lokale installatie op de doorsnee kantoorlaptop.

Productiviteit

Het internet staat vol sprookjes over de 10x developer, en goeroes van generatieve AI zouden u graag doen geloven dat deze technologie elke programmeur tot dat niveau kan verheffen. De realiteit is hardnekkiger. Developers spenderen om te beginnen geen 100% van hun tijd aan het schrijven van code, net zomin als dokters 100% van hun tijd voorschriften schrijven. Het merendeel van developers spendeert minder dan 1 uur per dag aan het effectief schrijven van code. De rest van de tijd gaat naar analyseren, lezen, leren, onderhoudstaken, communicatie,… Dat denkwerk en het overleg met de collega’s wordt vooralsnog niet gecomprimeerd door LLMs in te zetten.

Het is moeilijk om harde cijfers te vinden over productiviteit omdat het moeilijk te definiëren en dus te meten is. Een nuttige eerste schatting komt van Google zelf, die de iteratietijd (van kennisname van het probleem tot oplossing) onder de loep nam. Met een eerste versie van hun eigen AI code completion assistent, konden zij 6% tijdswinst noteren. Github zelf beweert dat het pure codeerwerk zo’n 55% sneller kan met hun CoPilot – al zeggen ze er in één adem bij dat het 95%-confidence interval van hun meting [21%-89%] is. De adoptie van een tool brengt bovendien geen meerwaarde als ze niet gepaard gaat met een traject om ze optimaal te leren benutten (net zoals vandaag nog vele kantoormedewerkers tijd verliezen met Office door onvoldoende kennis of ervaring met alle types van referenties, formules en snelkoppelingen).

Gegenereerde code biedt wel snel een eerste oplossing, maar die oplossing moet nog steeds begrepen worden door de programmeur. Een “pass@1” score van 50%, betekent dat de helft van de gegenereerde code snippets nog manuele aanpassingen behoeft voordat ze de unit tests passeert – en dan spreken we nog niet over optimaliteit of veiligheid. Gegenereerde code kan complex zijn en gebruikmaken van constructies die boven het kennisniveau van de programmeur liggen. Dat maakt gegenereerde code moeilijker om te onderhouden en te debuggen dan code die manueel geschreven is. Gegenereerde code die onvoldoende werd gereviseerd en getest, voegt aanzienlijke technical debt toe aan een project.

Het gebruik van plug-ins die zo ver gaan dat ze hele blokken code en documentatie met een vingerknip (of iets trager) kunnen genereren, is slechts een goed idee wanneer verschillende andere aspecten van het software engineering proces op orde zijn: er moeten over de hele lijn hoge standaarden aangehouden worden wat betreft teststrategie, code reviews, documenteren van code en kenniscompetenties van de developers.

Vertrouwelijkheid

Bedrijven en overheden hebben zelden de luxe om eender welk taalmodel te benutten. Er zijn niet alleen contractuele drempels, maar ook vragen over confidentialiteit, zeker bij gebruik van de cloud. Een goede suggestie van een taalmodel krijg je immers alleen door eerst voldoende informatie te uploaden. Als je niet alles in-house opzet, impliceert dat onvermijdelijk dat je een derde partij inzage geeft in jouw gegevens.

De mate van openheid en licentiëring kan aanzienlijk verschillen – in het ene uiterste is alles “black box” en enkel via cloud/API toegankelijk (hier vind je OpenAI, Anthropic, Cohere en de meeste andere gevestigde startups). Deze beloven in Enterprise versies soms meer garanties – maar je hebt nog steeds geen andere optie dan ze daarin te geloven op hun woord. In het andere uiterste is alles “open access” en permissief gelicentieerd. Daartussenin kan een bedrijf ook een Open Access taalmodel bouwen op een gesloten dataset. Van minstens 1 zo’n dataset is ondertussen uitgelekt dat ze illegaal gekopieerde auteursrechtelijk beschermde ebooks bevat, wat ongetwijfeld een sterk argument wordt in de class action lawsuit over het thema tegen Meta. De datasets van de code-LLMs Salesforce CodeGen en Tsinghua CodeGeeX zijn evenmin publiek.

Transparantie, licentiëring, deployment mogelijkheden, prijszetting, grootte en schaalbaarheid,… het relatief belang van al deze kenmerken zal dicteren welke tools je kan gebruiken. Wie maximale transparantie wil, zal sowieso vaak beperkt zijn tot Open Access LLMs. Sommige open licenties beperken het gebruik daarnaast tot niet-commerciële doeleinden. Een noodzaak tot inzage in de trainingsdata of gemakkelijke voorzieningen om zelf on-premise een instantie te kunnen hosten, beperkt de keuzemogelijkheden nog verder.

Conclusie

Dialoog-gebaseerde tools (chatGPT en aanverwanten) kan je als developer nuttig inzetten bij o.a.:

• Het initialiseren van een project/bestand/klasse/configuratie: maak een eerste versie van iets
• Het debuggen en aanpassen op vraag-antwoord-wijze
• Relatief onafhankelijke snippets van code

Tools die code aanvullen of ontbrekende code invullen (type Github Co-Pilot) komen dan weer goed van pas bij o.a.:

• Het vervolledigen van code aan de hand van eerder voorkomende voorbeelden
• Het documenteren van code
• Het maken van veranderingen midden in een groter bestand

De optimale ontwikkelomgeving is voor een developer iets vrij persoonlijks en iedereen zal een eigen voorkeur hebben. In onze ogen zijn deze twee manieren om codesuggesties te krijgen enigszins complementair, en het slim combineren van de twee kan voor de meeste productiviteitswinst zorgen. In één adem willen we daarbij wel zeggen dat een gezond projectmanagement, met aandacht voor codekwaliteit, testing, reviews, documentatie, … daar wel onontbeerlijk bij hoort.

De AI-wereld is in volle beweging. Er komen met de regelmaat van de klok nieuwe AI-modellen bij die kunnen dienen als back-end voor IDE-plugins. Voor industrieën waar vertrouwelijkheid van code belangrijk is, zijn de open-source varianten erg interessant. Zelfs al tonen benchmarks dat die vandaag nog minder performant zijn dan de laatste commerciële cloud-based initiatieven, kunnen we verwachten dat daar in de toekomst ook betere versies van zullen verschijnen. Er zijn alvast veel inspanningen om modellen te maken die op (weliswaar high-end) consumentenhardware kunnen draaien.

P.S.

Enkele uren na het publiceren van dit artikel, kondigt HuggingFace SafeCoder aan: een enterprise-level oplossing voor LLM-gebaseerde coding assistants die on-premise uitgerold kan worden. Huggingface voorziet alles in containers die in het eigen datacenter geïnstalleerd kunnen worden en private endpoints voorzien, én voorziet compatibele plugins voor de belangrijkste IDEs. Andere algemene deployment frameworks bestaan al langer – o.a. Seldon, BentoML en KServe kunnen LLMs hosten, ook TextSynth Server en GPT4All kunnen functioneren als API endpoint. Je hebt echter nog steeds plugins nodig om er gebruik van te kunnen maken in de IDE zelf, en om de nodige pre- en postprocessing te doen – en als ze niet voorzien worden, moet je er zelf eentje maken of een bestaande plugin aanpassen.

P.P.S.

Deze laatste woorden waren nog niet koud of Meta lanceerde Code LLama , een LLaMa 2 variant specifiek getraind voor code. Op sociale media wordt vermeld dat het mogelijk is de originele versie met 34 miljard parameters te draaien op een computer uitgerust met 4 RTX3090 GPUs met elk 24GB VRAM, waarmee ongeveer 20 tokens/seconde gegenereerd kunnen worden. Gemakkelijker is misschien de online chat-versie uit te proberen. Quantized versies zullen ongetwijfeld erg snel volgen, en we verwachten de eerste benchmarks eerstdaags op de verschillende leaderboards.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Deze blog is het tweede deel van een reeks, waarin we een aantal mogelijkheden die ons worden geboden door goede architecturale principes en technologieën, zullen toelichten. Een aantal van deze zaken werden ook reeds in vroegere blogs besproken, en de meeste worden ook nog eens samengevat in de blog “Vortex van Enablers“. De eerste blog van deze reeks beschouwde de gedeeltes van een applicatie-architectuur die de gebruikersinterface en externe clients ondersteunen: Architecturale Evoluties, deel 1.

In dit deel duiken we dieper in de applicatie, en zullen we beschouwen hoe we de interacties met onze applicatie verder kunnen afhandelen. Interacties kunnen via allerlei wegen onze applicatie binnenkomen (b.v. aanvragen vanuit een GUI, requests via een extern-gerichte API, maar ook interne, geplande acties die op bepaalde momenten worden gestart). Voor de binnenste onderdelen van de architectuur is dit onderscheid echter van minder belang. Wel belangrijk is of het gaat om een vraag om output te genereren (dit zullen we een query noemen), of dat het eerder gaat om nieuwe input (vaak een command genoemd, maar dit komt eigenlijk overeen met een Event). Soms zijn deze beide vormen gecombineerd (er is nieuwe input, die op zich al tot nieuwe output moet leiden), maar vaak is het mogelijk om deze aspecten in de verwerking van de interactie voldoende gescheiden te houden.

De Moderne Architectuur, Deel 2

In het eerste deel van deze blogreeks beschreven we reeds hoe alle externe interactie met onze applicatie kon worden herleid tot het oproepen van Restful APIs, die we konden aanbieden via één of meerdere microservices. In dit tweede deel kunnen we ons daardoor volledig focussen op de interne werking van een collectie microservices, die samen een applicatie (of een groep van applicaties) ondersteunen. Dit is een radicale breuk met de meer traditionele 3-tier of n-tier architecturen van weleer. Gartner heeft deze nieuwe trend de naam “MASA” gegeven, wat staat voor Mesh App and Service Architecture: een zeer modulair and flexibel aanpasbaar netwerk van oplossingen die de dynamisch veranderde behoeften vanuit de business snel kunnen opvangen.

Eén opmerking die we voor de volledigheid nog moeten maken, is dat het in deel 1 om interactie met écht externe zaken ging, zoals de clients en 3rd party applicaties. Dit leidt er doorgaans toe dat we sterk gestandaardiseerde interactievormen via het web zullen gebruiken (waardoor vrijwel enkel REST APIs kunnen worden beschouwd). Integratie binnen het eigen ecosysteem kan echter, naast APIs, ook nog via de Event Bus gebeuren, die op zich gebouwd is bovenop het principe van asynchrone uitwisseling van berichten tussen de services. Dit duale principe (synchroon REST kanaal en asynchroon event kanaal, ook reeds toegelicht in de blog over Data Centric IT) moet volstaan om alle communicatie tussen de verschillende onderdelen van een applicatie (of ecosysteem) in goede banen te leiden. Op zijn beurt laat deze ogenschijnlijke beperking toe om de technische kant van het verhaal te standaardiseren.

• Een woordje over de MASA

Zoals reeds gezegd, staat MASA voor “Mesh App & Service Architecture”. Het woordje “mesh” (= een fijnmazig net) betekent dat de huidige architectuur uit vele aparte onderdelen zal bestaan, die via steeds veranderende configuraties met elkaar communiceren. Het model dat we in deze blogreeks uit de doeken doen, namelijk een ecosysteem van samenwerkende microservices, communicerend via Event Bus en RESTful APIs, is daarbij eigenlijk nog een eenvoudige versie. In de praktijk zal men evolueren naar ingewikkelder patronen, waarbij in deze mesh ook legacy toepassingen zullen verweven zitten, alsook zaken die in de Cloud draaien i.p.v. op het lokale netwerk, afzonderlijke functies die volgens het zogenaamde “Serverless” principe werken, en zelfs IoT devices. Dit soort gemengde architectuur ontstaat doordat vele organisaties nu eenmaal legacy toepassingen draaiende moeten houden, en doordat er een grote heterogeniteit aan projecten te volbrengen is, hetgeen er voor zorgt dat er vaak ook verschillende keuzes gemaakt worden wat betreft de onderliggende platformen. In zo’n geval is het echter ook belangrijk (of zelfs nog belangrijker) dat men tracht de communicatiepatronen tussen al deze verschillende zaken te standaardiseren, om aldus de compatibiliteit en integreerbaarheid te maximaliseren.

• De Duale Service Interface: CQRS

In de introductie vermeldden we reeds het onderscheid tussen commando’s en queries. CQRS staat voor Command Query Responsability Segregation, wat zoveel betekent als “scheiding van de verantwoordelijkheid voor het afhandelen van commando’s en queries”. In de praktijk wil dat zeggen dat we zullen proberen om een logische scheiding te krijgen tussen de systemen die commando’s verwerken en tussen degene die vragen beatwoorden. Dit is schematisch weergegeven in onderstaande Fig. 2.

Queries kunnen doorgaans rechtstreeks door een API worden beantwoord, al dan niet door de vraag, mogelijks in stukjes gekapt, aan een verdere API door te geven. Uiteindelijk zullen het de onderliggende (micro-)services zijn die het echte werk doen van opzoeken in databases en eventueel nog een paar bewerkingen uitvoeren om het antwoord in de gevraagde vorm te krijgen. Wat betreft de interactie tussen verschillende services, hoeft hier dus niet te worden afgeweken van RESTful synchrone communicatie.

Het ligt iets anders voor commando’s. Wanneer we volledig het paradigma van Event Sourcing toepassen, zullen we een commando steeds omzetten in een gebeurtenis (b.v. het commando “bestel één blockchain boek” wordt dan het event “bestelling van één blockchain boek geplaatst“). Deze omzetting zal door een eerste laag van services worden gedaan, speciaal gebouwd voor het opvangen van dergelijke commando’s vanuit de client side.

Het commando kan dan verder worden afgehandeld als een typisch event: het komt op de Event Bus terecht en alle geïnteresseerde diensten zullen het asynchroon ontvangen en kunnen behandelen (één backend service zal b.v. de inventory aanpassen; een andere zet het verpakken op gang en nog een andere verwittigt de koerierdienst). In elk geval is het creëren van afgeleide informatie (b.v. de hoeveelheid in stock) een verantwoordelijkheid van een microservice die daarvoor zijn eigen database zal hebben.

Wanneer nu later een vraag toekomt die betrekking heeft op informatie beïnvloed door een eerder commando, dan zal deze geforward worden naar de microservices die deze up-to-date informatie controleren (b.v. de vraag “hoeveel van die blockchain boeken zijn er nog in voorraad” komt uiteindeljik terecht bij de service voor de inventory). Vermits events asynchroon werken kan het soms zijn dat een vraag nét te snel komt en de informatie dus niet volledig up-to-date is (meestal is het echter een kwestie van enkele seconden). Vandaar dat het bij dit soort architecturen aangewezen is de principes van “eventual consistency” goed toe te passen, en zelfs door te trekken tot op business niveau.

Bovenstaande Figuur 3 toont een iets gedetailleerder voorbeeld. In de figuur zien we dat er achter de App API, 2 Command APIs en 1 Query API schuilgaan. Daarnaast zien we een door meerdere zaken gebruikte Event Bus, waarvan alle events ook in een centrale event store terecht komen. Sommige backend microservices communiceren rechtsreeks met de bus en spelen dus kort op de bal; daarnaast is er een service die vooral gebruik maakt van de event store en die dus meer zaken kan doen met historische events (b.v. analytics). Verder zien we dat er een legacy systeem communiceert via het event kanaal en dat een aantal services APIs aanbieden, sommige zelfs rechstreeks aan externe systemen. Er is een kort scenario uitgewerkt in de tekening:

1. Een update wordt gevraagd, wat zich vertaalt in een reeks van events die door een aantal services verwerkt worden. Het event komt uiteraard in de event store terecht.
2. Een andere update zorgt er uiteindelijk voor dat er events ontstaan die aanpassingen doen gebeuren aan een database van afgeleide informatie, behorende tot een bepaalde microservice.
3. Een query vraagt informatie op via API, en uiteindelijk wordt een API van de microservice van stap 2 aangeroepen; deze zal dus van de geüpdate informatie uit de database van stap 2 gebruik maken.
4. Een andere query doet een iets diepgaandere vraag. Via verschillende calls tussen deelnemende services, wordt er uiteindelijk informatie opgevraagd uit de event store.

Dit verhaal is, vanwege het gebruik van Events, voor een deel asynchroon. Sommige cliënts zullen echter zo synchroon mogelijk moeten worden geüpdated. Hoe kunnen zij vlot op de hoogte worden gebracht van de meest recente informatie? Ter herinnering: in een volledig synchrone wereld zal een cliënt als antwoord op een commando ook onmiddellijk de nieuwe toestand meekrijgen. Met de nieuwe architectuur moet de cliënt echter “gissen” na hoeveel tijd hij een query naar de server moet sturen, om er zeker van te zijn dat het effect van zijn laatste commando in rekening is gebracht. Dit giswerk kan men echter vermijden. Sowieso is het niet zo efficiënt om ervan uit te gaan dat het altijd de cliënt is die alle communicatie moet initiëren. We zullen er dus voor zorgen dat ook de server dit initiatief kan nemen. Als gevolg van een binnenkomend Event moet ook de server in staat zijn om op dat moment een bericht te sturen naar de client. Er zijn ondertussen verschillende manieren waarop een cliënt aan een server zijn interesse kan laten blijken in het krijgen van callbacks wanneer up-to-date informatie beschikbaar is, en er zijn zelfs al full-duplex communicatiemogelijkheden voor applicaties op het web. (WebSocket is een vrij modern voorbeeld).

Indien het niet mogelijk is de client op een manier te bouwen dat deze door de server kan worden gecontacteerd, en het is evenwel belangrijk dat de client zo snel mogelijk up-to-date informatie krijgt, dan is er nog een noodoplossing mogelijk. We kunnen alsnog een API voorzien die toelaat dat men via één enkele request zowel een update doet als de nieuwe informatie meekrijgt in het antwoord. Desalniettemin zullen we het CQRS patroon voor het grootste gedeelte respecteren in de backend. Het volstaat om de API zo te bouwen, dat hij de request zelf opdeelt in een commando en één of meerdere queries. De microservice die achter deze API schuilgaat, zal dan eerst het event lanceren om het commando uit te laten voeren, en zal vervolgens wachten tot er genotificeerd komt via de juiste events, die de afhandeling van dit commando aangeven. Daarna kan de service overgaan tot het lanceren van de queries en dan vervolgens zelf antwoorden op de vraag van de client. Dit patroon zorgt er wel voor dat soms de client wat langer (synchroon) zal moeten wachten op zijn antwoord, omdat het asynchrone gedeelte volledig aan de serverkant moet worden afgehandeld.

Conclusie

We zien hoe een moderne architectuur ervoor zorgt dat men een applicatie (of groep applicaties) kan opdelen in zo klein mogelijke microservices, elk met hun eigen verantwoordelijkheid. Deze zijn efficient te onderhouden en ook vervangbaar, wat het gehele systeem een ongeziene flexibiliteit geeft om zich aan te kunnen passen aan zowel veranderende functionaliteit als aan veranderingen aan de infrastructuur of de benodigde capaciteit. Daarnaast hebben we een gestandaardiseerde manier van communiceren toegelicht, die ervoor zorgt dat de mesh van apps, de “MASA”, continu kan veranderen en groeien, doordat men alle onderdelen gemakkelijk via het netwerk met elkaar kan laten communiceren. Ten slotte konden we ook zien hoe CQRS hiervan gebruik maakt om een nette afhandeling van alle mogelijke vragen te voorzien, gebruik makende van Events, die ook de historiek en traceerbaarheid van het systeem garanderen, van client tot backend.

]]> https://www.smalsresearch.be/architecturale-evoluties-deel-1/ Wed, 21 Mar 2018 13:35:54 +0000 /?p=11434 Vroeger was het simpel: je had front end, back end, en database. En toch is dit verre van optimaal. Hoe ziet een architectuur eruit die gebruik maakt van moderne principes en technologieën?

Er zijn heel wat mogelijkheden te overwegen wanneer men de architectuur van een applicatie bepaalt. Dit is nog eens extra het geval wanneer het een applicatie betreft die niet alleen staat, maar op allerlei manieren zal moeten integreren met andere applicaties en diensten, zowel binnen als buiten de eigen organisatie. In een tweedelige blogreeks bespreken we een aantal mogelijkheden die ons worden geboden door een aantal architecturale principes en technologieën, die ik reeds eerder samenvatte als de “Vortex van Enablers“.

In dit eerste deel bespreken we de bovenste regionen van de moderne applicatie architectuur. Alles wat met de interactie met de buitenwereld te maken heeft, zoals clients en 3rd party systemen (die vaak gewoon ook als clients kunnen worden beschouwd). In de volgende blog zal het dan gaan over de meer interne systemen. We beginnen hier met een terugblik op de traditionele 3-tier architectuur.

De 3-tier Architectuur

De 3-tier architectuur kennen we ondertussen stilaan. De verschillende “tiers” die er kunnen bestaan, en de geschiedenis ervan, werden reeds uitvoerig beschreven in de blog Van N-tier naar Microservices.

Deze stilaan verouderde architectuur kent een aantal problemen, niet in het minst qua herbruikbaarheid en integratiemogelijkheden. Zo komt men vaak in de problemen wanneer men nieuwe manieren van interactie wil toevoegen, zoals een mobiele app, of, waarom niet, een conversational interface. Een ander euvel is integratie: wanneer de data nodig is voor andere toepassingen, blijkt de op zichzelf ontworpen 3-tier applicatie vaak te incompatibel, en is men gedwongen de integratie via de data te doen. Dit door ofwel de database te koppelen aan meerdere applicaties via opengestelde fluxen, of d.m.v. het creëren van een duplicaat van de data, dat men dan om de zoveel tijd zal moeten updaten via één of ander ETL mechanisme. Een groot probleem is daarbij ook vaak dat de data semantisch sterk is gekoppeld aan de specifieke applicatiecontext.

Verderop in deze blogreeks gaan we bekijken hoe het beter kan, met een modernere architectuur. Uiteraard is dit echter geen zwart-wit verhaal. De beschreven voorbeeldoplossing zal op een behoorlijk verregaande manier verschillen van de traditionele oplossing, maar er zijn uiteraard ook allerlei tussenoplossingen en middenweg-scenario’s te bedenken. Een zeer eenvoudig voorbeeld is bijvoorbeeld het koppelen van de verschillende tiers binnen zo’n verouderde architectuur via RESTful APIs (zie Fig. 2). Dit is een vaak broodnodige upgrade, die nu reeds op veel plaatsen wordt toegepast. Het is een goed begin, maar meestal nog onvoldoende om de flexibiliteit en herbruikbaarheid te bereiken die we beogen met een echte modernisering.

De Moderne Architectuur, Deel 1

De moderne architectuur bestaat uit de culminatie van een aantal belangrijke architecturale principes, zoals Restful API‘s, Event-Driven Architecture (EDA) en MicroServices, waarover ik reeds meerdere blogs heb geproduceerd (Al deze technologieën maken ook deel uit van de Vortex van Enablers). In de laatste, over Services in alle Maten, gaf ik reeds een uitgebreid, zei het vaag blijvend, voorbeeld over hoe een API (een op clients gericht product !) kan worden geïmplementeerd door een combinatie van (interne) microservices, die met elkaar kunnen communiceren via REST en EDA.

Laten we nu iets concreter ingaan op hoe een modern gebouwde applicatie kan worden gebouwd gebruik makende van deze technologieën. Een dergelijke applicatie staat echter nooit alleen, dus we beschouwen deze samen met zijn onmiddellijke omgeving, bestaande uit clients, maar ook andere applicaties en diensten.

• Front-Facing API Ecosystem

  

   

  We beginnen ons verhaal bij de Front End. Dit betekent dat we de modernisering van de eigenlijke client en gebruikers-interface (UI) in deze blog buiten beschouwing laten. Dit betekent echter niet dat daar geen evoluties zouden zijn, of dat de architectuur van een “app” zelf geen modernisering zou behoeven.

  Naar de clients en de buitenwereld toe, zijn APIs de belangrijkste evolutie van de voorbije jaren. Meer en meer zal men APIs zélf gaan aanbieden als product naar derde partijen toe, en eveneens naar andere applicaties en diensten binnen de eigen onderneming. Daarbovenop komt nog dat er een proliferatie is geweest aan verschillende kanalen via dewelke een applicatie kan worden gebruikt. Dit zorgt ervoor dat de front end meer en meer een product op zich wordt, dat zich vooral moet bezighouden met het aanbieden van de nodige faciliteiten voor alle mogelijke vormen van interactie met de buitenwereld, en vooral niet met enige andere zaken, zoals de business logica zelf.

  Omdat het een goed principe is om alles zo modulair mogelijk te maken (hoe kleiner de aparte componenten, hoe makkelijker men ze afzonderlijk kan aanpassen, of zelfs vervangen via het rip-and-replace principe), bekomt men zo uiteindelijk een volledig ecosysteem van gerelateerde APIs, elk bevoegd voor het afhandelen van een bepaald type interactie met de buitenwereld. De API die achter de traditionele web app staat, zal aldus verschillen van de API die gebruikt wordt voor 3rd party clients. Afhankelijk van hoe sterk de verschillen zijn, kan men er al dan niet voor opteren om achter al deze APIs nog een verenigende API te plaatsen, die zaken zal bevatten die door alle extern gerichte APIs kunnen worden (her-)gebruikt. Een uitgebreid voorbeeld zien we in Figuur 4 (vele andere voorbeelden zijn mogelijk; zo zou de mobiele app ook met de webserver kunnen communiceren).

  

Beschouwingen

Wanneer men het voorbeeld bekijkt, zou men kunnen zeggen dat het er ingewikkelder uitziet dan vroeger, toen dit nog gewoon “de bovenste tier” was. Schijn bedriegt echter: de APIs worden nu gedragen door gespecialiseerde microservices die met elkaar samenwerken. Dit gedistribueerd systeem heeft uiteraard zijn eigen complexiteit, maar de oorspronkelijke tier had die ook in zekere mate: alleen was ze daar geïnternaliseerd binnen één monolithische component.

Verder zijn er heel wat voordelen verbonden aan de nieuwe architectuur: microservices, die via APIs communiceren, kan men veel sneller aanpassen of zelfs herontwikkelen. Hierdoor kan men sneller reageren op veranderende noden van de business. Daarenboven heeft het ook technische voordelen: de communicatie is nu gestandaardiseerd over http, waardoor (soms onverwachte) integraties een stuk soepeler kunnen worden geïmplementeerd. Bovendien kan men microservices apart schalen, en kan het systeem als geheel zich dus veel elastischer gedragen, afhankelijk van de belasting die het ondervindt. Ten slotte zijn microservices het ideale complement van containers: de basis bouwsteen van een moderne Cloud infrastructuur. Typisch zal men één microservice op één container uitrollen.

In het vervolg zullen we zien hoe commando’s (zaken die de toestand van de applicatie kunnen veranderen) en query’s (zaken die informatie opvragen uit applicaties) uit deze bovenste regionen naar de verder liggende backends worden gestuurd en daar worden behandeld. Daar zal ook de kracht van Event Driven Architecture tot zijn recht komen.

We zullen het daarbij hebben over een aantal categorieën of grootteordes van services: microservices, miniservices en macroservices. En dan zetten we er ook nog zogenaamde nanoservices langs, die eigenlijk (nog?) geen officiële definitie hebben… Al deze architecturele paradigma’s zijn in zekere mate geïnspireerd door de reeds langs gekende Service-Oriented Architecture (SOA).

We kunnen nu wel al iedereen gerust stellen: er bestaat geen “one size fits all”; alle groottes van services zullen nuttig zijn in de portfolio van applicaties, diensten en componenten die een IT-bedrijf zal ondersteunen. Deze heterogeniteit wordt ook vooropgesteld door Gartner en ze noemen dit de MultiGrained Mesh App and Service Architecture (MG-MASA). Het belangrijkste daarbij is dat alle componenten hierin zo onafhankelijk mogelijk ontwikkelbaar zijn, terwijl ze toch vlot met elkaar kunnen communiceren en integreren.

Met uitzondering van de dubieuze term “nanoservices”, zullen we van klein naar groot gaan: we zullen eerst grondig definiëren wat microservices nu eigenlijk zijn, alvorens de “grotere” services te bespreken.

MicroServices: van Startup tot Web Scale speler

Microservices zijn onafhankelijke diensten met een sterk beperkte scope. Ze volgen rigoureus een aantal architecturale principes waardoor ze extreem wendbaar ( agile ) zijn en ook heel flexibel schaalbaar. Ze zijn zo ontkoppeld mogelijk van andere applicaties en diensten, doch communiceren er ook mee. Deze schijnbare tegenstrijdigheid wordt doorgaans opgevangen door een Event-Driven Architecture, dewelke losgekoppelde communicatie in gedistribueerde systemen ondersteunt.

De beperkte scope en bijgevolg doorgaans kleinere codebase is ook voor een stuk wat een microservice zo wendbaar maakt: ze kunnen door een klein devops team worden ontwikkeld en onderhouden en meermaals daags opnieuw uitgerold worden met veranderende features. Een grote applicatie die aldus ondersteund wordt door een groep van microservices, zal constant online blijven maar continu kleine veranderingen ondergaan en dus voortdurend evolueren. Op deze manier zorgt de microservices architectuur dus voor extreem door-gedreven Continuous Delivery. Andere aspecten van deze architectuur zijn het principe van “single responsability” (wat op hetzelfde neerkomt als de beperkte scope), extreme schaalbaarheid en – indien de microservice gepersisteerde data beheert, exclusieve toegang (= “eigenaarschap” of ownership) tot zijn database (of andere persistentie-oplossing), in het kader van de loskoppeling.

Microservices zijn op de kaart gezet door toepassing bij een aantal grote en bekende bedrijven als Twitter, Airbnb, Disney, Dropbox, GE, Goldman Sachs, en uiteraard ook grote Cloud spelers  zoals Amazon en Google. Microservices, volgens de strikte definitie, zijn echter bij veel middelgrote bedrijven nog zeldzaam, al evolueren sommige miniservices (zie verder) na een tijdje wel tot een groepje microservices, doordat aparte functionaliteiten worden afgesplitst.

Ze worden qua aangeboden functionaliteit opzettelijk en strikt beperkt gehouden: normaal gezien wordt er slechts één specifieke feature ondersteund, of één bounded context binnen een domein (voor meer info over deze term, kijk naar Domain Driven Design (DDD)). Doordat ze zo klein zijn en slechts één functionaliteit hebben, en apart uitrolbaar zijn, vormen microservices dus de ultieme vorm van flexibele schaalbaarheid. Een applicatie bestaande uit vele microservices kan optimaal gebruik maken van beschikbare resources: elke component die iets meer gebruikt wordt dan een andere, kan apart opgeschaald worden. Componenten die minder vaak nodig zijn, worden omlaag geschaald.

De onafhankelijkheid van een microservice beperkt zich best niet tot fysiek afzonderlijke deployments. Ook gedeelde libraries kunnen namelijk worden beschouwd als een te grote afhankelijkheid tussen verschillende microservices. Op deze manier wordt hergebruik soms een anti-patroon (“anti-pattern”). Het gaat dan natuurlijk wel om de code die het domein implementeert, er is weinig op tegen om utilitaire bibliotheken, zoals een logging raamwerk, te hergebruiken in meerdere microservices.

Microservices vinden we dan ook vooral terug bij bedrijven die op grote schaal (“web scale”) actief zijn, en dusdanig grote volumes moeten ondersteunen dat elke uitgespaarde percent benodigde resources een enorme kostenreductie tot gevolg heeft. We denken dan aan grote mediaspelers als Netflix, winkels als Amazon en Zalando, en uiteraard ook de Twitters, Facebooks en Googles van deze tijd.

Maar doordat het een nieuwe, moderne manier van ontwikkelen is, zijn microservices ook enorm populair bij startups. Deze hebben vaak het voordeel dat ze van nul kunnen beginnen met hun technologie, zonder enige legacy, en dat ze met kleine teams en een frisse bedrijfscultuur werken. Een Devops en Agile cultuur zijn namelijk sterke vereisten om microservices te kunnen ontwikkelen; hun architectuur verschuift namelijk de complexiteit weg van de binnenkant van een monoliet, maar recht naar de onderlinge interacties tussen vele (gedistribueerde) applicatiecomponten. Het voordeel  van microservices voor de startups is weliswaar dat ze op technologisch vlak een stuk robuuster zijn bij eventuele plotse groei, en ze de wendbaarheid ook goed kunnen gebruiken om snel in te spelen op marktopportuniteiten (er zijn reducties in ontwikkelingstijd tot 75% geschat).

APIs en Microservices

Microservices worden vaak beschouwd als de ideale manier om een API te implementeren. Dit is inderdaad een goede werkwijze, maar dan met één hele belangrijke caveat: de onafhankelijkheid van de microservice moet gewaarborgd blijven. Het scheiden van een API en zijn implementatie is een fundamenteel principe bij SOA, dat nog belangrijker wordt in de context van de extreme vereisten die aan een microservices architectuur worden gesteld.

Een API moet behandeld worden als een product. Geregeld worden APIs namelijk naar buiten toe opengesteld (en soms zelfs effectief gemonetariseerd), en op zijn minst dienen ze als interface naar andere software componenten (en dus andere ontwikkelteams) toe. Ze hebben dus nood aan een rigoureus change management.

De microservices daarentegen moeten snel kunnen evolueren en aangepast kunnen worden. Soms worden ze zelfs volledig vervangen (ze zijn disposable: het verlies blijft beperkt doordat ze kleiner zijn). Sowieso zal één microservice ook nooit een volledige API implementeren (tenzij als het echt om een miniscuul klein product zou gaan): achter de API bevindt zich doorgaans een hele batterij van componenten, waarbij verschillende microservices de effectieve business logica zullen uitvoeren. Andere componenten zijn bijvoorbeeld een Event bus, maar ook en vooral een API bemiddelingstool (“mediation”), die ervoor zal zorgen dat de calls naar de API bij de correcte afhandeling terecht komen, en op die manier de microservice loskoppelen van de ondersteunde API. Deze tools zijn doorgaans vervat binnen de context van een API Gateway of API Management suite.

De Pragmatische Aanpak: MiniServices

De term “microservice” wordt vaak misbruikt om eender welke kleine en herbruikbare dienst te benoemen. Maar zoals we hierboven zagen, voldoet dit nog lang niet aan de eigenlijke definitie, en is het ook zo dat een microservice zijn eigen API best niet zelf publiceert.

De categorie die dan ook door vele “enterprise niveau” bedrijven het vaakst wordt toegepast, is eigenlijk de miniservice, ook al zijn deze bedrijven snel om te zeggen dat ze een “microservices architectuur” gebruiken. De architecturen lijken dan ook wel enigszins op elkaar en enkel de grootte en scope (en het uiteindelijke doel) verschillen hier nog.

Miniservices implementeren geen volledige applicatie, en zullen normaal gezien ook slechts een stukje van een extern gerichte API invullen. Ze focussen zich op de functionaliteiten verband houdende met een bepaald subdomein in de applicatie. Wanneer we de principes van Domain Driven Design (DDD) volgen: een miniservice kan een volledig domein implementeren, maar eventueel ook een niet al te kleine “bounded context”, of alles wat ertussen ligt.

Miniservices zijn onafhankelijk van elkaar te ontwikkelen en uit te rollen, waardoor er een flexibiliteit ontstaat: doordat men werkt met kleinere componenten die losjes gekoppeld zijn en die men daardoor apart kan ontwikkelen en laten evolueren, kan men iets sneller de functionaliteiten veranderen via een meer agile ontwikkelingsmethode, en men kan dus sneller op de bal spelen. Hierdoor kan men beter ten dienste staan van de business, die sneller zijn product kan laten aanpassen aan veranderende marktomstandigheden. Dit komt dus neer op een afgezwakte versie van de vereisten voor microservices.

Wat data betreft, heeft men opties: in sommige gevallen kan men ervoor opteren om de database die onder een miniservice staat, nog bruikbaar te houden voor andere applicaties en diensten; soms is dit gewoon gemakkelijker en efficiënter dan de data via de API bloot te stellen, of op een moderne gedistribueerde manier te verspreiden zoals dit bij microservices gebeurt. Men moet hier echter mee oppassen en het beperken, want hierdoor creëert men quasi onherroepelijk afhankelijkheden. Beter is het om wat de data betreft toch eerder richting microservices architectuur te evolueren en de miniservice exclusieve toegang tot zijn data te geven.

Volgens een schatting van Gartner zal tegen 2019 90% van de organisaties het microservices paradigma te disruptief vinden en eerder gebruik maken van miniservices.

Er zijn, ten slotte, nog een aantal andere alternatieven voor een microservices aanpak, naast miniservices. Zo bestaan er PaaS platformen waarbij er sterk visueel kan worden ontwikkeld (met zogenaamde “zero coding”) en men op die manier de productiviteit kan laten stijgen. En voor het implementeren van business processen kan men nog gebruik maken van BPMS suites, die ook hier vaak een sterke automatisatie toelaten op een meer grafische manier.

Old School: de MacroService

Macroservices representeren de traditionele SOA aanpak, die nu sterk in vraag wordt gesteld door de IT industrie. Via een macroservice brengt men een volledige applicatie of dienst online, in één grote deployment; deze ondersteunt dan een typische request/response API. Het woord service kan dan in hoofdzaak worden aangewend doordat men de applicatie of dienst heeft ge-“service enabled”. Er wordt m.a.w. een SOAP of (beter!) een REST API aangeboden aan de buitenwereld om met de macroservice te interageren. Vaak is het ook zo dat deze applicatie bovenop een database gebouwd wordt, via dewelke nog wordt geïntegreerd met andere toepassingen.

Momenteel is het sterk afgeraden om op deze manier een nieuwe applicatie op te bouwen, maar deze systemen hebben echter wel nog af en toe hun nut! Vele bedrijven hebben namelijk een bepaald arsenaal aan zogenaamde “legacy” toepassingen, die vaak nog belangrijke taken verrichten, en die te groot en te complex (en dus te duur) zijn geworden om ze volledig te vervangen door een moderne variant die dezelfde kernfunctionaliteit encapsuleert. Wat men dan op z’n minst kan doen om deze applicaties beter te kunnen integreren met de nieuwere generatie componenten, is ze te “service enablen”. Dit betekent dat men er een laag rond bouwt die een moderne (REST) API zal aanbieden waarmee andere toepassingen dan gemakkelijker verbinding kunnen maken. De laag zal ervoor zorgen dat de buitenwereld niets hoeft te merken van de soms rare zaken die met de legacy toepassing kunnen misgaan, of van de esoterische programmeertalen en protocols die erin worden gebruikt.

Let wel dat er steeds moet worden afgewogen om zulke applicaties toch niet te re-engineeren. Wanneer het echt om de core business van een bedrijf gaat, en men wil kunnen inspelen op b.v. een veranderende markt (m.a.w. wanneer men wendbaarder, meer agile, wil zijn), kan het op langere termijn soms voordeliger zijn om ze te vervangen door een meer op microservices geïnspireerde architectuur. Het gebruik van MacroServices is eerder geschikt voor applicaties die minder vaak veranderingen dienen te ondergaan, maar die wel via een API moeten kunnen worden aangesproken. Soms kan het ook gaan om aangekochte software, die dus inherent niet onder de eigen controle zit en niet kan ge-reëngineered worden.

De Toekomst is hier: NanoServices

NanoServices kan twee zaken betekenen. Enerzijds is het een door sommige mensen aangewende term om op een anti-patroon bij het bouwen van microservices te duiden: namelijk een te sterke beperking van de scope, op een manier die zinloos is. Het komt er dus op neer dat men goed moet nadenken over de bounded context en het te verwachten aparte gebruik van de diensten die deel uitmaken van een applicatie.

Anderzijds kan men de term ook officieus gebruiken als bijnaam voor de zogenaamde Serverless diensten, of nog Function Platform as a Service (FPaaS). Via deze platformen kan men hele kleine stukjes code uitrollen zonder zich iets te moeten aantrekken van onderliggende infrastructuur, en deze aan te bieden via een kleine API. De granulariteit van de manier van ontplooien zorgt er daarbij voor dat men vaak nog kleiner kan gaan dan bij microservices. Uiteraard moet men erover blijven waken dat het zin blijft hebben om de functionaliteit zodanig in stukjes te kappen, wil men niet in het gelijknamig benoemde anti-pattern terechtkomen.

Serverless Architecture maakt momenteel grote furore in de public cloud en er zijn ook al enkele open source oplossingen om een dergelijk platform in het eigen datacenter op te zetten.

Besluit: Wat moeten we nu Bouwen?

De microservices architectuur is een zeer goede blauwdruk voor software ontwikkeling. De voordelen van wendbaarheid en flexibiliteit zijn een must voor bedrijven die goed willen kunnen inspelen op de markt en de klant, en een robuuste portfolio aan herbruikbare services willen uitbouwen.

De vereisten om aan échte microservices ontwikkeling te doen zijn echter erg hoog, en het is niet altijd noodzakelijk om zulke extreme flexibiliteit en schaalbaarheid te behalen. Vaak is het voldoende om de microservices architectuur eerder benaderend na te streven via het bouwen van zogenaamde miniservices. In de meeste gevallen is dit dan ook de aangewezen manier van werken.

Wanneer legacy toepassingen moeten worden ontsloten en er geen grote nood is aan het wendbaarder maken van deze applicaties, maar wel een ontsluiting via een goede API, dan kan het voldoende zijn om een services laag rond deze applicaties te bouwen en er op die manier een zogenaamde macroservice van te maken, die vanaf dan vlot mee kan integreren met de rest van de portfolio. Denk echter goed na of toekomstige wendbaarheid en flexibiliteit echt wel van minder belang zijn, alvorens dergelijke technische schuld (technical debt) te betonneren.

NanoServices, ten slotte, indien het niet om het anti-patroon gaat, zijn zeker iets waar men mee mag beginnen experimenteren. Het voordeel om zich niets meer van infrastructuur te hoeven aan te trekken en de beschikbaarheid en schaalbaarheid op een quasi magische manier cadeau te krijgen, is niet te onderschatten. In een toekomstige blog wordt er zeker nog teruggekomen op deze Serverless Architectures.

Op termijn kan deze architecturale stijl de grenzen tussen verschillende applicaties gaan vervagen, om ze te transformeren tot een applicatie-ecosysteem bestaande uit vele herbruikbare, onafhankelijk uitrolbare en afzonderlijk schaalbare componenten.

De Geschiedenis van “Tiers”

De meest traditionele applicaties zijn monolithisch: één programma dat al zijn functies vervult zonder afhankelijk te zijn van externe hulpmiddelen. Lang geleden werden de meeste applicaties op deze manier gebouwd, en vandaag zijn heel wat desktop applicaties hier nog steeds voorbeelden van. Met de opkomst van netwerken en Database Management Systemen (DBMS), werd echter voor vele applicaties een meer component-gebaseerde uitrol nodig. Voor een gedistribueerde applicatie werd het b.v. nodig om een “client” en een “server” of “backend” te hebben, om op die manier een gebruiker toe te laten de applicatie op een andere plaats (op een andere machine) te gebruiken dan de plaats waar de kern van de applicaties zich bevindt (meestal ook met het doel om meerdere gebruikers gelijktijdig van de applicatie gebruik te kunnen laten maken). Dit wordt de “client-server” of “2-tier” architectuur genoemd. Voor applicaties, die aan geavanceerde I/O doen, werd het daarnaast ook noodzakelijk om de verantwoordelijkheid hiervoor bij een DBMS te leggen. Dit systeem wordt dan de “data tier” van de applicatie.

Uiteraard leidden deze twee architecturen reeds snel tot de zogenaamde “3-tier” architectuur, met een client tier en een backend die werd gesplitst in een tier voor de business logic en een data tier. Tegenwoordig zijn er vaak nog meer opsplitsingen mogelijk. In de context van web-applicaties zal men b.v. de client tier nog in twee delen splitsen: de eigenlijke client in de browser, en een “web tier” om de client via het web te kunnen aanbieden. Men zou deze laatste zelfs nog kunnen opdelen in aparte servers voor het statische en dynamische gedeelte van de applicatie. Ook wordt het mogelijk dat een applicatie meerdere verschillende databronnen gebruikt, of dat haar business logica verdeeld geraakt over meerdere tiers (b.v. application logic vs domain logic). Langzaamaan verdwijnt dan ook de notie van tiers (waarbij men een min of meer hiërarchische en lineaire relatie verwacht tussen de componenten), om plaats te maken voor een flexibeler systeem, waarbij de communicatie flexibeler vormen kan aannemen…

Tiers of Lagen?

De opdeling in tiers klinkt allicht bekend in de oren voor wie reeds met software architectuur bezig is, en doet ook denken aan de opdeling van een applicatie in lagen (“layers”). De beide termen, tiers en layers, worden soms zelfs als synoniemen beschouwd (zuiver taalkundig zijn ze dat ook, en in het Nederlands kunnen we ze beide vertalen als “lagen“). Dit is logisch: er is een grote similariteit tussen deze beide concepten, en bijgevolg is er dus enige verwarring aanwezig.

Lagen voorzien in een logische scheiding binnen de architectuur van een applicatie, waarbij het zaak is om tussen deze lagen, die functioneel gezien zo coherent mogelijk moeten zijn, een zo groot mogelijke onderlinge onafhankelijkheid te creëren (het zogenaamde “loskoppelen“). Ze hebben eerder als doel om functionele belangen (user interface (UI), applicatielogica, business logica, data access, etc.) gescheiden te houden en de applicatie aldus makkelijker onderhoudbaar te maken op lange termijn, doordat deze belangen apart benaderd kunnen worden. Tiers daarentegen, zijn fysiek gescheiden onderdelen van een applicatie, die apart van elkaar worden ontplooid, waardoor ze niet alleen het aparte onderhoud en de aparte ontwikkeling verder doortrekken, maar ook apart hergebruiken en schalen mogelijk maken.

De verwarring tussen de beide concepten ontstaat allicht omdat de logische layers in de praktijk zeer vaak corresponderen met de fysieke tiers: de UI zit in de client tier, de business logica zit in de logic tier, en de database-laag komt overeen met de data tier. De scheiding in losgekoppelde lagen is daarnaast de ideale manier om ervoor te zorgen dat tiers los van elkaar kunnen worden gedeployed. Daarenboven wordt het onderscheid ook vervaagd in de context van de Cloud: Tiers zijn dan wel fysiek gescheiden, maar door het gebruik van Cloud-technologie (IaaS of PaaS) kunnen ze evenwel worden gehost op dezelfde fysieke of zelfs virtuele machine. Ze zouden eenvoudig in verschillende Containers kunnen worden geplaatst (zij het JEE, Docker of andere containers).

Om te besluiten: layers vormen dus de bouwstenen van een applicatie op een logische manier, en beïnvloeden sterk de architectuur en het design ervan. Tiers, op hun beurt, definiëren de opdeling van een applicatie in onafhankelijk uitrolbare componenten. Ze hebben ook een sterke impact op de architectuur, maar eerder op het niveau van de interacties tussen de applicatie en andere systemen binnen een groter geheel, en op het niveau van de infrastructuur. Tiers kunnen moeilijk zonder layers: het loskoppelen van delen van de applicatie is nodig om ze apart te kunnen uitrollen. Beide zijn onontbeerlijk om de complexiteit van een applicatie in beheersbare blokken op te delen.

Richting Microservices

Over de interessante evoluties binnen applicatie-architectuur en lagen, kunnen we in de toekomst nog een blog schrijven. Vandaag ligt de focus op tiers, en hoe het opsplitsen van een applicatie in componenten en diensten verregaande gevolgen kunnen hebben voor applicatie-ecosystemen.

Ik heb het reeds in verscheidene blogs over applicatie-ecosystemen gehad, maar nagelaten het concept eenduidig te definiëren. Bij deze dan een poging tot definitie:

Een ecosysteem van applicaties is een groep applicaties (en gerelateerde IT entiteiten) die werken rond een gelijkaardig business domein, of die toebehoren aan eenzelfde organizatie (of beide). Soms betreft het zelfs groepen van applicaties die rond verschillende maar gerelateerde business domeinen werken. Typisch verwerken ze dezelfde of sterk gerelateerde gegevens, en vrij vaak interageren ze ook met elkaar, en/of worden ze gebruikt door dezelfde groep van eindgebruikers.

Hieruit volgt dat binnen een applicatie-ecosysteem er een groot potentieel (!) bestaat voor hergebruik. Of dit potentieel effectief wordt gehaald, hangt sterk af van gemaakte keuzes betreffende enterprise, applicatie en systeem-architectuur.

Een kritiek die is komen te ontstaan op de N-tier architectuur, is dat een applicatie nog steeds te geïsoleerd en self-contained is: alle business-logica zit vaak in één tier, alle persistentie-logica in een andere, etc. Men zou zelfs kunnen zeggen dat we de monolithische applicatie hebben vervangen door monolithische tiers! En dit terwijl applicaties steeds complexer worden en verregaandere behoeften hebben, zoals de integratie van business rules, taakbeheer en workflows; allemaal zaken die zo complex zijn, dat ze al een toepassing op zichzelf kunnen vormen.

Service Oriented Architecture (SOA) is een stap in de goede richting, maar historisch gezien richt deze methodiek zich op interacties tussen verschillende applicaties, binnen het ruimere opzicht van enterprise architectuur. Microservices nemen de ideeën van N-tier en SOA samen, en drijven ze naar een nieuw summum: elke aparte applicatie wordt nu beschouwd als zijn eigen mini-ecosysteem van onafhankelijk uitrolbare diensten, zich elk focussend op een verschillende business capabiliteit, zo klein gemaakt als maar kan (vandaar “micro”), en met zo min mogelijk gecentraliseerde orchestratie. Meestal heeft elke microservice – indien deze nood heeft aan persistentie – ook zijn eigen database (of een ander soort persistentiesysteem), die enkel en alleen voor deze microservice wordt ingeschakeld.

Deze stijl verhoogt sterk de Agility van SOA: de kleinere services kunnen meer cohesief op zichzelf staan, en intern zijn ze meestal ook eenvoudiger dan volledige applicaties typisch zijn. Daarnaast kunnen onderhoud en evolutie van alle microservices apart van elkaar worden beheerd. Dit alles maakt dat deze aparte microservices makkelijker te bouwen en onderhouden zijn dan de volledige applicatie (uiteraard kruipt er wel enig werk in het op een goede manier opdelen van de applicatie in verschillende microservices). Men kan zelfs zo ver gaan als volledige microservices te vervangen door nieuwere en betere: indien ze klein genoeg zijn, kan de kost gerechtvaardigd zijn om een dergelijk stuk software – huiver – weg te gooien.

Daarnaast wordt het voor ontwikkelteams ook mogelijk om flexibeler te kiezen welke technologie, welke talen en welke raamwerken ze zullen gebruiken om hun specifieke microservice zo optimaal mogelijk te implementeren. Ze zouden Java, Node.js, of eender welke andere technologie kunnen kiezen, zo lang ze maar overeenkomen over een gestandaardiseerd communicatiekanaal. Dit kanaal, op zijn beurt, zien we meer en meer evolueren richting RESTful APIs: een robuuste de facto standaard.

Deze evolutie wordt verder nog versterkt door de opkomst van Container technologie: deze zijn de infrastructuurplatformen van de toekomst (of zelfs al van vandaag), en zijn “lichter” en makkelijker inzetbaar dan virtuele machines, waardoor het kosten-effectief wordt om een groter aantal kleinere services te hosten i.p.v. een klein aantal zwaardere applicatie(s)(-tiers). De beide technologische evoluties werken op die manier hand in hand om de schaalbaarheid van applicaties te verbeteren op een fijnmazig niveau: elke microservice kan onafhankelijk van de andere worden geschaald, en via containers kan er voor worden gezorgd dat de eronder liggende infrastructuur, gebruikt door het geheel aan services, een betere match vormt met het evoluerend verbruikspatroon.

Microservices maken het mogelijk voor een organizatie om meer Agile te werken en cross-functionele teams te bouwen, gefocust op business capabiliteiten, i.p.v. teams gefocusd op specifieke IT functies (UI specialisten, middleware specialisten, DBA’s, …). Wanneer een applicatie monolithisch wordt gebouwd, is er vaak veel heen-en-weer “gedoe'” tussen verschillende teams nodig om cross-functionele zaken te implementeren, met het gevaar dat business logica doorsijpelt op plaatsen waar deze niet hoort te zitten (b.v. in de UI of de data laag). Een meer expliciete scheiding van de applicatie in service componenten maakt de grenzen duidelijker, zowel tussen de microservices als tussen de teams die ze implementeren, waardoor er meer onafhankelijkheid in het implementatieproces kan worden gestopt. Een meer servicegericht model van samenwerking wordt op deze manier mogelijk: teams worden klant van elkaar omdat hun producten klant zijn van elkaar.

Ecosystemen van Services

Binnen een applicatie-ecosysteem van enige omvang, is er altijd al op vele niveau’s de nood geweest aan integraties. Met een beetje geluk waren deze integraties gekend wanneer een applicatie werd gebouwd, maar vaak is het echter zo dat de nood aan integratie achteraf ontstaat, wanneer een applicatie reeds enige tijd in productie is. Integraties komen ook voor op het UI niveau, waar ze leiden tot portaal technologie en integration-at-the-glass. Of ze komen voor op het niveau van de data, wat vaak tot gevolg heeft dat een database wordt gedeeld tussen verschillende applicaties. Er zijn reeds verdienstelijke pogingen gedaan om al deze integraties op te vangen via middleware, maar zelfs de alomtegenwoordige Enterprise Service Bus (ESB) is geen panacee.

We kunnen nooit vrij zijn van de onverwachtheid van sommige integratie-behoeftes, maar microservices kunnen een aantal van de moeilijkheden helpen verminderen. Enerzijds komt dit door de standaardisatie van de communicatie tussen microservices. Anderzijds doordat business capabiliteiten dankzij deze architectuur worden opgedeeld in kleinere stukken, wordt het makkelijker om een component te gaan hergebruiken in een andere applicatie, en deze apart te schalen indien hij daardoor zwaarder belast wordt. Bovendien kunnen we applicaties op zo’n manier opsplitsen, dat hergebruik wordt aangemoedigd: er zullen enerzijds applicatiespecifieke microservices deel uitmaken van een applicatie, maar anderzijds zullen er ook microservices zijn die een bepaalde business problematiek of capabiliteit ondersteunen, die onafhankelijk is van applicatielogica; deze laatste zijn vaak in meerdere toepassingen nuttig. Verder kunnen we ook nog microservices hebben die verantwoordelijk zijn voor een bepaald deel van de persistentie-behoeften van de applicatie. Services zo klein dat ze data betreffen die ook door andere applicaties gebruikt wordt. Deze “data services” zullen de poortwachters zijn van de data: zij encapsuleren de databases (of maken deel uit van een algemenere Data as a Service aanpak) en hebben meerdere applicaties als klant.

Uiteindelijk leidt deze opdeling in services tot een heel ander ecosysteem: niet één van monolithische of tiered applicaties, maar één van intergeconnecteerde microservices. En deze grote groep microservices kan dan “ten dienste” staan van specifieke “client”-componenten die een UI bevatten en dus de gebruikers toelaten dit ecosysteem te gebruiken op verschillende manieren. Dezelfde achterliggende dienst kan bijvoorbeeld een rol spelen binnen een web-toepassing, maar ook in een mobiele toepassing.

Eén probleem is dat deze sterke interconnectiviteit tussen een steeds groter wordende groep microservices kan gaan lijken op een onbeheersbaar kluwen (zogenaamde point-to-point integraties). Er zijn echter een paar zaken die dit effect tegengaan:

• Enerzijds is de point-to-point integratie slechts een integratie op conceptueel niveau. Op technisch vlak zal dit worden opgevangen door middleware-technologie, zoals de ESB. Zolang een dienst een logisch en leesbaar adres heeft, kan deze op die manier worden aangesproken. De werkelijke localisering en verbinding is de verantwoordelijkheid van een onderliggend platform.
• Daarnaast kan men ook twee reeds eerder besproken principes toepassen: die van Data-Centric IT, en die van Event-Driven Architecture. Deze zijn compatibel met elkaar en met Microservices, en zorgen samen voor een beheersbaar “inter-service” communicatiemodel: samen kunnen deze methodieken er namelijk voor zorgen dat een dienst enkel moet weten welke data en events er nodig zijn en hoe deze kunnen worden geadresseerd. Er zijn uiteraard nog externe zaken nodig die geen data of Event zijn, maar dit zijn dan meestal generieke en nuttige diensten, zoals het genereren van pdf’s of het aanroepen van eerder technische capabiliteiten, zoals authenticatie of logging.
• Ten slotte komen er specifiek voor deze problematiek ook oplossingen te voorschijn onder de noemer van API management. De publieke interface van een microservice kan namelijk gezien worden als een API (Application Programming Interface). Naast het beheer van een veelvoud aan APIs, richten deze platformen zich ook vaak op het beheer van de levenscyclus van de erachterliggende diensten.

Besluit

Microservices zijn als deployment architectuur een perfecte match voor Agile software ontwikkeling, en verankeren de goede principes van Service Oriented Architecture. Ze maken het mogelijk software op een flexibeler manier te ontwikkelen, met vele kleine componenten, waardoor er sneller kan worden ingespeeld op veranderende behoeften. Ze laten herbruikbaarheid toe op een fijnmazige manier, en verhogen de efficiëntie in het gebruik van resources. Ook met de huidige ontwikkelingen op vlak van infrastructuur: Containers, gaan ze heel goed samen. Samen daarmee, en met EDA en REST, vormen ze een blauwdruk om een applicatie-ecosysteem future-proof op te bouwen.

Containers, the name you know !

Het woord “Container” klinkt vele mensen, niet alleen in de bouw en scheepvaart, maar ook in de IT, reeds bekend in de oren. Het is dan ook, net zoals “Component“, een erg brede term, die binnen ons vakgebied wijd uiteenlopende implementaties kent. In ruime zin wil het uiteraard precies zeggen wat het woord betekent: “Een ding waar andere dingen in kunnen”.

Een paar voorbeelden:

• Containers als Abstract Data Type: binnen programmeertalen kunnen ze worden gebruikt om verzamelingen van andere waarden of objecten te bevatten en beheren (e.g. een Lijst of een Set).
• Containers zijn ook een andere naam voor Applicatieservers, of een specifiek deel ervan om servlets te hosten (de “Web Container“).
• Waar het in deze blog over gaat: Containers als Virtualizatie-middel op niveau van besturingssystemen (“Operating-system-level Virtualization“).

Containers are the new VM’s !

Wat is dat dan precies, die nieuwe Containers waar iedereen het over heeft? Zoals gezegd is het dus een soort van virtualizatietechniek op niveau van, t.t.z. binnen een besturingssysteem. En hier zit natuurlijk het verschil met Virtuele Machines, waarbij we virtualizatie hebben over besturingssystemen heen. Desondanks zorgt de technologie ervoor dat Containers en de erin aanwezige processen netjes van elkaar geïsoleerd blijven. Zoals op de figuur te zien is, hebben Containers het grote voordeel tegenover VM’s dat ze veel lichter zijn. Binnen een VM zal er altijd nood zijn aan een gast-besturingssysteem (“guest os”), dat, hoe klein ook, een deel van de bruikbare middelen van het systeem zal opslorpen. Containers dragen deze last niet. Voorlopig blijven VM’s koning van het datacenter, maar Containers zouden wel eens een coup kunnen plegen.

Containers zijn mogelijk dankzij de manier waarop de Linux kernel werkt (Microsoft kondigde echter al support aan voor Containers binnen Windows Server). Het isoleren van processen en het beperken van hun resource-gebruik is reeds heel lang mogelijk binnen Linux; er was echter een bedrijf als Docker nodig om een ecosysteem aan ondersteunende tools te creëren, om zo deze technologie van onder de grond te halen en recht naar de Cloud te katapulteren. Ondertussen is er trouwens al wat concurrentie in de Containermarkt.

Containers: build once; ship and run anywhere !

De technologie die de laatste tijd rond Containers is uitgebouwd en vooral door Docker en CoreOS is gepopulariseerd, laat toe om om een applicatie met alle nodige bibliotheken, bestanden en configuratie, in een pakketje te stoppen, en dit pakketje naar een Container ondersteunend platform te sturen om de applicatie te laten werken. Het is perfect mogelijk om in je eigen datacenter, of zelfs op één machine op je zolder, Containers te ondersteunen, net zoals in de public cloud. Het mooie is dat het niet uitmaakt waar de server zich bevindt: indien Containers ondersteund zijn, kan je je pakketje erop zwieren. Bovendien bestaan er al van heel veel applicaties standaard pakketjes (b.v. te vinden in de Docker Hub), en hoef je dus al vaak zelf niet meer veel werk te doen om iets te kunnen lanceren.

Containerpakketjes zijn ook heel flexibel uitbreidbaar: ze kunnen gelaagd worden opgebouwd, een beetje als een ajuin. Indien bijvoorbeeld iemand al een Node.js image heeft voorzien, kan je jouw node.js applicatie daarbovenop bouwen. Je hoeft dus niet telkens van nul te beginnen.

Ten slotte is het ook mogelijk je applicatie in meerdere pakketjes te stoppen: b.v. het applicatieve deel en de database apart. Je kan zo’n pakketje zelfs schalen, door het meermaals uit te rollen. Je kan b.v. het webgedeelte van je applicatie in één Docker Image stoppen, en tien maal uitrollen om alle front-end gebruikers aan te kunnen, terwijl je daarnaast b.v. maar één Docker Image uitrolt voor de database (handig als niet alle gebruikers steeds de database nodig hebben). Zo komt de droom van ultieme Modulariseerbaarheid (remember Components?) weer een stapje dichterbij.

CaaS, CPaaS, ContaaS ?

Via Docker en Containertechnologie kan men dus zeer snel applicaties of hun onderdelen uitrollen. Uiteraard wordt het al snel onoverzichtelijk wanneer men dit zomaar ad hoc gaat doen. Gelukkig zijn er reeds systemen ontwikkeld die het beheer van een Container-ondersteunend datacenter en de erop uitgerolde Containers goed ondersteunen. Google Kubernetes is er zo eentje, maar ook CoreOS is al jaren op deze markt actief. De Google Container Engine is een voorbeeld van Containers as a Service in de public cloud.

Momenteel worden zulke “CaaS” platformen meer naar voren gebracht als alternatief voor IaaS en PaaS. Ze vullen dan ook een unieke niche tussen de twee: IaaS werkt met VM’s en vergt veel meer configuratie en administratie, en PaaS is voor sommige gebruikers misschien te beperkend of gewoon een stap te ver qua niveau van ondersteuning. Dan biedt CaaS een gulden middenweg. De betere PaaS platformen maken ondertussen zelfs al gebruik van Containers!

Spijtig genoeg is CaaS vooralsnog geen officiële afkorting – althans niet voor Containers as a Service. De meest gebruikte betekenis van CaaS is Communication as a Service, maar Compiler, Commerce, Content, Crimeware en ja, zelfs Cloud as a Service (partner managed cloud) zijn kandidaten.  ContaaS bestaat allicht nog niet, maar klinkt wat ongelukkig. Ook Container Platform as a Service kunnen we niet afkorten als cPaaS, dit betekent reeds collaboration Platform-as-a-Service. Gezien echter het stijgende gebruik binnen het IT nieuws, zullen ook wij toch de terminologie CaaS hanteren.

Containers, Conclusie !

Containers zijn een bijzonder handige manier om applicaties uit te rollen en te modulariseren. Ze zijn momenteel sterk gehyped en, ondersteund door CaaS, zouden ze wel eens grote invloed kunnen hebben op de cloud, en op ons vak!

De moderne “stack” voor applicaties in de Cloud, van IaaS (Infrastructure as a Service) over PaaS (Platform as a Service) tot SaaS (Software as a Service), is stilaan een gekend plaatje. Maar de strikte scheiding tussen het virtualiseren van infrastructuur, het automatiseren van middleware en het aanbieden van applicaties, en dit alles “als een dienst”, hoeft soms helemaal niet zo strikt te zijn.

In de Application Platform as a Service (aPaaS) branche, die reeds in een vorige blogpost uit de doeken werd gedaan, kan men bijvoorbeeld verschillende soorten aPaaS onderkennen, die variëren van een dunne schil boven IaaS, tot een soort van “Applicatie-Ontwerp-SaaS” oplossingen. In deze blogpost een korte verkenning van deze wondere wereld.

1. Vlak boven de infrastructuur

Sommige PaaS platformen bieden geen ingebouwde applicatieserver of database aan, maar vormen een laag bovenop de infrastructuur die het gebruikers makkelijker maakt om de nodige technologie geïnstalleerd en geconfigureeerd te krijgen op (niet noodzakelijk) virtuele servers.

Een voorbeeld is Cloudify. Bij deze aPaaS kan men als gebruiker een applicatie definiëren aan de hand van een recept. Dit recept stuurt men dan naar een Cloud met Cloudify ondersteuning, waardoor het platform de nodige “ingrediënten” van het recept in gebruik zal nemen. Het grote voordeel, zo stelt Cloudify, is dat recepten niet Cloud-specifiek zijn, en dat ze dus op de meeste Cloud systemen kunnen werken. Dit is b.v. nuttig voor het migreren van applicaties van de ene Cloud naar de andere.

2. Middleware als dienst

De bekendste aPaaS platformen bieden doorgaans een sterke integratie met web- en applicatieservers, en met diensten voor gegevensopslag. Sommige focussen zich op ondersteuning van een welbepaalde technologie, andere op het werken met zoveel mogelijk van de populairdere frameworks van het moment.

Een belangrijk kenmerk van platforms op dit niveau, en voor mij één van doorslaggevend belang, is dat er abstractie wordt gemaakt van de onderliggende infrastructuur. Niet langer moet je rekening houden met op welke server wat komt te staan: je deployt naar een platform, en dit platform kiest transparant welke delen van jouw applicatie op welke resources terecht komen. Welke en hoeveel infrastructuur onderliggend zijn aan het platform, daar hoef je als ontwikkelaar dan minder wakker van te liggen. Bovendien is er bij platformen met deze eigenschap doorgaans enige ondersteuning voor failover, elastisch schalen en multi-tenancy (voor ontwikkelaars).

Architectuur in een Openshift Node

Dit keer kiezen we Red Hat OpenShift als voorbeeld. Dit aPaaS platform bestaat zowel in de publieke cloud, als in een “on premise” installeerbare versie, waardoor je het dus kan gebruiken voor een private Cloud. De basis van het platform is open source.

Wanneer we op deze PaaS inloggen, krijgen we een web console te zien met behulp van dewelke we applicaties kunnen deployen in de Cloud. We moeten daarbij kiezen uit welke “cartridges” een app bestaat. Cartridges kan men beschouwen als een technologisch afgezonderde module, e.g. een MySQL cartridge. daarnaast kiezen we ook hoeveel “gears” de applicatie krijgt, en of ze schaalbaar zal zijn. Gears (letterlijk vertaald: tandwielen of radartjes) zijn eenheden van computatie, ze stellen een bepaalde hoeveelheid processorkracht, geheugen en opslag voor, los van de onderliggende infrastructuur. De cartridges van de applicatie komen dan terecht op de gears en die laatste worden transparant gedeployed op het platform.

3. (Semi-)Grafisch Applicaties ontwikkelen

Dichter bij de SaaS-laag van Cloud platformen, vinden we producten terug die doorgaans gespecialiseerd zijn in slechts enkele onderliggende implementatie-, server- en database-technologieën. Deze specialisatie laat echter wel verregaande automatisatie toe, waardoor het mogelijk wordt om eenvoudige tot matig complexe applicaties te ontwikkelen zonder code te schrijven, of dit slechts in beperkte mate te doen.

Zoho Creator is bijvoorbeeld zo’n platform. Het richt zich vooral op applicaties die sterk gericht zijn op online databases. Zo kan men via drag and drop webformulieren aanmaken, waarvan de data dan in zo’n database zal terechtkomen en eventueel in een complexe workflow. Voorts kan men acties en triggers voorzien rond data-access. Verder kan men bepaalde taken automatiseren, zoals het versturen van emails en genereren van rapporten. Html pagina’s kan men dan verder aanpassen m.b.v. html en het zogenaamd “Deluge Script”, een taal eigen aan het platform.

 Besluit

Deze 3 voorbeelden van een genuanceerdere definiëring van wat aPaaS nu eigenlijk inhoudt, zijn, opnieuw, niet te beschouwen als de enige correcte onderverdeling. In de software-industrie zijn er ondertussen tientallen producten die zichzelf volgens de definitie PaaS mogen noemen, en nog veel meer die zichzelf de noemer geven zonder het strikt genomen te zijn, allemaal met hun eigen specifieke invulling van de term. Al deze producten staan allicht net iets verder of net iets minder ver van IaaS/SaaS dan de voorbeelden hier omschreven.

Dit is voor ontwikkelaars zowel een voordeel als een nadeel: Aan de ene kant biedt het voor elk wat wils, en voor elke applicatie die moet worden geschreven kan men het “ideale platform” vinden. Anderzijds kan dit standaardisatie tegenwerken, en laat dat nu net één van de kenmerken zijn die een aPaaS platform nuttig maken.

Over aPaaS verschenen onlangs een Research Note en Presentatie.

Wat is PaaS?

Productiviteitsverhoging is nu precies de focus van Platform as a Service (PaaS). Een PaaS is een verzameling van diensten voor de infrastructuur van applicaties. In het cloudverhaal kan men PaaS situeren tussen Software as a Service (SaaS – applicatielaag) en Infrastructure as a Service (IaaS – hardwarelaag). De aangeboden diensten zijn onder andere: het applicatieplatform, integratie, databases en business process management. Vandaag wordt er vooral geconcentreerd op de meer specifieke aPaaS: application Platform as a Service.

aPaaS platformen ondersteunen de ontwikkeling en in-productiestelling van applicaties in de cloud. Ze zijn als het ware een uitgebreide applicatieserver in de cloud en ondersteunen multi-tenancy en elastische, horizontale schaalbaarheid van applicaties. aPaaS-platformen bieden bijgevolg nieuwe mogelijkheden aan developers om makkelijker en sneller applicaties te ontwikkelen.

In eerste instantie lag de focus van PaaS-oplossingen op het aanbieden van platform services in de public cloud. Al snel werd duidelijk dat dezelfde technologie toegepast kan worden binnen een organisatie zelf, in een private cloud. Het private aspect is onder andere belangrijk vanwege de confidentialiteit van de gegevens.

Wat zijn de beoogde voordelen?

PaaS-platformen beloven om een aantal obstakels weg te nemen die beletten om productiever toepassingen te ontwikkelen. Ze zijn zo ontworpen dat ontwikkelaars zich kunnen focussen op de toepassingscode en zich niet moeten bezighouden met het opzetten en configureren van servers, storage en middleware stacks. Die worden immers aangeboden “als een service”.

Dit zijn een aantal beoogde voordelen van PaaS:

• Via self-service kunnen ontwikkelaars on-demand een application stack deployen. Met andere woorden, de provisioning van alle nodige componenten (frameworks, middleware, etc.) gebeurt automatisch.
• Toepassingen kunnen automatisch geschaald worden bij een toenemende belasting.
• De huidige deployment methodologie op basis van verschillende omgevingen (ontwikkeling, test, acceptatie, productie) kan worden behouden, maar de overgang tussen de verschillende omgevingen verloopt veel vlotter omdat elke omgeving gebaseerd is op dezelfde application stack, en men dus een homogenere infrastructuur bekomt.
• Indien gewenst kan een toepassing eenvoudig overgezet worden van de ene cloud naar de andere. Zo kan een prototype van een applicatie die ontwikkeld is op een public cloud infrastructuur overgezet worden naar een private infrastructuur of kan een toepassing die gehost is op een private infrastructuur gebruik maken van een public cloud infrastructuur om bijkomende load op te vangen.

Veel van de beoogde voordelen steunen op doorgedreven automatisatie en standaardisatie van het ontwikkelings- en deploymentproces.

Bepaalde PaaS-oplossingen bieden daarnaast ook ondersteuning voor verschillende programmeertalen en frameworks. Architecten en ontwikkelaars kunnen dan de meest aangepaste programmeertaal en framework kiezen voor het type toepassing dat moet ontwikkeld worden, wat de productitiveit ten goede kan komen. Alhoewel het geen algemene eigenschap is van PaaS, is dit toch de moeite waard om te vermelden.

Welke uitdagingen kunnen we verwachten?

Uiteraard brengen PaaS-oplossingen ook een aantal uitdagingen met zich mee. Dit zijn een aantal aandachtspunten:

• Er moet over gewaakt worden dat ontwikkelaars zoveel mogelijk gebruik kunnen blijven maken van hun bestaande competenties, zowel op vlak van programmeertalen en frameworks, maar ook op vlak van de benodigde tools.
• Om tot een zo hoog mogelijke graad van automatisatie te komen moeten een aantal services geïntegreerd worden in de PaaS-oplossing en als plug-and-play componenten kunnen aangeboden worden aan ontwikkelaars. Denk daarbij aan gebruikersbeheer en toepassingsmonitoring.
• Het eenvoudiger maken van het leven van de ontwikkelaars zou geen extra belasting mogen teweegbrengen voor operations. Een PaaS-oplossing zou een win-win moeten zijn voor alle betrokkenen in het ontwikkelproces.
• In hoeverre kan het deployment-proces geautomatiseerd worden in al zijn aspecten? Zijn de nodige deployment parameters beschikbaar voor bijvoorbeeld database-connecties of message queues? Moeten er configuratie-aanpassingen gebeuren op niveau van de infrastructuur?

Het valt dus te bezien in hoeverre PaaS-platformen effectief tegemoet komen aan de vraag naar een hogere productiviteit in toepassingsontwikkeling. In ieder geval is de trend naar dergelijke platformen ingezet waarbij de focus ligt op automatisatie en standaardisatie die toelaat om als het ware een assembleerlijn te maken om toepassingen efficiënter te ontwikkelen en ze sneller te kunnen opleveren.

Hoewel de markt van PaaS-oplossingen nog in zijn kinderschoenen staat, zijn er vandaag al veel verschillende oplossingen beschikbaar, met elk hun eigen invalshoek. Dat is echter voer voor een volgende blogpost.

Over aPaaS zijn een Research Note en Presentatie beschikbaar.