Introduction

Dans cet article, nous allons découvrir les outils que nous met à disposition Microsoft sur Azure afin de mieux analyser et  valoriser la donnée.

Actuellement le problème pour les entreprises est l’analyse de la data et comment la monétiser, l’utiliser et la comprendre.

On constate depuis quelques années que le coût du stockage baisse, les baies de stockage ont de plus en plus de capacité de ce fait, on collecte de plus en plus de données sans toutefois bien l’utiliser.

analyser ces données  coûte cher, il faut des machines de plus en plus performantes pouvant faire face à la capacité de données à traiter, il faut donc prendre en compte le coût, l’évolution et le maintien du matériel existant permettant d’effectuer ces traitements.

Le cloud permet donc à moindre frais de pouvoir analyser nos données, mieux les comprendre et savoir si elles ont de la valeur et donc permettre de la monétiser.

Cela peut permettre à un décideur de prendre une décision concernant son entreprise au sujet d’un produit, s’il est intéressant ou rentable, ou encore à un site internet de savoir quel type de population vient le consulter.

Pourquoi la donnée est elle importante aujourd’hui

La plupart des entreprises ont encore du mal à obtenir des analyses pertinentes de leurs données et à exploiter pleinement le potentiel de l'intelligence artificielle. La migration vers le Cloud permet de  simplifier le Big Data et l’IA comme la solution Databricks désormais proposée par Microsoft en tant que service intégré Azure.

Databricks est la principale plateforme d’analyse basée sur Spark. Ce nouveau service fourni aux équipes de data science une plateforme rapide, simple et collaborative basée sur Spark dans Azure. Il offre aux utilisateurs une plateforme unique pour le traitement de données volumineuses et l’apprentissage automatique.

Azure Databricks est maintenant intégré nativement à Microsoft Azure de plusieurs façons, allant d’un simple clic à une facturation unifiée. Il exploite la sécurité d'Azure et s'intègre de manière transparente aux services Azure tels que Azure Active Directory, SQL Data Warehouse et Power BI. Tout cela a pour seul but de rendre l’analyse Big Data et l’IA beaucoup plus accessibles pour les utilisateurs.

Pourquoi de la data sur Azure

Mais avant tout, pourquoi Azure ? L’avantage des solutions d’analyse de la data dans le Cloud Azure est qu’elles sont complètes et particulièrement bien documentées. Il existe des outils disponibles sur le marketplace pour la réplication et l’ingestion des données en temps réel tel que Attunity par exemple :

• https://databricks.com/blog/2017/11/15/introducing-azure-databricks.html
• https://docs.microsoft.com/fr-fr/azure/architecture/reference-architectures/data/stream-processing-databricks
• https://www.qlik.com/us/products/data-integration-products

Les solutions proposées par Microsoft sont les suivantes :

Azure HDInsight est une distribution cloud des composants Hadoop de Hortonworks Data Platform (HDP). Azure HDInsight permet de traiter des quantités énormes de données facilement, rapidement et à moindre coût. Vous pouvez utiliser les frameworks open source les plus populaires tels que Hadoop, Spark, Hive, LLAP, Kafka, Storm, R.

Azure Databricks est une plateforme d'analyse basée sur Apache Spark, optimisée pour la plateforme de services cloud Microsoft Azure.

Azure Data Lake Analytics est un service managé d'analyse à la demande qui simplifie le Big Data. Au lieu de déployer, configurer et ajuster le matériel, vous écrivez des requêtes pour transformer vos données et extraire des informations précieuses.

Ci-dessous le processus d’ingestion et de traitement de la donnée avec Azure Databricks

Ci-dessous le processus d’ingestion et de traitement de la donnée avec Azure Data Lake Storage Gen2

Azure leader dans le traitement de la donnée dans le Cloud

Microsoft est le leader dans la gestion de la donnée comme nous le montre le magic quadrant, porté par  l’ensemble des solutions mise à disposition des data scientists dans le Cloud Azure.

Présentation de Azure Data Factory

Azure Data Factory est le service ETL disponible dans cloud d’Azure qui permet au travers d’une pipeline de mettre à disposition des données dans un blob storage ou vers Azure Data Lake

Voici le lien vers différents tutoriaux Microsoft permettant de créer un pipeline Azure Data Factory :

• https://docs.microsoft.com/fr-fr/azure/data-factory/tutorial-control-flow
• https://docs.microsoft.com/en-us/azure/data-factory/tutorial-copy-data-portal

Présentation de Azure Data Lake Analytics

Azure Data Lake est un service d'analyse et de stockage dans le Cloud évolutif et à la demande. Il peut être divisé en deux services connectés, Azure Data Lake Store (ADLS) et Azure Data Lake Analytics (ADLA).

Azure Data Lake Store est un système de fichiers qui permet le stockage de tous type de données de  n'importe quelle structure, et est donc parfait pour l'analyse et le traitement de données non structurées.

Azure Data Lake Analytics est une plateforme de travail distribuée en parallèle qui permet l'exécution de scripts U-SQL dans le cloud. La syntaxe est basée sur SQL et C #.

Les fichiers texte de différentes sources sont stockés dans Azure Data Lake Store et sont joints, manipulés et traités dans Azure Data Lake Analytics. Les résultats de l'opération sont transférés vers un autre emplacement dans Azure Data Lake Store.

Les tâches ADLA peuvent uniquement lire et écrire des informations depuis et vers Azure Data Lake Store. Il est possible de le compléter avec un service d'orchestration de données tel que Data Factory.

Voici le lien vers la présentation du produit chez Microsoft :

• https://azure.microsoft.com/en-ca/blog/introducing-azure-data-lake/

Analyse avec Data Lake Analytics

Data Lake Analytics offre des fonctionnalités similaires à Databricks. Vous pouvez écrire du code pour analyser les données et l’analyse peut être automatiquement parallélisée.

Microsoft a publié une nouvelle version de Data Lake, qu’il appelle Data Lake Storage Gen2 basée sur du storage Blob afin d’améliorer les performances des analyses effectuées avec Data Lakes Analytics . Les données stockées dans un Data Lake sont accessibles de la même manière que sur un volume HDFS et Microsoft  fournit un nouveau pilote pour accéder aux données d'un Data Lake pouvant être utilisé avec SQL Data Warehouse, HDinsight et Databricks.

Avec Data Lake Analytics, l'analyse des données est conçue pour être effectuée en U-SQL. Bien qu'il prenne en charge les bibliothèques R et Python, les utilisateurs de cette technologie devront se familiariser avec U-SQL, qui ressemble beaucoup à C #.

Présentation de Databricks

Azure Databricks est la dernière offre Azure pour les data scientistes. Les points forts de Databricks sont les suivants :

• Solution intégrée nativement à Azure
• Environnement collaboratif et interactif basé sur des notebooks

Databricks est optimisé par Apache Spark et offre un panel d'API pouvant être utilisée par les langages R, SQL, Python, Scala et Java. L'écosystème Spark permet également de faire du Streaming avec MLib et GraphX.

Les données peuvent être collectées à partir de diverses sources, telles que Blob Storage, ADLS et à partir de bases de données ODBC utilisant Sqoop.

Analyse avec Databricks

Pour analyser vos données avec Databricks vous pouvez utiliser trois langages différents R, Scala et Python.

Les données peuvent être lues à partir de différentes options Azure Storage, notamment Blob Storage, Data Lake et à l'aide d'une connexion JDBC. Vous pouvez également vous connecter à Azure SQL DB, ainsi que Azure SQL Data Warehouse.

Étant donné qu'il existe trois langages différents pouvant être utilisés, il n'y a aucune raison d'apprendre un nouveau langage, car la plupart des gens connaissent déjà très bien au moins l'un des trois langages pris en charge.

En plus de la possibilité de développer du code, Databricks offre d'autres fonctionnalités que l'on ne retrouve pas dans Data Lake Analytics. De nombreux projets prévoient que les gens travaillent en équipe et auront besoin d'un environnement pour partager le code et le mettre à jour. Cette fonctionnalité est intégrée à Azure Databricks, dans la mesure où elle fournit un environnement permettant de partager des données avec d'autres, et de sauvegarder les données nativement dans un référentiel GitHub. L’environnement de développement est Jupyter Notebooks, qui constitue un excellent moyen de documenter le code et d’inclure des échantillons de données. Databricks inclut également un composant de planification de travail afin que le travail créé dans Databricks puisse utiliser un planificateur natif permettant de relancer et d'envoyer des messages configurables en cas d'erreur ou d'achèvement. L’ensemble de ces fonctionnalités donnent à Databricks un avantage décisif dans la détermination de la technologie à utiliser.

HDInsight

Azure HDInsight est un service cloud qui permet le traitement de données à l'aide de frameworks open source tels que Hadoop, Spark, Hive, Storm et Kafka, entre autres.

À l'aide d'Apache Sqoop, nous pouvons importer et exporter des données vers et depuis une multitude de sources, mais le système de fichiers natif utilisé par HDInsight est Azure Data Lake Store ou Azure Blob Storage.

Parmi toutes les technologies ETL Azure basées sur le cloud, HDInsight est la solution la plus proche d’un IaaS, du fait de la gestion des clusters. La facturation est calculée à la minute, mais les activités peuvent être planifiées à la demande à l'aide de Data Factory, même si cela limite l'utilisation du stockage à Blob Storage.

Comparaison

Voici une comparaison complète des trois services:

Petite news du Microsoft Ignite :)

Microsoft nous a présenté lors du Microsoft Ignite : Azure Synapse Analytics

Azure Synapse Analytics est une évolution de SQL Data WareHouse, actuellement, c'est le seul système d'analyse à avoir exécuté TPC-H à l'échelle pétaoctet.

De ce fait Azure Synapse Analytics permets aux entreprise d'analyser plus rapidement leurs sources, entrepôts de données et système d'analyse de big data.

Avec Azure Synapse, les ingénieurs data peuvent interroger des données relationnelles et non relationnelles à l'échelle du pétaoctet à l'aide du langage SQL

Il est intégré à Power BI et Azure Machine Learning pour élargir la découverte des informations de vos données et appliquer des modèles d’apprentissage automatique à vos applications

Le studio Azure Synapse fournit un espace de travail unifié pour

• la préparation de données,
• la gestion de données,
• l'entreposage de données,
• les données volumineuses
• et les tâches d'intelligence artificielle.

Il permet aux équipes de travailler plus efficacement :

• Les ingénieurs de données peuvent utiliser un environnement visuel sans code pour gérer les pipelines de données.
• Les administrateurs de base de données peuvent automatiser l'optimisation des requêtes.
• Les scientifiques de données peuvent créer des POC en quelques minutes.
• Les analystes métier peuvent accéder en toute sécurité aux jeux de données et utiliser Power BI pour créer des tableaux de bord en quelques minutes, tout en utilisant le même service d'analyse.

Conclusion

Comme nous l'avons vu, le type de plateforme est à choisir suivant son besoin.

ADLA est particulièrement puissant lorsque nous ne souhaitons pas allouer autant de temps que nécessaire à l'administration d'un cluster. Cela permet également aux développeurs qui connaissent C # à exploiter tout le potentiel de U-SQL.

HDInsight a toujours été très fiable lorsque nous connaissons les charges de travail et la taille des clusters que nous devrons exécuter. Mais la mise à l'échelle est fastidieuse, car les machines doivent être supprimées et activées de manière itérative jusqu'à ce que nous trouvions le bon paramétrage. Utiliser Hive est un avantage, étant donné qu’il est open source et très similaire à SQL, il nous permet de passer directement au développement sans formation supplémentaire. En utilisant Hive, nous tirons pleinement parti de la puissance de MapReduce, qui brille dans les situations où les quantités de données sont énormes.

Databricks semble un choix idéal lorsque l'expérience interactive sur ordinateur portable est indispensable, lorsque les ingénieurs de données et les informaticiens doivent travailler ensemble pour obtenir des informations à partir de données et s'adapter en douceur à différentes situations, car l'évolutivité est extrêmement facile. Un autre avantage de l'utilisation de Databricks est sa vitesse, grâce à Spark.

Data Lake Analytics est plus efficace lors des opérations de transformation et de chargement grâce au traitement à l'exécution et aux opérations distribuées.

L’usine logicielle pour le développement d’applications comprend de nombreuses pièces répondant chacune à des besoins différents : Stockage du code source, construction du code, tests, analyse qualité, intégration continue, stockage des livrables, déploiements automatisés, système d’alertes. L’élément central qui s’interface avec tous les autres éléments est l’intégration continue. Des nombreuses solutions d’intégration continue existent. Une des plus utilisées est Jenkins.

Jenkins

La mise en place d’un serveur Jenkins est relativement simple : installation du serveur, téléchargement des premiers plugins, configuration basique du serveur (notamment la gestion des droits d’accès) et des extensions. Ensuite, les équipes commencent à créer des processus de construction, des « jobs » selon la dénomination de Jenkins.

Au début, pour commencer rapidement, les équipes utilisent l’interface d’administration et créent des jobs ‘free-style’ et y ajoutent des étapes de construction en fonction des extensions disponibles. Mais au fur et à mesure des déclarations de jobs, la configuration de l’outil devient rapidement un enchaînement fastidieux et répétitif de clics. En outre, l’ajout d’un peu de logique entre les différentes étapes de construction se révèle compliqué.

La version 2 de Jenkins apporte une nouvelle capacité pour réduire les actions répétitives lors de la configuration de l’outil. Il est désormais possible avec l’aide de l’extension Pipeline, de transformer une partie de la configuration en code.

Jenkins Pipelines

Un job ‘Pipeline’ permet la décomposition d’une construction Jenkins en plusieurs étapes et utilise le langage Groovy pour décrire les actions à exécuter et la logique à prendre en compte. Les différentes étapes sont définies dans un fichier dont le nom par défaut est ‘Jenkinsfile’. Il existe 2 syntaxes de Pipelines : Declarative Pipeline et Scripted Pipeline. Declarative Pipeline est une syntaxe récente plus simplifiée et plus explicite que la syntaxe Scripted Pipeline fournie par défaut. Son utilisation est recommandée pour débuter avec les Pipelines et dans des cas d’utilisation simples. Contrairement à Declarative Pipeline, Scripted Pipeline est une syntaxe pour un usage plus étendu et moins contraint. La plupart des fonctionnalités fournies par le langage Groovy sont mises à la disposition des utilisateurs de Scripted Pipeline.

Cependant, un point de blocage apparaît rapidement dès l’ajout de script Groovy complexe dans le fichier ‘Jenkinsfile’. Car pour protéger Jenkins de l'exécution de scripts malveillants, le code Groovy est exécuté dans un bac à sable Groovy, qui limite l’accès aux API internes, notamment sur l'instanciation de classes et l’appel de méthodes statiques.

