Application du low-code dans les plateformes analytiques

Chers lecteurs, bonne journée !

La tâche de créer des plates-formes informatiques pour la collecte et l'analyse des données se pose tôt ou tard pour toute entreprise dont l'activité repose sur un modèle de prestation de services intellectuellement chargé ou sur la création de produits techniquement complexes. Construire des plateformes analytiques est une tâche complexe et chronophage. Cependant, n’importe quelle tâche peut être simplifiée. Dans cet article, je souhaite partager mon expérience dans l'utilisation d'outils low-code pour aider à créer des solutions analytiques. Cette expérience a été acquise lors de la mise en œuvre de plusieurs projets au sein de la direction Big Data Solutions de la société Neoflex. Depuis 2005, la direction Big Data Solutions de Neoflex s'occupe des problématiques de construction d'entrepôts et de lacs de données, résout les problèmes d'optimisation de la vitesse de traitement de l'information et travaille sur une méthodologie de gestion de la qualité des données.

Personne ne pourra éviter l’accumulation consciente de données faiblement et/ou fortement structurées. Peut-être même s’il s’agit de petites entreprises. Après tout, lors de la croissance d'une entreprise, un entrepreneur prometteur sera confronté aux problèmes de développement d'un programme de fidélité, voudra analyser l'efficacité des points de vente, réfléchira à la publicité ciblée et sera intrigué par la demande de produits d'accompagnement. . En première approximation, le problème peut être résolu « à genoux ». Mais à mesure que l’entreprise se développe, le recours à une plateforme analytique reste inévitable.

Cependant, dans quel cas les tâches d’analyse de données peuvent-elles se transformer en problèmes de classe « Rocket Science » ? Peut-être au moment où nous parlons de très grandes données.
Pour faciliter Rocket Science, vous pouvez manger l'éléphant morceau par morceau.

Plus vos applications/services/microservices sont discrets et autonomes, plus il sera facile pour vous, vos collègues et l’ensemble de l’entreprise de digérer l’éléphant.

La quasi-totalité de nos clients sont parvenus à ce postulat, après avoir reconstruit le paysage en s'appuyant sur les pratiques d'ingénierie des équipes DevOps.

Mais même avec un régime « séparé et éléphantesque », nous avons de fortes chances de voir une « sursaturation » du paysage informatique. À ce moment, cela vaut la peine de s'arrêter, d'expirer et de regarder de côté plateforme d'ingénierie low-code.

De nombreux développeurs sont effrayés par la perspective d’une impasse dans leur carrière lorsqu’ils abandonnent l’écriture directe de code pour se tourner vers le « glisser » des flèches dans les interfaces utilisateur des systèmes low-code. Mais l'avènement des machines-outils n'a pas entraîné la disparition des ingénieurs, mais a amené leur travail à un nouveau niveau !

Voyons pourquoi.

L'analyse des données dans le domaine de la logistique, de l'industrie des télécommunications, de la recherche sur les médias et du secteur financier est toujours associée aux questions suivantes :

• Vitesse d'analyse automatisée ;
• Capacité à mener des expériences sans affecter le flux principal de production de données ;
• Fiabilité des données préparées ;
• Suivi des modifications et gestion des versions ;
• Provenance des données, lignée des données, CDC ;
• Livraison rapide de nouvelles fonctionnalités dans l'environnement de production ;
• Et le plus notoire : le coût de développement et de support.

Autrement dit, les ingénieurs ont un grand nombre de tâches de haut niveau, qui ne peuvent être accomplies avec une efficacité suffisante qu'en évacuant leur conscience des tâches de développement de bas niveau.

Les conditions préalables pour que les développeurs puissent passer à un nouveau niveau étaient l'évolution et la numérisation de l'entreprise. La valeur du développeur évolue également : il existe une pénurie importante de développeurs capables de s'immerger dans les concepts du métier en cours d'automatisation.

