Compétences métiers

Mots-clés: programmation concurrente et distribuée, DevSecOps, ALM, intégration continue, industrialisation

B2: Concevoir, évaluer, implémenter, intégrer et exploiter des services numériques produisant de la valeur pour les utilisateurs et utilisatrices en Considérant les règles éthiques et juridiques de la profession ; tenant compte de l’existant et des environnements technologiques hétérogènes ; évaluant et sélectionnant les technologies de l’information et de la communication ; optimisant les ressources techniques, financières et humaines ; optimisant l’expérience utilisateur et utilisatrice ; garantissant la sécurité.

Programmation concurrente et distribuée

Mes collègues Roald et Flavio ont présenté ces concepts lors de leurs présentations LI : LI Roald: Programmation distribuée et LI Flàvio: Programmation concurrente. Les sujets qui m'ont particulièrement marqué sont :

1. Quelques différences :

   • Lieu d'exécution : La programmation concurrente concerne l’exécution de plusieurs tâches ou processus sur une seule machine, généralement en utilisant plusieurs cœurs ou threads d’un processeur. En revanche, la programmation distribuée fait référence à l’exécution de tâches sur plusieurs machines ou nœuds au sein d’un réseau,
   • Communication : Dans la programmation concurrente, les threads ou processus communiquent principalement par le partage de la mémoire. Dans la programmation distribuée, la communication est réalisée en envoyant des messages ou des données à travers le réseau entre les différents nœuds,
   • Défaillances : Dans la programmation concurrente, une défaillance est généralement catastrophique et entraîne l’arrêt de tous les threads ou processus. Dans la programmation distribuée, une défaillance peut se limiter à un seul nœud, tandis que les autres nœuds peuvent continuer à fonctionner. Cependant, la gestion de ces défaillances peut représenter un défi.

2. Quelques caractéristiques communes:

   • Parallélisme : Les deux approches visent à exécuter plusieurs tâches en parallèle anfin d'améliorer les performances ou la capacité de traitement,
   • Coordination : Que ce soit en programmation concurrente ou distribuée, une coordination appropriée est nécessaire pour garantir que les tâches sont exécutées dans l'ordre correct, surtout lorsqu'elles partagent des ressources ou des données
   • Synchronisation : Les deux types de programmation nécessitent une certaine forme de synchronisation - que ce soit pour l'ordonnancement des threads dans un contexte concurrent, ou pour garantir la cohérence des données entre les nœuds dans un contexte distribué.

3. Paradigmes modernes : L'architecture orientée services (SOA), les microservices, l'informatique en nuage, et les conteneurs sont des tendances actuelles à comprendre et à maîtriser.

4. Sécurité : La protection des données et des systèmes contre les attaques est un aspect essentiel de la programmation distribuée.

Dans notre application, un exemple de fonction concurrente pourrait être la fonction asynchrone. Dans un contexte traditionnel de requête à une base de données, une application doit attendre la réponse de la base de données avant de pouvoir continuer son exécution. Cela peut poser problème, surtout si la requête est lente ou si la base de données est fortement sollicitée, car cela peut bloquer d’autres opérations. En revanche, avec une connexion asynchrone à une base de données, l’application peut envoyer une requête à la base de données et continuer à exécuter d’autres tâches sans attendre la réponse. Une fois que la base de données a fini de traiter la requête, elle envoie une réponse à l’application, qui peut alors traiter les résultats à un moment qui lui convient. Cela représente un exemple de programmation concurrente car plusieurs tâches, telles que l’envoi d’une requête à la base de données et l’exécution d’autres opérations par l’application, sont en cours d’exécution simultanément.

La fonction asynchrone que j'ai créée dans le projet Ceres. Le plein potentiel, c'est-à-dire l'exécution d'autres actions dans l'attente de la réponse, n'a pas été exploité dans le cas présent.