L’utilisation d’une API non autorisée se conclut par l’échec de l’exécution du Pipeline Jenkins. Les administrateurs doivent ensuite utiliser la page "In-process Script Approval" (https://jenkins.io/doc/book/managing/script-approval/), fournie par l’extension ‘Script Security’, pour déterminer, le cas échéant, quelles méthodes non-sécurisées doivent être autorisées dans l'environnement Jenkins. Ces actions manuelles et répétitives font pratiquement perdre tout l’intérêt de la syntaxe Scripted Pipeline.

Ⓒjenkins.io/doc/book/managing/script-approval/

Shared Libraries

Néanmoins, un contournement est possible. L’extension ‘Pipeline: Shared Groovy Libraries’ permet de définir une bibliothèque partagée dans un projet git distinct. Le code contenu dans la bibliothèque partagée n’est pas soumis à l’approbation de script. Attention, il faut garder à l’esprit qu’une personne avec les droits de publication sur le dépôt git contenant la bibliothèque partagée, a ainsi un accès illimité au serveur Jenkins.

Ⓒjenkins.io/doc/book/pipeline/shared-libraries/

La bibliothèque partagée est déclarée dans la configuration générale de Jenkins (Administrer Jenkins > Configurer le système), dans la section ‘Global Pipeline Libraries’.

En cliquant sur le bouton ‘Ajouter’, une nouvelle déclaration de bibliothèque est disponible. Il suffit alors de renseigner un nom (qui sera utilisé pour identifier la bibliothèque), de donner une version par défaut à charger si un Pipeline n'en sélectionne aucune autre. Cela peut-être un nom de branche, une balise, un hachage de validation, etc., en fonction le type de gestion de code source utilisé.

Dans les sous-sections ‘Retrieval method’,  ‘Source Code Management’, il faut renseigner le type de gestion de code source utilisé, l’adresse du référentiel de code source et les informations de connexion (nom d’utilisateur / mot de passe) à ce référentiel.

Une bonne pratique est de décocher ‘Load implicitly’ et de déclarer explicitement l’import de la bibliothèque dans le fichier Jenkinsfile à l’aide de l’annotation @Library. Cela est utile dans les cas où plusieurs bibliothèques sont déclarées sur un serveur Jenkins et certains jobs ‘Pipelines’ n’en utilisent qu’une seule ou bien aucune.

Ⓒjenkins.io/doc/book/pipeline/shared-libraries/

Une documentation sur les bibliothèques partagées est disponible sur le site de Jenkins : https://jenkins.io/doc/book/pipeline/shared-libraries/

Quelques retours d'expérience

Lors d’une première utilisation et la maintenance des bibliothèques partagées, quelques règles ont été précieuses pour éviter certains désagréments.

1- Il faut toujours vérifier la compilation du code de la bibliothèque partagée (avec des outils comme Maven ou Gradle) avant de publier sur le référentiel de code source. Sinon à la moindre erreur, tous les jobs ‘Pipelines’ utilisant la bibliothèque sont en erreur au lancement d'une construction.

2- Pour tester les scripts contenus dans la bibliothèque avant à la mise à disposition générale, l’utilisation d’une ou plusieurs branches de développement sur le référentiel de code source ainsi que l’utilisation de plusieurs jobs Pipeline de test référençant ces branches de développement est souhaitable.

3- Centraliser les fichiers ‘Jenkinsfile’ dans un référentiel de code source indépendamment du code source des projets est pratique lorsque ces référentiels ‘projet’ contiennent des dizaines de branches et qu’une modification dans un fichier ‘Jenkinsfile’ doit être répercutée sur toutes les branches.

Dans cet article, nous présentons le Schema Registry de Confluent, un composant clé dans une plateforme data. Nous présentons son rôle et ses nombreux avantages. L’article donne des recommandations accompagnées d’exemples permettant d’explorer les vertus de ce composant ainsi que de maîtriser ses fonctionnalités.

Context

Le composant Confluent Schema Registry est un composant open source initialement développé par Confluent. Le Schema Registry permet la gestion centralisée de l’ensemble des schémas d’une plateforme de données et donc une meilleure gouvernance des données. Ces schémas sont utilisés dans les processus de sérialisation et désérialisation des messages par les clients de la plateforme.

Le Schema Registry représente un référentiel partagé de schémas qui permet aux applications d'interagir de manière flexible les unes avec les autres. Il permet :

• d’enregistrer des schémas,
• de les consulter,
• de les faire évoluer en gardant l’historique,
• le versioning des schémas,
• la vérification de compatibilité entre les différentes versions.
  

Dans plusieurs contextes d’intégration des données, de collecte des open data, ou encore l’ingestion des données en flux provenant de l’internet des objets, les données sont en perpétuelle évolution et leur stockage (e.g. BigQuery, Hadoop) nécessite une définition de schémas bien documentée, validée et gérée. Avoir des schémas bien définis aidera à mieux intégrer des données et services dans des architectures microservices ainsi qu’une meilleure exploration et exploitation des données à des fins d’analytics (e.g. Machine Learning) ou de conformité (e.g. RGPD). Grâce à la validation des schémas, la qualité des données est sensiblement améliorée.

Fig. 1 : Source

Rôle d’un Schema Registry

Les schémas permettent de garder une cohérence de la structure des messages échangés. En effet, il ne faut pas se focaliser sur le premier cas d’usage. L’utilisation des données augmentera avec le temps et d’autres équipes peuvent venir à la chasse de ces données pour de nouveaux cas d’utilisation. Les besoins fonctionnels et techniques peuvent vous amener à changer la structure de vos messages, ce qui impactera gravement les consommateurs si on n’a pas de schéma de données.

Prenons l’exemple de l’une des plateformes de nos clients, où toute publication de message devrait être contextualisée via un ensemble d’attributs : localisation, timestamp, et bien d’autres. Dans cette situation un objet métier contexte a été requis pour la publication de tous les messages dans la plateforme. Devant cette contrainte, la formalisation d’une structure de message est primordiale. Cette structure nous a permis le contrôle de conformité des messages. Par conséquent, la mise en place d’un Schema Registry permet une meilleure gouvernance des données dans nos pipeline Data. Il introduit aussi une dimension d’efficacité opérationnelle en fournissant des schémas réutilisables, en définissant les relations entre les schémas et en permettant aux fournisseurs de données et aux consommateurs d'évoluer à des rythmes différents.

Fig. 2 : Sérialisation de messages et Schema Registry

On peut se poser la question du rôle d’un Schema Registry dans une organisation. La première motivation est de ne pas voir les données mal formatées prendre leur chemin vers les moyens de stockage ou vers nos topics (Fig.2). Nous avons eu l’expérience avec la mise en œuvre d’une plateforme de distribution et de communication entre des points de productions et de consommations géo-répartis sur trois régions, à savoir, Europe, US et APAC. Avoir des schémas par région n’est sûrement pas la solution la plus optimale, sachant que les données peuvent être consommées et analysées à un niveau fédéré. Le découplage entre les consommateurs et les producteurs représente aussi une motivation pour mettre un Schema Registry central. Ce dernier permettra la gouvernance de l’ensemble des schémas utilisés au niveau global et assurera la compatibilité et la vérification des évolutions des schémas. Le Schema Registry a aussi le rôle de limiter les accès en écriture via des politiques de contrôle d’accès basées sur ACL ou RBAC. Le Schema Registry s’intègre parfaitement avec les autres composants Confluent comme Kafka Connect, et bien d’autres outils comme Apache NIFI ou StreamSet. Il est recommandé d’utiliser le système AVRO pour le stockage des schémas.

Apache AVRO

Lien : http://avro.apache.org/

Apache Avro est un système de sérialisation de données. Il fournit des structures de données riches, un format de données binaires et un format de fichier conteneur pour stocker les données persistantes. Avro permet de stocker les données et leurs schémas au même endroit. Par conséquent, Avro ne nécessite pas de génération de code et s'intègre facilement avec des langages dynamiques comme JavaScript, Python, Ruby, C, C#, C++, Java, Scala. Avro est très utilisé dans l'écosystème Hadoop et représente la première recommandation pour Kafka par Confluent.

Apache Avro se compare souvent à Thrift, Protocol Buffers, JSON, etc. Il a besoin d’encoder moins d’informations car il stocke les noms et les types dans le schéma, ce qui réduit la duplication et la taille de sérialisation. Un autre avantage clé d'Avro est son support des schémas évolutifs qui assure les contrôles de compatibilité et permet de faire évoluer vos données dans le temps. Avro est largement supporté par plusieurs plateformes Big Data comme Hadoop, Hortonworks ou d’ingestion et traitement de données comme Apache Nifi, StreamSet, BigQuery, etc. Dans le contexte de Kafka, Avro est utilisé pour la sérialisation des clés et valeurs des messages publiés et consommés des topics.

Avro utilise JSON pour la définition des schémas, et sérialise les données dans un format binaire. La définition des schémas est composée de types primitifs (null, boolean, int, long, float, double, bytes,  string) ou complexes (record, enum, array, map, union, fixed).

Dans la Fig. 3, une exemple du schéma pour les données consommateurs.

Fig. 3 : Exemple d’un schéma en AVRO

Schema Registry & Kafka

Un message dans Kafka se compose principalement d’une clé, d’une valeur et optionnellement d’un header. Avro est utilisé pour la sérialisation des clés et valeurs des messages envoyés dans les topics Kafka. Par ailleurs, dans le Schema Registry, les schémas sont définis et évoluent dans le cadre d’un espace de nom défini par un Subject. Le nom du subject dépend de la stratégie configurée par subject, qui par défaut sera dérivée du nom du topic. Rappelons que le nom du topic peut être complètement indépendant du nom du schéma.

La stratégie de nommage des Subjects est configurable et peut être de deux types. Le premier, permet aux messages du même topic de se conformer au même schéma, et c’est la stratégie par défaut. Le second type n’impose pas cette contrainte et autorise qu’un même topic puisse supporter plusieurs schémas.

Les clients peuvent donc définir la stratégie de nommage du Subject pour la clé ou la valeur, en utilisant les paramètres de configuration suivants :

key.subject.name.strategy
value.subject.name.strategy

La stratégie par défaut est TopicNameStrategy, configurable par position de cette clé  (io.confluent.kafka.serializers.subject.TopicNameStrategy).

value.subject.name.strategy=io.confluent.kafka.serializers.subject.TopicNameStrategy

Cette stratégie nomme le schéma en fonction du nom du topic et exige implicitement que tous les messages du même topic soient conformes au même schéma. Une comparaison de ces différentes stratégies est disponible sur le site  de documentation.

Il faut sans doute préciser certaines limitations dans l’utilisation de ces conventions. Elles sont configurables toutes les trois seulement avec les clients Java. Les autres clients utilisent seulement la stratégie par défaut, à savoir TopicNameStrategy. KSQL utilise exclusivement la stratégie par défaut, et ne supporte pas plusieurs schémas dans un même topic. Pour plus de détails sur d’autres limitations, veuillez vous rendre sur la documentation.  

La Fig. 4 présente le composant Schema Registry et les interactions avec les autres composants d’une plateforme Kafka.

Fig. 4 : Schema Registry, Kafka Cluster, Producer & Consumer

Prenons l’exemple suivant pour l’envoi des données en flux sur un topic consumers. Le producteur de messages produit des données avec le schéma Consumer présenté ci-dessus au topic consumers. Si le producteur sérialise la valeur du message en Avro, le Schema Registry  aura un sujet appelé consumers-value, dans ce sujet on trouvera au moins le schéma Consumer avec un identifiant unique global ID attribué par le Schema Registry. Si le producer sérialise la clé, un autre subject sera dans la Schema Registry nommé consumers-key. Dans ce périmètre, les schémas seront validés suite aux différents changements, mises à jour, évolutions, etc.

Il est recommandé que les instances du Schema Registry soient séparées des Brokers Kafka. Nous décrivons dans la suite le fonctionnement du Schema Registry avec les producteurs et consommateurs Kafka. Lors de l'envoi d'un message par le producteur, le sérialiseur s'assurera que le schéma est enregistré, obtiendra son ID ou enregistrera de manière automatique une nouvelle version du schéma pour vous. Ceci est même recommandé de le désactiver via la propriété auto.register.schemas à false.

Enfin, le Schema Registry est une application Java. Il a été validé sur certaines des versions les plus récentes de Java, dont Java 11, mais pas sur toutes les versions comme Java 9 ou 10.

Du côté Producteur, enregistrement d’un schéma

• Le producteur envoie le schéma Consumer au Schema Registry.
• Le Schema Registry enregistre le schéma dans le périmètre. L'attribution d'ID de schéma se produit toujours dans le nœud primaire et les ID de schéma augmentent toujours de façon monotone.
• Le producer reçoit l’ID du Schema Registry pour le mettre localement dans un cache pour de futures utilisations, et donc, le Schema Registry n’est interrogé qu’une seule fois.

Fig. 5 : Interaction Schema Registry et producteurs  

Les propriétés suivantes sont à rajouter du côté du producteur :

props.put(“key.serializer”,”io.confluent.kafka.serializers.KafkaAvroSerializer”)
props.put(“value.serializer”,”io.confluent.kafka.serializers.KafkaAvroSerializer”)

Du côté consommateur, lecture d'un schéma

• Le consommateur lit les données et l’ID de leur schéma.
• Il envoie une demande du schéma identifié par ID au Schema Registry.
• Le Schema Registry récupère le schéma correspondant à l’identifiant ID et renvoie le schéma au consommateur.
• Le consommateur reçoit le schéma du Schema Registry pour le mettre localement dans un cache pour de futures utilisations, et donc, le schéma registry n’est interrogé qu’une seule fois.

Fig. 6 : Interaction Schema Registry et consommateurs  

Gouvernance des données

La gouvernance des données correspond aux processus et à l’organisation mis en place permettant d’encadrer la collecte de données et leur utilisation. L’un des processus de gouvernance consiste en la vérification de l’exactitude des données en entrée de votre plateforme de données pour ensuite appliquer des politiques centralisées au sein de votre organisation. Le Schema Registry est un composant indispensable pour arriver à une gouvernance centralisée des structures de vos données. Le contrôle d’accès à ces schémas fait aussi partie des processus à mettre en place. Pour cela, le Schema Registry met à disposition les ACLs et RBAC pour la restriction des accès uniquement aux personnes autorisées. Pour une meilleur gouvernance, pensez aussi à désactiver l’enregistrement automatique des schémas. Les évolutions et la définition des relations entre schémas sont effectuées de manière centralisée et incrémentale avec le test de compatibilité et l’historisation des modifications. Les options de compatibilité configurées par subject sont les suivantes :

On peut se demander comment on peut faire évoluer son schéma et garantir la politique d'évolution sous-jacente. Merci à Confluent de nous avoir récapitulé dans le tableau ci-dessous les opérations possibles :

Pour une meilleure gouvernance, il est fortement recommandé qu’une équipe indépendante s’occupe de la gestion du cycle de vie des schémas en terme d’enregistrement, de mise à jour, d’évolution et de suppression. Une autre recommandation est de mettre en place la vérification des compatibilités entre les différentes versions via des processus d'intégration continue et de déploiement continu.

Récemment, sur la version Confluent 5.4-preview, l'éditeur a annoncé que la validation des messages par rapport à ces schémas sera prévue au niveau des Brokers Kafka. Une erreur sera renvoyée par le broker Kafka si le message ne respecte pas le schéma fourni pour la clé et pour la valeur à une limitation près, l'erreur renvoyée par Confluent Server lorsque la validation de schéma est activée est trop générale.

Définition du schéma avec Avro

Afin d’avoir rapidement un premier environnement de développement en local, nous avons utilisé la version de Confluent conteneurisée. Les images sont disponibles sur DockerHub pour chacun des composants de la plateforme Confluent. Une version all-in-one packagée et déployable via docker-compose. Un environnement de développement est rapidement provisionné via le script suivant :

git clone https://github.com/confluentinc/examples
cd examples
git checkout 5.3.1-post
cd cp-all-in-one/
docker-compose up -d --build

La liste des composants installés sont les suivants via la commande :

docker-compose ps 

Ensuite, nous aurons l’interface graphique du Control Center est accessible sur http://localhost:9021/.

Le Control Center, qui fait partie de l’offre entreprise de confluent, est un outil graphique de supervision des clusters. Il permet aussi de créer et configurer des topics et des schémas. Une autre manière de créer vos schémas est d’utiliser l’API REST exposée par le Schema Registry.

Nous avons défini un schéma via le Schema Registry UI pour l’entité consommateurs qui comporte un peu plus d’une trentaine de champs, et des champs imbriqués. Dans la suite, pour des raisons de simplicité, nous ne présentons qu’une sous partie de notre modélisation.

{
     "type": "record",
    "name": "Consumer",
    "namespace": "fr.ippon.schemaregistry.avro",
    "fields": [
        { "name": "consumer_id" , "type": "string"},
        { "name": "last_name"   ,"type": "string"},
        { "name": "first_name", "type": "string" },
        { "name": "city", "type": "string"},
        {"name": "civility",
            "type": {
                "type": "enum",
                "name": "Civility",
                "symbols": ["MISS", "MR", "MS"]}
        },
        {"name": "country","type": "string" },
        {"name": "phoneNumber", "type": [ "string","null" ]},
        {"name": "email", "type": [ "string","null" ]}
    ]
}

Subject : value-consumers

Pour plus d’information sur la modélisation des schémas, veuillez vous rendre sur ce site.

Enregistrement d’un schéma via REST APIs

curl -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" --data \
'{"schema":"{\"type\":\"record\",\"name\":\"Consumer\",\"namespace\":\"org.ippon.schemaregistry.avro\",\"fields\":[{\"name\":\"consumer_id\",\"type\":\"string\"},{\"name\":\"last_name\",\"type\":\"string\"},{\"name\":\"first_name\",\"type\":\"string\"},{\"name\":\"city\",\"type\":\"string\"},{\"name\":\"civility\",\"type\":{\"type\":\"enum\",\"name\":\"Civility\",\"symbols\":[\"MISS\",\"MR\",\"MS\"]}},{\"name\":\"country\",\"type\":\"string\"},{\"name\":\"phoneNumber\",\"type\":[\"string\",\"null\"]}]}"}' \
http://localhost:8081/subjects/[TOPIC.NAME]-value/versions 

Resultat : 
{"id":1}

Enregistrement du schéma pour la valeur du schéma

Voici le résultat dans le Control Center, avec un TOPIC.NAME = test.ippon.topic

Vous pouvez donc produire l'événement suivant via vos clients Java, Scala ou via les scripts du Kafka.  

{
    "customer_id":"abc-1234",
    "civility":"MISS",
    "last_name":"Z",
    "first_name":"X",
    "city":"Paris",
    "country":"FR",
    "email":"******@ippon.tech",
    "phone_number":"+336xxxxxxxx"
}

Production des enregistrements

Maintenant que nous avons un environnement de développement, nous présentons le processus d’enregistrement d’un schéma et le code permettant de publier des messages conformes à ce schéma.

Pour la publication de nouveaux événements conformes à un schéma, deux possibilités :

• La première consiste à générer le code d’une classe Builder de l'événement et construire l’objet par la suite. La génération est automatique via Maven. Cette approche nécessite une compilation à chaque modification du schéma.
• La seconde consiste à utiliser un objet générique "GenericRecord" pour construire les messages à envoyer.

La partie d’envoi de messages est présentée ci-dessous, l’ensemble du projet est accessible sur github.  

Consommation des enregistrements

Pour la partie consommation, rien n’est plus facile. Voici le code correspondant à la boucle de consommation de messages avec un envoi automatique des offsets.

L’ensemble du code du consommateur est en libre service sur github.

Conclusion

Le Schema Registry est une brique essentielle dans nos architectures de données. Il représente une réponse optimale aux questions de gouvernance, d’évolution, d’organisation et de flexibilité. Les autres  avantages de la mise en place d’un Schema Registry sont sa scalabilité et sa haute disponibilité pour répondre à des variations de charge.

Dans ce billet nous ne nous sommes pas attardés sur l’évolution des schémas et la compatibilité ascendante. Ce point sera détaillé dans un futur article. Dans cette vidéo je présente rapidement comment nous pouvons faire évoluer notre schéma avec un attribut "age".  

Références

• Blog post: Schemas, Contracts, and Compatibility
• Blog post: 17 Ways to Mess Up Self-Managed Schema Registry
• Blog post: Yes, Virginia, You Really Do Need a Schema Registry
• Blog post: How I Learned to Stop Worrying and Love the Schema
• https://mapr.com/docs/61/Kafka/KafkaSchemaRegistry/KafkaSchemaRegistry.html
• Evolution de schémas  https://www.youtube.com/watch?v=4ngG34TteoU&feature=youtu.be
• Code source  : https://github.com/mhilia/schema-registry-poc

Dans cette suite de 3 articles, je vous présente Vault d’Hashicorp afin de vous donner une vision sur les possibilités qu’offre cet outil pour vos différents projets. La phase d’installation est volontairement omise (le lien vers l’installation de Vault : ici). Cette suite d’article s'appuie sur mon expérience liée à l'utilisation de Vault dans le SI d’Ippon Technologies pour la gestion des secrets dans Ansible et Puppet.

Ce deuxième article rentre plus dans les détails sur les différents modules de Vault avec un exemple d’utilisation de Vault avec le module SSH.

Les Modules

Vault est composé de modules. Ces modules permettent de gérer des types de secrets (SSH, PKI, Clé/valeur), des types de stockage (Filesytem, Consul), des systèmes d’identification tiers (LDAP, Kubernetes) et des journaux (syslog, file). Ils peuvent être classés en 4 familles :

• Gestion des secrets
• Stockage
• Gestion de l'authentification au serveur Vault
• Audit

La gestion des secrets

Concernant la gestion des secrets, Vault propose une quinzaine de modules. Chaque module gère un type de secret. Par exemple, nous avons le module KV pour les clés/valeurs, ou encore le module AWS pour les access key d’IAM (service de gestion d’identité d’AWS). Voici un screenshot des modules disponibles via l’interface WEB.

A chaque module activé correspond une branche sur l’arbre des données de Vault. Le nom de la branche est choisi par l’utilisateur et plusieurs branches peuvent utiliser le même moteur de secret comme montré dans la copie d’écran suivante :

Selon les modules utilisés, les secrets peuvent être associés à un Time to live (TTL). Ce TTL correspond à une durée de vie du secret. A l’expiration de ce compteur, Vault peut être amené à exécuter des actions selon le type du secret. Par exemple, avec le module MySQL, Vault génère des comptes d’accès aux bases de données et les supprime à la fin de leur TTL.

Chaque branche agit comme un chroot etpeut être composée de section, de sous-section au nombre souhaité. Voici pour le chemin kv/client2 :

Cette notion de branche est importante dans la gestion des accès de Vault. Les autorisations d’accès pointent vers une branche ou un élément d’une branche. Dans l’exemple suivant seul le secret “client2/ansible” est concerné.

# pour le moteur KV v2
path "kv/data/client2/ansible {  # ’data’ est spécificité de la version 2 du moteur KV
capabilities = ["create"]
}

# en v1
path "secret/client2/ansible" {
capabilities = ["create"]
}

L’exemple suivant impacte toute une branche.

path "kv/data/client2/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}

#On peut ensuite interdire l’accès d’un secret particulier
path "kv/data/client2/ansible" {
capabilities = ["deny"]
}

#Ou encore
path "kv/data/+/puppet" {
capabilities = ["deny"]
}

# Note sur l’exemple:
# Le caractère ‘*’ ne correspond pas un à une regular expression. Il est supporté uniquement en dernier caractère d’un chemin
# Le caractère ‘+’ correspond à un “n’importe quel caractère”

Les autorisations sont définies dans des policies. En l’absence d’autorisation, c’est le droit DENIED qui est appliqué. Au niveau des règles de sécurité, on peut interdire, autoriser ou rendre obligatoire des paramètres sur les commandes de Vault, exemple :

# Ici on autorise la création de secret dans secret/test avec comme paramètre ‘data’ uniquement. Ce paramètre ne peut contenir que les valeurs ‘ippon’ ou ‘autres’
# Attention ici j’utilise le moteur kv v1, à la date de mes tests allowed_parameters et required_parameters ne fonctionnent pas avec le moteur kv V2 
# Issue: https://github.com/hashicorp/vault/issues/4368

path "secret/test" {
	capabilities = ["create"]
	allowed_parameters = {
		"data" = ["ippon", "autres"]
	}
}

# La commande suivante est autorisée
vault kv put secret/test data="ippon" 

# Mais pas les commandes suivantes
vault kv put secret/test data="un test"                          => permission denied
vault kv put secret/test data="ippon" autre_val=”test”  => permission denied

Les chemins des policies correspondent aux chemins utilisés par les appels API. Celles-ci acceptent des variables prédéfinies dans leurs paths. Pour plus de détails, je vous renvoie vers la documentation officielle sur les policies (ici).

Un autre point sur les policies. Celles-ci ne concernent pas uniquement les accès des secrets. Elles peuvent être appliquées aussi sur des commandes de Vault.

# Ici on autorise la commande list sur les méthodes d’identification
path "sys/auth" {
	capabilities = [ "read" ]
}

[root@vault ~]# vault auth list
Path     	Type    	Accessor              	Description
----     	----    	--------              	-----------
ansible/ 	approle 	auth_approle_324f53ab 	n/a
approle/ 	approle 	auth_approle_6654519d 	n/a
token/   	token   	            auth_token_0df76f2f   	token based credentials
userpass/	userpass	auth_userpass_406b4ac6	n/a

#Ici on autorise la création et la gestion des tokens
path "auth/token/*" {
	capabilities = [ "create", "read", "update", "delete", "list", "sudo" ]
}

Stockage

Vault propose un peu moins de 20 supports de stockage concernant les données. Il existe par exemple des modules de stockage pour S3, etcd et DynamoDB. Quel que soit le module utilisé, les données de Vault sont systématiquement stockées chiffrées.

Tous les modules de stockage proposés ne sont pas supportés directement par Hashicorp. Hashicorp supporte uniquement les modules consul, filsesystem, in-memory (non recommandé pour la production). De plus, la haute disponibilité n’est pas supportée par tous les modules de stockage.

Le choix dépend principalement de votre usage et de vos objectifs. Personnellement, je ne peux que vous conseiller d’utiliser les modules directement supportés par Hashicorp.

Audit

Vault journalise tous les appels de son API vers un fichier, syslog ou une socket selon le ou les modules d’audit activés. Au moins un module d’audit doit être activé et fonctionnel. Sans cela, Vault bloque l'exécution des commandes et se met en défaut.

Gestion de l'authentification au serveur Vault

Pour accéder au serveur Vault, on peut utiliser différentes méthodes d’authentification : elles peuvent être internes (user/password, Token) ou externes (LDAP, Radius, Kubernetes).

Voici une capture d’écran des différentes méthodes d'authentification possibles :

La documentation officielle propose plusieurs cas d’utilisation :

• AppRole (module à destination des applications et des workflows automatiques)
• AWS

Coté organisation, Vault associe différents types de méthodes d’identification (aliases) dans un objet appelé entity. Cet objet est lié à un utilisateur et peut être associé à un ou plusieurs groups. Le schéma suivant illustre cette organisation. Pour un exemple sur l’utilisation des groupes et des entity (lien vers la documentation).

Exemple d’utilisation: Module SSH

Sur le module SSH, Vault propose deux types d’identifications :

• OTP (one time password) : les identifiants ne sont valables qu’une seule fois. Vault est capable de journaliser leurs utilisations.
• Certificats SSH : Vault fonctionne en tant que CA. Chaque serveur SSH utilise la clef publique de Vault pour valider localement les certificats clients lors des tentatives de connexions SSH.

La suite de ce chapitre concerne uniquement l’identification sur les certificats SSH.

Du côté utilisateur, celui-ci doit appeler Vault afin de générer un certificat SSH. Cet appel se fait via des rôles. Les rôles permettent de forcer ou interdire des options SSH comme l’IP source, les users autorisés, le domaine DNS accessible. Ils permettent aussi de définir la durée de vie des certificats SSH clients.

Exemple d’options possibles pour les rôles :

Voici le processus pour la connexion d’un utilisateur en ligne de commande (l’équivalent existe sur l’interface web) :

• Ici l’utilisateur génère un certificat SSH

vault write -field=signed_key ssh/sign/role public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pub

• Connexion au serveur avec le certificat de l’utilisateur et celui donné par Vault

ssh -i signed-cert.pub -i ~/.ssh/id_rsa username@10.0.23.5

Note: l’argument -i signed-cert.pub peut être paramétré au niveau du fichier ssh_config

Le moteur SSH de Vault propose aussi la génération de certificat SSH à destination des hosts.

Un mot pour la fin

Le dernier article de cette suite vous proposera trois exemples d’utilisation (PKI, base de données et AWS) de Vault. La notion de secret as a service et le fonctionnement des Tokens seront abordés.

Elasticsearch est un serveur permettant d'indexer et de rechercher des données de manière très performante. Il fournit un moteur de recherche distribué et multi-entité via une API REST.

Présentation API Scroll

La recherche de documents dans Elasticsearch peut retourner un grand nombre de résultats. De manière assez classique, nous sommes souvent intéressés par la possibilité de paginer ces résultats. Il est possible de gérer la pagination de façon manuelle dans les requêtes Elasticsearch grâce aux paramètres from et size de l’API Search.

Il existe également une autre façon, plus automatique de gérer la pagination : l'API Scroll. Le principe consiste à ouvrir un contexte de recherche pendant un certain intervalle de temps. La première requête retournera la première page de résultat et un identifiant scroll_id correspondant au contexte de recherche. La seconde requête à l'API Scroll, avec le paramètre scroll_id, retournera la deuxième page de résultats, et ainsi de suite.

A l'inverse d'une recherche avec pagination classique, les résultats retournés par l'API Scroll sont relatifs au contexte et aux données présentes dans Elasticsearch au moment où la première recherche est lancée. On peut comparer ça à un snapshot : les mises à jour de documents ultérieures à la requête ne seront pas reflétées dans les résultats. La gestion de nombreux contextes étant coûteuse en mémoire, Elasticsearch limite à 500 le nombre de contextes de recherche ouverts simultanément par l’API Scroll.

A l’inverse de l’API Get, l’API Scroll n’est pas real-time : si des données sont sur le point d’être indexées, il faut utiliser l’API Refresh sur les index concernés afin de s’assurer que les nouveaux documents seront bien dans le contexte de scroll.

Dans cet article, nous verrons comment requêter l'API Scroll d'Elasticsearch depuis une application Angular avec RxJS. Le but n'est pas d'expliquer comment installer Elasticsearch ni son fonctionnement, et nous supposons donc que vous disposez d'un serveur Elasticsearch prêt à l'emploi. En particulier, les CORS doivent être correctement configurés pour autoriser la connexion depuis votre application front.

Les requêtes seront faites de manière non sécurisées à l’API Elasticsearch. Il est conseillé d’installer un proxy comme Keycloak Gatekeeper avec authentification devant l’API pour en sécuriser son accès.

Si vous souhaitez vous lancer sur Elasticsearch en partant de zéro, n’hésitez pas à suivre le guide officiel. A l’heure où j’écris cet article, j’utilise la version 7.3.

Installation des dépendances

Nous allons installer la librairie qui va nous permettre de requêter l'API Elasticsearch ainsi que disposer des types associés. Je précise ici les numéros des versions utilisées lors de la rédaction de l’article.

npm install --save elasticsearch-browser@16.3.0

npm install --save-dev @types/request-promise@4.1.44

npm install --save-dev @types/elasticsearch@5.0.34

L'installation de la librairie client (première commande) permet de requêter les différentes méthodes de l'API en utilisant directement des fonctions portant le nom de l'API à requêter, évitant ainsi d'écrire manuellement les requêtes HTTP.

L'installation des types (deux dernières commandes) est un réel avantage car ils permettent, sans devoir parcourir toute la documentation d'Elasticsearch, d'avoir à disposition les paramètres d'entrée de l'API et la structure des objets de retour. Cependant, les types en version 5.0.34 ne sont pas parfaitement à jour avec l’API d’Elasticsearch 7.3 : j’ai rencontré un seul cas d’erreur pour l’instant (sur le nombre total de hits) que j’ai contourné en castant vers le type attendu.

A l’heure où j’écris cet article, la librairie elasticsearch-browser est en passe d’être dépréciée par Elasticsearch. C’est indiqué sur ce dépôt Github (branche 16.x, au début du readme). Comme l’explique leur article, Elasticsearch conseille de migrer vers leur nouvelle librairie pour Javascript (qui supporte également Typescript). Malheureusement, comme indiqué dans leur documentation, cette librairie n’est pas pensée pour être utilisée dans un navigateur, elle utilise des fonctions exclusives à Node.js. Ils justifient cela par des raisons de sécurité, mais annoncent dans le guide de migration qu’une version de la librairie pour les navigateurs est prévue. Dans l’attente de la sortie de cette nouvelle version, nous resterons donc sur la seule version fonctionnelle à l’heure actuelle.

Création d’un service Angular

Nous allons placer tout le code permettant de requêter Elasticsearch dans un service Angular dont voici le code. Je reviendrai sur le rôle des variables d’instance et des imports dans les sections suivantes de l’article.

import { Injectable } from '@angular/core';

import { EMPTY, from, Observable, of } from 'rxjs';
import { expand, last, map, switchMap, tap } from 'rxjs/operators';

import { Client, CountResponse, SearchResponse } from 'elasticsearch';
import { Client as ClientJs } from 'elasticsearch-browser';

@Injectable({
    providedIn: 'root'
})
export class ElasticsearchService {
    private static readonly NB_RESULTS_PAGE: number = 1000;
    private static readonly SCROLL_API_SEARCH_CONTEXT_DURATION: string = '1m';

    private client: Client;
}

Configuration du client

Avant de lancer n'importe quelle requête vers Elasticsearch, nous devons disposer d'une classe Client initialisée. Le paramètre minimal à renseigner est l'adresse sur laquelle est exposée votre instance d'Elasticsearch.

private getElasticsearchClient(): Client {
    if (!this.client) {
        // The name of the types in not the same as the package name, 
        // so we instantiate it with its JS import and use its TS type elsewhere.
        this.client = new ClientJs({
            host: 'http://localhost:8888/elasticsearch'
        });
    }
    return this.client;
}

C'est sur cet objet que nous appellerons les méthodes requêtant les différentes API exposées par Elasticsearch.

Comme tracé sur cette question dans Stackoverflow, le nom de la librairie de types étant différent de celui de la librairie, nous devons user d’un contournement au moment de l’import afin de pouvoir bénéficier des types dans notre IDE.

Récupération de la première page de documents

Nous allons écrire une première fonction getDocumentsWithScrollFirstPage qui va initialiser un contexte de scroll et retourner la première page de résultat.

/**
    * Fetch documents from Elasticsearch with pagination, for the first time.
    * @param queryBody an object describing the search query for Elasticsearch using the query DSL
    * @param documentIndex the index where documents are stored (if undefined, searches everywhere)
    * @return an observable containing the first results page from the Elasticsearch scroll API
    */
public getDocumentsWithScrollFirstPage<T>(queryBody: any, documentIndex?: string | Array<string>): Observable<SearchResponse<T>> {
    return from(this.getElasticsearchClient().search({
        index: documentIndex,
        scroll: ElasticsearchService.SCROLL_API_SEARCH_CONTEXT_DURATION,
        body: {
            size: ElasticsearchService.NB_RESULTS_PAGE,
            query: queryBody
        }
    }));
}

Cette fonction prend en paramètre zéro, un ou plusieurs index : il s'agit de l'emplacement où va être lancé la recherche dans Elasticsearch : dans tous les index ou dans certains index en particulier. Elle prend également en paramètre un objet contenant tous les critères de recherche au langage Query DSL, comme expliqué dans l'API Elasticsearch. C'est dans cet objet que vous préciserez par exemple de trier vos résultats selon un critère, de les filtrer selon une chaîne de caractères, etc.

Nous avons utilisé un type générique T pour cette fonction. Cela permet de typer vos objets retournés dans l'attribut source avec une interface par exemple et d'utiliser la même fonction quel que soit l'index utilisé et la requête envoyée.

