Des nouvelles du Paris Time Series Meetup : l’éditions 6 sur TimescaleDB et l’édition 7 sur QuestDB

CI/CD

• 3 YAML tips for better pipelines : la troisième est certainement la plus intéressante - il est possible d’avoir des mécanismes de “composabilité” / “héritage” avec YAML et Gitlab. Si les include et extends sont déjà sympathiques, les anchors ont l’air de faire des choses intéressantes aussi !

Code

• What’s New In Python 3.9 et un thread twitter qui donne des exemples des principales nouveautés : au programme nouvelle syntaxe pour la fuston des dictionnaires, des méthides pour supprimer des suffixes/préfixes sur les strings, du typage et plein d’autres améliorations et corrections.
• Fortunately, I don’t squash my commits : s’il peut être tentant sur une MR/PR de faire un squash des commits, l’article vous confortera dans l’idée que ce n’est pas une bonne idée. En écrasant l’historique des commits, on y perd sur nos capacités de debug. Par ailleurs, il est conseillé de faire des petits commits pour capturer un ensemble de changements traduisant un moment précis du développement.

Container et orchestration

• Kubernetes Ingress Goes GA : l’apparition de IngressClassName dans k8s 1.19 va plus loin qu’un simple renommage de champ comme je l’avais compris initialement. C’est une vraie ressource et cela ouvre aussi des possibilités. Avant de l’utiliser, vérifiez aussi que vos ingress controller le supporte (en plus d’attendre d’être en 1.19)
• Houston, we have Plugins! Traefik 2.3 Announcement : la version 2.3 dont on a déjà parlé ici, est arrivé en version stable avec son support des plugins, son intégration avec Traefik Pilot, le support d’Amazone ECS et le support de la ressource IngressClassName. Au passage, Containous, la société éditrice de Traefik s’appelle maintenant Traefik Labs.
• Introducing Traefik Pilot 1.0: the Traefik Control Center : Version 1.0 de ce nouveau “Control Plane” de Traefik qui permet d’avoir une vision globale sur ses instances traefik, d’utiliser les plugins et d’avoir un monitoring et des alertes autour de la disponibilité, des performances et de la sécurité.
• Rootless mode : A voir si cela pourra être inclus dans la version 1.20 mais le rootless mode est clairement une tendance de fond dans kubernetes et les conteneurs en général. Si vous ne vous y êtes pas déjà mis, ne tardez pas !
• Announcing Traefik Mesh 1.4 - New Name, New Features : nouvelle version du service mesh par Traefik Labs et qui s’appelle maintenant Traefik Mesh (et non uniquement Maesh). Le reste des améliorations semble porter sur le filtrage des headers et des paths.
• yq : A command line tool that will help you handle your YAML resources better : vous voulez faire des opératoins sur des fichiers YAML sans faire un chart helm ou sortir kustomize, vous pouvez faire des choses minimalistes avec yq (le pendant yaml de jq).
• Bridge to Kubernetes GA, “bridge to kubernetes” est une extension pour vscode permettant de connecter une application tournant en local avec d’autres applications situées dans un ckuster kubernetes et faciliter ainsi l’expérience des développeurs.

Culture DevOps

• La culture de la résilience à travers le DevOps, DevPO, et DevQA : article intéressant de Paul Leclerq sur la résilience et la collaboration au sein d’une équipe.

Data

• How to Measure Your Organization’s Data Maturity : les différents stade de maturité de votre organisation concernant la gestion et l’exploitation des données.
• Announcing MQTT-on-Pulsar: Bringing Native MQTT Protocol Support to Apache Pulsar: Apache Pulsar, la plateforme de message distribué et de streaming, se dote d’un plugin “MQTT On Pulsar” (MoP) permettant ainsi de migrer vos applications MQTT sur Apache Pulsar. Après le plugin Kafka (KoP) il y a quelques mois en partenariat avec OVHCloud, Pulsar ajoute une corde à son arc pour devenir la plateforme universelle. Le protocole AMQP est déjà aussi supporté depuis plusieurs mois.
• Building An Event-Driven Orchestration Engine : retour d’expérience sur les raisons de la migration à Apache Pulsar e la simplificaiton apportée en ayant une platforme riche et complète (streaming + queue + fonctions + data tiering sur S3 + …)

