Découvrez nos impressions et notre résumé de la 3ème édition de cette conférence by OCTO Technology.
City George V
Nouvelle édition, nouveau lieu pour accueillir les conférenciers. Cette année, la conférence avait lieu City George V, non loin du mythique Crazy Horse et de la Tour Eiffel.
Un espace moderne (comme nous ont habitué les éditions précédentes) mais plus petit ; ce qui s’explique vraisemblablement par un nombre de participants moins nombreux (quelques 200 personnes) comparé aux années précédentes.
Pas de goodies cette année; la tendance actuelle des organisateurs de conférences est d’oeuvrer en faveur de l’écologie et pour une réduction de l’empreinte carbone (et c’est tout à leur honneur !). Chaque participant a donc financé l’association Faune Alfort qui soigne des animaux avant de les réintroduire dans la nature.
Comme les années précédentes, un thread unique nous est proposé. Voici un résumé des talks que nous avons préféré.
NO CODE : LA DÉMOCRATISATION DU DÉVELOPPEMENT
Le No Code, un terme qui peut paraître étrange quand on parle de développement d’applications. Pourtant ce terme revient de plus en plus fréquemment dans la presse spécialisée, et ce depuis quelques années déjà.
Mais au delà du buzzword qu’est ce que le No code / Low code ? Et surtout à quelles problématiques répondent ces plateformes de création d’applications d’un nouveau genre ?
C’est à ces questions que se sont proposés de répondre Alain Faure et Laurent Sollier lors de ce talk.
Le No Code est apparu suite a divers constats :
- nos projets sont de plus en plus complexes tant sur l’architecture de ces derniers que du côté des usines logicielles à mettre en oeuvre pour construire et déployer nos applications.
- il y a aujourd’hui une pénurie importante de développeurs (il manquerait d’ailleurs pas moins de 500 000 développeurs en Europe) alors que le besoin en terme de production logicielle est en constante augmentation et nécessite un certain savoir faire (qu’il s’agisse de la production de code source ou du déploiement des projets).
Mais alors comment produire des applications avec un minimum de code, voir même pas du tout, et un minimum d’actions pour les déployer ?
C’est là l’un des principes du No code / Low code, leur but étant de réduire autant que possible les coûts de développement en termes de temps mais aussi d’argent.
En somme permettre aux équipes de développement de répondre aux attentes métiers plus rapidement, en leur proposant une plateforme qui se soustraira à certaines complexités techniques et favorisera la réutilisation.
Après avoir rappelé les objectifs et enjeux du No code, nos speakers ont embrayé sur la présentation de quelques plateformes du marché, en donnant à chaque fois avantages / inconvénients et exemples d’applications :
- l’application mobile DuckConf a été réalisée avec Glide. et Google Sheet en 2 jours (1 jour pour appréhender la plateforme, et un jour de réalisation)
- le même développement a été tenté avec PowerApps, qui a nécessité 6 jours (3 + 3)
- la SNCF, quant à elle, s’est dotée de PowerApps (couplé à PowerBi et PowerAutomate) pour la création de leurs applications internes ; cette plateforme offre une approche par modélisation (case management) et s’intègre facilement au reste du SI.
Le talk s’est terminé avec les avantages et inconvénients de l’usage de ce type de plateforme. Les principaux bémols sont les coûts de licence, le vendor-locking, mais également le fait que la phase de conception est vitale pour que le projet soit construit correctement et que les composants produits puissent être réutilisés pour d’autres besoins (mais n’est-ce pas là le lot de la plupart de nos projets ?).
Les points forts sont quant à eux nombreux, avec en tête de liste :
- la démocratisation du développement (n’importe qui ou presque pourrait produire du logiciel sans avoir de compétences fortes en développement)
- la minimisation de l’effort de formation
- la portabilité des applications produites (crossplatform)
En conclusion, il est essentiel de bien choisir sa plateforme de No code avant de se lancer car toutes ont leurs forces et faiblesses. Bien qu’encore jeune et peut être pas suffisamment mature pour être utilisé sur n’importe quel projet, ce nouveau courant est prometteur et donc à surveiller de très près.
LES PAPYS DE L’ESB ONT UNE HISTOIRE À VOUS CONTER
En osant un parallèle avec la première trilogie de Star wars, les deux speakers nous racontent comment l’ESB s’est imposé dans les architectures dans les années 2000, apportant le meilleur comme le pire, pour finalement laisser sa place à de nouvelles solutions ou faire de la résistance.
Loin d’une charge, contre ce qui fait parfois office de dinosaure dans les systèmes d’informations, ce talk n’est pas non plus une déclaration d’amour, il se veut plutôt objectif et constructif. Il y a quand même quelques vannes bien placées qui nous rappellent que développeur ou architecte, on ne peut pas s’empêcher quelques trolls.
L’intégration des données de l’entreprise a été compulsée dans le livre de Gregor Hohpe et Bobby Woolf sous le nom des EIP : Enterprise Integration Patterns. Les ESB permettaient donc de reprendre ces patterns avec des implémentations plus ou moins efficaces au fil des années. Surtout ils permettaient une intégration sur 4 niveaux :
- Données
- Services
- IHM
- Processus
Les ESB promettaient aussi d’en finir avec le plat de spaghettis que représentaient les flux de données et de services dans une entreprise. Finalement, les ESB se sont avérés être surtout un magnifique couvercle au dessus de ce plat. Avec des antis patterns comme l’obligation de passer tous les flux par l’ESB et bien souvent par une équipe lui étant dédiée (et donc, généralement la cible de toutes les critiques en cas de problème).
Toutefois, il ne faut pas cracher dans la soupe (ou dans les spaghettis) : les ESB ont relevé de nombreux défis dans les entreprises et ont accompagné bon nombre de transformations digitales. Certaines aujourd’hui, dans beaucoup de domaines, continuent de les utiliser avec succès.
Pour les autres, elles sont passées à d’autres architectures basées sur des API manager ou des Middleware Of Messaging, en répétant à coup sûr un bon nombre d’écueils qu’on trouvait déjà à l’époque des ESB !
Finalement, la terminologie change avec le temps (ESB, API Manager, Data Streaming platform …) mais les besoins adressés sont identiques.
MON DSI VEUT UNE MEP/JOUR, COMMENT FAIRE DE L’ARCHI QUAND TOUT EST EN MOUVEMENT ?
Ce retour d’expérience de Fabien, déjà présent l’année dernière, met en avant la nouvelle posture adoptée par les architectes dans les (nouveaux ?) cycles de développement agile.
Pour mesurer l’impact des MEPs de composants d’un SI, notre speaker nous dévoile 4 domaines d’interventions :
Orchestrer le chaos des changements
Afin de pouvoir maitriser quelle version du code sera livrée à quel moment, il est nécessaire de versioner le SI entier : le code applicatif, l’infrastructure (as code), la configuration des modules et les scripts de déploiements.
Cette approche va permettre à terme de pouvoir intégrer en continu les modifications (artifacts) effectuées sur les composants du SI.
Amener les changements du SI
Pour obtenir une cartographie technique et précise du SI, il est nécessaire de lier les composants du SI les uns aux autres au travers d’un pipeline (comme pour les pipelines de déploiements que vous connaissez).
Ce pipeline va permettre, entre autre, de pouvoir maitriser la reconstruction des environnements du SI .
Designer des modes dégradés avec le métier
Dans un SI en mouvement, chaque composant doit, par design, prévoir des modes dégradés si les composants externes qu’il utilise changent de comportements (breaking changes / service down / mode dégradé …) suite à des mises à jour.
Les architectes doivent impliquer le métier dans des démarches d’event storming afin de parler un langage commun et surtout de proposer aux utilisateurs finaux l’expérience la moins irritante possible.
Amortir l’impact des conflits entre différents services
Une fois vos événements métier définis, et communiqués par les composants du SI en cas de problème; vous serez en mesure de limiter les coupures de service de votre système.
Fabien préconise l’approche Fail-safe Design afin de dégrader le service rendu à l’utilisateur sans le couper complètement.
Lors d’une commande sur internet, si le choix des relais colis est indisponible, faut il rendre impossible la commande de l’utilisateur ou lui proposer une livraison par défaut à son adresse ?
Pour conclure, voici les nouvelles missions d’un architecte dans un SI en mouvement :
- Adopter une posture de coach pour les équipes.
- Encourager les déploiements par l’industrialisation.
- Prioriser le fail-safe design pour favoriser l’autonomie des équipes (et composants).
L’API MANAGEMENT : AU-DELÀ DES PROMESSES
L’APIsation des systèmes d’information a fait pas mal de chemin ces dernières années. Cependant dès que ces projets prennent de l’ampleur, le nombre d’APIs peut rapidement devenir important.
Pire encore, les applications peuvent partager (ou non) des APIs communes, avec plus ou moins de restrictions. Et le tout avec un minimum de sécurité. Mais alors comment émerger de ce maelström ?
Comment publier, organiser, sécuriser et surveiller nos APIs ?
La réponse peut paraître simple : via une brique d’API Management; technologie que l’on rencontre fréquemment chez nos clients.
Au delà des promesses avancées par ce type de solution, qu’en est-il vraiment ? Est-ce suffisant ? Sont elles vraiment respectées ? Et ne vaut il pas mieux créer notre propre portail développeur quand le besoin de customisation se fait sentir ?
C’est dans ce contexte que prend place ce talk.
Après nous avoir présenté l’état de l’art et détaillé les objectifs fondamentaux de l’API Management, nos speakers se sont attardés sur une question que nous nous posons tous à un moment de notre carrière : vaut-il mieux développer sa propre solution ou privilégier une solution commerciale “clé en main” ? Est-ce pertinent de personnaliser une solution d’API Management ?
Pour répondre à ces question et aiguiller nos choix, quelques conseils ont été apportés :
- Si l’API devient un point d’entrée de notre CORE IT, si le portail doit être différenciant et s’il est perçu comme un atout concurrentiel alors mieux vaut le développer.
- Au contraire, si notre besoin est commun à toutes les entreprises alors investir dans une solution commerciale est à privilégier.
Et plus largement, on nous recommande de ne pas suivre les solutions les yeux fermés (si notre portail doit être différenciant, il faudra le développer), de ne pas négliger la gouvernance de nos APIs , d’utiliser une solution IAM externe si l’usage est de type B2C (Business to Consumer) et surtout que chacune de nos API doit assurer sa propre sécurité et rester agnostique des couches d’infrastructures sous-jacentes.
Pour plus de détails sur l’API Management en 2020, n’hésitez pas à consulter leur nouvelle refcard.
ELLE EST OÙ TON APPLI ? DANS MON KUBE !
Cette petite réplique détournée plante le décor de la présentation, L. BOISSERIE & B. BRABANT, nous ont rappelé ce qu’était K8s avant de nous expliquer en quoi cette technologie réinvente le métier d’ingénieur opérationnel. Mais au delà de la simple présentation de Kubernetes, nos speakers nous ont également proposé un REX sur la conteneurisation d’une application java, le tout en parcourant les 12 factors.
Le nouvel OPS doit pouvoir :
- Consulter les logs
- Monter de version son cluster
- Déployer des applications
- Accéder directement à une application
- Diagnostiquer un problème rapidement
- Modéliser et exposer des applications
- Gérer les capacités d’un cluster
- Gérer les accès
Ce sont autant de fonctionnalités qu’offre K8s.
Que faut-il choisir entre solution managée, on-premise ou hybride?
Sur ce point nos speakers sont persuadés que de nos jours les solutions managées sont plus fiables et offrent plus de garanties qu’il y a quelques années. Il ne faut donc pas hésiter à les choisir.
Opérer son propre cluster n’est pas une mince à faire, alors réfléchissez bien avant de vous lancer. Kubernetes reste un moyen, pas une fin en soi !
Multi-tenancy ou plusieurs clusters?
Multi-tenancy ou Multi-clusters ? A nous de voir. Nul doute que le budget et la sécurité sont des facteurs clés dans le choix à faire.
Conteneuriser son application
Concernant la conteneurisation de nos applications, quelques bonnes pratiques nous ont été rappelées, et notamment :
- Faire table rase du passé et garder les choses simples (KISS).
- Mettre tous les composants dans un seul cluster pour éviter d’en avoir partout. Attention toutefois aux applications qui viennent déjà avec des briques d’infra (Zuul, Config server, Eureka, etc.). K8s possède déjà des briques qui font déjà le travail.
- Externaliser les sessions, les configurations, les logs et les services.
- Exposer la santé de son application (healthcheck, metrics).
- Construire son application pour faire face gracieusement aux pannes régulières que constituent le commodity hardware des cloud providers.
Kubernetes était décidément la star de la conférence avec 3 talks spécialisés, en plus des clins d’oeil dans les autres sessions.
MIGRATION DE 6PLAY : L’AMOUR EST DANS LE CLOUD
C’est avec une mise en situation simple que Pascal Martin, Lead Devops chez M6, débute son talk : que pourrait-il se passer sur nos applications hébergées On-Premise lors d’un évènement exceptionnel, comme les soldes par exemple ? Imaginez “un pic de trafic sur votre application, un nombre de requêtes qui s’envole ! Les CPU qui chauffent ! Les serveurs qui s’écroulent…”.
Et c’est en partant de ce prédicat que notre speaker souhaite nous faire prendre conscience des limites du “on-premise” en entreprise : l’ajout de nouvelles ressources prend du temps (commande de matériel, installation, …) et peut être une source de perte d’argent (citons notamment la consommation électrique constante alors que les serveurs ne sont pas toujours sollicités).
Mais alors si le on-premise est si contraignant pourquoi ne pas passer au Cloud ? Et quoi de mieux qu’un retour d’expérience pour nous faire prendre conscience des bénéfices de cette solution ?
Pascal Martin nous a donc conté le récit de sa propre expérience lors de la migration de la plateforme de vidéo de M6 sur AWS (déployée dans plusieurs pays). Au delà de la présentation des services offerts par cette plateforme (S3, Lambda, EKS, …) et des outils utilisés (Jenkins, Terraform), le point qui a le plus retenu notre attention est sans doute de quelle façon chaque brique a été décommissionnée lors de la migration : comment les bases de données et fichiers ont été migrés, comment les applications et batchs ont été progressivement déportés sur AWS sans provoquer d’interruption de service, dans le meilleur des cas, rendant ainsi la migration complètement transparente pour les utilisateurs finaux.
Et pour se faire la stratégie était simple :
- positionner un HAProxy en amont de la brique hébergée en On-Premise
- dupliquer la brique sur le Cloud, et router une petite partie du trafic vers cette duplication. Le trafic routé vers l’application hébergée dans le cloud est ensuite augmenter petit a petit afin d’en contrôler le comportement. Une fois que l’intégralité du trafic est orienté vers le cloud, l’application On-Premise est décommissionnée en toute sécurité.
Du Blue Green Déploiement à la M6 😉
La présentation s’est terminée sur les améliorations qui pouvaient encore être apportées à cette migration, mais surtout sur les gains obtenus et notamment :
- réduction des coûts : on ne paie que pour ce qui est réellement consommé.
- disponibilité face aux montées en charge : la robustesse de la solution à été éprouvée via des tests de charge durant lesquels était envoyé 10 fois plus de trafic dans le cloud que ce qui arrivait initialement sur les serveurs On-Premise (via l’utilisation de GoReplay).
Mais comme l’a souligné le speaker, ce type de migration doit se faire si le besoin s’en fait vraiment sentir (ce qui était le cas dans son cas de figure) et ne se fait jamais sans douleur (plusieurs centaines de jours de travail, et bon nombre de personnes sollicitées).
Migrer vers Le Cloud n’est pas un projet technique ! Migrer vers Le Cloud est un projet d’entreprise, qui répond à un besoin business.
Pascal Martin
Terminons en précisant que nous trouverons toutes les réponses à nos questions sur ce type de chantier dans l’ouvrage de Pascal Martin intitulé “Le plan Copenhague” en cours de rédaction.
CONTINUOUS SECURITY : SECURE A DEVOPS WORLD
Les deux protagonistes nous rappellent que la sécurité est l’affaire de tous dans un projet numérique : du métier à l’exploitation en passant par les développeurs.
Pourtant, elle est souvent reléguée au second plan, jugée comme non prioritaire, ralentissant les développements…
Voyez plutôt les deux exemples cités et leur faille publique associée qui font froid dans le dos :
- un assuré médical qui peut consulter n’importe quel dossier une fois connecté en changeant l’identifiant du dossier dans l’url (l’article ici)
- une société financière qui n’a pas pris en compte une faille d’un de ses frameworks bien connus et qui a subi des fuites de données ! (le fait ici)
- ou encore Facebook qui laisse en accès libre un bucket S3 contenant les données de 540 millions d’utilisateurs (c’est part ici)
Ces brèches dans les applications restent rarement invisibles longtemps; vous n’avez qu’à vérifier les scans réguliers de vos machines à chaque annonce d’une vulnérabilité connue (même sans annonce d’ailleurs) et surtout si vous êtes dans le cloud public, vous êtes à la merci des bots qui scannent les serveurs du monde entier.
Alors comment faire pour éviter ce genre d’écueil ? Introduire une démarche DevSecOps dans vos projets dès la phase de cadrage. Elle peut se résumer par une prise de conscience de toute l’équipe projet, l’introduction de User stories spécifiques et d’une suite d’outils à introduire à chaque étape de votre projet :
Le security by design devient incontournable dans le développement applicatif
- A la conception, on partage avec les product owners sur les besoins en sécurité des features : “Je me connecte”, “un utilisateur peut accéder à son dossier et seulement à son dossier”… On ajoute au backlog les stories spécifiques (appelé User Security Story) car si ce n’est pas fait là, ça ne sera jamais fait !
- En phase de développement, les équipes doivent être sensibilisées aux bonnes pratiques OWASP grâce à des outils d’analyse de code spécialisés comme Checkmarx.
- Des tests doivent être implémentés pour valider que l’application est sécurisée (via Spring Security Test dans l’écosystème Java/Spring par exemple)
- En phase de build, on ajoute aux étapes d’intégration continue des outils (Software Composition Analysis) pour vérifier les vulnérabilités connues sur les composants utilisés (dépendances, images docker, etc).
- Au déploiement, on s’assure que l’infrastructure répond bien aux exigences (Dynamic Application Security Testing). L’infraAsCode et l’automatisation vous aideront grandement.
- Pour finir, le monitoring est crucial en phase de run. Les firewalls “physiques” et applicatifs ont un grand rôle à jouer, mais il faut aussi y ajouter une analyse des logs fine, des outils d’ASM comme Sqreen deviennent indispensables pour analyser les comportements et l’utilisation de vos applications. Des audits en continu sont nécessaires et peuvent se faire grâce à des outils comme AWS Guard Duty ou Cloud Custodian.
Au même titre que nous avons fait de la performance un enjeu, qui s’est accompagné par le déploiement d’APM, les ASM sont cruciaux.
Vous avez suivi ces règles à la lettre et vous êtes en production, tests d’intrusion d’un cabinet externe réalisés et monitoring au top, est ce que c’est terminé ?
Non, vous l’avez vu sur le visuel du DevSecOps, c’est un cycle, une boucle qui ne se termine pas. A chaque évolution, correction de bug, il pourra toujours y avoir un nouveau développement, une nouvelle librairie vulnérable et on pourra même découvrir des vulnérabilités sur une stack déployée depuis plusieurs mois !
Alors vous l’aurez compris, la sécurité doit être un pilier de votre architecture et non pas devenir un sujet de préoccupation et tomber dans la paranoïa. La sécurité est un sujet d’attention qui doit mobiliser toutes vos équipes, elles joueront d’autant plus le jeu si elles sont outillées correctement pour être proactives plutôt que réactives.
La sécurité, c’est l’affaire de tous.
un partisan du DevSecOps
Bilan de notre journée
Une édition intéressante, avec des talks variés, le tout dans un lieu propice au partage de connaissances.
Nous regretterons cependant le manque de retours d’expériences plus concrets, durant lesquels les patterns d’architecture mis en place sont un peu plus détaillés (point qui nous avait particulièrement séduit lors des années précédentes).
Comme nous l’évoquions au début de cet article, en dehors de la nouvelle refcard d’Octo sur les APIs, aucun goodies n’a été distribué cette année, les organisateurs ayant préféré financer l’association l’association Faune Alfort avec ce budget (initiative que nous saluons tout particulièrement).
En résumé, bien qu’un peu en deçà des précédentes éditions la DuckConf 2020 fut une bonne expérience, et plus particulièrement pour ceux d’entre nous qui participaient pour la première fois à l’événement.
Vous retrouverez l’ensemble des talks en vidéo sur la chaine Youtube de la Duck Conf 2020.