La durée de vie du contexte de recherche (variable SCROLL_API_SEARCH_CONTEXT_DURATION) dépend de vos besoins. Si vous souhaitez agréger toutes les pages de résultats dans votre application front, par exemple pour afficher des points sur un graphique, une durée de vie de quelques secondes sera suffisante. A l'inverse, si vous souhaitez afficher les résultats page par page dans un tableau sur lequel l'utilisateur choisit lui-même de passer à la page suivante, vous créerez un contexte durant au moins plusieurs minutes. La syntaxe et les unités de temps sont décrites sur la documentation.

Le retour de cette fonction nous renvoie donc, dans l'objet SearchResponse, le scroll_id qui devra être utilisé pour récupérer la page suivante de résultats, ainsi que les premiers résultats dans l'objet hits.hits. Voici une petite méthode utilitaire qui permet de récupérer une liste d’objets correctement typés depuis la réponse d’Elasticsearch :

private getDocumentsContent<T>(searchResponse: SearchResponse<T>): Array<T> {
    return searchResponse.hits.hits ? searchResponse.hits.hits.map(v => v._source) : [];
}

Le retour de la requête HTTP est encapsulé dans une promesse qui est résolue lorsque l'appel a terminé. En cas d'erreur, un objet contenant entre autres le code d'erreur et un message explicatif est encapsulé dans le rejet de la promesse. Il possible de convertir aisément l'objet Promise en Observable via la méthode from de RxJS afin de garder une certaine cohérence dans le code de son application Angular en ne manipulant que des Observable.

Récupération des pages suivantes de résultats

La fonction getDocumentsWithScrollNextPage sera appelée pour récupérer les pages suivantes de résultats.

/**
* Fetch documents from Elasticsearch with pagination, once getDocumentsWithScrollFirstPage() 
* has already been called.
* @param scroll_id the search id returned by getDocumentsWithScrollFirstPage()
* @return an observable containing a results page from the Elasticsearch scroll API
*/
public getDocumentsWithScrollNextPage<T>(scroll_id: string): Observable<SearchResponse<T>> {
    return from(this.getElasticsearchClient().scroll({
        scrollId: scroll_id,
        scroll: ElasticsearchService.SCROLL_API_SEARCH_CONTEXT_DURATION
    }));
}

Son unique paramètre scroll_id est égal à l'attribut scroll_id retourné par la précédente requête : comme il peut changer, il est conseillé d'utiliser celui de la dernière requête et de ne pas garder celui de la première requête. Le fait d'appeler cette méthode remet à zéro le timer associé à la durée de vie du contexte de recherche.

L'objet de retour est construit sur le même modèle que pour la fonction getDocumentsWithScrollFirstPage et on peut exploiter des résultats typés.

Si la liste hits.hits est vide ou de taille inférieure à la taille des pages définie initialement, c'est que la dernière page de résultats correspond au contexte de recherche créé par la fonction getDocumentsWithScrollFirstPage a été atteinte.

Conclusion

Au travers de cet article, nous avons vu comment requêter, depuis une application front-end en Angular, l'API Scroll de Elasticsearch pour récupérer de façon paginée des documents dans un contexte de recherche figée au moment de la première requête.

De nombreuses autres possibilités sont offertes par l'API d'Elasticsearch mais les détailler ici nuirait à la clarté de l'article. Par exemple, il est aussi possible de nettoyer manuellement les contextes de recherche avant qu'ils n'expirent.

Bien que les exemples s'appuient sur Angular et RxJS en langage Typescript, vous pouvez largement appliquer les principes décrits dans cet article pour requêter l'API Scroll avec d'autres technologies. La documentation de l'API Elasticsearch est à mon avis très claire et détaillée. C'est plutôt leur partie client navigateur qui pêche en cette période de transition de leur côté.

Sources

Les liens suivants sont utiles tout au long de la programmation :

• Documentation officielle de l’API Scroll d’Elasticsearch
• Documentation officielle de la librairie Elasticsearch Javascript

Les problématiques moins génériques de l’article sont sourcées directement au moment où elles sont abordées.

Après 20 heures de transit vers Las Vegas et quelques heures de sommeil, nous voilà sur les starting block pour débuter notre semaine.

Samuel et moi nous vous présentons la 1ere session de la journée du Lundi à laquelle nous assistons :

Pour ceux qui nous pas eu l'opportunité d'assister à un précédent Re:ivent il faut savoir que la zone que couvre les hôtels de l'événement est juste gigantesque. Nous trouvant dans un des hôtel du sud, il nous a fallu une bonne heure  pour atteindre la salle de conférence du Mirage hôtel.

Mais assez parlé de nos aventures, allons au coeur du sujets les stratégies à adopter et nouveautés sur AWS Transit Gateway.

Vous le savez peut être certainement, AWS Transit Gateway n’est pas un nouveau service. Effectivement ce service à été annoncé il y a un an mais c’est certainement son expérimentation sur une année qui permet aujourd’hui de proposer des stratégies et des évolutions pertinentes. Des évolutions clairement en phase avec les besoins des clients d’AWS qui nagent dans le casse tête des interconnexions réseaux.

L’idée générale est de simplifier le travail pour les personnes qui s’occupent de monter des réseaux et de les interconnecter (à l’échelle mondiale !!)

Notions de bases

Rappelons quelques composants nécessaires lorsqu’on fait du réseau sur le Cloud AWS :

• VPC : Virtual Private Cloud permet d'isoler une section de manière logique et dans laquelle vous pouvez lancer des ressources AWS dans un réseau virtuel.
• VPN & DirectConnect (DX) : pour connecter vos infrastructures “onPremise” avec vos VPCs
• VPC Peering : Établissement d’un lien réseau entre 2 VPCs. N’oubliez pas qu’un peering n”est pas transitif.
• VPC Private Link : Établissement d’un lien privé (non exposé sur Internet) entre 2 VPCs, mais orienté “application” : vous aurez besoin d’un NLB pour joindre une application (Support des ALBs annoncé sur la fin de l’année 2020)
  

Enfin, à l’intérieur d’un VPC, vous avez déjà la possibilité d’ajouter de la segmentation avec IAM, les Security Groups et les NACLs.

Un service contre la complexité

Une fois les composants réseau interconnectés avec tout çà, il est nécessaire de mettre en place les routes. Et c’est là que les difficultés commencent (restriction d’accès entre plusieurs environnements par exemple)

Voici une “capture live” d’une architecture de référence avec la Transit Gateway :

La transit Gateway fonctionne avec des policies. Ces policies permettent de propager tout ou en partie des sous-réseaux attachés à la transit Gateway. Ainsi, il est possible d’autoriser la connectivité sur tous vos VPCs avec un compte “Shared Service” qui contiendrait votre outil d’indexation de logs, vos fichiers partagés, etc… Vous pouvez publier une route sur une base de données de production à travers un VPN sans pour autant qu’elle soit accessible sur des VPC de non production..

Le service permet de centraliser les échanges réseaux, de dé-complexifier les interconnection et garder un niveau de sécurité adapté à ses exigences.

Une stratégie de taille

Nick Matthews Principal Solutions Architect chez AWS nous conseille de rester sur une segmentation orientée réseau et infrastructure sur des petites Landing zone (peu de compte, peu de VPC).

Cependant dès que nous visons des infrastructures “plat de spaghetti” avec beaucoup  d’interconnexion, c'est justement ici qu’intervient AWS Transit Gateway.

Cas particulier

Si un développeur demande un lien en désaccord avec la matrice des interconnexions peut-être est-il plus pertinent de partir sur un autre service pour ce cas là. Nous pouvons par exemple évoquer Private Link ou les VPC Peering.  

Nick Matthews nous a également présenté des uses cases d’utilisation de la Transit Gateway qui mérite d’être cité :

Conserver vos IP voir les centraliser grâce au  service Transit Gateway

• Gérer de manière avancée les ingress et egress à l’échelle globale de votre infrastructure.
• Attachement d’interfaces vs Propagation via la transit Gateway
  

STNO - Serveress Transit Network Orchestrator