Faisons une analogie avec les langages de programmation de bas niveau et de haut niveau. Le passage des langages de bas niveau vers les langages de haut niveau est une transition de l'écriture de « directives directes dans le langage du matériel » vers des « directives dans le langage des personnes ». C'est-à-dire ajouter une couche d'abstraction. Dans ce cas, la transition vers les plateformes low-code à partir de langages de programmation de haut niveau est une transition de « directives dans le langage des gens » vers des « directives dans le langage des affaires ». S'il y a des développeurs qui sont attristés par ce fait, c'est peut-être qu'ils l'ont été depuis la naissance de Java Script, qui utilise des fonctions de tri de tableaux. Et ces fonctions, bien entendu, ont une implémentation logicielle sous le capot par d'autres moyens de la même programmation de haut niveau.

Le low-code n’est donc que l’apparence d’un autre niveau d’abstraction.

Expérience appliquée en utilisant le low-code

Le sujet du low-code est assez vaste, mais je voudrais maintenant parler de l'application pratique des « concepts low-code » en utilisant l'exemple d'un de nos projets.

La division Big Data Solutions de Neoflex se spécialise davantage dans le secteur financier des entreprises, en créant des entrepôts et des lacs de données et en automatisant divers rapports. Dans ce créneau, l’utilisation du low-code est depuis longtemps devenue un standard. Parmi d'autres outils low-code, on peut citer les outils d'organisation des processus ETL : Informatica Power Center, IBM Datastage, Pentaho Data Integration. Ou encore Oracle Apex, qui fait office d'environnement pour le développement rapide d'interfaces d'accès et d'édition des données. Cependant, l’utilisation d’outils de développement low-code n’implique pas toujours la création d’applications très ciblées sur une pile technologique commerciale avec une dépendance évidente à l’égard du fournisseur.

Grâce aux plateformes low-code, vous pouvez également organiser l’orchestration des flux de données, créer des plateformes de data science ou, par exemple, des modules de contrôle de la qualité des données.

L'un des exemples appliqués d'expérience dans l'utilisation d'outils de développement low-code est la collaboration entre Neoflex et Mediascope, l'un des leaders du marché russe de la recherche sur les médias. L'un des objectifs commerciaux de cette société est la production de données sur la base desquelles les annonceurs, les plateformes Internet, les chaînes de télévision, les stations de radio, les agences de publicité et les marques prennent des décisions concernant l'achat de publicité et planifient leurs communications marketing.

La recherche sur les médias est un domaine d'activité technologiquement chargé. Reconnaître des séquences vidéo, collecter des données à partir d'appareils qui analysent la visualisation, mesurer l'activité sur les ressources Web - tout cela implique que l'entreprise dispose d'un personnel informatique important et d'une énorme expérience dans la création de solutions analytiques. Mais la croissance exponentielle de la quantité d’informations, du nombre et de la variété de leurs sources oblige l’industrie des données informatiques à progresser constamment. La solution la plus simple pour faire évoluer la plateforme analytique Mediascope déjà opérationnelle pourrait être d’augmenter le personnel informatique. Mais une solution bien plus efficace consiste à accélérer le processus de développement. L’une des étapes allant dans cette direction pourrait être l’utilisation de plateformes low-code.

Au moment du démarrage du projet, l’entreprise disposait déjà d’une solution produit fonctionnelle. Cependant, l'implémentation de la solution dans MSSQL n'a pas pu répondre pleinement aux attentes en matière de fonctionnalité de mise à l'échelle tout en maintenant un coût de développement acceptable.

La tâche qui nous attendait était vraiment ambitieuse : Neoflex et Mediascope devaient créer une solution industrielle en moins d'un an, sous réserve de la sortie du MVP dans le premier trimestre suivant la date de démarrage.

La pile technologique Hadoop a été choisie comme base pour créer une nouvelle plateforme de données basée sur l'informatique low-code. HDFS est devenu la norme pour le stockage de données à l'aide de fichiers Parquet. Pour accéder aux données situées dans la plateforme, on a utilisé Hive, dans lequel toutes les vitrines disponibles sont présentées sous forme de tableaux externes. Le chargement des données dans le stockage a été implémenté à l'aide de Kafka et Apache NiFi.

L'outil Lowe-code de ce concept a été utilisé pour optimiser la tâche la plus exigeante en main-d'œuvre dans la construction d'une plate-forme analytique : la tâche de calcul des données.