Hardware

• NVidia’s Planned Acquisition of Arm Portends Radical Data Center Changes : une analyse assez en profondeur sur le rachat d’arm par nvidia et les autres acteurs du marché comme AMD.

IaC

• Announcing HashiCorp Terraform 0.14 Beta: la capacité à marquer des variables comme sensibles pour éviter que leur valeur soit visible dans les logs/diff/…, un diff plus concis, un lock sur les providers et des binaires disponibles pour arm64.

Monitoring

• Long-term store for Prometheus, with the combined power of SQL and PromQL : Timescale s’ajoute à la liste des solutions permettant un stockage long terme à vos données Prometheus. En plus de ce stockage long terme, elle fournit une couche d’analytics. Un connecteur récupère les données dans Prometheus et les injecte dans TimescaleDB. On en parle dans l’édition 6 du PTSM.

Pratique

• endoflife.date : recense les dates de fin de support de vos langages et technologies préférées. Tout n’est pas complètement à jour mais cela permet de récupérer rapidement les informations.

SQL

• Exciting and New Features in MariaDB 10.5 : évoqué au mois d’aout, le support de S3 dans MariaDB est disponible en version GA dans la version 10.5. D’autres améliorations existent comme le support du type INET6, des améliorations sur ColumnStore, la gestion des privilèges, le cluster Galera supporte complètement le GTID, du refactoring au niveau d’InnoDB et enfin les binaires mariadb vont enfin s’appeler mariadb et non plus mysql (avec une couche de compatibilité via des liens symboliques)

Time Series

• Introducing FLoWS, a functional language for Time Series Analytics : FLoWS est arrivé - il vous faudra utiliser une version 2.7.1+ de Warp10 pour profiter de cette approche fonctionnelle en alternative à Warpscript.
• How can you tell which Time Series Database is suited to your needs? : un petit rappel sur les critères à prendre en compte pour choisir une base de données séries temporelles ; j’avais déjà parlé du guide de Senx sur le sujet - il est disponible en fin de billet.
• InfluxDB 2.0 Release Candidate Now Available : la première Relese Candidate (RC0) pour InfluxDB 2.0 OSS avec le retour du moteur de stockage de la V1 - qui contrairement à ce que j’ai pu dire le mois dernier ne concernerait que la façon dont les données sont stockées sur disque et pas le reste d’une part et sera maintenu et amélioré par Influxdata d’autre part. Quelques changements sur le port (retour au port 8086). Pour ceux qui étaient en version alpha/beta, il faudra suivre une procédure de migration. La migration depuis une version 1.x n’est pas encore disponible, cela devrait être dans une prochaine RC. Vous pourrez tester néanmoins les API 1.x, les templates, une version récente de Flux ou encore les améliorations de la CLI.
• Release Announcement: InfluxDB 2.0.0 RC 1 : cette version apporte essentiellement l’upgrade des données 1.x vers 2.x et une mise à jour de Flux.
• Store and Access Time Series Data at Any Scale with Amazon Timestream – Now Generally Available - Getting Started with Amazon Timestream - AWS Releases Amazon Timestream into General Availability : AWS sort enfin son produit orienté time series après l’avoir annoncé il y a deux ans.

Sur la base des informations disponibles pour le moment :

• vous définissez une période de rétention en mémoire (entre 1h et 1 an) et une période de rétention sur stockage magnétique (1 jour à 200 ans),
• le requêtage des données se fait en SQL (via Presto ?),
• les données à requêter communément sont à mettre dans la même table,
• le join est limité à la même table,
• des mesures simples (pas de multi mesures pour un même enregistrement),
• une intégration avec l’écosystème comme telegraf, grafana, etc en plus de l’intégration avec différents composants AWS

Pour les moins bons côtés :

• pas d’UPDATE/DELETE sur vos données ; en cas de doublons, c’est le premier arrivé qui gagne
• pas de bulk import de vos données, donc pas de reprise de vos données existantes. En effet, il n’est pas possible d’ingérer des données plus vieille que la période en mémoire,
• dans la même veine, si un incident de production dépasse votre période de rétention, vous ne pourrez pas réinjecter vos données
• il ne semble pas possible de mettre à jour ses durées de rétention - donc pas de ménage possible ou d’ajustements en cours de route