C’est une nouvelle brique qu’AWS nous présente ici : la possibilité de gérer l’association entre d’une part la Transit Gateway et d’autre part des Comptes AWS. Cette brique est entièrement serverless (comprendre c’est une fonction lambda qui s’occupe d'effectuer les opérations pour vous) et se base sur la présence de tags spécifiques sur vos VPC & Subnets.

Ci-joint le schéma global :

(https://aws.amazon.com/fr/solutions/serverless-transit-network-orchestrator/

Cette brique est complétée avec :

une interface qui vous permet de suivre l’historique des actions

un système d’approbation : En effet, un composant “State Machine” est implémenté notamment lorsque le rattachement à un réseau est trop sensible pour que ce soit automatisable.

Conclusion

Ne nous voilons pas la face : La partie “Netwok” des infrastructures est compliquée. Commencez simplement avec Transit Gateway. Puis, petit à petit intégrer plus de connexions avec vos VPN, direct Connect, VPC ou encore vos service partagés.

Ne partez pas sur ce service si vous n’avez pas une infrastructure réellement dimensionnante.

Le coût peut sembler assez élevé et complexe à prévoir. Toutefois dans certain cas l’opération peut être rentable. Au lieu d’avoir 3 Nat gateway par VPC nous pouvons imaginer 3 Nat Gateway par région à travers la Transit Gateway. Nous pouvons penser à plein d’autres cas où la Transit Gateway permet de rendre des ressources communes et partagées.

Intégrez des services et procédures de sécurité dans l’élaboration de votre architecture réseau.

Faites vous aider par des partenaires AWS tel que Ippon Technologies qui accompagne au quotidien ses clients sur des problématique d’infrastructure dimensionnante, scalable et résiliente.

2eme session du Lundi : Cloud HSM.

Bien que le déploiement d’un cloud HSM est quelque chose que nous rencontrons pas tous les jours, cette session nous permettait de rencontrer 2 ingénieurs de la Crypto Team AWS, spécialistes du chiffrement, en charge du développement de leur service “Cloud HSM”.

Pour ceux qui utilisent AWS, vous avez très certainement manipulé des clés KMS. Celles-ci vous permettent de chiffrer vos données, qu'elles soient stockées dans une base RDS, sur un EBS ou encore un bucket S3. Quasiment tous les services d'AWS s'intégrent avec KMS (DynamoDB, ElasticSearch, etc ...)

CloudHSM est le service managé qui vous permet d'aller encore plus loin en terme de sécurité et répondre aux exigences fortes des entreprises dont les données sont classées “extrêmement confidentielles” ou pour les gouvernements, par exemple la norme FIPS 140-2 Level 3. A noter également qu’il s’agit d’une solution matérielle : vos clés sont générées sur des serveurs physiques (en opposition aux machines EC2 par exemple).

Un HSM (Hardware Security Module)  intervient pour faire du double chiffrement c’est-à-dire chiffrer les clés de chiffrement. C’est le cas si on souhaite l'intégrer avec AWS KMS par exemple.

Le cloud HSM permet de générer  (presque) tout type de clé de chiffrement. On peut parler de clés avec corum ou du SECP256K1 pour le blockchain. Nous ne nous attarderons pas sur ces cas spécifiques. Le but est ici plus de vous présenter ce service difficile d'approche mais aussi de  vous parler des nouveautées 2019 et 2020.

Il est également important de rappeler qu’un HSM dispose de clés matérielles par conséquent nous allons devoir démarrer des serveur physiques et pas de simples machines virtuelles. Comprenez par là que le prix d’entrée sera élevé.

Le double chiffrement est le dernier rempart si une personne malveillante a réussi à accéder à vos données. Cependant, afin de garder un esprit critique je tiens à préciser que l’utilisation d’un Cloud HSM avec KMS ne vous protège pas du redouté “Patriot Act”: à un moment KMS aura votre clé.

Que couvre le service Cloud HSM ?

• Le provisionning de votre cluster ;
• La Haute disponibilité de votre cluster HSM ;
• La maintenance du Cluster ;
• Les sauvegardes.
  

On parle ici de “Cluster”, car il faudra, pour répondre à toutes les exigences des standards de sécurité qu’HSM impose, au moins 2 noeuds qui s’échangent et propagent les clés ainsi que les commandes d’administration que vous lancez et tous les éléments nécessaires au bon fonctionnement.

Comme dans le “modèle de responsabilité”, AWS annonce à ses clients, qu’il sera de leur responsabilité de :

• Gérer les utilisateurs qui accèdent / génèrent des clés à l’intérieur de votre cluster
• d’intégrer la gestion des clés de votre cluster dans votre applicatif.
  

Notez que, pour répondre aux exigences de confidentialité nécessaires pour HSM, AWS ne peut pas “débugger à distance”. Une intégration avec CloudWatch est déjà en place et continue à s’étoffer afin de permettre aux utilisateurs de cloudHSM de comprendre les problématiques.

Concernant l’intégration avec votre applicatif, citons plusieurs standards supportés par cloudHSM :

• PKCS#11 (Cryptographic Token) ;
• OpenSSL ;
• JCE (Java Cryptography Extension).
  

Ci-joint quelques liens pour démarrer sur ces technologies :

https://github.com/aws-samples/aws-cloudhsm-pkcs11-examples

https://github.com/aws-samples/aws-cloudhsm-jce-examples

Interagir avec votre cluster

AWS fournit un toolkit permettant d’interagir avec votre cluster. Il fonctionne selon 2 modes :

• “global” : dans ce cas, les commandes sont propagées à l’intérieur de votre cluster à l’ensemble de vos noeuds. Attention, toutes les commandes ne peuvent pas etre lancées dans ce mode.
• “server” : dans ce cas, vous vous adressez directement à un noeud via son adresse IP. L’IP ne bougera pas et est attribuée au moment de la création du cluster. Il faudra donc penser à synchroniser vous même vos noeuds dans ce cas.
  

Cross Region Réplication

C’est une des fonctionnalités les plus bluffantes de cette offre. Pour des entreprises implantées à travers tout le globe, il est possible de répliquer vos clés à travers plusieurs régions AWS. La procédure est assez similaire pour une base RDS :

• copier le backup de votre cluster HSM dans la nouvelle région
• Créer un nouveau cluster dans cette région
• Synchroniser vos 2 clusters via des “Wrapped Keys” ou en le faisant “manuellement” avec vos scripts que vous aurez très certainement écrits !
  
  

Wrapped Keys vs Sync Keys

HSM vous permet de créer ces 2 types clés. Voici un récapitulatif entre ces types différents .

Wrapped Keys :

• A privilégier si vous devez générer de nombreuses clés ;
• Automatisation possible via du code (C ou Java) ;
• Si vous n’avez pas besoin de connectivité directe entre vos clusters (cas du multi région par exemple) ;
• Ne fonctionne pas pour certaines clés non exportables ;
• Pour utiliser une clé “wrappée”, vous devrez “unwrapper” son contenu. Il faudra prendre vos précautions dans votre code, pour restituer l’intégralité des “méta-données” inhérentes à cette clé, si vous souhaitez qu’elles soient identiques à l’arrivée.
  

Sync Keys :

• A utiliser si vous utilisez des clés non exportables ;
• Elle reste co-localisée à votre cluster HSM ;
• L’import d’une clé de ce type vous permettra d’avoir exactement la même “empreinte” entre 2 clusters (attributs, policies) ;
• La clé ne sera utilisable que sur un clone de votre cluster ;
• Pour l’instant, seul le binaire “cloudhsm_mgmt_util” (mode server uniquement) vous permet de les manipuler.
  

Les nouveautés

Les fonctionnalités implémentées sur l’année 2019 :

• Le “wrapping” pour les clés asymétriques lors des échanges de clés ;
• Compatibilité avec les outils standards de l’écosystème Java : jar signer, keystore et autres outils de “signature” équivalents ;
• Support de la norme Secp256k1 pour les applications block-chains ;
• Dérivation des clés générées via les clés matérielles type HMAC (attribut CKA_DERIVE) ;
• Support des fonctions lambdas ;
• Gestion des backups depuis la console Web.
  
  

Les nouveautés pour 2020 :

• Support pour la signature et l’encryption des clés KMS asymétriques via un custom key store ;
• Gestion des tags à la création et sur les backups et la gestion fine des droits d’accès aux ressources ;
• Gestion des attributs avancés de JCE.
  
  

Conclusion

Parce que l’architecture de votre sécurité peut être une barrière technique mettant à mal le succès de votre projet, rapprochez vous d’experts certifiés pour vous accompagner. Chez Ippon nous mettant en place la sécurité du Cloud chez nos clients. Des clients contraint au plus haut niveau de protection, avec des données de santé ou encore des données financière soumisent au norme RGPD, HDS ou bancaire.

Présent sur le Re:Invent 2019, @Samuel notre expert SecOps pourra répondre à vos questions. Vous pouvez également télécharger son dernier livre blanc La sécurité dans les nuages.https://fr.ippon.tech/la-securite-dans-les-nuages/

J’ai assisté à une session de Yan Cui, "AWS Serverless Hero", lors du AWS Re:invent 2019 sur comment refactoriser une application monolithique en une application serverless.

Cet article a donc pour but de vous partager le contenu de cette session. Yan Cui citant 8 étapes dans ce voyage dans le monde du serverless, je vais vous les présenter une à une.

Vous pouvez retrouver les slides complets de sa présentation en cliquant ici.

Étape 1 : inverser la Loi de Conway

Yan Cui cite la Loi de Conway qui dit : "les organisations qui conçoivent des systèmes ... sont contraintes de produire des designs qui sont des copies de la structure de communication de leur organisation".

Une architecture serverless est composée de petits composants faiblement couplés qui peuvent scaler et être déployés indépendamment les uns des autres. Si on suit la loi de Conway il faut structurer son organisation interne de la même manière.

Cela implique donc de créer de petites équipes, autonomes et pluri-compétentes qui ont la capacité et la responsabilité de gérer leurs propres services.

Le concept "2 pizzas team" mis en place par Jeff Besos en est un bon exemple : "si vous ne pouvez pas nourrir une équipe avec deux pizzas, c’est qu’elle est trop grosse".

Il est important de noter que l’organisation doit faire confiance à chaque équipe afin de pouvoir leur accorder une certaine autonomie. Cela ne doit pas l’empêcher de vérifier les décisions prises et de les challenger si besoin.

Dernier point et pas des moindres, passer d’un mode de conception monolithique à un mode serverless ne se fait pas sans heurt. C’est un changement drastique que les équipes doivent adopter du build jusqu’au run. Il faut donc accepter qu’une montée en compétence des équipes est obligatoire.

Étape 2 : identifier les services

Un point important cité par Yan Cui est d’identifier clairement les différents services que l’on va produire.

Les applications monolithiques étant généralement de taille considérable et couvrant plusieurs domaines métiers, il est impossible de tout refaire d’un coup. Cela implique donc d’identifier clairement au sein du monolithe les différentes frontières et d’en extraire des services indépendants.

Un service doit avoir l’autorité sur un domaine métier de l’application :

• Il doit être autonome ;
• Il doit connaître ses frontières ;
• Il est propriétaire de ses données et est le seul à pouvoir les exposer ;
• Il est faiblement couplé à d’autres services (à travers des contrats d’interface pour les APIs par exemple).

Attention toutefois à ne pas définir des services trop granulaires. Par exemple, dans le cadre d’un monolithe composé d’un ensemble de ressources sous forme de CRUD, ne pas définir automatiquement un service pour chacune des ressources.

Un service doit représenter un domaine métier clair. Voici un exemple concret :

Pour finir, il est grandement recommandé de démarrer sur des services à faible risque et non critique afin d’éviter tout impact business sur l’organisation.

Étape 3 : organiser le code

Un autre changement majeur lorsqu’on développe une application serverless est la manière dont le code va être géré. Dans une application monolithique, c’est généralement simple, un seul repository où tout le code source est stocké. Un choix naturel puisque toute l’application ne génère qu’un seul livrable.

La question qui se pose alors est que doit-on faire dans une application serverless ? Yan Cui cite deux possibilités.

Un repository pour tous les services

Un repository par service

De mon point de vue, la seconde approche doit toujours être privilégiée, c’est la solution la plus souple et la moins complexe sur le long terme.

Étape 4 : choisir vos outils

Déployer une application serverless est simple à condition de choisir les frameworks de déploiement qui vous conviennent. Vous serez ainsi capable de déployer une application entière en quelques minutes.

Il existe actuellement plusieurs frameworks, en voici une liste non exhaustive :

• Serverless framework
• AWS SAM
• AWS CDK
• AWS Chalice

Le framework doit être choisi en fonction des besoins de l’organisation et non l’inverse. Une fois la décision prise, il est important que le framework soit adopté par l’ensemble des équipes de l’organisation afin de garantir une certaine consistance dans la manière de déployer entre les différentes équipes.

Étape 5 : développer des fonctions simples

Les différentes fonctions d’un service doivent rester simple et respecter le principe de responsabilité unique de Robert C. Martin. Le but principal étant de faciliter la lisibilité de la fonction afin de comprendre rapidement ce qu’elle fait.

Respecter ce principe permet également d’avoir une sécurité accrue sur la fonction. La fonction n’ayant qu’un seul rôle, ses droits seront limités et si elle est compromise, l’impact et les risques seront moindres qu’une fonction ayant un champ d’action plus large.

Dernièrement, une fonction simple aura moins de code, moins de classe, moins de dépendance à charger au démarrage et le fameux cold start qui fait couler beaucoup d’encre sera moins important.

Étape 6 : basculer sur les nouveaux services gracieusement

Un point clé cité par Yan Cui lors du déploiement d’un nouveau service en remplaçant la partie monolithique est de ne pas impacter les utilisateurs.

Une approche qui a fait ses preuves est de maintenir la compatibilité des APIs existantes pour router le trafic vers le nouveau service. Afin de minimiser les risques il est préférable de router le trafic graduellement (canary deployment) en commençant par exemple avec 10% des requêtes vers le nouveau service. Si les signaux sont verts, augmenter le pourcentage jusqu’à arriver à 100%. Le weighted routing du service Route 53 permet de répondre à ce besoin.

On peut être tenté de vouloir changer l’API pour l’améliorer mais cela apporte un risque plus grand non nécessaire pendant la phase de migration. Il est préférable d’apporter ces modifications dans une seconde étape lorsque la migration sera effectuée.

Étape 7 : repenser la stratégie de test

La manière dont l’application est testée est également différente dans une architecture serverless.

Yan Cui explique que les tests unitaires ont un retour sur investissement moins important et qu’il faut donc se concentrer sur les tests d’intégration. Pour appuyer ses dires il donne en exemple le cas d’un endpoint sur API Gateway qui déclenche une Lambda pour écrire dans DynamoDB une ressource. Tester unitairement la Lambda a peu d’intérêt puisqu’il est plus intéressant de tester le processus de bout en bout pour vérifier que la ressource est bien présente dans DynamoDB.
Bien évidemment cela s’applique uniquement pour des cas simples où la Lambda ne contient pas de règle métier complexe puisqu’il faudrait dans ce cas faire autant de tests d’intégrations que de règles métiers.
Je reste dubitatif sur ce point car selon moi, même si la Lambda est simple il est toujours bon de la tester unitairement.

Il insiste également sur toujours privilégier l’utilisation des vrais ressources AWS lors des tests d’intégrations plutôt que d’utiliser des frameworks de mock tels que LocalStack par exemple.

Étape 8 : consolider le système pour qu’il soit robuste

Plusieurs points ici cités par Yan Cui :

• Mettre en place de l’observabilité sur toutes les briques. Une architecture serverless étant plus complexe de par son design, il est important de pouvoir tracer de bout en bout les requêtes et de pouvoir détecter les points de contention dans le système ;
• Utiliser des timeouts courts et adaptés aux différents processus ;
• Utiliser des files de messages (SQS par exemple) entre les différentes briques pour amortir le trafic ;
• Mettre en place le pattern SAGA pour faciliter le rollback des transactions si nécessaire ;
• Utiliser des circuit breakers pour éviter les failures en mode cascade ;
• Faire du chaos engineering afin de connaître les failles et limites de son système.

Conclusion

Le passage d’une architecture monolithe à une architecture serverless est un virage stratégique, organisationnel et technique qui ne doit pas être sous estimé. Les étapes décrites dans ce billet ont eu pour but de vous donner un point de départ sur les différents aspects de cette transformation. Pour vous accompagner dans cette conduite au changement, faites-vous aider par des experts !

Cet article fait partie d'une série visant à accompagner les entreprises dans leur migration d'un SI Big Data existant vers les offres cloud d'AWS.

Le but de cette série n'est pas de faire un comparatif détaillé sur l'intérêt d'une migration vers le Cloud ! Nous supposons que le choix est déjà fait et qu'il faut donc choisir parmi les solutions natives proposées par AWS.

Les solutions cibles favorisées sont les solutions natives équivalentes lorsqu'elles existent (Kinesis, DynamoDB, ...) et non les offres managées (solutions externes hébergées).

Nous avons donc privilégié le replatforming et non le lift and shift (Cf. stratégies de migration vers le cloud, les "6 R").

En effet, les solutions natives offertes par AWS présentent les avantages suivants :

1. Administration simplifiée et entièrement prise en charge par AWS,

2. Facturation plus avantageuse,

3. Solution parfaitement intégrée dans l'écosystème AWS.

Chacun des articles de la série va s'intéresser à une solution source très répandue dans le monde du Big Data et permettre :

• De comprendre les différences fondamentales entre les solutions,

• D'identifier les cas d'usage propices à la migration vers les solutions natives,

• D'identifier les cas d'usage propices à la migration vers une solution managée.

Introduction

Elasticsearch, Apache Solr et CloudSearch sont des solutions d’indexation et de recherche textuelles. On trouve dans ces solutions des notions avancées qui permettent d’améliorer grandement l’expérience utilisateur dans ces systèmes, telles que la possibilité de trier les résultats par pertinence ou les résultats avec facettes.

Elasticsearch, la référence

La première version d’Elasticsearch est sortie en février 2010 par Shay Banon, et a été créée pour être une solution scalable, ayant une interface HTTP ainsi que des connecteurs pour de nombreux langages. Il s’agit toujours d’un projet open source sous license Apache 2.0 que vous pouvez retrouver ici. Elasticsearch, l’entreprise, a quant a elle été créée en 2012, renommée Elastic en 2015, et propose un ensemble d’outils (certains open sources, d’autres payants) autour d’Elasticsearch et une solution d’Elasticsearch managé dans le cloud (AWS ou GCP).

Elasticsearch est un moteur d’indexation et de recherche basé sur la bibliothèque Lucene qui est distribué, permettant notamment une recherche full-text. L’outil possède une interface HTTP et stocke des documents JSON. Il est écrit en Java, et possède des interfaces dans une multitude de langages.

Elasticsearch est très connu pour être la pierre centrale de la stack ELK : Elasticsearch, Logstash et Kibana (maintenant renommée Elastic Stack avec l’introduction de Beats).Il permet de faire notamment de l’analyse rapide de logs au travers de dashboards grâce à Kibana. De plus, d’autres produits, créés par l’entreprise Elastic, gravitent autour d’Elasticsearch, tels que Beats qui permet d’importer facilement des données à partir d’un grand nombre de sources, ou Site Search permettant d’intégrer facilement de la recherche dans un site web.

Apache Solr, le principal concurrent

Apache Solr est le principal concurrent d’Elasticsearch dans le monde open source. C’est une solution distribuée de recherche textuelle, basée elle aussi sur Lucene, qui est open source et distribuée sous licence Apache 2.0. Depuis 2011, le développement de Solr est intimement lié à Lucene, les améliorations de l’un sont donc directement disponibles pour l’autre.

De plus Solr est inclus dans les distributions HortonWorks, mais c’est aussi la solution choisie par Datastax pour faire de l’indexation sur la base Cassandra, facilitant ainsi son adoption. Il existe un certain nombre d’outils open source construits autour de Solr, tel que Banana, un fork de Kibana permettant de visualiser les données.

CloudSearch, la solution historique d’AWS

CloudSearch est la solution managée cloud d’Amazon Web Service pour adresser les problématiques de recherche dans les applications et les sites web, créée en 2012.

Le service a été mis à jour en 2013 pour une toute nouvelle API. CloudSearch utilise de façon sous-jacente Apache Solr, donc se base lui aussi sur Lucene.

CloudSearch entre dans l’écosystème AWS, c’est-à-dire qu’il va bénéficier simplement des outils AWS disponibles pour monitorer, sécuriser et scaler son cluster.

Elasticsearch et le cloud.

AWS a développé depuis quelques années (2015) une solution managée d’Elasticsearch sur son cloud. Ainsi on peut créer en quelques clics / commandes un index Elasticsearch automatiquement redondé dans AWS. Cette solution managée bénéficie de la même manière d’une intégration simplifiée dans l’écosystème AWS avec la gestion de la sécurité (VPC, IAM…), mais aussi de l’intégration à Kinesis Data Firehose, qui permet de déverser simplement des streams de données dans Elasticsearch. Enfin, une instance de Kibana est directement installée avec les nœuds Elasticsearch.

Concrètement, AWS Elasticsearch est une solution installée sur des instances EC2, mais dont on n’a pas besoin de gérer le scaling ni la redondance, tout cela étant managé par AWS. Il est important de noter que AWS Elasticsearch se base sur la distribution Open Distro, développée par AWS et rendue open source en mars de cette année, et donc ne possède pas exactement les mêmes caractéristiques que la version officielle.

Enfin, Elastic propose de déployer une instance Elastic Stack directement sur le cloud (AWS/GCP) sans passer par un tiers, qui sera managé par leurs soins. Elle est donc difficilement intégrable avec des solutions d’infrastructure as code (IaC) comme Terraform ni avec les solutions d’IAM d’AWS par exemple

Les différences entre les solutions

Je parlerai ici principalement des différences entre Elasticsearch, Solr et CloudSearch. De plus, je ferai des parallèles entre les avantages des solutions managées et des solutions on-premise.

Voici un petit diagramme récapitulatif des points d’attentions lors de la migration

Connectivité

Malgré la liste des connectivités qui est très proche entre les solutions (API REST et langages supportés), la façon de se connecter change beaucoup. Cloudsearch se basant sur Solr, il possède la même connectique.

Enfin, la solution AWS Elasticsearch permet une connexion simplifiée pour le stockage des données avec une intégration avec Kinesis Data Firehose.

Alimentation des données

La façon d’importer les données dans le moteur d’indexation varie entre les solutions. Elasticsearch dispose principalement d’une alimentation via Logstash, autre produit de l’entreprise Elastic, permettant en premier lieu d’envoyer les logs d’un serveur vers Elasticsearch. S’ajoute à cela Beats, permettant d’ingérer des données provenant d’un grand nombre de sources différentes. De plus, Il est possible de créer soi-même son injecteur, pour envoyer ses données, ou d’utiliser un framework tel que Spark pour alimenter Elasticsearch.

CloudSearch, quant à lui, fonctionne par indexation de fichiers (JSON ou XML) en mode batch, c’est-à-dire qu’on va envoyer un fichier contenant un ensemble d’actions (ajout, suppression de documents) dont il exécutera les actions.

Il faut aussi noter qu’il n’y a pas de champ Enum ni de champ boolean dans CloudSearch contrairement à Elasticsearch. De plus il possède un support plus faible des nombres (seuls les types integer et double sont disponibles).

Enfin, la solution managée de AWS permet d’utiliser Kinesis Data Firehose comme source de type streaming afin d’ingérer des données.

Indexation de données

Lors de la création d’un index (ou d’un domaine sur CloudSearch), on peut définir l’utilisation d’algorithmes spécifiques pour la partie analyse et tokenisation des documents. Il y a moins de choix d’algorithmes chez CloudSearch que chez ses concurrents.

Sécurité : Shield et AWS

CloudSearch, étant dans l’écosystème de AWS, se permet de profiter de l’implémentation d’une sécurité assez poussée et de facilement gérer cette composante maintenant essentielle dans beaucoup d’entreprises, notamment pour le contrôle d’accès. L’utilisation de VPC, très conseillée, permet de limiter les possibilités d’accès à la base et donc de sécuriser l’accès aux données.

Concernant Elasticsearch on-premise, il est possible d’y apposer de la sécurité, et notamment du contrôle d’accès. Cependant il s’agit d’un service payant proposé par la société Elastic qui s’appelle Shield. Cette solution a l’avantage d’offrir une protection globale pour toute la stack Elastic, allant jusqu'à Kibana, mais aussi de faire du contrôle d’accès jusqu’au niveau du champ.

Monitoring

Pour passer de l’un à l’autre, il faut penser aux solutions de monitoring de notre cluster. Elasticsearch, grâce à sa communauté, propose des solutions telles que ElasticHQ qui permet de gérer simplement son cluster et ses index. Côté CloudSearch et solutions managées, on monitore principalement à l’aide de CloudWatch, qui utilise les métriques par défaut proposées par la solution.

Les différences entre Elasticsearch et Open Distro

La dernière différence notable entre les différentes solutions présentés est la distribution sur laquelle est construit le produit. Il existe en effet une distribution originale, celle maintenue principalement par Elastic et depuis environ un mois la distribution sur laquelle se base AWS Elasticsearch nommée openDistro. Elle possède des caractéristiques différentes que la distribution classique que je vous laisse découvrir ici. Par exemple AWS a ajouté à openDistro un service d’event monitoring et d’alerting.

Critères de choix solutions cibles

Le premier critère de choix est simplement l’utilisation d’un service managé, ce qui nous permet de ne pas avoir à gérer les machines sous-jacentes. Cela nous permet de facilement avoir accès à l'auto scaling, la sécurité ou même le monitoring.

Le second critère est le cas d’utilisation pour lequel on utilise Elasticsearch. Si on a besoin d’un cas d’utilisation simple et facilement administrable de recherche textuelle, on pourra partir sur CloudSearch. La solution AWS est certes peu fournie en algorithmes, mais possède l’essentiel pour une solution de ce type, et est plus simple à opérer que les autres solutions. De plus, la solution n’est pas prévue pour être nativement intégrée dans Kibana.

Enfin, si on possède déjà des infrastructures dans le cloud Amazon, on peut bénéficier pleinement des outils mis à disposition, ainsi qu’une connexion rapide et simplifiée entre les outils.

Cependant, il n’est pas conseillé de passer vers CloudSearch si on fait une utilisation de concepts avancés dans l’indexation notamment, utilisant des tokenizers particuliers, car certains de ces éléments n’y sont pas disponibles. Dès qu’une utilisation plus poussée d’Elasticsearch est nécessaire, on devra se tourner vers les solutions d’Elasticsearch managées.

Enfin, le dernier point d’attention est la non disponibilité de CloudSearch dans toutes les régions AWS, seule une dizaine de régions peuvent héberger la solution. Vous pouvez trouver toutes les informations sur ce sujet ici.

Migration

Migration des données, la théorie

Pour préparer la migration de vos données de Elasticsearch vers CloudSearch, il faut tout d’abord comprendre comment fonctionne l’ingestion et ses limites dans CloudSearch. Les principales limites à prendre en compte lors de cette phase sont :

• La taille d’un batch est de 5 mo max,

• La taille d’un document est 1 mo max,

• Vous pouvez lancer 1 batch toutes les 10 secondes (Environ 10 000 batch pour 24 heures).

Les batchs peuvent être au format JSON ou XML, formés d’une liste, avec pour chaque document un id unique, un type (ajout ou suppression) et la liste des champs du document.

Il est possible d’augmenter la vitesse d’upload en augmentant la taille de la machine. Ainsi en prenant la machine la plus puissante, on peut exécuter un plus grand nombre de batches en parallèle.

Concernant la migration de données d’un Elasticsearch on-premise et d’un Elasticsearch managé dans le cloud, deux solutions s’offrent à vous. Vous pouvez faire de la même manière un dump de vos données, il suffit alors d’utiliser un outil de migration de données tel que elasticdump, qui permet notamment de migrer l’ensemble des données, analysers et indexes d’un cluster Elasticsearch vers un autre. Il faudra par contre bien prendre en compte que cela doit être fait sur une machine disposant des droits d’accès aux nœuds, et donc dans le VPC sur AWS par exemple.

La seconde solution est de faire une lecture pour réindexation dans le cluster sur le Cloud. Il est possible, à l’aide de la méthode scroll, ou simplement avec un connecteur tel celui de Spark, de lire l’ensemble de la donnée afin de la réécrire dans notre nouvel index (vous pouvez trouver un exemple de cluster EMR temporaire ici). Cela est très utile lorsque l’on a une très grande quantité de données et peut de plus permettre un traitement supplémentaire au besoin.

Migration du Code existant pour utiliser CloudSearch

Pour migrer le code d’Elasticsearch vers CloudSearch, la modification des appels REST nécessitera une adaptation. Les requêtes dans CloudSearch se font dans l’URL, de cette façon :

http://search-movies-rr2f34ofg56xneuemujamut52i.us-east-1.cloudsearch.amazonaws.com/2013-01-01/search?q=(and+(phrase+field='title'+'star wars')+(not+(range+field%3Dyear+{,2000})))&q.parser=structured

Pour Elasticsearch on est sur des requêtes dans le body de la requête. La plupart du temps les appels sont faits au travers d'un SDK, et c'est donc un nouveau SDK qu'il faudra utiliser dans son code pour passer de l'un à l'autre.

En plus de cette migration de code et de la migration des données, il ne faut pas oublier de mettre en place un processus de migration pour passer d’une base à l’autre. Pour cela, la procédure standard est d’ingérer les nouvelles données dans les deux bases en même temps, effectuer la migration de données historiques de la première vers la seconde et enfin de migrer le code vers la nouvelle base de données.

Gestion des Contrôles d'accès et sécurité

Afin de faire fonctionner parfaitement CloudSearch, il ne faut pas oublier d’appliquer le contrôle d’accès de AWS : le service doit être dans un subnet public avec une IP publique si on doit l'appeler à partir d’une application externe, ou bien dans un subnet privé pour que seules vos applications dans le même subnet puissent y accéder.

Il est fortement conseillé d’installer Elasticsearch, dans le cas où il est managé par AWS, dans un VPC privé, avec un contrôle d’accès par ressource géré par l’IAM. Vous pourrez ensuite vous connecter aux machines au travers d’un bastion qui aura les droits d’accès aux nœuds et/ou au Kibana. De plus, il est fortement conseillé de chiffrer les données, paramètre disponible lors de la création du cluster sur AWS.

Estimation du coût AWS

Quels sont les leviers de facturation ?

La facturation AWS pour CloudSearch s’articule autour de trois principaux leviers. Le premier est l'exécution des batchs que l’on lui envoie, et qui coûte 0,1$ / 1 000 batchs (1 batch = 5 mo max)

Ensuite, la facturation dépend des instances sous-jacentes choisies pour CloudSearch et si on choisit le multi AZ. Chaque type d’instance coûte plus ou moins cher selon sa puissance.

Enfin, le dernier point concerne la réindexation manuelle des documents. On peut demander à CloudSearch de réindexer l’ensemble des documents, par exemple en ajoutant un champ à indexer. Cela coûte 0,98 $/go et n’est facturé que lors des actions manuelles, et non lors des indexations automatiques par CloudSearch.

Vous pouvez trouver tous les points de facturation, dépendant de la région cible, ici.

Concernant AWS Elasticsearch, la facturation est faite comme telle :

• Prix des machines EC2 sous-jacentes à l’installation d’Elasticsearch selon votre besoin (avec les modifications tarifaires en cas d’utilisation d’instances réservées par exemple),

• Prix du stockage EBS (si applicable) qui est environ de 0,11 $ par go-mois de stockage prévu. Plus d’informations ici.

Il est à noter que l’utilisation des snapshots n’est pas facturée. Vous trouverez les prix précis de chaque type d’instance pour chaque région ici.

Elastic propose une tarification qui, à l’instar de celle d’AWS, s’appuie principalement sur les machines qui feront tourner le cluster. À l’aide de leur calculateur, on peut voir rapidement ce qui sera déployé et le taux horaire / mensuel.

Estimation

Estimation de coûts pour une migration d’un Elasticsearch de 100 go avec des documents de 2Ko moyen vers un CloudSearch. On prendra comme région EU-Irlande et une augmentation de 500 000 documents par jour (1 go environ).

• Coût de migration (one shot)

On possède environ 50 millions de documents, et on peut mettre plus ou moins 2 500 documents par batch. Cela nous fait 20 000 batches pour remplir notre CloudSearch.

On va prendre la machine la plus puissante, qui nous permet de faire 16 insertions en parallèle, cela nous prendra donc environ 3,47 heures pour tout insérer. On aura donc comme coût :

20 000 Batches = 2 $

Instance search.m3.2xlarge = 0,832 $ * 3,47 = 2,89 $

On paiera donc 4,89 $ pour insérer l’ensemble de nos données.

• Coûts de maintenance (récurrent)

Par jour nous aurons 200 batches, ce qui coûte 0,02 $. Pour soutenir la charge, nous avons 3 instances search.m2.xlarge qui coûtent 0,104 $ par heure.

Sur un mois on arrive à : 0,02 * 30 + 3 * 0,104 * 24 * 30 = 225 $/mois

Estimation des coûts d’un Elasticsearch + Firehose

Afin de gérer une infrastructure équivalente, nous allons prendre une instance redondée en stockage optimisé afin de tenir la charge, à 0,275 $ de l’heure (i3.large.elasticsearch). Avec cette instance, nous n’avons pas besoin de stockage EBS, donc le coût de stockage est inclus dans l’instance. On obtient une tarification de 198 $ par mois.

Afin de faire la migration des données déjà existantes, il vous sera facturé la bande passante AWS comme pour toute migration. Cependant, si vous souhaitez utiliser son intégration avec Firehose pour l’ingestion des données, le prix de ce service doit être pris en compte. Si on reprend notre exemple, avec 500 000 objets par jour pesant 2 ko (devant être arrondis à 5 ko pour Data Firehose), avec une tarification à 0,031 $ par Go ingéré pour les 500 premiers to, on obtient 2,38 Go par jour et donc une tarification à 2,28 $ par mois. On a donc un coût de fonctionnement avoisinant les 200 $ par mois.

Estimation des coûts Elastic

Afin de gérer une infrastructure équivalente, nous n’avons pas besoin d’un gros cluster. Cependant, nous souhaitons une redondance sur 3 availability zones, avec des instances capables de tenir la charge principalement en I/O, ainsi qu’une instance de Kibana afin de rester sur quelque chose de comparable. Nous en arrivons donc à une estimation de 255 $ par mois environ.

Comparaison des prix

Conclusion

Elasticsearch, Solr et CloudSearch ont, sur la plupart des features nécessaires pour un moteur d’indexation, les mêmes caractéristiques. Les différences se feront principalement sur les notions avancées et les utilisations poussées des différents outils d’indexation, qui sont moins importants du côté de CloudSearch. Jevous conseillons donc de vous tourner vers cette solution dans le cas où votre utilisation d’Elasticsearch est centrée sur de la recherche textuelle. Cependant, pour une utilisation plus poussée, par exemple pour de l’indexation de logs ou l’utilisation dans le cadre d’applications de monitoring, il faudra passer par une installation personnelle ou l’utilisation d’une solution managée d’Elasticsearch.

La complexité de la migration réside principalement sur les connexions vers l’outil, qui changent grandement entre les solutions.

La différence de prix entre les solutions ne nous permettent pas de définir un clair gagnant, d’autant plus que les instances proposées ne sont pas les mêmes entre les solutions de management. Cependant, comparativement au fait d’avoir trois serveurs (afin d’avoir la donnée répliquée comme sur 3 availability zones) qui sont maintenus par une équipe, et le prix de la migration elle-même étant très faible, cela peut valoir le coup pour beaucoup d’organisations de passer sur une solution cloud managée.

Il faut aussi noter que Google a présenté sa solution d’Elasticsearch managé, au cœur d’un grand nombre d’annonces de solutions managées.

Aller plus loin

Comparaison Solr, CloudSearch et Elasticsearch
Solr
CloudSearch
Elasticsearch
CloudSearch limits
Preparing data for cloudsearch
CloudSearch scaling
Disponibilité des services par régions
Sizing cloudsearch
Elasticsearch managé par Elastic
Elasticsearch sur GCP
Le prix d’une architecture serverless

Si souvent, le concept même d’un Daily Meeting (ou Stand up Meeting) est relativement  connu de tous, il n’en reste pas moins que sa raison d’être et son déroulé ne sont pas toujours très clairs, et pour les participants et pour leur écosystème. C’est d’ailleurs, de mon expérience, un des premiers sujets sur lequel un Scrum Master débutant demande des conseils ou bien une équipe lassée, de l'assistance.

Cet article n’a pas vocation à expliquer dans les grandes lignes ce qu’est un Daily, ni à quoi il sert, mais plutôt de donner des axes concrets sur la façon de le faciliter. Voici tout de même un rappel, à partir de ce que l’on peut trouver dans le Scrum Guide (ici en anglais et en français) :

"L’Équipe de Développement y planifie ses activités pour les prochaines 24 heures. Elle optimise la collaboration et la performance de l’équipe en lui permettant d’inspecter le travail effectué depuis la dernière Mêlée Quotidienne et de prévoir le travail à venir dans le Sprint. "

"L’Équipe de Développement utilise la Mêlée Quotidienne pour inspecter sa progression vers l’Objectif du Sprint et pour inspecter si ces progrès aident à finir le travail contenu dans le Backlog de Sprint. La Mêlée Quotidienne augmente la probabilité pour l’Équipe de Développement d’atteindre l’Objectif du Sprint. Chaque jour, les membres de l’Équipe de Développement sont amenés à comprendre la façon dont ils ont l’intention de travailler ensemble en tant qu’équipe auto-organisée pour atteindre l’Objectif du Sprint et créer l’incrément d’ici la fin du Sprint."

Mais, s’il n’est pas facile en quelques mots de décrire ce qu’est un Daily, il est facile de dire ce qu’il n’est pas :

• Une remontée d'information, d'avancement, verticale vers un chef de projet.
• Une réunion qui dure.
• Une explication technique des fonctionnalités.
• Ce n'est pas le moment pour résoudre les problème mais seulement les évoquer, pour qu'à l'issue du Daily, les personnes concernées puissent les traiter.
  

D’ordinaire, le Daily suit un déroulé simple en trois questions posées à chaque participant de l’équipe de réalisation :

• Qu’ai-je fait hier qui a aidé l’Équipe de Développement à atteindre l’Objectif du Sprint ?
• Que vais-je faire aujourd’hui qui va aider l’Équipe de Développement à atteindre l’Objectif du Sprint ?
• Est-ce que je vois un obstacle qui m’empêche ou empêche l’Équipe de  développement d’atteindre l’Objectif du Sprint ?

Mais là où le Guide Scrum ne parle que d’un exemple de trois questions, beaucoup d’équipes appliquent ce schéma à la lettre, sans chercher à en comprendre l’objectif, à le challenger et en adapter le format en fonction de leurs besoins.

Bien entendu cet article n'aurait pas lieu d’être si ce n’était pas pour parler d’une autre approche.

J’ai donc choisi ici de vous faire un retour sur celle que j’ai pu essayer : un daily non pas basé sur chaque membre individuellement, mais sur chaque US individuelle (qui dans l’idéal, décline l’objectif du sprint).

Pourquoi changer ?

Être acteur d'un système ne permet pas toujours de se rendre compte qu'il est perfectible. Car, finalement poser les trois questions du Scrum Guide n’est pas une mauvaise pratique ; dans l’équipe, nous les utilisions et elles nous permettaient d'atteindre le but du Daily Meeting. Du moins, c’était l’impression générale. Pourtant, il y avait quelques irritants dans le fonctionnement de l’équipe, rien de dangereux, mais parfois handicapant :

• Des US grosses et difficiles à découper.
• Une organisation du travail plutôt en silo, en parallèle que conjointe.
• Des membres de l’équipe impliqués, mais très concentrés sur leur partie du travail plutôt que la globalité. Sur ce qui a été fait plutôt que sur ce qu’il reste à faire.
• Beaucoup de sujets commencés, peu de terminés.
• Un manque de visibilité qui pouvait parfois, par inadvertance, laisser deux personnes travailler sur le même sujet, en doublon.
  

Le Daily dans sa forme habituelle pouvait-il nous aider à y remédier ? Sans doute pas tout à fait, mais j’ai eu envie de leur proposer quelque chose de nouveau, d’essayer, d’expérimenter.  

Concrètement que s’est-il passé ?

Plutôt que d’être centrés sur chaque membre de l’équipe, nous nous sommes concentrés sur chaque US, en respectant leur priorisation. Nous nous sommes posés de nouvelles questions :

• Qu’est-ce qui est terminé ?
• Que manque t-il à cette US pour être terminée ?
• Qu’est-ce qui nous bloque pour la terminer ?
  

L’effet le plus visible, immédiat, a alors été de voir l’organisation du travail changer.

Puisque l’US était le sujet, chacun voyait mieux s’il manquait des tâches pour assurer sa réalisation (meilleur découpage).

En passant en revue toutes les US non terminées, il était plus facile de voir les blocages, les petits rien du tout (qui n’ont parfois de petit que le nom) qui empêchent de considérer un sujet comme terminé, ou simplement d’identifier les sujets sur lesquels personne ne travaillait alors que l’US était entamée. Non seulement les blocages devenaient plus visibles, mais l’équipe s’est organisée pour aller vers ces sujets, plutôt que de commencer une nouvelle US ou de continuer même si ce n’était pas leur domaine de prédilection (rédiger/passer des tests par exemple). De même pour se réorganiser en fonction des priorités.

L’objectif de livrer au plus vite une US a été remis au coeur du processus.

Le travail de plusieurs personnes sur un même sujet a été facilité et la tendance à avoir une seule personne par US s'est résorbée. De même, la situation où 2 personnes traitaient le même sujet sans s'en apercevoir ne s’est plus présentée.

Le Daily lui-même est devenu plus facile à suivre. Les participants étant moins focalisés sur leurs sujets, ils étaient du coup plus à l'écoute du reste du groupe. L’animation en était relativement facile, il fallait avant tout s’assurer que toutes les questions étaient posées, et bien demander ce qu’il manquait pour que l’US soit terminée.

Pour autant, ce n’est pas une solution miracle.

Pour l’appliquer, outre obtenir l’adhésion de l’équipe au système, il faut s’assurer qu’elle en ait bien compris les enjeux, car même si elle est convaincue, il est parfois plus simple de retourner à l’ancien fonctionnement par facilité.

Dans une équipe, qu’elle soit récemment formée, ou qu’elle n’ait pas l’habitude de travailler ensemble, il faut être attentif à l’équilibre dans la répartition des tâches entre les membres. La conversation n’étant plus orientée sur une personne, il est facile de passer à côté de quelqu’un qui fournirait trop (ou pas assez) de travail. Charge pour le SM (et l’équipe) alors d’y être vigilant.

En résumé, cette approche a incité les membres de l’équipe à mieux travailler ensemble, de mieux collaborer, de savoir où elle allait, de casser ses silos internes.

Mais il faut garder à l’esprit un des enseignements de l’agilité. Une même façon de faire ne peut être universelle, elle ne peut être la réponse unique à des équipes/questions/situations différentes. Ce format, bien qu’il ait été efficace dans cette équipe, ce contexte, ne doit pas être retenu comme la nouvelle façon de faire par défaut.

Discutez avec les autres membres de l’équipe. Identifiez à quels besoins de l'équipe le Daily doit répondre. Essayez, quitte à vous dire que non, définitivement, vous étiez mieux avant. Qui sait, vous serez peut être mieux après.

Cela fait déjà quasiment 2 ans que j’ai assisté chez Ippon à la présentation d’Istio par un expert google. J’avais été bluffé par sa présentation et les fonctionnalités qu’un service de “mesh” (maillage en français) pouvait apporter.

J’ai suivi la sortie du produit équivalent chez AWS : AppMesh avec beaucoup d’intérêts et testé leurs exemples disponibles ici : https://github.com/aws/aws-app-mesh-examples

C’est donc avec beaucoup d’excitation que j’ai assisté à la session du re:invent, dan l’un des plus grands casinos de Las Vegas le “Venetian”. Voici le teaser :

Service AppMesh - Présentation rapide

Ce service vient se brancher sur vos infrastructures du type EC2 tournant dans un Autoscaling Group, un cluster EKS ou un cluster ECS (Fargate ou EC2).

Vos services vont être “wrappés” par un système de proxy. Ce proxy va permettre de rendre votre applicatif beaucoup plus résilient. Les gros systèmes comme netflix, facebook, l’utilisent quotidiennement sur leur système de production. Citons quelques fonctionnalités :

• Canary Deployment : c’est LA fonctionnalité dont tout le monde parle : déployez votre version N+1 dans votre cluster, et configurez AppMesh pour router 10% de votre trafic sur votre service N+1. Le routage peut être “intelligent” et se baser sur des informations attachées aux requêtes.
• Gestion plus fine des défaillances : Une des tasks / pods s’emballe. Votre système de healthcheck voit votre service comme “Healthy” car les autres tasks / pods compensent. Les systèmes d’auto-scaling pouvant mettre un “certain temps” à réagir, AppMesh détectera la défaillance et re-routera le trafic sur les instances viables.
• “Circuit Breaker” : Lors des défaillances des systèmes sous-jacents, force est de constater que les applications, micro-service ou non, se comportent mal en général. Vous l’aurez compris, le “circuit breaker” permet de renvoyer une réponse HTTP en évitant que le système défaillant s’engorge.
• Encryption at Transit : Vos collègues développeurs ne respectent pas vos contraintes de sécurité ? Ils ne voient pas l’intérêt de le mettre en place? un service Mesh vous permettra d’ajouter de l’encryption SSL à la volée entre les appels intra-cluster.
  

AWS AppMesh est basé sur la stack envoy. Envoy va gérer les “Data Plane” et les autres composants d’AppMesh vont gérer le “Control Plane”. Je vous invite à consulter ce lien qui explique les différences entre ces 2 fonctionnalités : https://sdntutorials.com/difference-between-control-plane-and-data-plane/

Service AppMesh - Concrètement comment çà marche ?

Disons que vous avez 3 services. Vous allez définir 3 “virtual services” devant vos services.

Vous définirez ensuite des “Virtual Routers”, en charge de l’intelligence du routage entre vos services.

Ensuite vous devrez déclarer des “virtual routes”, c'est à dire l’ensemble des chemins entre ces “virtual routers”.

Note : un “virtual Service” ne peut correspondre qu’à un seul pattern de l’uri :

Chacun de vos “virtual services” seront joignables via des entrées DNS. AppMesh utilise le service “directory service” d’AWS Cloud Maps pour faire cela :

Enfin terminons par ajouter qu’AppMesh introduit de l’intégration avec les outils d’observabilité classiques AWS : X-Ray, CloudWatch Metrics & CloudWatch logs.

L’implémentation d’AppMesh se fait déclarativement. Voici un exemple de déclaration en cloudFormation :

---
Parameters:
  EnvironmentName:
    Type: String
    Description: Environment name that joins all the stacks

  ServicesDomain:
    Type: String
    Description: DNS namespace used by services e.g. default.svc.cluster.local

  AppMeshMeshName:
    Type: String
    Description: Name of mesh

Resources:

  ColorTellerBlackVirtualNode:
    Type: AWS::AppMesh::VirtualNode
    Properties:
      MeshName: !Ref AppMeshMeshName
      VirtualNodeName: colorteller-black-vn
      Spec:
        Listeners:
          - PortMapping:
              Port: 9080
              Protocol: http
            HealthCheck:
              Protocol: http
              Path: "/ping"
              HealthyThreshold: 2
              UnhealthyThreshold: 2
              TimeoutMillis: 2000
              IntervalMillis: 5000
        ServiceDiscovery:
          DNS:
            Hostname: !Sub "colorteller-black.${ServicesDomain}"

  ColorTellerVirtualRouter:
    Type: AWS::AppMesh::VirtualRouter
    Properties:
      MeshName: !Ref AppMeshMeshName
      VirtualRouterName: colorteller-vr
      Spec:
        Listeners:
          - PortMapping:
              Port: 9080
              Protocol: http

  ColorTellerRoute:
    Type: AWS::AppMesh::Route
    DependsOn:
      - ColorTellerVirtualRouter
      - ColorTellerWhiteVirtualNode
      - ColorTellerRedVirtualNode
      - ColorTellerBlueVirtualNode
    Properties:
      MeshName: !Ref AppMeshMeshName
      VirtualRouterName: colorteller-vr
      RouteName: colorteller-route
      Spec:
        HttpRoute:
          Action:
            WeightedTargets:
              - VirtualNode: colorteller-white-vn
                Weight: 1
              - VirtualNode: colorteller-blue-vn
                Weight: 1
              - VirtualNode: colorteller-red-vn
                Weight: 1
          Match:
            Prefix: "/"

  ColorTellerVirtualService:
    Type: AWS::AppMesh::VirtualService
    DependsOn:
      - ColorTellerVirtualRouter
    Properties:
      MeshName: !Ref AppMeshMeshName
      VirtualServiceName: !Sub "colorteller.${ServicesDomain}"
      Spec:
        Provider:
          VirtualRouter:
            VirtualRouterName: colorteller-vr

Terraform n'est pas en reste non plus :

resource "aws_appmesh_mesh" "simple" {
 name = "simpleapp"
}
 
 
resource "aws_appmesh_route" "serviceb" {
 name                = "serviceB-route"
 mesh_name           = "${aws_appmesh_mesh.simple.id}"
 virtual_router_name = "${aws_appmesh_virtual_router.serviceb.name}"
 
 spec {
   http_route {
     match {
       prefix = "/"
     }
 
     action {
       weighted_target {
         virtual_node = "${aws_appmesh_virtual_node.serviceb1.name}"
         weight       = 90
       }
 
       weighted_target {
         virtual_node = "${aws_appmesh_virtual_node.serviceb2.name}"
         weight       = 10
       }
     }
   }
 }
}
 
resource "aws_appmesh_virtual_node" "serviceb1" {
 name      = "serviceBv1"
 mesh_name = "${aws_appmesh_mesh.simple.id}"
 
 spec {
   backend {
     virtual_service {
       virtual_service_name = "servicea.simpleapp.local"
     }
   }
 
   listener {
     port_mapping {
       port     = 8080
       protocol = "http"
     }
   }
 
   service_discovery {
     dns {
       hostname = "serviceb.simpleapp.local"
     }
   }
 }
}
 
resource "aws_appmesh_virtual_router" "serviceb" {
 name      = "serviceB"
 mesh_name = "${aws_appmesh_mesh.simple.id}"
 
 spec {
   listener {
     port_mapping {
       port     = 8080
       protocol = "http"
     }
   }
 }
}
 
resource "aws_appmesh_virtual_service" "servicea" {
 name      = "servicea.simpleapp.local"
 mesh_name = "${aws_appmesh_mesh.simple.id}"
 
 spec {
   provider {
     virtual_node {
       virtual_node_name = "${aws_appmesh_virtual_node.serviceb1.name}"
     }
   }
 }
}

REX - Chick-Fill-A

“Chick-Fil-A” est une société américaine dans le domaine de la livraison de “sandwichs au poulet”. Cette société a connu une fulgurante ascension.

Leur architecture est basée sur un cluster EKS, ainsi que des tables dynamoDB et des bases de données RDS. Un système de datalake complète le tout.

Ils ont introduit AppMesh avec l’utilisation de la librairie flagger de weaveworks.

AppMesh leur apporte le “canary deployment” : ils avaient le besoin de livrer rapidement des évolutions de leurs services basées sur les analyses des données effectuées depuis leur datalake.

L’ensemble de leur déploiement sur EKS est piloté classiquement depuis un “Jenkins”.

et en zoomant :

Lors du déploiement d’une nouvelle version, Flagger va s’occuper de modifier le routage du traffic :

et basculer le traffic progressivement de manière automatique et progressive. L’interface de flagger permet de rollbacker et de suivre le déploiement. La démonstration faite en live s’est déroulée sans problème : simple mais efficace.

Citons les 2 derniers outils présentés lors de cette session :

• kustomize : c’est un déployeur de la solution AppMesh, développé par la même société weaveworks, spécifiquement pour kubernetes.
• kcp : opérateur Kubernetes pour la gestion d’un service Mesh dans un cluster Kubernetes.
  

Conclusion

J’ai pu constater que pas mal de chemin a été fait depuis le début de la RoadMap AppMesh. Le monde de l’open-source a développé les outils qui manquaient. Imaginez-vous gérer la bascule de votre trafic avec des "apply" successifs d’un code terraform ?

La mise en oeuvre d’un tel outil semble nécessiter une rigueur importante dans le design des architectures micro-service. Vos collègues devops devront investir un temps certain pour maîtriser ce produit.

En sortant de la salle, je reste néanmoins un peu sur ma faim. Les autres fonctionnalités, telles que le “circuit breaker” ou “l’encryption at transit” au sein du cluster, ne sont pas abordées et restent pour l’instant absentes.

D’autre part, l’utilisation d’AppMesh est souvent présentée dans le cadre d’EKS. Qu’en est-il des autres types d’infrastructure, notamment ECS Fargate ?

AppMesh est un outil encore un peu jeune mais la fonctionnalité du “canary deployment” fonctionne à merveille. Pour les utilisateurs des clusters EKS, je pense qu’AppMesh est prêt. Reste à l’évaluer sur du Fargate.

Le concept principal du cloud AWS est basé sur la notion de VPC “Virtual Private Cloud”. Cette notion correspond littéralement à un groupement de datacenters géographiquement éloignés pour assurer une disponibilité maximale, nommé "Availability Zone". En répartissant vos "workloads" sur ces zones de disponibilité, même en cas de perte de l’une d'entre elles, vos systèmes peuvent continuer à fonctionner. Depuis 2006, AWS est une référence en terme de conception de ces datacenters.

Dans les années 80, lors du développement des services de datacenters “physiques”, la mise en oeuvre de procédures d’exploitation au sein même des datacenters s’est professionnalisée. Citons les normes ISO-27001 & HDS pour les données de santé à caractère personnel. Aujourd’hui, avec la facilité d’utilisation des clouds providers, un nouveau vent de professionnalisation est nécessaire. Au delà de toutes les nouvelles technologies de développement (serverless, containers, IA), la conception d’un SI basé sur une organisation de comptes AWS nécessite une réelle réflexion. C’est à ce moment que le terme de “Landing Zone” est apparue.

Comme maintenant tout est “apifié”, la construction des Landing Zones peuvent se comparer au développement d’une "application" qui va héberger les applicatifs de tout ou partie d’une entreprise. Certains choix de départ peuvent être assez structurants, à l’échelle de votre IT.

C’est avec toutes ses réflexions en tête que j’ai assisté à cette session “Best Practices” dispensée par Sam Elmalak, un "World Wide TechLeader" de chez AWS, dont voici la description :

Landing zone - Les grands principes

Rappelons-en les grands principes :

• Elle se base sur “AWS Organizations”.
• Un master account pour la gestion du paiement.
• Vous organisez vos comptes en créant une arborescence d’OU (Unité organisationnelle).
• Vous appliquez des SCP (Service Control Policy) vous permettant de brider certains services (interdire sur les plateformes de dev de créer des machines c5.12xlarge ou l’utilisation de disque SSD hautement performant !!).
• Au moins 1 compte “sécurité” : récupération de l’intégralité des logs CloudTrail pour les audits, gestion de vos clés de chiffrement et politiques de rotation.
• Au moins 1 compte “Shared” dans lequel vous installerez vos applications de monitoring, vos applications de qualimétrie (Sonar, Gatling, etc …), votre AMI Factory, votre Docker Factory etc ..., potentiellement votre CI/CD même s'il vaut mieux la mettre dans un compte séparé.
  

Avant d’illustrer ces propos, que risque-t-on à ne pas faire de landing zone ?

Rappelons que par défaut, un compte AWS est bridé avec un nombre important de "Service Limits", souvent de type "soft limit" (un case au support AWS sera alors nécessaire pour étendre cette limite) ou "hard limit". Citons 2 cas pour le domaine du "serverless" :

Concurrent executions : 1000 lambdas en parallèle. Si vous lancez par exemple, des lambdas de traitement de "petits fichiers" résultant du découpage d'un très gros fichier, vous pouvez atteindre facilement la limite de 1000. Ces aspects sont abordés en détail dans l'article de mon éminent collègue Fabien Roussel "AWS Re:Invent 2019 - Du monolithe au serverless, un voyage en plusieurs étapes"

Nb de lambda edge : 100. Ce nombre s'applique par instance de cloudFront.

Best Practices

Evidemment, AWS propose un outil pour mettre en place votre landing zone. Il en avait même deux : AWS Landing Zone & AWS Control Tower. Lors de ce re:invent, Sam Elmalak nous annonce que les 2 produits vont être fusionnés dans AWS Control Tower.

Services Control Policies (SCP)

• Permet de limiter l’accès aux API AWS (<=> les services).
• Les SCP sont invisibles pour tous les utilisateurs des comptes où elles s’appliquent, y compris pour le compte “root”.
• Les SCP sont appliquées pour tous les utilisateurs des comptes où elles s’appliquent, y compris pour le compte “root”.
• Les permissions manipulables dans les comptes où elles s’appliquent correspondront à l’intersection entre les permissions définies dans la SCP et les permissions IAM.
• Définir une SCP est totalement transparent pour les simulateurs de policy IAM.

Les SCP sont définissables via tous les outils "Infra As Code", Ci-joint un exemple en terraform, de la défintion d'une SCP permettant d'interdire des services sur les régions autres que celles vous souhaitez :

resource "aws_organizations_policy" "deny_services_unwanted_regions" {
  name = "deny_services_unwanted_regions"

  content = <<CONTENT
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideEU",
            "Effect": "Deny",
            "NotAction": [
               "iam:*",
               "organizations:*",
               "route53:*",
               "budgets:*",
               "waf:*",
               "cloudfront:*",
               "globalaccelerator:*",
               "importexport:*",
               "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-central-1",
                        "eu-west-1"
                    ]
                }
            }
        }
    ]
}
CONTENT
}