DevSecOps Le concept de DevSecOps est apparu pour la première fois ce semestre lors du SF DevOps , pour lequel j’ai fait un rapport disponible ici: Rapport SF DevOps. Apres, j’ai eu l’occasion d’assister à des présentations sur ce sujet lors des DevOps Days à Genève. Le discours le plus mémorable a été donné par Akshata Sawant, qui a abordé la sécurité sous le titre « Zero Trust Security for your APIs » : DevOpsDays
Comme son titre l’indique, la présentation portait sur la philosophie de “Zero Trust”. Cela se résume par “Ne jamais faire confiance, toujours vérifier”. Elle souligne que l’accès à toute ressource informatique ne doit être accordé qu’après une vérification rigoureuse de l’identité et des permissions, quel que soit l’emplacement de l’utilisateur ou l’origine de la demande. Cela implique un rejet par défaut de toute tentative d’accès, à moins qu’elle n’ait été explicitement validée, même si la demande vient de l’intérieur du réseau de l’organisation. Cette approche vise à réduire au minimum les risques liés aux menaces internes et aux mouvements latéraux en cas d’attaques. Ce n’est pas la première fois que j’entends parler de cette approche et honnêtement, plus je m’immerge dans le monde de l’informatique, plus je suis en faveur de cette solution.

Concept DevSecOps qui me séduit pleinement, et j’espère avoir l’occasion de l’appliquer consciemment à un nouveau projet dès le semestre prochain. Les étapes auxquelles je pense actuellement sont les suivantes :

• Intégration de la sécurité dès le début : L'aspect le plus important de DevSecOps est d'intégrer la sécurité dès les premières étapes du cycle de développement. Cela signifie que les questions de sécurité doivent être prises en compte dès la phase de conception et d'architecture du projet.
• Automatisation des tests de sécurité : Utiliser des outils automatisés pour effectuer des tests de sécurité réguliers tout au long du cycle de développement. Cela peut comprendre des tests d'intrusion automatisés, une analyse statique du code pour détecter les vulnérabilités, et la vérification de la conformité aux normes de sécurité.
• Infrastructure as Code (IaC) : Utiliser des outils d'IaC tels que Terraform ou Ansible pour automatiser la configuration de l'infrastructure, ce qui permet d'appliquer les mêmes pratiques de contrôle de version et de révision de code que pour le code de l'application.
• Intégration et déploiement continus (CI/CD) : Intégrer la sécurité dans vos pipelines CI/CD pour que chaque version soit soumise à des contrôles de sécurité avant le déploiement. En appliquant ces principes, nous pourrons créer un environnement DevSecOps où la sécurité est une partie intégrante du processus de développement, plutôt qu'une considération secondaire.

ALM Ensuite, ce sujet a été présenté par mon collègue Flavio LI Flàvio: ALM. Malheureusement, cette présentation n’a pas apporté grand‐chose de nouveau. J’ai ressenti le besoin d’une approche plus large du sujet. Entre autres, j’aurais aimé comprendre la différence entre DevOps et ALM, ainsi que la responsabilité de la dernière phase du cycle de vie de l’application : le décommissionnement. D’après ce que j’ai compris, ALM est une approche qui couvre l’ensemble du cycle de vie de l’application, de la phase de conception jusqu’à son retrait, en passant par le développement, les tests, le déploiement et la maintenance. Il s’agit d’une approche complète qui vise à gérer et à contrôler toutes les phases du développement de logiciels. D’autre part, DevOps se concentre principalement sur la phase de développement et d’exploitation du cycle de vie de l’application, mettant l’accent sur l’intégration continue, le déploiement continu, l’automatisation et la collaboration entre les développeurs et les opérations. L’objectif de DevOps est de raccourcir le cycle de développement et de fournir des mises à jour de haute qualité plus rapidement. De plus, DevOps est à la fois une culture et une pratique technique. Il s’agit de briser les barrières entre les développeurs et les opérations pour encourager une collaboration plus étroite et une meilleure communication. D’autre part, ALM est plus orienté vers la gestion de projet et le contrôle. Il vise à mettre en place des processus et des outils pour gérer efficacement toutes les phases de la vie de l’application, y compris la gestion des exigences, la gestion des versions, la gestion des tests, etc.