Une solution a priori très orienté pour du monitoring et qui semble souffir des mêmes travers qu’InfluxDB avec InfluxQL et pourtant en passe d’être résolus avec Flux.

On devrait en parler plus en détail dans une prochaine édition du Paris Time Series Meetup avec des personnes de chez AWS ;-)

Work

• Virtual First Toolkit : toolkit proposé par Dropbox dans le cadre de leur passage non pas à Remote first mais à virtual first.

Contexte

Editeur d’une plateforme data, la société cherche à se faire accompagner et confier le role de Lead Platform à une personne en mesure d’industrialier et d’automatiser la plateforme, son déploiement et son exploitation mais aussi d’améliorer les pratiques de développement de l’équipe. Une contribution directe au produit est également envisagé.

Notre réponse

En tant que Lead Platform :

• Passage d’un logique “Build/Ship” à une logique “Build/Ship/Run”
• Mise en place de Gitlab et Gitlab-CI pour le suivi du code et l’automatisation des tâches,
• Migration des outils de déploiement sous Terraform et Ansile en fonction des cas,
• Mise à jour des composants de la plateforme et de l’outillage autour de la plateforme,
• Amélioration des pratiques de développement et recette : amélioration du process de revue de code et de validation d’un développement, mise en place des “Architectural Design Review” pour cadrer les initiatives, etc.
• Amélioration des pratiques de monitoring et d’exploitation des plateformes
• POC Nomad/Consul/Terraform comme alternative à Kubernetes pour des déploiements plus légers,
• Déploiement du logiciel chez différents cloud proviers (GCP, AWS, Scaleway, etc)
• Etc.

Bénéfices pour l’éditeur

• Expertise sur les pratiques d’automatisation et d’industrialisation des process de développement et de déploiement
• Réduction de la dette technique et remise au carré des outils et des plateformes
• Adoption des outils considérés comme à l’état de l’art
• Fiabilisation des processus de développement et de déploiement

Bénéfices pour CérénIT

• Premier projet professionel en Go
• Premer POC avec Nomad, Consul et Vault
• Travail sur la transimission des pratiques et de la culture de l’automatisation & industrialisation

Rendez-vous le 17 décembre prochain à la troisième édition du Paris Time Series Meetup consacré à TSL (billet introductif à TSL : TSL: a developer-friendly Time Series query language for all our metrics) et le module RedisTimeSeries qui apporte des fonctionnalités et des structures Time Seriies à Redis.

Cloud

• The RIPE NCC has run out of IPv4 Addresses : Le RIPE NCC vient d’annoncer avoir attribué son dernier bloc d’IP v4 en /22. La réserve d’IPv4 est donc épuisée mais pour autant cela ne veut pas dire que toutes les IPv4 sont utilisées. Par ailleurs le RIPE NCC précise que de nouveaux blocs devraient voir le jour au fur et à mesure que des organisations revendent des plages inutilisées ou cessent leur activité. Le mécanisme d’attribution se fera alors sous la forme d’une liste d’attente. Ce n’est donc pas l’IPcalypse même si on s’en rapproche de plus en plus et s’il faut prévoir de passer à IPV6 de plus en plus rapidement.

Container et Orchestration

• Red Hat Introduces open source Project Quay container registry : De la même manière que RedHat publie l’upstream d’Ansible Tower avec le projet AWX, RedHat va fournir l’upstream de Quay (registry docker) et Clair (scanner vulnérabilités) sous le nom de Project Quay
• Helm 3.0.0 has been released! : si tout le monde attendait la suppression de tiller, ce n’est pas la seule nouveauté. Le billet donne aussi plein de liens sur la migration vers helm 3, la politique de support de Helm 2 (bug & sécurité pour 6 mois et sécurité uniquement les 6 mois suivants), etc.
• Mirantis acquires Docker Enterprise, Docker Restructures and Secures $35 Million to Advance Developer Workflows for Modern Applications et Docker’s Next Chapter: Advancing Developer Workflows for Modern Apps : Mirantis rachète la branche “Entreprise” de Docker Inc et les actifs associés (employés et propriété intellectuelle). Docker Inc va se focaliser sur l’expérience utilisateur (Docker Desktop, Docker-Compse, Docker-Apps, etc). Pour cela, en plus d’une restructuration du capital, ils ont sécurisé 35 millions de dollars. Il est quand même étonnant de voir qu’à court terme, en dehors de la vente à Mirantis, Docker Inc n’a plus de sources de revenus…
• What Docker Inc’s Reorganization Means For Docker Swarm : Suite à l’annonce précédente, il est légitime de se demander ce que va devenir Swarm. Le produit est donc géré par Mirantis et ces derniers ont embauché la personne en charge de Swarm et lui ont apparemment donné des garanties de pérénité du projet. Il conviendra de rester prudent sur le sujet même si j’espère que le projet Swarm continuera à exister. En effet, il est bien pratique et léger dans beaucoup de cas qui ne requiert pas Kubernetes.
• k3s 1.0 : k3s, la version allégée mais certifiée de k8s atteint la version 1.0. Très pratique pour faire du k8s sur des raspberry pi et assimilés.
• KSS - Kubernetes pod status on steroid : un petit script python qui permet d’avoir un status d’un pod et de son/ses container(s)