L'outil Low-Code Datagram a été choisi comme mécanisme principal de mappage des données. Datagramme Neoflex est un outil de développement de transformations et de flux de données.
Grâce à cet outil, vous pouvez vous passer d'écrire du code Scala manuellement. Le code Scala est généré automatiquement à l’aide de l’approche Model Driven Architecture.

Un avantage évident de cette approche est l’accélération du processus de développement. Cependant, en plus de la rapidité, il existe également les avantages suivants :

• Visualisation du contenu et de la structure des sources/récepteurs ;
• Retracer l'origine des objets de flux de données jusqu'à des champs individuels (lignage) ;
• Exécution partielle des transformations avec visualisation des résultats intermédiaires ;
• Réviser le code source et l'ajuster avant son exécution ;
• Validation automatique des transformations ;
• Téléchargement automatique des données 1 en 1.

La barrière à l'entrée dans les solutions low-code pour générer des transformations est assez faible : le développeur doit connaître SQL et avoir de l'expérience avec les outils ETL. Il convient de mentionner que les générateurs de transformation pilotés par le code ne sont pas des outils ETL au sens large du terme. Les outils low-code peuvent ne pas disposer de leur propre environnement d'exécution de code. Autrement dit, le code généré sera exécuté dans l'environnement qui existait sur le cluster avant même l'installation de la solution low-code. Et c’est peut-être un autre avantage du karma low-code. Car, en parallèle d'une équipe low-code, une équipe « classique » peut travailler qui implémente des fonctionnalités, par exemple, en code Scala pur. La mise en production des améliorations apportées par les deux équipes sera simple et transparente.

Il convient peut-être de noter qu’en plus du low-code, il existe également des solutions no-code. Et à la base, ce sont des choses différentes. Le low-code permet au développeur d'interférer davantage avec le code généré. Dans le cas de Datagram, il est possible de visualiser et de modifier le code Scala généré ; le no-code peut ne pas offrir une telle opportunité. Cette différence est très significative non seulement en termes de flexibilité de la solution, mais aussi en termes de confort et de motivation dans le travail des data ingénieurs.

Architecture des solutions

Essayons de comprendre exactement comment un outil low-code aide à résoudre le problème de l'optimisation de la vitesse de développement de la fonctionnalité de calcul des données. Examinons d’abord l’architecture fonctionnelle du système. Un exemple dans ce cas est le modèle de production de données pour la recherche sur les médias.

Les sources de données dans notre cas sont très hétérogènes et diverses :

• Les compteurs de personnes (TV-mètres) sont des dispositifs logiciels et matériels qui lisent le comportement des utilisateurs des répondants du panel de télévision - qui, quand et quelle chaîne de télévision a été regardée dans le foyer participant à l'étude. Les informations fournies sont un flux d'intervalles de visionnage de diffusion liés au paquet multimédia et au produit multimédia. Les données au stade du chargement dans le Data Lake peuvent être enrichies d'attributs démographiques, de géostratification, de fuseau horaire et d'autres informations nécessaires à l'analyse de l'écoute télévisée d'un produit médiatique particulier. Les mesures prises peuvent être utilisées pour analyser ou planifier des campagnes publicitaires, évaluer l'activité et les préférences du public et constituer le réseau de diffusion ;
• Les données peuvent provenir de systèmes de surveillance des émissions de télévision en streaming et de mesure de la visualisation du contenu des ressources vidéo sur Internet ;
• Outils de mesure dans l'environnement Web, y compris des compteurs centrés sur le site et centrés sur l'utilisateur. Le fournisseur de données pour Data Lake peut être un module complémentaire de navigateur de barre de recherche et une application mobile avec un VPN intégré.
• Les données peuvent également provenir de sites qui consolident les résultats du remplissage de questionnaires en ligne et les résultats des entretiens téléphoniques dans les enquêtes en entreprise ;
• Un enrichissement supplémentaire du lac de données peut avoir lieu en téléchargeant des informations à partir des journaux des entreprises partenaires.