Cela inclut également la gestion de la fin de vie de l’application, une étape à laquelle je n’ai pas eu l’occasion de réfléchir en profondeur auparavant. D’après ce que j’ai lu, ce sujet est divisé en plusieurs éléments :

• Planification : prévoir une stratégie de fin de vie pour l'application, ce qui inclut l'identification des critères pour décider quand une application doit être mise hors service.
• Communication : Informer toutes les parties prenantes (utilisateurs, équipes de support, partenaires commerciaux, etc.) de la fin de vie de l'application.
• Transition : Planifier une transition vers d'autres systèmes. Cela peut impliquer la migration des données, le remplacement de l'application par une autre application, ou la mise à niveau vers une nouvelle version de l'application.
• Archivage : Il est essentiel de définir comment les données et les informations de l'application seront archivées et accessibles à l'avenir. Cela comprend la conservation des données pour des raisons légales ou réglementaires.
• Support : Pendant la période de fin de vie, l'application peut nécessiter un support limité. Il est donc important de définir le niveau de support qui sera fourni.
• Suppression : La dernière étape consiste à démanteler l'application et à libérer les ressources associées. Il faut veiller à ce que cela soit fait de manière à ne pas perturber les autres systèmes ou à compromettre la sécurité des données.

Cette lecture m’ai fait comprendre que il reste encore des éléments à prendre en considération.

Cloud Ce semestre, le sujet a été présenté plusieurs fois : LI par Maxime sur MongoDB LI Maxime: Cloud Firestore/ Mongo DB, Hugo sur SQL LI Hugo: SQL/noSQL. J'ai eu l'occasion de l'expérimenter en pratique sous différents aspects :

1. Fonctions cloud de Firestore : Cloud Functions est un service proposé par Firebase, la plateforme de développement d'applications mobiles et web de Google. Les Cloud Fonctions permettent aux développeurs d'exécuter du code backend en réponse à des événements déclenchés par des composants Firebase et des services HTTPS dans un environnement sans serveur. Voici quelques points clés sur les Cloud Functions dans le contexte de Firebase :
   • Sans serveur : Les Cloud Functions suivent le paradigme "serverless", ce qui signifie que vous n'avez pas à gérer les serveurs pour exécuter votre code backend. Google gère automatiquement l'allocation des ressources.
   • Événementiel : Les Cloud Functions exécutent le code en réponse à des événements, tels que des changements dans Cloud Firestore, de nouveaux utilisateurs s'inscrivant à votre application via Firebase Auth, des événements d'analyse des utilisateurs, ou même des requêtes HTTPS directes.
   • Scalabilité automatique : Les Cloud Functions peuvent ajuster automatiquement leurs ressources pour faire face à l’augmentation ou à la diminution de la demande, ce qui les rend très flexibles et économiques.
   • Intégration avec Firebase et Google Cloud : Les Cloud Functions peuvent interagir avec d’autres services Firebase et Google Cloud, vous permettant de créer des flux de travail complexes. Par exemple, il est possible de créer une fonction qui est déclenchée à chaque fois qu’un utilisateur s’inscrit à votre application via Firebase Auth. Cette fonction pourrait ensuite écrire des informations sur ce nouvel utilisateur dans votre base de données Cloud Firestore. L’objectif est de permettre aux développeurs de se concentrer sur la création de leur application, tout en externalisant la logique de gestion du serveur à Firebase.

Faite sur la base : Cloud Functions

Moi je me suis intéressée à l'utilisation de Email Trigger , pour automatiser l’envoi des e-mails dans le projet Ceres. Finalement j’ai abandonné cette solution et j’en ai choisi une autre, crée directement dans l’application.