Data

• Introducing ksqlDB : Confluent, l’entreprise derrière Apache Kafka et la Confluent Platform sort une nouvelle version de ksql qui est renommé ksqlDB. ksql se voit donc ajouter un connecteur sql pour des enrichissements depuis des sources de données externes, ainsi qu’un système de requêtage dynamiques de topics Kafka pour le présenter sous la forme d’une base de données et prendre en compte les changements au fur et à mesure qu’ils arrivent. Ce n’est donc pas une base de données à proprement parler mais nommer les choses en informatique, c’est une chose compliquée…

Outillage

• Welcome to the Matrix : Le plugin Declarative Pipeline se dote d’une propriété matrix qui va permettre de faire la même action avec des configurations différentes plutôt que d’avoir un jenkinsfile pour chaque option/déclinaison du job. Le parallelisme semble supporté par défaut et un système d’inclusion/exclusion permet de mieux définir la combinaison des possibles. Dans l’exemple donné qui croise des systèmes d’exploitation et des navigateurs, cela permet par ex de ne pas lancer le job utilisant Micrsoft Edge sous Linux (même si…).

Tech

• Zalando Tech Radar : Zalendo publie son Tech Radar à la ThoughtWorks et open source l’outil de rendu pour que chaque société puisse publie son tech radar
• ThoughtWorks Tech Radar Vol 21 - Nov 2019 : La dernière édition du Tech Radar Thoughtworks en 4 grands axes : techniques, platformes, outils, langages & frameworks. Va falloir lire le PDF pour aller apprécier cette édition.

Time Series

• How to Use Redis TimeSeries with Grafana for Real-time Analytics (version française) : Mise en oeuvre du module RedisTimeSeries et exploitation des données au travers de Grafana.
• Time Series Prediction - A short introduction for pragmatists : une introduction aux différents algorithmes de prévision sur des données temporelles. L’article montre que l’on peut obtenir des résultats assez probants avec des moyens assez simples et sans se comliquer la vie.
• Using Gradient Boosting for Time Series prediction tasks : une autre introduction assez pédagogique à la prédiction basée sur des séries temporelles avec l’outil XGBoost et en appliquant le Gradient Bootsting.

Contexte

Affini-Tech est une société d’ingénierie “Big Data” dont l’objectif est d’accompagner ses clients dans la prise en main et l’exploitation de leurs données. Elle souhaite faire évoluer son site web et développer un framework de traitement de données (pipelines) pour permettre à ses clients de manipuler plus facilement leurs données.

Notre réponse

• Site Web : Analyse critique du site Affini-Tech.com et du blog et recommendation du CMS Statique Lektor
• Développement logiciel : sur la base d’un POC existant et de chaines de traitement de données mis en place pour des clients sur Google Cloud Platform, développement d’une première version d’un framework de traitement de données (pipeline) permettant de manipuler simplement des données via des tâches génériques (exécution d’une requête SQL, chargement de fichiers dans une base, etc) ou des tâches spécifiques (code python & fonction simplifiées).

Bénéfices

• Site Web : capitalisation sur plus de 10 ans d’expériences pour fournir une réponse adaptée aux besoins exprimés
• Développement logiciel : capitalisation sur une expertise technique (python, docker) permettant d’obtenir une première version d’un framework générique permettant de déployer des chaines de traitement de données."