OU (Organizational Units)

Master Account

• Pas de connexion Internet
• Pas de ressource déployée
• Contiendra vos OUs
• Définition des SCP applicables pour chacune de vos OUs
• Coût consolidé de vos consommations. Le tagging de vos ressources sera un élément essentiel pour répartir vos coûts au sein de votre SI.
• Accès Utilisateur Limité
  

Foundational OUs

Cette OU sera créée pour héberger les composants d’infrastructure et de sécurité sur lesquelles vos autres OUs se baseront. Cette OU contiendra les comptes suivants :

Archive Logs

Ce compte servira dans le cadre de vos audits. L’ensemble des logs d’accès à l’api AWS (CloudTrail) seront déversés ici. Remarquez l’activation de la protection “MFA delete”. Tout objet de ce compte ne pourra être supprimé qu’avec un double facteur d’authentification.

Security Accounts

Ici, 3 sortes de comptes différents :

“Read Only” : ce compte sera dédié aux "humains" à des fins de consultations, dédiés pour les audits.

• “Break Glass” : Alert on Login, Réponse dans le cas d’un incident. Ce compte ne devrait jamais être utilisé ! Ce compte sera également utilisé pour les activités de “Forensic” que les cellules sécurité peuvent avoir à faire lors de certaines attaques.

• “Tooling” : vos outils de sécurité & audit, Amazon Guard Duty, AWS Security Hub, AWS Config agrégation, Définition des “Cross Account Roles”.
  

Notons ici que n’a pas été abordé la notion de “compte de rebond”. Comme un bastion pour des infrastructures, le compte de rebond servira à vos “ops” à se connecter facilement dans l’intégralité des comptes nécessitant leur expertise.

Shared Services

Comme son nom l’indique, ce compte contiendra l’ensemble des composants communs de votre infrastructure, hors outils de sécurité. Pour information, les "Golden AMI" correspondent à vos images de référence pour vos machines, si vous n'êtes pas encore passés en "serverless" ou en "conteneurs" sur Fargate. Une "AMI Factory" vous sera nécessaire pour assurez des socles stables et patchés en terme de sécurité. De nombreux outils vous permettront de faire çà : AWS Golden AMI Pipeline, Packer couplé avec AWS Code Build ou Ansible.

Network Services

Ce compte hébergera vos connectivités réseau : AWS Direct connect, VPC Transit Gateway, shared VPCs etc ... Ici, ce seront vos ingénieurs réseaux qui maintiendront les différents composants déployés.

Additionnal OUs

Developer Sandbox

L’innovation est un message “fort” et martelé par AWS dans sa communication. Mettre en place des comptes “sandbox” permettant de tester et construire des pocs peut être un accélérateur de croissance phénoménal pour les entreprises.

Si un poc est viable, il pourra alors être déployé dans les comptes de workload “officiels” :

Workloads Dev, Preprod & Prod

Ces comptes serviront à héberger vos applications. On préférera séparer les environnements. Ici, il ne faut pas hésiter à déployer plusieurs comptes. Un compte par "entité" (entité, businessUnit, secteur, etc ...) est complètement envisageable. Le développement de certaines activités peuvent nécessiter un usage intense des lambdas, par exemple, et il serait dommage de pénaliser d'autres activités pour des raisons de "co-localisation" dans le même compte.

PolicyStaging OUs

La mise en oeuvre des SCPs et de leurs tests sera une activité à considérer comme telle dans votre plan de charge. Pour cela, une OU dédiée aux tests de policy sera nécessaire :

Suspended OUs

Les comptes AWS ne doivent pas être supprimés d’une organisation. On le déplace au sein de l’arborescence dans une OU dédiée.

Individual Business User OUs

Certaines entreprises peuvent nécessiter de créer des comptes AWS pour des utilisateurs “business”. Ceux-ci seront créés dans une OU dédiée :

Exception OUs

Malgré toute la préparation possible, les “exceptions” existent toujours. Si un cas se présente et qu’il ne peut pas logiquement se ranger dans les OUs précédemment créés, alors c’est qu’il faudra créer une OU pour ce genre de comptes :

Deployments OUs

Les systèmes de déploiement de vos applicatifs doivent être gérés séparément des comptes où les applications sont déployées. L’accès à ces comptes doit être sécurisé, notamment pour la production, car c’est le seul endroit où un utilisateur mal intentionné pourrait déployer du code malveillant sur vos systèmes.

Big Picture

Voici le diagramme des flux de logs de sécurité :

L’ensemble des logs de tous les comptes sont envoyés sur le compte d’archivage des logs.

Voici le diagramme des flux réseaux :

Les services AWS utilisables

Une synthèse de l’AWS Organizations :

Présentation AWS Control Tower

AWS Control Tower va s’occuper de générer automatiquement un certain nombre de comptes présentés précédemment :

• Compte de Sécurité “Tooling”
• Compte d’archivage des logs

Terminons par présenter la picture que couvre la Landing Zone  :

Et maintenant on fait quoi ?

Sam Elmalak termine sa présentation en insistant sur le fait de ne pas multiplier les outils et de mettre en place un “standard”. Ce standard sera désormais géré par un service unique AWS : AWS Control Tower. Du coup, voici ses recommandations sur vos organisations existantes ou pour les nouveaux clients :

Si la génération d’une landing zone est maintenant automatisable, on peut également commencer à se poser la question si on peut avoir plusieurs landing zones. Voici quelques éléments de réflexion :

Et voici pour conclure quelques points importants que Sam Elmalak nous propose d’approfondir en consultant les guidelines disponibles sur le site AWS :

Conclusion

Personnellement, j'ai trouvé cette session la plus intéressante de toutes celles que j'ai pu voir durant cette semaine. Sam Elmalak a cité de nombreux exemples de cas rencontrés pendant sa vie de "AWS baroudeur". Sa présentation est en ligne ici.

Sam Elmalak a conclu sa présentation en nous annoncant que l’intégration de comptes déjà existants dans une organisation générée par Control Tower sera disponible très prochainement.

Pour conclure, quand on voit le nombre de comptes que peut contenir une Landing Zone dans le cas des grosses entreprises, on se rend bien compte qu'une réflexion globale sur les rôles est nécessaire. On privilégiera toujours des solutions utilisant des rôles et non des comptes IAM, beaucoup plus lourds à gérer.

Pourquoi parler d’écologie et d’informatique ?

L’impact environnemental de l’informatique et de son expansion ces dernières années n’est plus à prouver : consommation énergétique affolante des data centers, mise à jour régulière des parcs informatiques des entreprises, obsolescence accélérée de nos matériels… Tous ces facteurs font de l’informatique l’un des domaines les plus polluants de la planète. Des actions pour limiter son impact existent, mais restent encore rares. Amazon a annoncé par exemple la neutralité carbone de leurs datacenters pour 2040 et Google achète autant d’énergie verte qu’il en consomme.

Aujourd'hui, nous ne nous rendons pas compte de ces problématiques. Avec l’avènement du cloud et de la simplicité d’accès aux ressources, l’utilisation de plus en plus de puissance pour des calculs, la place de plus en plus grande du machine learning et le traitement massif de données, notre consommation de l’informatique est devenue titanesque. Mais là où de nouveaux challenges émergent, des opportunités se créent.

Vous pourrez trouver dans ce rapport des informations quant aux impacts du numérique dans la consommation d’énergie mondiale, mais aussi les impacts du matériel informatique (téléphones, ordinateurs) : https://theshiftproject.org/wp-content/uploads/2018/11/Rapport-final-v8-WEB.pdf

Qu’est-ce que le Green IT ?

Depuis quelques temps, on entend le terme de Green IT. Intéressons-nous à ce courant de pensée qui pourrait s’apparenter à un nouveau buzz word, mais qui pourrait avoir un apport pertinant au domaine l’informatique.

Le Green IT, ou sobriété numérique en français, est un terme qui a été défini plusieurs fois ces dernières années. On lui prête volontier tout un ensemble de valeurs qui entrent plus ou moins dans son giron.

On peut déterminer trois grands principes qui se rattachent à la sobriété numérique ou Green IT, il d’agit d’une démarche d’amélioration continue qui vise à réduire l’empreinte écologique, économique et sociale :

• Des technologies de l’information et de la communication.
• De l’organisation (au sens physique du terme) grâce aux outils numériques.
• D’un produit ou d’un service, grâce aux Technologies de l’Information et des communications.
  

On voit toute la portée ici de ce terme, qui va bien au-delà des aspects techniques liés aux technologies de l’information, et s’intéresse aussi aux aspects sociaux et économiques des projets informatiques. Pour aller plus loin, une définition complète est disponible sur le site de GreenIt.

Comment mettre cette nouvelle vision au centre des préoccupations ?

Le Green IT c’est bien, cela donne bonne conscience et une bonne image. On pense à l’écologie. Mais est-ce que cela peut apporter quelque chose à un client ? Comment lui faire comprendre la nécessité de passer à un mode de travail plus vert ? Cela va-t-il lui coûter plus cher ? Ou au contraire, lui réduire sa note ? S’ajouter encore de nouvelles contraintes dans notre métier ne va-t-il pas à l’encontre de sa complexité inhérente ?

Dans cet article, nous nous concentrerons sur le rôle de l’architecte dans un contexte big data. Nous le verrons dans la poursuite d’une amélioration de l'empreinte carbone de l’entreprise et comment la mise en place des principes de sobriété numérique peut être transformée en opportunité.

Ressources partagées

Lorsqu’on lance un nouveau projet dans une entreprise, on a tendance à vouloir tout construire de zéro. Construire un nouveau datalake, une nouvelle infrastructure sur Kubernetes, ou mettre en place un cluster Kafka. Mais souvent il existe déjà dans l’entreprise une plateforme qui utilise ce type d’outils, et cela peut être une bonne idée de mutualiser les environnements SI. L’utilisation de ressources partagées est cependant contraignante : cela demande un peu de rigueur et de compromis entre les équipes, mais permet aussi de réduire la quantité de serveurs ou de services que l’on doit utiliser au sein de l’entreprise.

Ressources temporaires

Avec l’avènement du cloud, des services managés, du serverless mais surtout de la conteneurisation, le cycle de vie de nos infrastructures a bien changé. Certains composants de nos Systèmes d’Information n’ont pas besoin de vivre éternellement comme cela pouvait être le cas sur des serveurs dédiés, mais peuvent être arrêtés car non utilisés. Dans le cas d’une pipeline de données, une fois le traitement terminé, quel intérêt de continuer à avoir un cluster qui tourne si on sait qu’aucun traitement ne sera relancé avant le lendemain ?