La mise en œuvre du chargement depuis les systèmes sources vers la première étape des données brutes peut être organisée de différentes manières. Si le low-code est utilisé à ces fins, la génération automatique de scripts de chargement basés sur des métadonnées est possible. Dans ce cas, il n’est pas nécessaire de descendre au niveau du développement de mappages source-cible. Pour implémenter le chargement automatique, il faut établir une connexion à la source, puis définir dans l'interface de chargement la liste des entités à charger. La structure des répertoires dans HDFS sera créée automatiquement et correspondra à la structure de stockage des données sur le système source.

Cependant, dans le cadre de ce projet, nous avons décidé de ne pas utiliser cette fonctionnalité de la plateforme low-code car la société Mediascope a déjà commencé de manière indépendante à travailler sur la production d'un service similaire utilisant la combinaison Nifi + Kafka.

Il convient de préciser d'emblée que ces outils ne sont pas interchangeables, mais plutôt complémentaires. Nifi et Kafka sont capables de fonctionner aussi bien en connexion directe (Nifi -> Kafka) qu'en connexion inverse (Kafka -> Nifi). Pour la plateforme de recherche média, la première version du bundle a été utilisée.

Dans notre cas, NayFi devait traiter différents types de données provenant des systèmes sources et les envoyer au courtier Kafka. Dans ce cas, les messages ont été envoyés à un sujet Kafka spécifique à l'aide des processeurs PublishKafka Nifi. L'orchestration et la maintenance de ces pipelines sont réalisées dans une interface visuelle. L'outil Nifi et l'utilisation de la combinaison Nifi + Kafka peuvent également être qualifiés d'approche de développement low-code, qui présente une faible barrière à l'entrée dans les technologies Big Data et accélère le processus de développement d'applications.

L'étape suivante de la mise en œuvre du projet consistait à regrouper les données détaillées dans un format de couche sémantique unique. Si une entité possède des attributs historiques, le calcul est effectué dans le cadre de la partition concernée. Si l'entité n'est pas historique, alors il est éventuellement possible soit de recalculer tout le contenu de l'objet, soit de refuser complètement de recalculer cet objet (faute de modifications). A ce stade, des clés sont générées pour toutes les entités. Les clés sont stockées dans les répertoires Hbase correspondant aux objets maîtres, qui contiennent une correspondance entre les clés de la plateforme analytique et les clés des systèmes sources. La consolidation des entités atomiques s'accompagne d'un enrichissement avec les résultats du calcul préliminaire des données analytiques. Le cadre de calcul des données était Spark. La fonctionnalité décrite pour regrouper les données en une seule sémantique a également été implémentée sur la base des mappages de l'outil Low-Code Datagram.

L'architecture cible nécessitait un accès SQL aux données pour les utilisateurs professionnels. Hive a été utilisé pour cette option. Les objets sont automatiquement enregistrés dans Hive lorsque vous activez l'option « Register Hive Table » dans l'outil low-code.

Contrôle du flux de calcul

Datagram dispose d'une interface pour créer des conceptions de flux de travail. Les mappages peuvent être lancés à l'aide du planificateur Oozie. Dans l'interface du développeur de flux, il est possible de créer des schémas pour des transformations de données parallèles, séquentielles ou dépendant de l'exécution. Les scripts shell et les programmes Java sont pris en charge. Il est également possible d'utiliser le serveur Apache Livy. Apache Livy est utilisé pour exécuter des applications directement depuis l'environnement de développement.

Si l'entreprise dispose déjà de son propre orchestrateur de processus, il est possible d'utiliser l'API REST pour intégrer des mappages dans un flux existant. Par exemple, nous avons eu une expérience assez réussie de l'intégration de mappages dans Scala dans des orchestrateurs écrits en PLSQL et Kotlin. L'API REST d'un outil low-code comprend des opérations telles que la génération d'une année exécutable basée sur la conception du mappage, l'appel d'un mappage, l'appel d'une séquence de mappages et, bien sûr, la transmission de paramètres à l'URL pour exécuter les mappages.

Avec Oozie, il est possible d'organiser un flux de calcul à l'aide d'Airflow. Peut-être que je ne m'attarderai pas longtemps sur la comparaison entre Oozie et Airflow, mais dirai simplement que dans le cadre d'un travail sur un projet de recherche sur les médias, le choix s'est porté en faveur d'Airflow. Les principaux arguments cette fois-ci étaient une communauté plus active développant le produit et une interface + API plus développées.