2. Comparaison entre la BI en local et de l'architecture en cloud : (LINK). L’un des éléments que j’ai réussi à accomplir dans le projet CIMO était la réalisation de la fusion de l’architecture BI sur site et en cloud. Il s’agit d’un vaste sujet pour lequel il n’existe pas de réponse claire. La solution doit être adaptée au cas spécifique. Il est certain que le cloud est une solution qui gagne en popularité et, compte tenu de l’évolution du monde, elle représente une solution d’avenir.

Une des diapositives de ma présentation

Intégration continue Ce sujet est apparu sous diverses formes : mon LI Introduction à DevOps, SF DevOps Rapport SF, LI Hugo: Pipeline. J’ai pratiquement eu l’occasion de le traiter dans le cadre du projet Ceres. Comme nous étions cinq personnes travaillant sur le projet, les commits et les merges réguliers étaient essentiels pour maintenir la version à jour. Le projet prévoyait l’automatisation de ces tâches à l’aide d’un pipeline Azure, mais malheureusement, nous n’avons pas atteint cette étape. Le pipeline a été préparé et un test de base a été réalisé. Pour ma part, j’ai préparé un test afin de vérifier la partie principale de ma fonction : getSupplierById().

Cloud computing Ce sujet a été initialement présenté par LI de Maxime Cloud computing. Ensuite, j’ai eu l’occasion de l’approfondir dans une version conceptuelle lors de la préparation du projet d’architecture BI. Un aperçu des architectures IaaS‐PaaS‐SaaS se trouve dans ma section :

Il me semble que c’est l’avenir de l’internet, mais il reste encore beaucoup de questions à résoudre (je le mentionne également dans mon rapport destiné à la CIMO) :

• Sécurité des données : Bien que les fournisseurs de cloud prennent généralement des mesures pour sécuriser leurs plateformes, la responsabilité de la sécurité des données est souvent partagée avec les utilisateurs. Les risques incluent les fuites de données, les cyberattaques, l'insuffisance des contrôles d'accès, etc.
• Confidentialité et conformité : Les données stockées dans le cloud peuvent être soumises à différentes lois de confidentialité et de protection des données, en fonction de leur emplacement géographique. Les entreprises doivent s'assurer que leurs pratiques de cloud computing sont conformes à ces lois.
• Gestion des coûts : Bien que le cloud computing puisse réduire les coûts initiaux d'infrastructure, les coûts peuvent augmenter avec le temps en fonction de l'utilisation. La gestion et le contrôle de ces coûts peuvent être difficiles.
• Disponibilité et temps de fonctionnement : Les pannes de service sont un risque dans le cloud computing. Même si de nombreux fournisseurs de cloud offrent des accords de niveau de service (SLA) avec une disponibilité élevée, aucune plateforme n'est à l'abri des pannes.
• Interopérabilité et portabilité : Si une entreprise utilise plusieurs services de cloud ou souhaite passer d'un fournisseur à un autre, elle peut rencontrer des problèmes d'interopérabilité et de portabilité des données.
• Dépendance vis-à-vis du fournisseur : Une fois qu'une entreprise a choisi un fournisseur de cloud et y a migré ses opérations, elle peut devenir dépendante de ce fournisseur. Si le fournisseur augmente ses prix ou change ses conditions de service, cela peut poser problème.
• Gestion de la bande passante : L'utilisation de services en nuage nécessite une connexion Internet. Pour les entreprises qui traitent de grandes quantités de données, la bande passante nécessaire peut être importante et coûteuse.

Industrialisation Ce sujet a été mis en lumière par une présentation très intéressante de Hugo sur les BPMS LI:BPMS. Un BPMS permet d’automatiser et de standardiser les processus métier. Un BPMS peut intégrer divers systèmes et applications, ce qui améliore l’efficacité et réduit les erreurs. Dans la pratique, nous avons réalisé une automatisation des processus chez CERES. Au lieu de traiter les commandes manuellement, le client pourra scanner les produits, préparer la commande dans l’application et envoyer directement les e-mails contenant les commandes à tous les fournisseurs.

Un exemple de l'application CERES