L’utilisation sur AWS de Spot Instance en est une très bonne illustration. Il s’agit d’instances non provisionnées par Amazon, qui ne sont donc pas utilisées. Si le besoin se fait sentir, plutôt que de provisionner à long terme des instances, on peut utiliser de façon temporaire une puissance de calcul supplémentaire, et ce à moindre coût. Il est aussi possible, par exemple, de créer des clusters EMR (Elastic Map Reduce, cluster Hadoop dans le cloud AWS) de façon éphémère, pour un simple traitement, comme décrit dans cet article.

L’utilisation de services serverless sur les différents cloud providers permet aussi de n’utiliser que ce dont on a besoin, et par conséquent de ne payer que pour l’utilisation des ressources utiles. L’utilisation de FaaS (Function as a Service, type Lambda chez AWS) est un très bon exemple de cela, car on peut limiter son utilisation à quelques millisecondes.

Ressources dimensionnées

Choisir le dimensionnement de ses instances est une tâche compliquée. On a tendance à vouloir prendre plus gros pour assurer, mais est-ce vraiment nécessaire ? Lorsque l’on connaît son use case, ses cas à la marge et la quantité de données qui sera traitée par notre système, il faut exécuter des tests de charge pour se rendre compte de comment va se comporter l’application et de voir si elle est capable d’absorber le volume prévu. Il est possible par exemple de mettre en place un capacity planning, permettant d’établir une stratégie quand à la gestion de la charge de l’application. Avec un petit peu de marge et en utilisant des processus d’auto-scaling pour absorber des pics de charge, obtenir un premier dimensionnement relativement correct n’est pas sorcier.

Il est de plus plus intéressant, pour limiter son impact, d’utiliser des ressources de taille raisonnable (pas de serveur mastodonte), et de gérer l’ajout et la suppression de nouvelles machines en cas de montée de charge. Cela va nous donner à la fois plus de flexibilité pour limiter la consommation et s’adapter aux changements d’utilisation de l’application.

Identifier ses use cases et se limiter à ceux-ci

La meilleure pratique pour limiter l’impact de l’informatique est de bien définir les use cases. Définir finement les limites, se conformer aux nécessités, éviter de stocker et traiter de la donnée qui ne nous intéresse pas.

La meilleure façon d’avoir un impact sur les use case est d’impliquer les métiers en leur expliquant que si on stocke et qu’on traite 3 ans de données alors qu’ils n'accèdent qu’à 3 mois de données, on crée une surconsommation énergétique, au delà d’un surcoût dû au stockage et traitement supplémentaire.

L’un des principes fondamentaux de l’informatique, “Less is more”, est aussi totalement applicable dans ce contexte. Il ne sert à rien de stocker et de traiter de la donnée dont on aura potentiellement besoin pour un use case dans 1 ou 2 ans. Cela se recoupe de plus avec les principes de la RGPD (Réglementation générale pour la protection de données), directive européenne qui fixe des limites quant à l’utilisation des données personnelles pour éviter les dérives.

Optimisation des algorithmes

Ce n’est peut être pas le rôle direct de l’architecte, mais avec une connaissance des principaux outils de traitement de données, on peut se rendre compte que l’on peut toujours optimiser un traitement. Cela à un double avantage :

• Réduction du temps de calcul, donc accélération des traitements
• Réduction du besoin matériel lié à ce traitement
  

Nous nous retrouvons en finalité avec une réduction des coûts liés au traitement, mais aussi de l’énergie consommée par notre traitement et des moyens matériels employés.

Afin d’optimiser nos traitement, il y a toujours un grand nombre de possibilités dépendant de la technologie utilisée :

• Utilisation de formules mathématiques permettant de réduire la complexité de nos algorithmes, comme on peut retrouver dans le projet Euler (Vous en avec une présentation lors du DevFest Nantes cette année)
• Mise en cache de datasets pour faire des jointures en Spark
• Design de bases pour optimiser le requêtage
  

Cycle de vie des données

Le stockage des données est devenu si ridiculement bon marché qu’il est facile de se dire que l’on va stocker notre donnée ad vitam eternam. Cependant, mettre en place des politiques de gestion du cycle de vie de la donnée pour supprimer automatiquement les données obsolètes permet un gain en lisibilité, et nous permet de nous concentrer que sur les données utiles.

Quand on parle de données, il ne faut pas oublier les logs qu’écrivent nos applications. Ces fichiers textes peuvent prendre une taille considérable et être désuets très rapidement (en une semaine les logs peuvent ne plus être utiles !). Il est donc préférable d’avoir une solution de purge de ces logs pour ne pas consommer outre mesure de l’espace de stockage.

D’ailleurs, c’est une bonne habitude que chacun peut prendre à son échelle en supprimant ses mails anciens, et en priorité ceux avec des pièces-jointes volumineuses. La lisibilité de votre boite mail que vous gagnerez sera bénéfique, vous n’avez plus besoin de ce mail de publicité de 2016 !

Le Edge Computing (ou informatique de périphérie)

La collecte et l’envoi de données à partir de nombreux périphériques vers un data center, ou vers le cloud, est devenu au fil du temps une norme, notamment dans l’IoT (Internet of Things). Or, dans de nombreux cas, cela consomme une très grande quantité de bande passante pour accumuler toutes ces données qui viennent parfois de partout dans le monde vers un seul data center. C’est dans ce genre de cas où peut intervenir le concept de Edge Computing. L’idée derrière le terme est d’effectuer les calculs directement au niveau des équipements distants, ou sur un serveur co-localisé, plutôt que sur un serveur central. Cela permet de réduire sa consommation en bande passante et en puissance de calcul dans le datacenter.

Transformer la contrainte en opportunité

Toutes ces optimisations, qui s’apparentent en premier lieu à des contraintes, ne sont pas uniquement bonnes pour l'empreinte carbone du projet ou de l’entreprise. Le client va sentir des améliorations sur différents aspects : rapidité des traitements, optimisation du stockage des données et surtout réduction des coûts de la plateforme grâce aux différentes optimisations effectuées.

Conclusion

Nous vivons dans un monde qui se transforme. Les plus grandes manifestations actuelles et les plus grandes préoccupations de notre temps devraient se concentrer sur le climat et sa protection. Nous avons aussi un rôle à jouer et cela n’est pas incompatible avec nos travaux. Tout le monde peut agir à son échelle, et on peut changer les choses.

Nous avons maintenant accès, grâce au cloud, à énormément de puissance de calcul et de stockage, le tout à des prix plus que corrects. Pourtant, ces technologies ne sont pas sans conséquences sur notre environnement. Nous devons donc, en tant qu’architecte, les utiliser avec parcimonie. Un grand pouvoir implique de grandes responsabilités.

Pour que le Green IT ne reste pas qu’un faire-valoir, pensez-y lors de vos prochaines études d’architecture de données, cela vous apportera plus qu’une bonne conscience.

Plongée subjective au sein des craftsmen bordelais

Le Software Craftsmanship... Ce mouvement qui aborde le métier de développeur comme celui d’un artisan du logiciel, au sens noble du terme. A l’image du Compagnonnage, il nous incite à bâtir nos cathédrales logicielles - ou plutôt nos chapelles, restons modestes - avec technicité, goût du travail bien fait, souci du détail. Le tout avec bienveilance et désir de partage. En somme, il s’agit d’aborder notre métier comme un esthète.

A Bordeaux, la conférence NewCrafts, propulsée par l’association Okiwi, s’inscrit dans ce mouvement. Ippon est partenaire de l’évènement. En voici un témoignage quelque peu subjectif.

Jour 1 - 04/10/2019

8h52, Cité Mondiale, quai des Chartrons. L’ensemble architectural en arc de cercle entièrement vitré, plus habitué aux costumes bancaires 3 pièces, semble aujourd’hui surpris de refléter le triptyque vestimentaire majoritaire : sneakers/jean délavé/polo. Manifestement les crafstmen sont aussi venus pour redéfinir les bonnes pratiques du dress code.

Follow the white rabbitMQ Alice... Quelque pas sur le parvis, première porte coulissante gauche, un escalator bruyant et des murs kaléidoscopiques nous accompagnent jusqu’au sous-sol (l’IT c’est toujours au sous-sol !). Remise de badge en 2-2, café en une gorgée, rafle de quelques goodies, direction l’amphi. On s’affale sur les beaux sièges rouges et relâche les muscles pour laisser un maximum de débit au canal [tympan-cerveau].

9h00. Ouf. Nous voici fins prêts pour la keynote… In English sir ! Oui. Jean-Baptiste Dusseaut nous explique qu’aujourd’hui we re only gonna talk in English to respect all the speakers ! Les crafteux bordelais s’ouvrent au monde entier…

09:15 Felienne Hermans - How to teach programming (and other things)?

Fraîchement diplômée, Felienne a accepté un poste de professeur de code pour des enfants d’une dizaine d’années. Elle s’est donc naturellement interrogée sur le « how to teach code».

L’approche de son talk est simple : faire part de ses lectures sur le sujet, puis de son expérience. Elle commence donc par présenter et opposer certains courants de pensée en psychologie sur les méthodes d’apprentissage. Cite notamment Piaget et le constructivisme (laisser expérimenter sans guider). Empiriquement, elle retient un mode plus didactique (notamment la théorie par l’exemple). Elle souligne également certaines disparités en termes d’apprentissage : le déterminisme sexuel face à l’apprentissage des sciences, le contexte environnemental (notamment l’influence de la langue maternelle).

En résumé ? Pas encore de solution miracle à appliquer, les rouages du cercle vertueux motivation - skill restent à définir, voire à adapter à chaque élève…

Une heure qui passe vite, un support illustré agréable par son dépouillement et ses dessins enfantins. On sent beaucoup de bienveillance chez Felienne. Après debrief collégial, un des talks les plus appréciés de la journée.

10:15 James Watson - Building Resilient Event-Driven Services

Tout de flegme britannique vêtu, James nous présente l’architecture mise en place chez Adaptive pour adresser un besoin métier spécifique : le trading financier. Simplicité et separation of concern sont les maîtres mot dans un contexte à fortes contraintes techniques (traffic réseau conséquent, haute concurrence, obligations fortes de résilience et de rejeu, etc..). La solution est basée sur la librairie de messaging open source Aeron.

Cela fonctionne bien nous dit-il. Nous le croyons sur parole.

Pour information, une bonne introduction sur ces concepts est également disponible en français, par 2 membres organisateurs de l’évènement NewCrafts Bordeaux (tiens tiens…). C’est ici.

11:30 Kate Carruthers : Digital and Data Ethics - the Emerging Battleground

Kate présente ses travaux et ses convictions sur le sujet épineux de l’éthique dans les technologies émergentes, notamment sur la gestion de la donnée (big data), ou sur le pouvoir de décision laissé aux machines (IA, Bots, …).

Sur ce sujet, elle oppose clairement le courant libéral venu des Etats Unis (no control) avec le désir de régulation du reste du monde (exemple : RGPD européen). En tant que consultante pour le gouvernement australien, elle travaille sur la mise en place de chartes de bonne conduite.

Des slides très fournies, parfois impossibles à déchiffrer, mais un discours cohérent pour un message clair : sur le sujet de l’éthique, nos institutions centenaires doivent s’adapter rapidement face à des technologies de plus en plus prégnantes.

On le pressent bien : tout reste à faire.

13:30 Cyrille Martraire - modelling music for DDD practitioners.

Quoi de mieux qu’un peu de musique pour accompagner la digestion !

Cyrille présente sa création originale DIY de « guitare-piano » (1000 excuses, le nom officiel de cette création est passé aux oubliettes de ma mémoire) basée sur un arduino enveloppé dans une salière, un manche à balai et une led. Tant d’effort pour allier ses 2 passions : musique et DDD !

Il retrace habilement un pan de l’Histoire de la Musique pop du 20ème siècle : la miniaturisation des claviers jusqu’à l’avènement des synthétiseurs. Du piano à queue au moog, du monumental orgue d’église à l’orgue hammond, du mellotron au sampler. Il cite également l’apparition de la guitare amplifiée (Sans citer l’originelle Kinks - You Really Got Me ? Allez on lui pardonne…) et des nouvelles variantes de son qu’elle apporte avec ses pédales à effets. Une grande introduction qui pointe la face cachée de l’Histoire de la pop music : les tournées, ses road trips interminables, ses mini-vans inconfortables, son déballage quotidien de matos, et les tours de reins qui en découlent! Ce désir de portabilité qui a poussé à l’abstraction des concepts musicaux. Ou comment une révolution technologique a accompagné la propagation d’une révolution culturelle. Rien que ça...

Et nous dans cette histoire ? Une grande part de notre métier ne consiste qu’en cela : modéliser. Tout peut être considéré comme Domain. La musique ne déroge pas à cette règle : une mélodie peut être vue comme un ensemble de bounded contexts telle que la fréquence, la distorsion, etc. Avec le protocole MIDI comme contrat d’interface. L’instrument de Cyrille, si drôle soit-il, en témoigne.

Une conf énergique bourrée d’humour, vidéos youtube et pas de danse improbables à l’appui. Cyrille finit même par une roulade sur scène. On se marre et l’esprit se dévergonde, crée un lien improbable avec Boris Vian, son piano-cocktail (non modélisé à ce jour, avis aux amateurs) et ses fantaisies verbales. Au point de proposer un néologisme en guise de conclusion. Voici donc le refrainzumé (le résumé du talk par un refrain) :
Le DDD n’est qu’une excuse
Pour que Cyrille s’amuse

14:25 Bodil Stokke – Meeting with remarkable tries

A l’heure de la sieste, rien de mieux qu’une conférence sur les structures de données et leur efficience en termes de complexité de parcours, d’indexation, de coûts d’insertion, de split ou de jointures.

Bodil évoque le RRB tree (“relaxed radix balanced tree”), amélioration des Hickey trie ou autre Finger trees. Des implémentations RUST, Clojure existent déjà.

Outre la beauté du geste, l’enjeu est entre autres l’optimisation des coûts de l’immutabilité dans la programmation fonctionnelle. Sujet technico-technique s’il en est, l’exploit de Bodil est de vulgariser les travaux de recherche sur ces concepts de listes à travers des diagrammes simples à appréhender.

15:40 Emilien Pécoul - Category Theory: You Already Know It

Category theory ? Le nom peut faire peur aux non "matheux"… Une conférence pour vulgariser les concepts de base de cette théorie. On se rassure en découvrant que, comme Monsieur Jourdain pour la prose, nous utilisons déjà des monoïdes sans le savoir !

L’idée générale est de donner envie de creuser cette théorie (programmation fonctionnelle encore). Contrat rempli Emilien, nous y allons de ce clic.

16:40 Woody Zuill – Practical refactoring

Daddy, daddy Zuill, le papa du #noestimate et du mob programming, nous présente quelques concepts clés de refactoring sur du code legacy. Le tout en live coding.

Rien de bien nouveau, basé sur des principes déjà ouvragés et référencés*, eux-mêmes basés sur beaucoup de bon sens. La magie opère quand même. Woody est très drôle, Woody est humain. (« I miss my wife », attendant la fin de l’exécution des tests).

Un vrai show. On en aurait bien pris une ration horaire de plus !

*Refactoring: Improving the Design of Existing Code – Martin Fowler / Kent Beck

Jour 2 - 04/10/2019

Open forum time ! Idée originale s’il en est, la seconde journée s’articule autour d’une idée centrale : autonomie et partage. Ou comment les participants deviennent pleinement acteurs de l’évènement.

Le warm up commence donc autour d’un tableau : chaque participant peut proposer un/des sujet(s), le présente aux autres, choisit un créneau horaire et une salle. Libre à chacun d’y adhérer, de changer de salle en cours de route.

Seule obligation : soyons bienveillants, n’ayons l’air de rien.

En vrac : on évoque la programmation fonctionnelle dans nos langages objet traditionnels (.net, java), du bon usage des interface en POO, de nos relations en open space sous le prisme des théories de Bourdieu, des tricks des personnes habitués à dispenser des formations, de la mise en place du mob programming dans une équipe…

Conclusion

Deux jours denses, des conférences peuplées de passionnés prêts à échanger, entre l’infiniment grand (le recul sur notre métier, l’impact de ce que nous sommes en train de créer) et l’infiniment petit (focus techniques pointus).

Avec en trame de fond cette quête permanente : l’amélioration continue.

A l’année prochaine NewCrafts.

Chers recruteurs,

Tout comme vous, mon métier est de trouver les bons candidats pour les bons postes et de faire du matching qualitatif. Et dans le secteur pénurique de l’IT, ce n’est pas toujours facile de faire la différence parmi les dizaines de messages hebdomadaires reçus par les candidats !

L’enjeu est d’autant plus considérable qu’aujourd’hui tout est histoire de “communication” et de “rating”. Trop nombreux sont les messages de recruteurs postés sur LinkedIn par des candidats mécontents de l’approche. Certains se disent spammés par des messages copiés-collés où parfois le poste proposé n’a même aucun lien avec leurs missions. Et trop nombreux sont les mauvais commentaires trouvés sur des plateformes de notations relatant les mauvaises expériences candidat. Il faut se rappeler que toutes les prises de contact que nous faisons sont importantes.

Rappelez-vous de votre réaction la dernière fois qu’on vous a appelé par le mauvais prénom si vous avez encore des doutes sur le sujet ;)

Chers recruteurs repensez :

• à toutes ces heures passées sur LinkedIn à utiliser tous vos crédits d’Inmails sans réponse en retour ;
• à ces candidatures reçues avec pour message “PI voici mon CV” ;
• à la frustration de recevoir un CV de coach sportif pour un poste de coach agile ou encore un CV d’architecte d’intérieur pour un poste d’architecte cloud ;
• à l’état de détresse quand vous avez découvert une candidature “d’expert en snacks” parce que vous avez tenté une annonce au 2nd degré avec une référence à la tradition de la Pizzeria du vendredi midi ;
• à l’ascenseur émotionnel quand un candidat postule puis ne donne plus signe de vie ;
• ou encore à la fois où un autre recruteur vous a contacté pour un poste de Développeur Java... (Cela m’est arrivé il y a quelques jours mais j’ai préféré ne pas donner suite pour éviter un arrêt cardiaque au recruteur à la lecture du test technique !)  
  

Alors, au lieu de devenir scénaristes d’un nouvel épisode de Black Mirror, si nous ajoutions un peu plus d’humain et de valeur à nos prises de contact ?

Gardons en tête qu’en tant que recruteur, notre objectif est d’améliorer notre taux de transformation, c’est-à-dire augmenter le nombre de réponses aux messages envoyés. #LeGraalDuSourceur

C’est tellement contrariant de ne pas recevoir de réponse à sa candidature ou à son dernier Inmail LinkedIn.  On a l’impression que :

• Réponse A - Ce que je propose ne les intéresse pas, et puis c’est vrai, je n’aurais jamais dû contacter cette personne #Quelqu’unVeutUnCurly ?
• Réponse B - Les recruteurs et les candidats ne répondent jamais de toute façon ! #TousLesMêmes
• Réponse C - Mon message n’a peut-être pas été reçu ?! #LinkedInEtGmailSontContreMoi

Et si la réponse était tout simplement “Mon message ne les a pas accrochés !”.

Promis c’était la seule interrogation écrite de cet article, vous pouvez poser les stylos :)

Nous allons voir comment engager ces prises de contact que ce soit sur LinkedIn, Twitter, via les Cvthèques ou même via des forums virtuels. L’outil importe peu mais la démarche, elle, oui !!! Nous nous mettrons à la place de Pierre qui, en tant que candidat, cherche lui aussi à avoir des réponses à ses messages. Nous aborderons également le pouvoir des réponses négatives à nos messages d’approche et l’importance des relances dans notre démarche. Enfin, on poussera la réflexion avec quelques astuces pour recevoir des réponses qualitatives. Nous verrons que bien qu’on ait des objectifs ambitieux ; on tire de nos “essais” de belles success stories :)

La prise de contact

Pour commencer, lorsque nous décidons de contacter quelqu’un, il s’agit d’un acte volontaire où l’on vient solliciter la personne pour une raison bien précise. (Cela implique que nous n’aborderons pas dans cet article le cas où c’est la personne ciblée qui vient d’elle-même nous solliciter). La 1ère question à se poser est donc : quand nous contactons quelqu’un par message, téléphone ou que nous rencontrons quelqu’un à un événement, comment démarrer la conversation ?

Rappelons-nous que la première impression est celle qui va faire toute la différence sur la suite de notre échange. Saluer, se présenter et initier l’échange avec enthousiasme et respect sont donc les premières étapes à mettre en œuvre.

Jusque là, pas de réelle difficulté, mais la vraie question c’est : comment échanger ?

Tout d’abord il est primordial de s’intéresser à la personne à laquelle nous écrivons :

• Pourquoi lui écrire à elle en particulier et pas à une autre ?
• En quoi ce qu’elle fait ou a réalisé nous intéresse ?
• Que veut-elle faire dans le futur ? Quel est son projet professionnel ?

Pour cela, le mieux c’est de recueillir le maximum d’éléments en amont en se posant la question : “pourquoi je contacte cette personne ?”.

Son profil LinkedIn, son compte GitHub, ses tweets, ses publications ou tout simplement son CV en ligne sont d’excellents contenus pour vous assurer que c’est bien la bonne personne à contacter mais également pour apporter de la valeur à votre message. En tant que recruteur, nous vérifions pourquoi un candidat postule dans notre société et pas dans une autre. Dans le cas inverse, c’est la même chose, le candidat doit savoir pourquoi nous le contactons lui spécifiquement.

Exemple de mauvaise pratique partagée par un collègue :

L’autre élément à apporter est “qui sommes-nous ?”. Partons du principe que le candidat ne nous connaît pas et/ou ne connaît pas notre entreprise. Il est important de lui donner de la visibilité sur le métier de la société en lui épargnant le “bla bla” générique. Mettons-nous à sa place : “si j’occupais ce poste qu’est-ce qui m’intéresserait et me donnerait envie d’échanger avec ce recruteur ?”. L’idée est de personnaliser votre message. Si le candidat ciblé travaille sur des architectures cloud, les formations en UX design ne sont peut-être pas primordiales à évoquer dans un premier temps (encore qu’on pourrait ouvrir le débat... ;)).

Inversons les rôles 5 minutes pour bien comprendre les enjeux et remémorons-nous les conseils donnés aux candidats qui sont en train de rédiger leur mail de candidature. Prenons l’exemple de Pierre.

L’histoire de Pierre : recruteur-candidat même combat !

Pierre est développeur à Montpellier, il a mis à jour son CV, il a le poste de ses rêves en tête et différentes sociétés où l’exercer alors il n’y a plus qu’à…

Le 1er conseil de recruteur qu’on aurait envie de lui donner pour sa candidature serait de se renseigner sur la société pour laquelle il postule et de prendre note de ce qui a particulièrement retenu son attention.

Il est important de rappeler que le simple fait que la société existe dans son domaine et sa localisation ne peut pas constituer un argument valable à sa prise de contact. En tant que recruteur on parle de véritable motivation ! En cas de doute, demandez-lui s’il aimerait être contacté par un recruteur uniquement parce qu’il vit à Montpellier et qu’il a déjà fait du développement ? ;)

Le 2ème conseil qu’on peut lui apporter est de formaliser par écrit sa projection au sein de la société pour laquelle il postule : Qu’est-ce que Pierre a envie d’apporter ? Qu’est-ce qu’il attend de cette entreprise ? Qu’est-ce qu’il souhaite y faire ?

Trop nombreux sont les messages avec pour contenu “Voici ma candidature” comme si le message était juste informatif. Plus sérieusement les questions qu’on se pose en tant que recruteur sont “Une candidature à quoi ? Pour quelle agence ? J’en fais quoi ?”.

Il est important que Pierre soit précis dans ce qu’il recherche, avec à minima le poste, la localisation et ce qui l’anime au quotidien.

Pierre ne doit pas hésiter à évoquer ce qui le caractérise VRAIMENT ! Les messages génériques ne mettront pas en valeur sa motivation. Donc autant éviter les copiés-collés standards.

Se cacher derrière trop de généralités pour ne pas se dévoiler est inutile, on découvrira bien son “dark side” à un moment ou à un autre de toute façon… :p

Pour le contenu, Pierre a tout intérêt à mettre en valeur ses expériences et ses projets en lien avec le poste et la société. L’objectif est de voir si le matching est le bon entre la société, le poste et lui.

Pierre se demande s’il peut ajouter une touche d’originalité ? Oui, c’est possible avec maîtrise, en gardant en tête qu’il faut garder une approche professionnelle.

Mettre des photos de lui avec son chien derrière son CV et écrire qu’il chausse du 43 n’apporte peut-être pas la valeur recherchée #TrueStory.

Tout ça pour dire que, pour vous chers recruteurs qui êtes en quête de la manière de travailler vos messages d’accroche, les mêmes principes s’appliquent ! Vous êtes dans une situation comparable à celle de Pierre qui réfléchit à son mail de candidature ; vous devez susciter l’intérêt en peu de caractères avec cohérence. Appuyez-vous sur ce que vous avez à proposer: un poste, une entreprise, des méthodologies, un environnement de travail, une équipe, une culture, de l’accompagnement, un projet de carrière, des valeurs, un sens !

Le pouvoir des réponses négatives

En tant que recruteurs, nous ne sommes pas pour autant des surhommes ou des médiums, et il y a des variables que nous ne pouvons connaître : la situation personnelle du candidat, comment il se sent dans sa société actuelle, son lien avec son manager, son évolution en cours etc. Donc il nous arrive bien souvent d’avoir des retours négatifs aux messages d’accroche envoyés.