Airflow est également bon car il utilise le bien-aimé Python pour décrire les processus de calcul. Et en général, il n’existe pas tellement de plateformes de gestion de workflow open source. Lancer et suivre l’exécution de processus (y compris un diagramme de Gantt) ne fait qu’ajouter des points au karma d’Airflow.

Le format de fichier de configuration pour lancer des mappages de solutions low-code est devenu spark-submit. Cela s'est produit pour deux raisons. Premièrement, spark-submit vous permet d'exécuter directement un fichier jar depuis la console. Deuxièmement, il peut contenir toutes les informations nécessaires pour configurer le workflow (ce qui facilite l'écriture de scripts générant du Dag).
L'élément le plus courant du flux de travail Airflow dans notre cas était le SparkSubmitOperator.

SparkSubmitOperator vous permet d'exécuter des jars - des mappages de datagrammes packagés avec des paramètres d'entrée pré-générés pour eux.

Il convient de mentionner que chaque tâche Airflow s'exécute dans un thread distinct et ne sait rien des autres tâches. Par conséquent, l'interaction entre les tâches est effectuée à l'aide d'opérateurs de contrôle, tels que DummyOperator ou BranchPythonOperator.

Dans l'ensemble, l'utilisation de la solution low-code Datagram en conjonction avec l'universalisation des fichiers de configuration (formant Dag) a conduit à une accélération et une simplification significative du processus de développement des flux de chargement de données.

Calcul de vitrine

L’étape la plus chargée intellectuellement dans la production de données analytiques est peut-être celle de la construction de vitrines. Dans le cadre d’un des flux de calcul des données de la société d’études, à ce stade, les données sont réduites à une diffusion de référence, prenant en compte des corrections de fuseaux horaires et liées à la grille de diffusion. Il est également possible de s'adapter au réseau de diffusion local (informations locales et publicité). Entre autres choses, cette étape décompose les intervalles de visionnage continu des produits multimédias sur la base de l'analyse des intervalles de visionnage. Immédiatement, les valeurs de visualisation sont « pondérées » en fonction des informations sur leur signification (calcul d'un facteur de correction).

Une étape distincte dans la préparation des vitrines est la validation des données. L'algorithme de validation implique l'utilisation d'un certain nombre de modèles scientifiques mathématiques. Cependant, l’utilisation d’une plateforme low-code vous permet de diviser un algorithme complexe en un certain nombre de mappages distincts lisibles visuellement. Chacun des mappages effectue une tâche précise. En conséquence, le débogage intermédiaire, la journalisation et la visualisation des étapes de préparation des données sont possibles.

Il a été décidé de discrétiser l'algorithme de validation en sous-étapes suivantes :

• Construire des régressions des dépendances d'écoute des réseaux de télévision dans une région avec une visualisation de tous les réseaux de la région pendant 60 jours.
• Calcul des résidus studentisés (écarts des valeurs réelles par rapport à celles prédites par le modèle de régression) pour tous les points de régression et pour la journée calculée.
• Une sélection de paires région-réseau anormales, où le solde étudiant du jour de règlement dépasse la norme (spécifiée par les paramètres de fonctionnement).
• Recalcul du résidu studentisé corrigé pour les paires région anormale-réseau de télévision pour chaque répondant qui a regardé le réseau dans la région, déterminant la contribution de ce répondant (la quantité de changement dans le résidu studentisé) en excluant le visionnage de ce répondant de l'échantillon .
• Recherche de candidats dont l'exclusion ramène à la normale le solde étudiant du salaire.

L'exemple ci-dessus confirme l'hypothèse selon laquelle un ingénieur de données a déjà trop de choses en tête... Et, s'il s'agit bien d'un « ingénieur » et non d'un « codeur », alors la peur d'une dégradation professionnelle lors de l'utilisation d'outils low-code lui doit finalement battre en retraite.

Que peut faire d’autre le low-code ?

Le champ d'application d'un outil low-code pour le traitement des données par lots et par flux sans avoir besoin d'écrire manuellement du code dans Scala ne s'arrête pas là.

L’utilisation du low-code dans le développement de datalake est déjà devenue un standard pour nous. On peut probablement dire que les solutions basées sur la pile Hadoop suivent le chemin de développement des DWH classiques basés sur SGBDR. Les outils low-code sur la pile Hadoop peuvent résoudre à la fois les tâches de traitement des données et la tâche de création des interfaces BI finales. Par ailleurs, il convient de noter que la BI peut signifier non seulement la représentation des données, mais aussi leur édition par les utilisateurs métiers. Nous utilisons souvent cette fonctionnalité lors de la création de plateformes analytiques pour le secteur financier.

Entre autres choses, en utilisant le low-code et, en particulier, Datagram, il est possible de résoudre le problème du suivi de l'origine des objets de flux de données avec atomicité jusqu'aux champs individuels (lignage). Pour ce faire, l'outil low-code implémente une interface avec Apache Atlas et Cloudera Navigator. Essentiellement, le développeur doit enregistrer un ensemble d'objets dans les dictionnaires Atlas et référencer les objets enregistrés lors de la création de mappages. Le mécanisme de suivi de l'origine des données ou d'analyse des dépendances des objets permet de gagner beaucoup de temps lorsqu'il est nécessaire d'apporter des améliorations aux algorithmes de calcul. Par exemple, lors de la préparation des états financiers, cette fonctionnalité vous permet de survivre plus confortablement à la période de changements législatifs. Après tout, mieux nous comprenons la dépendance inter-formes dans le contexte des objets d'une couche détaillée, moins nous rencontrerons de défauts « soudains » et réduirons le nombre de retouches.

Qualité des données et Low-code

Une autre tâche implémentée par l'outil low-code sur le projet Mediascope était la tâche de classe Data Quality. Une particularité de la mise en œuvre du pipeline de vérification des données pour le projet de la société de recherche était l'absence d'impact sur les performances et la rapidité du flux de calcul des données principales. Pour pouvoir orchestrer des flux de vérification de données indépendants, Apache Airflow, déjà familier, a été utilisé. Alors que chaque étape de la production de données était prête, une partie distincte du pipeline DQ a été lancée en parallèle.

Il est considéré comme une bonne pratique de surveiller la qualité des données dès leur création dans la plateforme analytique. Ayant des informations sur les métadonnées, nous pouvons vérifier le respect des conditions de base à partir du moment où les informations entrent dans la couche primaire - non nulles, contraintes, clés étrangères. Cette fonctionnalité est implémentée sur la base de mappages générés automatiquement de la famille de qualité des données dans Datagram. Dans ce cas, la génération de code est également basée sur les métadonnées du modèle. Sur le projet Mediascope, l'interface a été réalisée avec les métadonnées du produit Enterprise Architect.

En associant l'outil low-code à Enterprise Architect, les vérifications suivantes ont été automatiquement générées :

• Vérifier la présence de valeurs « nulles » dans les champs avec le modificateur « non nul » ;
• Vérification de la présence de doublons de la clé primaire ;
• Vérification de la clé étrangère d'une entité ;
• Vérification de l'unicité d'une chaîne basée sur un ensemble de champs.

Pour des vérifications plus complexes de la disponibilité et de la fiabilité des données, un mappage a été créé avec Scala Expression, qui prend en entrée un code de vérification Spark SQL externe préparé par les analystes de Zeppelin.

Bien entendu, la génération automatique des chèques doit se faire progressivement. Dans le cadre du projet décrit, celle-ci a été précédée des étapes suivantes :

• DQ implémenté dans les notebooks Zeppelin ;
• DQ intégré à la cartographie ;
• DQ sous la forme de mappages massifs séparés contenant tout un ensemble de contrôles pour une entité distincte ;
• Mappages DQ paramétrés universels qui acceptent les informations sur les métadonnées et les contrôles commerciaux en entrée.

Le principal avantage de la création d'un service de contrôle paramétré est peut-être la réduction du temps nécessaire pour fournir les fonctionnalités à l'environnement de production. Les nouveaux contrôles de qualité peuvent contourner le modèle classique de livraison de code indirectement via des environnements de développement et de test :

• Toutes les vérifications de métadonnées sont générées automatiquement lorsque le modèle est modifié dans EA ;
• Des contrôles de disponibilité des données (déterminant la présence de données à un moment donné) peuvent être générés sur la base d'un répertoire qui stocke le moment attendu de l'apparition de la prochaine donnée dans le contexte des objets ;
• Les contrôles de validation des données commerciales sont créés par les analystes dans les blocs-notes Zeppelin. De là, ils sont envoyés directement aux tables de réglage des modules DQ dans l'environnement de production.

Il n’y a aucun risque à envoyer directement des scripts en production. Même avec une erreur de syntaxe, le maximum qui nous menace est l'échec d'un contrôle, car le flux de calcul des données et le flux de lancement du contrôle qualité sont séparés l'un de l'autre.

Essentiellement, le service DQ fonctionne en permanence dans l'environnement de production et est prêt à commencer son travail dès l'apparition de la prochaine donnée.

Au lieu d'une conclusion

L’avantage d’utiliser le low-code est évident. Les développeurs n’ont pas besoin de développer l’application à partir de zéro. Et un programmeur libéré de tâches supplémentaires produit des résultats plus rapidement. La rapidité, à son tour, libère du temps supplémentaire pour résoudre les problèmes d’optimisation. Par conséquent, dans ce cas, vous pouvez compter sur une solution meilleure et plus rapide.

Bien entendu, le low-code n’est pas une panacée, et la magie n’arrive pas d’elle-même :

• L’industrie du low-code traverse une phase de « renforcement » et il n’existe pas encore de normes industrielles uniformes ;
• De nombreuses solutions low-code ne sont pas gratuites et leur achat doit être une démarche consciente, qui doit être effectuée en toute confiance dans les avantages financiers de leur utilisation ;
• De nombreuses solutions low-code ne fonctionnent pas toujours bien avec GIT/SVN. Ou bien ils ne sont pas pratiques à utiliser si le code généré est masqué ;
• Lors de l'extension de l'architecture, il peut être nécessaire d'affiner la solution low-code - ce qui, à son tour, provoque un effet « d'attachement et de dépendance » à l'égard du fournisseur de la solution low-code.
• Un niveau de sécurité adéquat est possible, mais cela demande beaucoup de travail et est difficile à mettre en œuvre dans les moteurs de systèmes low-code. Les plateformes low-code ne doivent pas être choisies uniquement sur la base du principe de recherche des avantages de leur utilisation. Lors du choix, il convient de se poser des questions sur la disponibilité des fonctionnalités de contrôle d'accès et de délégation/escalade des données d'identification au niveau de l'ensemble du paysage informatique de l'organisation.

Cependant, si tous les défauts du système choisi vous sont connus, et que les bénéfices de son utilisation sont néanmoins majoritaires, alors passez sans crainte au petit code. De plus, la transition vers celui-ci est inévitable – tout comme toute évolution est inévitable.

Si un développeur sur une plate-forme low-code fait son travail plus rapidement que deux développeurs sans low-code, cela donne à l'entreprise une longueur d'avance à tous égards. Le seuil d’entrée dans les solutions low-code est plus bas que dans les technologies « traditionnelles », ce qui a un effet positif sur la problématique du manque de personnel. Lors de l'utilisation d'outils low-code, il est possible d'accélérer l'interaction entre les équipes fonctionnelles et de prendre des décisions plus rapides sur l'exactitude de la voie choisie pour la recherche en science des données. Les plateformes de bas niveau peuvent piloter la transformation numérique d'une organisation car les solutions produites peuvent être comprises par des spécialistes non techniques (en particulier les utilisateurs professionnels).

Si vous avez des délais serrés, une logique métier chargée, un manque d’expertise technologique et que vous avez besoin d’accélérer votre mise sur le marché, alors le low-code est un moyen de répondre à vos besoins.

On ne peut nier l'importance des outils de développement traditionnels, mais dans de nombreux cas, l'utilisation de solutions low-code est le meilleur moyen d'augmenter l'efficacité des tâches à résoudre.

Source: habr.com