Revue de Presse Xebia

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Mobilité

Google Fuchsia, nouvel OS mobile en préparation

Google travaille depuis quelques temps sur un éventuel remplaçant d’Android pour les terminaux mobiles. L’interface utilisateur de Google Fuchsia a commencé à apparaitre sur Internet. L’objectif de ce nouvel OS est de proposer une meilleure expérience sur mobile. L’interface porte le nom d’Armadillo et aurait été conçue via le SDK Flutter qui permet d’utiliser le même code de base mais de déployer sur iOS et Android. D’après Phonandroid Google Fuchsia n’est pas prévu avant 2020, Google semble travailler activement sur son développement comme en témoigne le dépôt Github de Fuchsia.

Front

Nouveau Webpack CLI

Even Stensberg, un des contributeurs de webpack vient de l’annoncer, le nouveau CLI vient de sortir avec deux nouvelles grosses features : init et migrate. Si vous n’avez jamais osé vous lancer, c’est le moment, en suivant cette démo : https://github.com/ev1stensberg/webpack-addons-demo, vous verrez que ce n’est pas si compliqué ! Pour ceux qui veulent passer de webpack v1 à v2, c’est maintenant possible en une commande. À lire ici : https://medium.com/webpack/announcing-the-new-webpack-cli-75ce1d9b8663.

Projet Glimpse

Une équipe de Microsoft a développé un petit outil npm : « Glimpse« , il s’agit d’un outil de debugging. Son interface est proche du debugger que l’on trouve sur Chrome mais son avantage est qu’il fournit un diagnostic de l’application côté client et côté serveur, et agrège ces données de sorte d’avoir une idée précise des exécutions du code en front et back. Dans cette même idée, il affiche conjointement les logs client et serveur pour suivre clairement le traitement. À tester : http://blog.getglimpse.com/2017/05/08/introducing-project-glimpse-node-edition/

Data

Facebook open-source fairseq

FAIR, l’entité de recherche en intelligence artificielle de Facebook, a publié les résultats de leur travail de recherche en matière de traduction. Leur approche consiste à utiliser des réseaux de neurones convolutionnels, une technique de Deep Learning utilisée aussi pour la reconnaissance d’images et qui est assez différente des approches habituelles de traitement de texte basées sur des réseaux de neurones récurrents. FAIR annonce aussi la sortie de fairseq, (sequence modeling toolkit code source et systèmes entraînés), qui est maintenant disponible sur Github. L’implémentation est en Torch, framework de développement de Deep Learning utilisé par Facebook, Google et Twitter entre autres.

DevOps

Service Discovery et Load Balancing dynamique expliqués par Mesosphere

Après la première puis la seconde partie, Mesosphère vient de publier la troisième partie de leur série d’articles sur la gestion du « réseau » pour des conteneurs Docker.

Cet partie traite de sujets connus tels que la découverte et l’enregistrement de service ainsi que leur load balancing, mais sous un angle moderne : celui d’une architecture entièrement dynamique, introduisant par exemple la nécessité d’auto découverte et d’auto configuration des load balancers (où des projets tels que Traefik ou Linkerd ont vu le jour pour palier les load balancers existants, bien souvent configurés de manière statique).

Tout l’intérêt de l’article est qu’il présente très bien les différents concepts et patterns d’architecture plutôt que de s’attarder sur des implémentations de solutions en particulier. Une lecture très intéressante pour quiconque désire comprendre les problématiques apportées avec des environnements toujours plus dynamiques, temporaires et hétérogènes !

Enfin des reloads sans perte de paquets pour HAProxy !

Dans l’entrée précédente de cette Revue de Presse, nous parlions des « load balancers existants, bien souvent configurés de manière statique ». C’est exactement le cas de HAProxy, le load balancer souvent considéré comme la référence jusqu’à aujourd’hui, notamment en terme de performances.

Le reproche lui étant régulièrement adressé est que sa configuration statique nécessite un rechargement du service pour prendre en compte toute modification de configuration; rechargement qui peut entraîner une légère perte de paquets, ce qui pose problème dans une architecture hautement dynamique où le load balancer est très fréquemment reconfiguré, par exemple dès qu’un container est créé ou est détruit.

HAProxy viennent enfin d’améliorer ce rechargement afin d’éviter la perte de paquets ! Ce correctif sera présent dans HAProxy 1.8, et permettra potentiellement de ne plus être obligé de se tourner vers d’autres load balancers, plus dynamiques. L’article annonçant l’amélioration est rempli de détails techniques présentant le problème sous toutes ses coutures et fournissant la preuve que cette amélioration est d’ores et déjà fonctionnelle.

Confluent annonce Kafka As A Service

Confluent vient d’annoncer « Confluent Cloud », qui n’est ni plus ni moins qu’Apache Kafka as a Service.

Jusqu’ici, en cas de nécessité d’une plateforme de streaming real-time, 2 choix émergaient : héberger son propre cluster Kafka, avec toute la maintenance qui s’ensuit, ou se tourner vers un fournisseur de cloud comme Amazon avec AWS Kinesis, introduisant un réel « vendor lock-in ». Ce Kafka as a Service proposé par Confluent offre donc une alternative très intéressante pour quiconque voudrait se lancer dans la gestion d’évènements en temps réel, sans pour autant avoir à former les opérationnels sur la gestion d’un cluster Kafka et en se gardant la possibilité de migrer plus tard vers un kafka interne sans avoir à changer quoi que ce soit côté applicatif.

La question qui se pose d’emblée est « où sera hébergé ce Kafka as a Service ? ». En effet, pour un service autant focalisé sur la performance, il serait dommageable d’introduire un temps de latence considérable uniquement pour joindre le service depuis l’application qui le consomme (et qui sera bien souvent hébergée par un des majeurs fournisseurs de cloud public). Confluent y a visiblement pensé, et annonce que Confluent Cloud sera disponible tout d’abord sur AWS, puis sur Azure et Google Cloud.

En revanche, Confluent Cloud ne semble pour l’instant qu’en early access et le modèle de paiement n’a pas été révélé, laissant donc planer un doute quand à sa pertinence en terme d’investissement.