Trop souvent négligés, ils ont une réelle valeur. Un candidat qui répond est un candidat qui donne de l’importance à votre démarche et qui prend le temps d’y donner suite. Le contenu de votre message initial est donc celui qui va susciter l’intérêt du candidat et lui donner l’envie ou non de vous répondre.

Ce n’est donc pas une fatalité, bien au contraire, vous venez d’engager le début d’une relation avec le candidat grâce à un message travaillé. Et il ne faut pas se cacher combien c’est gratifiant de recevoir un message de remerciement pour la qualité de notre message ;)

En voici quelques exemples : #TrueStory

Un message qui arrive quand on a pas assez travaillé et personnalisé son approche!

• Un commentaire live de cet article en relecture par un collaborateur!

• Le plus courant...
  

Il ne reste qu’à garder contact, suivre la personne, se mettre une alerte et la rappeler plus tard, lui transmettre du contenu, l’inviter à des événements…

• Celui qu’on vise: le message qui nous rappelle pourquoi on se lève le matin et on fait ce métier !
  

La réponse négative est déjà un beau pas en avant qui va vous permettre de rester en contact avec cette personne, la suivre dans son évolution, et c’est certainement ce message qui la fera vous rappeler au moment opportun.

Ne perdons pas espoir, une réponse négative est donc bien un début de réponse positive :)

Relances ou pas relances ?

Si vous ne recevez pas de réponse à votre message ou que, comme évoqué précédemment, la réponse est négative, il y a plusieurs raisons possibles. L’une d’elle peut être que la personne n’est pas intéressée car pas en recherche d’un nouvel emploi ou encore que le message n’a pas accroché suffisamment la personne. Dans tous les cas, relancer est signe d’intérêt et permettra au candidat de vous avoir en tête.

Soyons néanmoins vigilants : “relancer” ne veut pas dire “harceler”, il est important de respecter un délai raisonnable entre vos messages et d’appliquer la règle de “contenu de valeur” dans chacun d’eux. C’est en persévérant qu’on y arrive !

Et c’est possible !

Grâce à des prises de contacts et des suivis réguliers, un candidat est revenu vers moi au bout d’un an et c’est lui qui m’a rappelé au moment où il envisageait de changer de poste !

Je ne sais pas si cela a un lien avec la fameuse règle des “5 contacts pour retenir l’attention de son interlocuteur” mais ce qui est sûr c’est qu’il se rappelait de la société et de mes messages.

Une autre belle histoire à partager : suite à différents échanges et invitations aux événements, l’équipe Ippon est heureuse d’accueillir prochainement un nouveau collaborateur ; vous le trouverez bientôt suite à la mise à jour de son profil LinkedIn ;)

Et si nous prenions donc un peu plus de temps pour nous intéresser non seulement à la personne contactée mais également à la relancer ! C’est capitaliser sur la suite de vos relations et également contribuer au développement de votre réseau.

Enfin, après avoir abordé l’impact de la prise de contact, des réponses négatives et des relances, il reste l’ultime question : comment allons-nous transformer nos messages en retours positifs des candidats ?

Quelques astuces pour des réponses qualitatives

Voici donc quelques bonnes pratiques que je vous propose après expérimentation et échanges avec d’autres recruteurs qui pourront vous aider dans la transformation de vos messages en réponses qualitatives ET positives :

1. Stop au mass mailing ! 200 personnes ne peuvent pas correspondre au poste que vous proposez juste en raison d’un mot clé qu’ils ont tous en commun sur leur profil LinkedIn. En revanche, cibler la bonne personne avec un message personnalisé est une bonne pratique, et ça fonctionne !

Si vous avez fait la même école ou été tous les deux en Australie, pourquoi ne pas faire le lien ?

2) Vous avez rédigé une fiche de poste ? Cela signifie que la recherche est ciblée, ciblez donc la bonne personne et adressez-vous à elle spécifiquement :)

3) Projetez-vous avec cette personne : Que pouvez-vous lui apporter en tant qu’entreprise ? Qu’est-ce qui l’intéresserait d’après son profil ? Et comment, selon vous, aimerait-elle être abordée ? Lisez attentivement son profil et ses potentiels articles, et essayez de vous mettre à sa place. Parlez projet, carrière et évolution !

4) Soyez humain et n’hésitez pas à désacraliser la prise de contact. C’est un échange, rien de plus ! Si vous voulez commencer votre message par une anecdote qui vous correspond (bienveillance avant tout), n’hésitez pas et surtout faites-vous plaisir en écrivant !

5) Si vous utilisez des termes techniques, maîtrisez-les un minimum et vérifiez que l’orthographe est la bonne! Soyez un peu curieux et renseignez-vous sur les compétences que vous recherchez.

6) Un peu de fun ? Oui, pourquoi pas, mais attention, on reste pro. Le fun c’est bien mais cela n’a aucune valeur si les motivations du candidat ne sont pas nourries. La recherche d’accomplissement est l’un des besoins majeurs des collaborateurs. Un candidat vient au travail pour apporter de la valeur, de l’expertise, de l’impact… et si c’est en s’amusant c’est encore mieux! Si on décide d’employer le tutoiement, on sait l’assumer et garder une relation professionnelle pour autant.

7) Parler du dernier baby-foot de l’agence ? C’est surfait ! On veut du contenu, du vrai ! Le leitmotiv d’un candidat n’est pas un baby-foot...

Sauf si vous vous adressez à un candidat qui comme Pierre a failli postuler uniquement car le poste existait dans son domaine et sa localisation. Dans ce cas le baby-foot sera un vrai plus :p #Troll C’est pour voir si vous suivez toujours.

Plus sérieusement, parlez du poste, du contexte, de l’équipe, des dernières actualités, de votre propre expérience dans l’entreprise. Donnez également du contenu : partagez un livre blanc qui peut l’intéresser, un article, le dernier event où vous étiez… Et votre message prendra une toute autre tournure et une toute autre valeur.

8) En bonus : on arrête la surenchère des références à Star Wars dans nos messages d’accroche.

Et oui “le dark side of the force” de Pierre en fait partie... sorry je n’ai pas pu résister ^^

En conclusion, il ne faut pas oublier que solliciter quelqu’un reste un début d’échange ; donc “donnez de vous pour recevoir”. Pour cela, parlez de vous, livrez-vous un peu mais intéressez-vous également à la personne en face.

N’oubliez pas qu’on est tous humains : vous pouvez parler de vous sans que cela se termine en monologue ;). Et surtout, gardez en tête la valeur que vous apportez en écrivant et assurez un suivi dans les échanges que vous entreprenez ; n’hésitez pas à relancer !

Ce que j’aime chez Ippon, en tant que recruteur, c’est que nous croyons à des messages de qualité et préférons prendre du temps pour identifier les bonnes personnes.

Attention, BIENVEILLANCE avant tout !!! L’erreur est humaine. Restons réaliste et ne nions pas les copiés-collés qu’on a tous fait un jour. #MeaCulpa de recruteur : c’est en faisant des erreurs qu’on progresse ! Retenons que prendre le temps nécessaire ne nous fera pas perdre en résultat, bien au contraire. Il faut se l’avouer, notre métier c’est de l’humain, et non pas de rédiger des messages standards toute la journée !

Chers recruteurs, vous en avez marre des CVs sans âme .... soignez vos messages ... même combat !

Il y aurait bien des choses à dire sur le sujet alors n’hésitez pas à compléter, partager vos commentaires et vos retours d’expérience !

Anne-Cécile Réglier

Références photos:

Images Unspalsh

Image carrière

Image Spam

Image fun au travail

Image cadeau

Les formulaires se trouvent dans la plupart des applications web. Utilisés pour recueillir vos données (pour les revendre ensuite?), ils sont un des points d’entrée des informations dans un système informatique.

Le framework Angular permet d’ailleurs de gérer les formulaires de deux manières

• Les template driven forms, une approche orientée vue plutôt pour les formulaires simples
• Les reactive forms, plus orientés composant
  

Cet article abordera la manière dont Angular vous permet d’intégrer vos composants au sein de ces deux approches, grâce à l’interface ControlValueAccessor d’Angular.

Pizza Hat

Chez Pizza Hat on en est convaincu, une révolution est à venir dans le monde de la pizza. Au pôle marketing d’ailleurs on croit avoir trouvé une ‘key-feature’ qui pourrait mener à bien cette révolution...

Cette fonctionnalité en question, pensée pour être raccord avec le nom de l’enseigne, se trouve simple et originale. Plutôt qu’une liste déroulante, ennuyante au possible, avec les mots “petite”, “moyenne” et “large” pour sélectionner la taille de la pizza, les utilisateurs de l’application cliqueront sur des chapeaux !

Comme ce choix de design sera sûrement amené à être utilisé dans plusieurs formulaires au sein de l’application, le développeur en charge décide d’en faire un composant Angular pour la réutilisabilité : bonne idée !

Sans ControlValueAccessor

Pour l’utiliser dans son formulaire, il décide dans une première ébauche d’utiliser ce qu’il a appris dans l’interaction entre les composants.

Grâce aux notions d’input et d’output d’un composant, il arrive à produire le résultat voulu : le composant parent donne la valeur au composant fils et quand l’utilisateur change la valeur du composant fils, celui-ci envoie un événement pour notifier le parent de se mettre à jour.

En regardant le résultat, le développeur n’est pas très convaincu. En effet, il doit écrire un code spécifique pour associer la valeur de son formulaire à son composant alors qu’au final son composant est juste un input, pas standardisé par le W3C d’accord, mais un input quand même.

En approfondissant un peu la doc, il se rend compte qu’Angular a créé une interface pour adresser ce genre de problème : ControlValueAccessor ou CVA pour les intimes.

Avec ControlValueAccessor

L’interface ControlValueAccessor va servir de pont entre votre composant et l’API de gestion de formulaire d’Angular. Votre composant devra implémenter 3 fonctions :

• writeValue(obj: any): void

Le framework appelle cette fonction quand une nouvelle valeur (qui est passée en paramètre) est affectée à votre composant. A vous de changer l'état de votre composant pour refléter cette nouvelle valeur

• registerOnChange(fn: any): void

Le framework appelle cette fonction lors de l’initialisation de votre composant, le paramètre envoyé est une fonction de callback que vous devrez appeler, quand votre composant change de valeur (suite à un input utilisateur)

• registerOnTouched(fn: any): void

Le framework appelle cette fonction lors de l’initialisation de votre composant, le paramètre envoyé est une fonction de callback que vous devrez appeler quand votre composant a été touché par l’utilisateur. Cela servira à Angular pour gérer le flag “touched” du FormControl

Après réécriture voici à quoi ressemble maintenant notre composant :

Plusieurs changements au niveau du composant :

providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      multi: true,
      useExisting: PizzaSizeSelectionComponent,
    }
  ]

On est obligé de rajouter ce bout de code afin de dire au framework que notre composant implémente bien l’interface, et donc lorsqu’il le croisera pendant le rendu de la page, il pourra appeler les méthodes que nous avons définies.

@HostListener('click') hostTouched() {
    if (this.onTouched) {
      this.onTouched();
    }
  }

Nous avons défini une fonction hostTouched, qui sera appelée à chaque clic sur notre composant (grâce au décorateur HostListener) et si nous avons réussi à capturer la fonction passée en paramètre de registerOnTouched, alors nous l’appelons.

Pour le reste nous utilisons un BehaviorSubject afin de gérer le changement de valeur au sein de notre composant. Lorsque Angular nous pousse une valeur, nous l’ajoutons au BehaviorSubject grâce à la méthode next et nous faisons de même lorsque l’utilisateur clique sur une des vignettes avec le code suivant dans le HTML (click)="currentValue.next('medium')"

A présent notre composant peut être utilisé comme n’importe quel input, notre HTML niveau formulaire devient donc :

<app-pizza-size-selection formControlName="pizzaSize"></app-pizza-size-selection>

A noter que le formulaire présenté ici utilise l’approche “reactive form” mais nous pourrions très bien utiliser l’approche “template driven” en utilisant le fameuse directive ngModel sur notre composant

<app-pizza-size-selection [(ngModel)]="pizzaSize"></app-pizza-size-selection>

Le MVP est prêt à partir en prod, plus qu'à trouver un pizzaïolo !

Cette douce matinée de novembre s’annonce comme un matin de Noël : la preview de Spark 3.0 est sortie ! Je me demandais justement quand Spark allait sortir des nouveautés qui révolutionneraient le monde de la Data ! Ni une ni deux, je m’empresse d’aller sur la page annonçant les nouveautés : https://spark.apache.org/news/spark-3.0.0-preview.html. Ça y est, je vois une liste peu facile à lire : des changements, accompagnés des liens Jira (me rappelant des souvenirs douloureux). Café, stand-up meeting, réunions et aucune envie de me plonger dans le Jira de Spark, je procrastine et j’abandonne …

Disclaimer : La version de Spark 3.0 dont cet article traite est une preview, donc pas stable et susceptible de changer.

Langages

Spark s’appuie désormais sur scala 2.12.x (enfin !). Java 8 (8u92+) et 11 peuvent être utilisés. Quand on connaît le rythme de releases de Java, ces nouvelles sont les bienvenues si on ne veut pas travailler avec une version obsolète. Cependant d’après l’issue Jira ayant pour but de tester Spark avec le JDK 11, le travail est toujours en cours. Python 2 est déprécié ainsi que les versions de Python 3 inférieures à la 3.6.

Dynamic Partition Pruning (DPP)

Outch, on arrive dans le vif du sujet : les performances de Spark. L’idée, comme beaucoup d’optimisations derrière Spark, est de lire le moins de données possible afin d’optimiser les traitements. Le DPP est très utile pour des jobs de BI.

Imaginons la requête suivante :

SELECT city.name, citizen.name
FROM city
  JOIN citizen
  ON city.id = citizen.city_id
  WHERE city.pop > 1000

En BI classique, on dirait que city est la table de dimension et citizen la table de fait. Avec un Spark < 3, un filtre serait appliqué sur la table city puis le join des deux tables serait effectué.

Avec Spark 3, le filtre est appliqué sur city puis envoyé dynamiquement aux partitions de la table citizen et enfin le join est appliqué.

Il y a donc moins d’échanges de données et de traitements !

Attention, cette amélioration est uniquement valable dans le cas où la clé de jointure est la clé de partitionnement de la table de fait.

Exécution adaptative

Par défaut, Spark broadcastait sur les noeuds les Datasets inférieurs à 10MB (paramètre modifiable avec spark.sql.conf.autoBroadcastJoinThreshold). Pour effectuer ces broadcasts automatiquement, il se fiait aux statistiques présentes sur les sources utilisées. Seulement certaines sources avaient des statistiques fausses ou inexistantes, et donc le broadcast n’était pas prévu dans le plan d’exécution. Avec l’exécution adaptative, Spark se donne le droit de modifier son plan d’exécution au runtime en analysant ces datasets et en les broadcastant si possible.

Data Source V2

Ce type de Data Source est disponible depuis la version 2.3.0, donc pas si nouveau que ça mais le but est sa démocratisation en Spark 3.Voilà quelques point intéressants.

• Pluggable Data Catalog : En plus de lire des données directement, Spark peut désormais se référer au DataCatalog présent dans votre environnement.
• Le filtre pushdown et la gestion de partitionnement sont améliorés.
• La possibilité d’écrire les données de façon transactionnelle est ajoutée.
• Le streaming et le batch possèdent exactement la même API.

Pour plus d’informations sur la Data Source V2, je vous conseille ce talk (Spark Summit 2018) : Apache Spark Data Source V2.

Delta Lake

Disponible à partir de la 2.4.2, il ne faut pas attendre la version 3 pour commencer l’utilisation de Delta Lake. La mise en valeur de celui-ci est faite dans Spark 3. Ce sujet mériterait un article à lui seul. C’est une vraie amélioration rendant l’utilisation de Spark plus simple et donc plus abordable. En plus d’être open-source, Delta Lake a rejoint la fondation Linux.

Delta Lake permet de rendre un Data Lake requêtable de manière ACID. Il est donc désormais possible de travailler à plusieurs sur les mêmes données sans se soucier de la consistance et aussi d’upserter des données par exemple. Un journal de logs permet de tracer les données et de ne les modifier qu’une fois la transaction finie. Ainsi, on peut désormais alimenter le Data Lake en batch et en streaming sans avoir à maintenir une architecture lambda complexe.

Bref, Delta Lake est grossièrement une couche d’abstraction qui permet à un Data Lake de ressembler à une base de données. La concurrence des Data Warehouses comme Snowflake oblige Spark, et donc Databricks, à faire évoluer le produit pour qu’il englobe plus de cas d’utilisation.

Pour plus de détails, un Webinar sur Delta Lake a été fait chez Ippon ici.

Koalas

Pandas c’est bien, Koalas c’est mieux. Koalas est une librairie Python imitant Pandas fonctionnant sur du PySpark, donc en ajoutant une couche distribuée. Ainsi Data Scientists et Data Engineers marcheront main dans la main heureux. Néanmoins, Koalas n’embarque pas toutes les fonctionnalités de Pandas. Les fonctions les plus communes de Pandas sont implémentées dans Koalas, mais il reste du travail. Les “Insights” prometteurs sur Github laissent à penser qu’il s’agit d’un projet qui s’améliorera rapidement.

Performances de PySpark

Dans cette version, les développeurs de Spark ont beaucoup travaillé sur une meilleure intégration d’Apache Arrow. Et pour cause, plus de cinq pages de tickets Jira sont sur Arrow. Il s’agit d’un projet Apache offrant un format de données colonne stocké dans la RAM. Il permet à plusieurs composantes de communiquer de manière efficace et rapide. L’objectif final est d’améliorer les performances des échanges entre les jobs Python et la JVM.

Formats binaires

Nos amis Data Scientists seront contents car avec cette version de Spark apparait aussi la manipulation de formats binaires (images, vidéos …).

Petit exemple de code :

val df = spark
  .read
  .format("binaryFile")
  .option("pathGlobFilter","*.jpg")
  .load("/path")

À noter l’option pathGlobFilter permettant d’utiliser des regex sur des fichiers sans avoir à la mettre dans le load.

En sortie on aura un DataFrame contenant les données brutes et les metadata :

scala> df.printSchema
root
 |-- path: string (nullable = true)
 |-- modificationTime: timestamp (nullable = true)
 |-- length: long (nullable = true)
 |-- content: binary (nullable = true)

Petit hic, on ne peut pas écrire de formats binaires pour le moment.

GPU

Au travers de cette nouvelle sortie, Spark tente de rattraper ses concurrents sur la Data Science. La preuve en est avec cette nouvelle fonctionnalité permettant d’utiliser plusieurs GPU (AMD, Nvidia et Intel) en parallèle.

Cluster Manager

Les clusters managers ont aussi leur lot de nouveautés. La dernière version de Kubernetes est désormais utilisable. L’évolution la plus notable de cette release est l’allocation dynamique. L’intégration de Kerberos, l’utilisation des GPU des pods sont des améliorations notables de cette version.

Web UI

Dans cette version de Spark, de la documentation sur l’interface web de Spark a été ajoutée. Alors oui, ce n’est pas une nouvelle fonctionnalité en soit, mais qui ne s’est jamais arraché les cheveux devant cette interface ? On n’aura plus d’excuses maintenant.

SparkGraph

La version 3 de Spark introduit également SparkGraph, améliorant l’utilisation des Graphes. Il permet d’utiliser le Cypher Query Language développé par Neo4J dans Spark. Des algorithmes de graph processing ont aussi été ajoutés.

Conclusion

Spark était jusqu'alors cantonné à une population de Data Engineers. Avec cette nouvelle mise à jour, Spark a clairement pour objectif de se faire connaître et apprécier par d’autres métiers comme Data Scientist ou Data Analyst. L’amélioration de l’intégration avec Python, l’introduction d’outils pour Data Scientist (GPU, Arrow, Binaires), ou l’arrivée de Delta Lake en sont les témoins. Son ambition est bien plus grande.

Le rôle de Spark était souvent limité à un ETL (sur beaucoup de plateformes il ne fait que ça). Aujourd’hui, Spark tente d’élargir son offre pour couvrir l'ensemble des besoins d'une Plateforme Data (sauf DataViz) afin de faire face à la concurrence grandissante des solutions Cloud-Natives. Spark cherche également à ne pas subir le déclin des écosystèmes Hadoop (qui lui avaient permis de se propager aussi vite) en s'en détachant d'avantage.

Je suis certifié AWS Security Specialty depuis le 12 décembre 2019 🙂. Ce post a pour but de vous présenter les sources utilisés pour réussir cette certification.

Tout d’abord, voici le lien vers la fiche descriptive de cet examen : https://aws.amazon.com/fr/certification/certified-security-specialty/

Pour ma part, j’ai trouvé cet examen plus compliqué que l’examen AWS Architecte Associate, mais plus simple que l’examen AWS Architecte Professionnel.

Pour passer cette certification, j’ai commencé à réviser cet été pour la passer en décembre, j’ai utilisé le lab AWS mis à la disposition des consultants IPPON pour se former avec les différents services AWS et leur permettre ainsi d’être à jours et de pouvoir répondre à une demande d’un client sur telle ou telle fonctionnalité.

Il est nécessaire avant de passer cette certification d’avoir auparavant une certification associate car il faut déjà connaitres les services classique d’AWS.  Cette certification est essentiellement axé sur la sécurisation des services et sur les outils mis à disposition par AWS pour sécuriser son infrastructure Cloud.

Ayant déjà passé la certification Sécurité sur Azure, je n’étais pas perdu, en effet ces deux certifications sont similaire car elles sont axé sur les produits gérant la sécurité du Cloud mis à disposition par les providers.

L’examen comporte 65 questions et dure 3 heures, j’ai procédé comme d’habitude pour le passer, j’ai fait une première passe et répondu aux différentes questions et cocher la case Review puis j’ai fait une seconde passe en relisant bien les questions et en prenant plus de temps pour valider ou non mon premier choix. j’ai dut modifier 2 ou 3 questions. A savoir que le score minimal est de 750 pour réussir cet examen.

Lors de l’inscription, n’oubliez pas avant de demander les 30 minutes supplémentaires car l’anglais n’est pas notre langue maternelle !

Si vous souhaitez avoir un aperçu du type de questions que vous êtes susceptible d’avoir, je vous invite à consulter le lien suivant :

https://d1.awsstatic.com/training-and-certification/docs/AWS_Certified_Security_Specialty_Sample_Questions.pdf

Afin de bien réussir cet examen qui n’est pas le plus facile, il faut prendre connaissance des Study Notes de personnes ayant déjà passé et réussi cet examen.

https://medium.com/@cbchhaya/aws-certified-security-specialty-scs-c01-4b8a62d3c680

• http://100daysofdevops.com/my-road-to-aws-certified-security%e2%80%8a-%e2%80%8aspecialty-certification/
• https://info.acloud.guru/resources/aws-certified-security-speciality-exam-prep-guide
• https://gist.github.com/dboyd13
• https://github.com/mykter/aws-security-cert-service-notes

Rien ne vaut les retours d’expérience à mon goût, pour cela, je vais consulter régulièrement le forum Acloud.guru traitant de cette spécialité:

https://acloud.guru/forums/aws-certified-security-specialty/recent?p=1

J’ai acheté le cour Acloud guru ainsi que le practice exam de Whizlabs.

Voici différents supports de cours concernant cette certification

• https://acloud.guru/learn/aws-certified-security-specialty
• https://www.udemy.com/aws-certified-security-specialty/
• https://www.whizlabs.com/aws-certified-security-specialty/

J’ai aussi acheté le livre suivant sur Amazon, il est disponible ici  : https://www.amazon.fr/AWS-Certified-Security-objectives-preparation/dp/1645469182

Et pour finir, on se motive, on passe et surtout, on réussi l’examen !

Dans cette suite de trois articles, je vous présente Vault d’Hashicorp afin de vous donner une vision sur les possibilités qu’offre cet outil pour vos différents projets. La phase d’installation est volontairement omise (le lien vers l’installation de Vault : ici). Cette suite d’article s'appuie sur mon expérience liée à l'utilisation de Vault dans le SI d’Ippon Technologies pour la gestion des secrets dans Ansible et Puppet.

Ce dernier article décrit trois exemples d’utilisations (PKI, base de données et AWS) et aborde les services secret as a service de Vault et les tokens.

Les services de Vault

Vault propose de stocker et gérer les accès à des secrets. Ce service concerne uniquement les secrets statiques comme des mots de passe.

Il peut aller plus loin. Vault peut fonctionner en tant que secret as a service. Dans ce cas là, les secrets ne sont plus statiques mais dynamiques. Vault s’occupe de créer le secret, de vérifier les accès et de le supprimer. Par exemple, pour le module AWS, Vault va être capable de générer des access key d’AWS et de les supprimer à la fin d’un délai. Tout cela sans intervention humaine.

Il peut aussi fonctionner en tant que service de chiffrement grâce au module transit. Avec ce module, Vault chiffre, signe et vérifie des données sans les stocker. Un cas d’utilisation est présent dans la documentation (ici)

Un autre service possible est le response wrapping. Ce service permet de séparer les privilèges dans la récupération des secrets. Dans ce mode, un producteur génère un accès au secret et le ou les clients utilisent cet accès pour récupérer le secret. Le producteur peut ne pas avoir d’autorisation sur le secret ni en avoir la connaissance. Une illustration de ce principe dans la documentation (ici) avec le module cubbyhole. Dans ce module, l’accès et la durée de vie des secrets de type clés/valeurs sont liés à un token :

• Seul le token permet d’accéder aux secrets liés à celui-ci. Il n’y a aucune association avec des policies possible.
• La fin de vie du token entraîne la suppression des secrets associés.

Les tokens

Une des notions des plus importantes de Vault concerne les tokens. Ils sont la base de l’identification et des accès de Vault.

# Voici la création d’un token
[root@vault ~]# vault token create -policy="client1"
Key              	Value
---              	-----
token            	s.pVIzLsyIo7tnrP6qQnMjQtqW
token_accessor   	jsHvGeR4t1bgOBoALPozFzgP
token_duration   	768h
token_renewable  	true
token_policies   	["client1" "default"]
identity_policies	[]
policies         	["client1" "default"]

# Les paramètres du token
[root@vault ~]# vault token lookup s.pVIzLsyIo7tnrP6qQnMjQtqW
Key             	Value
---             	-----
accessor        	jsHvGeR4t1bgOBoALPozFzgP
creation_time       1560766565
creation_ttl    	768h
display_name        token
entity_id       	n/a
expire_time     	2019-07-19T12:16:05.431431635+02:00
explicit_max_ttl	0s
id              	s.pVIzLsyIo7tnrP6qQnMjQtqW
issue_time      	2019-06-17T12:16:05.431431458+02:00
meta            	<nil>
num_uses       	    0
orphan          	false
path            	auth/token/create
policies        	[client1 default]
renewable       	true
ttl             	767h29m39s
type            	service           

Ils sont utilisés de deux façons :

• directement : un token est utilisé directement pour s’identifier.
• indirectement : tous les modules d’authentifications associent un token à chaque session validée.

Chaque token est lié à une ou plusieurs policies et un lease. Un lease est un ensemble de données comprenant entre autres : l’ID, un accessors, le Time to live (TTL) et la durée maximum de renouvellement. A l’expiration de son TTL, le token est supprimé ou révoqué par Vault. Un TTL peut être étendu tant que celui-ci est encore valide ou que la durée maximum de renouvellement n’est pas dépassée.

Point important, il n’existe pas de commande permettant de récupérer l’identifiant des tokens. La gestion des tokens passe obligatoirement par leurs accessors. Ceux-ci sont récupérables et permettent de :

• lister les informations du token
• récupérer le module du token (dans le path)
• révoquer le token

#liste tous les accessors
[root@vault ~]# vault list auth/token/accessors
Keys
----
1JIEX84fT6F2c2CFE0kZ86iX
5plodCfa9f0i3kIe8I4du408
79giyHKmMc3mSYbUHoioB6cu
eDPEFDtbVVqJ1UbmnWG74H3s
...

#Affiche les paramètres d’un token
#A noter l’ID du token n'apparaît pas
[root@vault ~]# vault token lookup -accessor eDPEFDtbVVqJ1UbmnWG74H3s
Key             	Value
---             	-----
accessor        	eDPEFDtbVVqJ1UbmnWG74H3s
creation_time   1558367629
creation_ttl    	768h
display_name  userpass-bob
entity_id       	9912d75c-d7c6-5816-b007-52b8202f7e15
expire_time     	2019-06-21T17:53:49.297074601+02:00
explicit_max_ttl 	0s
id              	n/a
issue_time      	2019-05-20T17:53:49.29707441+02:00
meta            	map[username:bob]
num_uses       	0
orphan          	true
path            	auth/userpass/login/bob
policies        	[default test]
renewable       	true
ttl             	101h15m3s
type            	service

# Le token est révoqué
[root@vault ~]# vault token revoke -accessor eDPEFDtbVVqJ1UbmnWG74H3s
Success! Revoked token (if it existed)

Sur la révocation je souhaite préciser quelques points:

• Celle-ci peut être faite via l’API, l'interface web ou comme dans mon exemple en ligne de commande.
• Les tokens sont liés entre eux sous forme d’arbre. Sauf exception, les tokens sont obligatoirement associés à un token père. La révocation du token père révoque automatiquement ses fils.
• Le fait que les accessors permettent la révocation des tokens, ils doivent être vu comme une donnée sensible même s’ils ne permettent pas une authentification.

Lors de l’installation de Vault, le premier token est un root token. Les root tokens possèdent  un accès complet à Vault et ils sont les seuls n’ayant pas de TTL. Dans les environnements de production, Hashicorp conseille fortement d’utiliser ce type de token uniquement au besoin et de les supprimer dès que possible.

Il existe aussi des tokens dits periodic tokens. Ce sont des tokens avec une période de renouvellement sans limite. Ils sont surtout à destination des applications pour un usage de longue durée.

Pour aller plus loin dans les tokens : ici

Exemples d’utilisation

Module PKI (Certificat SSL)

Vault possède un moteur PKI. Il est capable d'importer ou de générer lui-même le certificat CA racine. La documentation officielle conseille l’utilisation d’un certificat CA racine à l’extérieur de Vault et de passer par un certificat CA intermédiaire.

Après la configuration du moteur, la génération de certificat peut se faire via l’IHM ou en ligne de commande. Voici un exemple extrait de la documentation afin de générer un certificat SSL :

$ vault write pki/issue/my-role common_name=www.my-website.com
Key                 Value
---                 -----
certificate         -----BEGIN CERTIFICATE-----...
issuing_ca          -----BEGIN CERTIFICATE-----...
private_key         -----BEGIN RSA PRIVATE KEY-----...
private_key_type    rsa
serial_number       1d:2e:c6:06:45:18:60:0e:23:d6:c5:17:43:c0:fe:46:ed:d1:50:be

Module Base de données

Vault supporte une dizaine de bases de données différentes comme MySQL/MariaDB, PostgreSQL et Cassandra. Il crée des utilisateurs de bases de données à la demande à partir d’une requête SQL. Ces utilisateurs seront automatiquement supprimés à la fin de leur TTL.

La configuration de Vault se fait en 2 temps. Dans un premier temps, on indique à Vault les paramètres de connexion à la base de données. Ensuite, on crée un rôle qui porte les requêtes SQL pour la création et la révocation des utilisateurs de la base. Le nombre de rôles n’est pas limité.

Par exemple (repris de la documentation officielle) pour MySQL:

# Configuration de la connexion à la base de donnée
vault write database/config/my-mysql-database \
   plugin_name=mysql-database-plugin \
   connection_url="{{username}}:{{password}}@tcp(127.0.0.1:3306)/" \
   allowed_roles="my-role" \
   username="root" \
   password="mysql"

# Modèle de la requête SQL pour la gestion des utilisateurs
# my-role correspond au champ allowedroles de la commande précédente
vault write database/roles/my-role \ 
# my-mysql-database correspond au chemin database/config/my-mysql-database de la commande précédente
  db_name=my-mysql-database \  
  creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY   '{{password}}'; GRANT SELECT ON *.* TO '{{name}}'@'%';" \
  default_ttl="1h" \
  max_ttl="24h"

#On peut rajouter le champ evocation_statements pour définir la requête SQL de suppression des utilisateurs

Coté client, la création d’un compte se fait via le processus suivant:

[root@vault ~]# vault read mysql/creds/my-role
Key                Value
---                -----
lease_id           mysql/creds/my-role/hv0SKIMsDkjoOddHBzZQZlH1
lease_duration     1h
lease_renewable    true
password           A1a-NqfElhVN1vEG5b2N
username           v-root-my-role-JQ6sTjecaJLxVE7lu4

#Résultat dans Mysql
MariaDB [mysql]> select User,Password from user where User="v-root-my-role-JQ6sTjecaJLxVE7lu4";
+----------------------------------+-------------------------------------------+
| User                             | Password                                  |
+----------------------------------+-------------------------------------------+
| v-root-my-role-JQ6sTjecaJLxVE7lu4 | *3AFB061BF01FE1052A8F56063061B9D0200B0522 | +----------------------------------+-------------------------------------------+

#Une heure plus tard, Vault a supprimé le compte  v-root-my-role-JQ6sTjecaJLxVE7lu4
MariaDB [mysql]> select User,Password from user where User="v-root-my-role-JQ6sTjecaJLxVE7lu4";
Empty set (0.001 sec)

Vault gère la rotation de ces identifiants sur la base de données.

vault write -f  mysql/rotate-root/test
Success! Data written to: mysql/rotate-root/test

Module AWS

Plusieurs méthodes d’identification existent :

• STS AssumeRole
• STS Federation Tokens
• IAM USer

Je vous présenterai la dernière méthode. Celle-ci demande la création d’un utilisateur IAM pour Vault (la documentation officielle propose une policy ici). Ensuite, on définit une policy AWS dans un rôle Vault. Les comptes IAM créés avec ce rôle sont automatiquement associés à la policy du rôle. Vault s'occupera aussi d’effacer les identifiants IAM créés à la fin de leur TTL.

#Lié Vault avec son compte IAM
root@vault ~]# vault write aws/config/root \
access_key=AKIAZPX3XVC3FZBDEIM7 \
secret_key=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 \
region=eu-west-3 

#Création d’un rôle
[root@vault ~]# vault write aws/roles/my-role \
#On peut aussi associé avec une policy déjà existant
#  policy_arns=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
credential_type=iam_user \
policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
  {
    "Effect": "Allow",
    "Action": "ec2:*",
    "Resource": "*"
  }]
}
EOF

root@vault ~]# Génération d’un identifiant IAM
vault read aws/creds/my-role
Key                Value
---                -----
lease_id           aws/creds/my-role/WqENsbkUcXwUXluW4Zjxxook
lease_duration     768h
lease_renewable    true
access_key         AKIAZPX3XVC3BBOZN2OZ
secret_key         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
security_token     <nil>                

Voici le résultat au niveau de la console d’AWS :

Comme pour le module sur les bases de données, Vault est capable de faire une rotation de ces identifiants IAM via la commande :

[root@vault ~]# vault write -f aws/config/rotate-root
Key           Value
---           -----
access_key    AKIAZPX3XVC3NCZLTCNF

Sur l’interface web, il est possible de visualiser les utilisateurs créés et de les révoquer.

La phrase de la fin

J’espère que les éléments présentés dans cette suite d'articles vous donneront envie de découvrir Vault. Je ne peux que vous conseiller de lire la documentation officielle de Vault (ici). Hashicorp propose des TPs de découverte avec des scénarios d’utilisation (https://learn.hashicorp.com/vault/).

Je viens de passer la nouvelle certification speciality Machine Learning d'Amazon Web Services (MLS-C01), disponible depuis avril 2019, et je vais partager avec vous à travers cet article mon retour d’expérience. Je vais aborder dans un premier temps le contenu de cette certification et je vous donnerai ensuite quelques conseils pour bien préparer et réussir l’examen.

Tout d’abord, la finalité de cette certification est de valider les compétences nécessaires pour mener à bien un projet de Machine Learning (ML) dans le Cloud d’Amazon. Ainsi devez-vous être capable de :

• Transformer un problème business en un problème de Machine Learning; cela sous-entend que vous êtes déjà très à l’aise avec les concepts de base du ML. Par exemple, vous devez savoir quand il faut utiliser un modèle de régression, de classification ou du clustering ; savoir si vous êtes dans un cadre supervisé ou non supervisé ; si vous avez affaire à des données structurées ou non structurées, données temporelles ou vectorielles ; les démarches à suivre pour éviter le sur-apprentissage, etc.
• Utiliser l’ensemble des services AWS, et surtout le service managé SageMaker, pour votre pipeline de Machine Learning, allant de l’ingestion et du traitement des données jusqu’au déploiement des modèles, en passant par les différentes phases d’apprentissage, de tunning des hyperparamètres et de l’évaluation.
• Utiliser les services AWS pour mettre en place une solution sécurisée et scalable. Vous devez par exemple gérer le chiffrement des jeux de données, les VPC endpoints, connaître les bonnes pratiques à mettre en place pour mieux encadrer l’utilisation des services AWS.

L’examen dure 3 heures et comprend 65 questions (QCU et QCM) pondérées par leur niveau de difficulté. Tout au long de l’épreuve, vous avez le rôle de Data Scientist et vous devez répondre à des questions scénarisées. La difficulté réside principalement dans le fait que le texte de l’énoncé est souvent long et les réponses proposées sont pratiquement toutes cohérentes, mais vous devez toujours choisir la réponse (QCU) ou les réponses (QCM) les plus appropriées. Comme pour toutes les certifications type Speciality d’AWS, il faut un score minimum de 750 sur 1000 pour être certifié.

Selon le guide officiel, les questions portent généralement sur quatre domaines différents, à savoir le Data Engineering, Exploratory Data Analysis, Modeling et Machine Learning Implementation and Operations. Je vais maintenant décrire le contenu de chaque partie en mettant l’accent sur les sujets abordés dans l’examen.

1. Data Engineering

Cette partie concerne la stack Big Data d’AWS, notamment l’ingestion et le traitement des données en streaming. Vous devez savoir, à l’aide de services AWS, comment créer des dépôts de données pour l’apprentissage des modèles ML, identifier et implémenter tout un pipeline d’extraction et de transformation de données. Pour être à l’aise dans cette partie, je vous recommande de voir de près les services suivants :

• Les services AWS pour le stream :

  • Kinesis Firehose (ingestion des données en quasi temps réel sans stockage intermédiaire, connaître les quatre outputs de Firehose, à savoir RedShift, S3, ELasticsearch Service et Splunk, transformation en format Parquet, couplage avec Lambda),
  • Kinesis Data Streams (ingestion des données en temps réel, KPL, Client Library, Kinesis agent, rétention de données, 24h jusqu’à 7 jours contrairement à Firehose),
  • Kinesis Video Stream (traitement des données vidéo en temps réel, voir aussi comment le combiner avec le service Rekognition),
  • Kinesis Data Analytics (un outil d’analyse en temps réel couplé avec des fonctionnalités de Machine Learning telles que la détection d’anomalies, Random Cut Forest, Hotspots. Vous pouvez faire des transformations en temps réel avec ce service).
    
    

• Les services AWS pour le stockage et les bases de données :

  • S3 (connaître les différentes classes de stockage et savoir gérer le cycle de vie des objets stockés dans S3),
  • DynamoDB,
  • RDS, DMS (gestion des bases de données relationnelles et gestion de la migration des bases de données dans le Cloud),
  • Redshift ( un service d’entrepôt de données AWS).
    
    

• Les services AWS pour l’Analytics :

  • Glue (ETL job, Crawler, Data Log et les différentes capacités ML intégrées dans ce service, notamment la fonctionnalité Find-Matches permettant de détecter des doublons dans les données),
  • Athena (un service de requêtes SQL interactif dans Amazon S3),
  • QuickSight (un service BI doté de plusieurs fonctionnalités ML comme par exemple la détection d’anomalies ou le forecasting).

Toutefois, le plus important n’est pas de maîtriser en détail l’ensemble de ces outils, mais plutôt de connaître comment ils fonctionnent et comment vous pouvez les combiner pour mettre en place une pipeline d’ingestion et de traitement de données efficace.

2. Exploration et analyse des données

Les sujets abordés dans cette partie ne sont pas forcément liés à AWS. Vous devez être familiarisé avec les concepts de base de l’analyse et de l’exploration des données tels que :

• Le feature Engineering : normalisation (min/max), standardisation (z-score), binning (quantile binning), one-hot encoding, binarisation des labels ;
• Le données textuelles : représentation vectorielle du texte (TF-IDF), savoir quand il faut utiliser une transformation n-gram ou une OBS (Orthogonal Sparse Bigram) par exemple ;
• Le traitement des données manquantes : par exemple, l’utilisation des algorithmes supervisés (KNN, DL), quand cela est possible, est largement préférée à l’imputation par la moyenne ou par une autre valeur représentative ;
• La visualisation des données et leurs intérêts : scatter plot (2 variables : corrélation) vs bubble plot (3 variables : corrélation conditionnelle), line charts (tendance temporelle), bar charts, histogramme et box plots (distribution d’une variable), composite visualisation (pie charts, stacked area charts, stacked column charts), heatmaps ;
• Savoir tester la normalité des données avec des outils de visualisation simples comme l’Histogram, le Q-Q plot ou encore le Normal Probability Plot ;
• Connaître la différence entre la sélection de variables (feature selection) et la réduction de la dimensionnalité à travers différentes techniques, linéaire ou non, telles que : PCA, SVD, MSD ou Isomap ;
• Savoir comment créer des features à partir des données non-vectorielles. Par exemple, pour le séries temporelles vous pouvez utiliser SAX pour les discrétiser ;
• L’analyse des séries temporelles à travers plusieurs techniques, comme la décomposition en terme de tendance, de saisonnalité. Se renseigner sur les techniques de modélisation de séries temporelles classiques comme ARMA et ARIMA.

Vous pouvez avoir éventuellement du code Pandas à déchiffrer ou des questions sur des fonctions très classiques de cette librairie.

3. Modélisation

Cette section est la plus importante de l’examen et sans doute la plus difficile pour ceux qui n’ont pas un background en Machine Learning. La finalité de cette partie est de valider vos connaissances en Statistiques et en Machine learning. Les questions que vous aurez dans cette section concernent en grande partie :

Les connaissances générales en Machine Learning :

• Les deux paradigmes de l’apprentissage automatique, à savoir, le supervisé, et le non-supervisé (Il y a bien évidemment d’autres paradigmes, mais je m’intéresse uniquement à ceux qui sont abordés dans la certification) ;
• Les algorithmes supervisés (classification ou régression) tels que, l’arbre de décision, les forêts aléatoires, la régression linéaire, le Naive bayes, le SVM, le Perceptron multi-couches et la régression logistique ;
• Les algorithmes non-supervisés pour le clustering et la segmentation tels que, le KMeans, DBSCAN et la CAH ;
• Les algorithmes non-supervisés pour la détection d’anomalies comme l’isolation forest, le LOF et le One-Class SVM ;
• Les systèmes de recommandation comme le collaborative filtering ;
• Comment évaluer un modèle de Machine Learning et choisir la métrique la plus adéquate pour un problème donné : précision, rappel, F1 score, matrice de confusion, AUC et la courbe ROC, RMSE, MAE, MSE, l’analyse des résidus pour les problèmes de régression ;
• Les indices d’évaluation internes et externes pour l’analyse du clustering tels que la silhouette, l’indice de rand, l’indice de Dunn et l’indice de Davies-Bouldin ;
• Vous devez comprendre le fonctionnement des algorithmes d’optimisation (GD, SGD, Adam, RMSProp, etc.) ;
• Les différentes fonctions de loss (Hinge Loss, Log loss, MSE loss, etc.) utilisées comme objectif par les différents algorithmes d’optimisation cités ci-dessus ;
• Connaître les différentes techniques de régularisation pour éviter le sur-apprentissage (L1 vs L2, dropout, élagage, etc.) et quand il est possible de les utiliser ;
• Bien comprendre la validation croisée et savoir comment l’utiliser dans le cadre des données temporelles ;
• Connaître la différence entre les méthodes ensemblistes, notamment le Bagging, le Boosting ou encore le Stacking ;
• Savoir comment traiter le problème de déséquilibre dans un dataset, en utilisant par exemple des techniques comme SMOTE ou GAN pour générer de nouvelles données.

Les connaissances Machine Learning liées à AWS :

• Le service managé de ML SageMaker d’AWS : vous devez connaître l’ensemble des algorithmes proposés par ce service et leurs use cases ;
• Connaître les différentes manières d’utiliser SageMaker : la console d’AWS, la Amazon SageMaker Python SDK, ou encore la bibliothèque de bas niveau Boto3 ;
• Connaître l’ensemble des paramètres de ces algorithmes et le type d’input supporté (CSV, libsvm, recordIO-protobuf) ;
• Faire la différence entre le mode File et le mode Pipe pour accéder aux datasets, et savoir quand est-ce qu’il est possible de bénéficier du Pipe Mode pour accélérer l’apprentissage ;
• Savoir utiliser des jobs de tuning d'hyper-paramètres avec L'Automatic Model Tuning et faire la différence entre la stratégie aléatoire et la stratégie bayésienne ;
• Se renseigner sur le Warm Start pour accélérer le tuning en se basant sur des jobs anciens ;
• L’étiquetage des données avec l’outil Ground Truth de SageMaker (se renseigner sur la possibilité d’affecter une tâche d'étiquetage à plusieurs personnes via la consolidation des annotations) ;
• Avoir une idée de comment intégrer d’autres frameworks de Machine (deep) Learning à SageMaker, notamment à travers Docker ;
• Pensez au Transfer Learning dans le cas d’une faible quantité de données : cela consiste à apprendre un nouveau modèle en se basant sur des modèles de deep-learning pré-entraînés par SageMaker.

4. Industrialisation du Machine Learning

Le sujet principal de cette dernière partie est le déploiement et l'industrialisation des modèles de Machine Learning dans AWS. Plusieurs sujets sont abordés tels que la sécurité, le monitoring des modèles, l’edge computing, l’optimisation des coûts et les différents types de déploiements. Ainsi, je vous recommande de regarder de près les sujets suivants :

• Comment déployer efficacement un modèle avec SageMaker ? (l’intérêt du batch transform dans le cas où une publication du modèle n’est pas nécessaire, l’intérêt du déploiement d’une pipeline SageMaker) ;
• Savoir comment ajouter de l’IA dans une application sans passer par SageMaker via les services de Machine Learning managés comme : Forecast, Rekognition, Comprehend, Textract, Polly, Lex, Translate, Transcribe, etc. ;
• Le service Step Function qui permet de coordonner plusieurs services AWS ;
• Le service AWS Batch qui permet d'allouer dynamiquement les ressources nécessaires pour tout type de calcul ;
• Savoir comment utiliser le tout nouveau IDE d’Amazon SageMaker Studio pour augmenter votre productivité ;
• Le service Elastic inference qui permet d’accélérer, à faible coût, la partie inférence (phase de prédiction) des modèles de deep learning sur des instances GPU ;
• Savoir comment utiliser les Spot Instances pour réduire les coûts liés à des jobs de tuning (ou d’apprentissage) importants ;
• L’intégration des jobs Spark dans une pipeline Data de SageMaker ;
• Les différents types d’instances recommandés pour les algorithmes de SageMaker, notamment les P3, P2, C5, C4, M4 ;
• L’utilisation du CloudWatch pour observer les modèles en se basant sur les métriques envoyées par SageMaker ;
• L’utilisation du CloudTrail pour le contrôle d’accès et la surveillance de l’utilisation de SageMaker (par exemple, contrôler les accès et les appels aux API) ;
• La possibilité de déployer, avec Neo les modèles ML dans d’autres appareils que les instances AWS, ce qui permet de faire de l’edge computing. Par exemple, entraîner un modèle de Vision par Ordinateur et le déployer dans une voiture.

Comment se préparer à l’examen ?

Tout d’abord, je vous conseille d’aller regarder ce cours de L’INRIA sur le langage Python et l’écosystème data science. Ensuite, vous pouvez aller voir Le cours d’Andrew Ng sur les concepts de base de machine learning. Vous pouvez vous familiariser alors avec l’apprentissage supervisé (régression, classification), l’apprentissage non-supervisé (clustering, détection des anomalies, la réduction de la dimensionnalité) et les systèmes de recommandation. Pour mettre en pratique tous ces concepts, je vous recommande de jouer un peu avec le framework scikit-learn en regardant par exemple cette conférence (Part 1 & Part 2) de Olivier Grisel et Guillaume Lemaître de l’INRIA.

Cela fait, vous pouvez commencer le cours d'Andrew Ng, sur le deep-learning. Vous y apprendrez l’implémentation de vos propres réseaux de neurones avant de passer à l’utilisation du framework Tensor Flow. Vous apprendrez aussi les différentes techniques de régularisation pour éviter le sur-apprentissage, le traitement des données complexes telles que les images, le texte, les séries temporelles et les flux vidéo.

Pour monter en compétence sur la partie AWS, je vous recommande de suivre les cours suivants :

• AWS Certified Solution Architect Associate 2020 de Ryan Kroonenburg pour avoir une bonne compréhension des services majeurs d’AWS, à savoir S3, EC2, VPC, Lambda, etc.
• AWS Certified Big Data Specialty 2020 de Frank Kane et Stéphane Maarek pour la stack Big Data d’AWS.
• AWS Certified Machine Learning Specialty 2020 de Frank Kane et Stéphane Maarek qui reprend une partie du cours de Big Data et fait un excellent zoom sur les fonctionnalités de SageMaker.
• Le cours edX Amazon SageMaker: Simplifying Machine Learning Application Development

Je vous recommande aussi de voir l’ensemble des vidéos de ce deep-dive sur SageMaker (et celui du re:Invent 2019) et de tester le maximum de notebooks disponibles gratuitement sur le github d’aws lab.

Pour la partie data, vous pouvez regarder ces vidéos :

• Un talk sur Kinesis avec le retour d’expérience d’un client,
• Un talk re:Invent 2018 sur Glue,
• Une introduction rapide à Glue.

Pour tester vos compétences et savoir si vous êtes prêts pour le passage de l’examen, vous pouvez vous tester avec les practices exam proposés par WhizLabs.

Enfin, je vous ai préparé la table ci-dessous pour vous donner une vue d’ensemble sur les algorithmes de SageMaker. Ainsi, pour chaque algorithme, vous y trouverez un lien vers sa documentation technique, une brève description de sa tâche principale et son paradigme, un lien vers un notebook Jupyter pour pratiquer, et quelques mots clés à regarder de près (paramètres, type de l’input, type d’instance, mesures d’évaluation, etc.).