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.

 

Front

Sortie de create-react-app v1.0.0

Le 22 Juillet 2016, la communauté React et une de ses figures de proue, Dan Abramov, lançait un boilerplate simple, efficace et supporté par Facebook, pour démarrer un projet React en quelques minutes : create-react-app. Tout y était inclus pour commencer à coder immédiatement, sans avoir à se soucier des longues étapes de configuration inhérentes aux projets Javascript : Une suite de testing (Jest, Enzyme), une architecture de fichiers qui suit les standards actuels, une gestion des variables d’environnement etc… Mais surtout une configuration Webpack pré-faîte, avec gestion du hot-reload, des loaders les plus communs, de babel et bien plus encore !

Depuis sa sortie, create-react-app a été très largement plebiscité (>26k stars, >3k forks) et revient encore plus fort avec sa version 1.0.0. Au menu de cette release, le passage à Webpack 2 sorti il y a quelques mois, un runtime error overlay avec lien vers le code incriminé directement dans votre IDE (attention, killer feature), une création par défaut du projet en mode Progressive Web App etc… Rendez-vous sur la page github du projet pour retrouver tous les détails de cette release.

Est-ce que la transpilation est encore nécéssaire ?

Depuis l’arrivée d’ES2015, la transpilation est devenue une étape nécéssaire pour produire du code moderne supporté par l’ensemble des navigateurs. D’ailleurs, tous les boilerplates comme create-react-app l’inclue par défaut. Mais est-elle encore nécéssaire aujourd’hui? Dans son article « You might not need to transpile your Javascript« , Alex Ewerlöf se pose la question et alimente sa réflexion par des statistiques sur les navigateurs actuels, notamment leur support des dernières features du langage Javascript. Il répond également à une question primordiale : « A quoi ressemblera le futur sans transpilation ? »

DevOps

CoreOS annoncent zetcd

CoreOS viennent d’annoncer zetcd, un proxy capable de traduire le protocole de Zookeeper vers un cluster etcd en backend.

Techniquement, le mapping des directories de Zookeeper vers une « flat » liste de clés coté etcd est intéressante et originale; il en va de même pour leur implémentation d’un cross-checking capable de répartir une requête à la fois vers un vrai Zookeeper et vers un cluster etcd afin d’en comparer les résultats pour s’assurer que zetcd réagit exactement de la même manière que Zookeeper.

Côté performances, il y a bien évidemment un surcoût non négligeable, mais qui semble rester raisonnable. Gardons à l’esprit qu’il ne s’agit ici que d’une version 0.1 qui sera sans aucun doute sujette à de nombreuses améliorations !

Sur une note plus personnelle, je me trouvais à la dotScale 2017 il y a un mois, et ai eu le plaisir de discuter avec Benjamin Hindman, co-créateur de Mesos ainsi que co-fondateur & architecte en chef à Mesosphere. j’ai abordé avec lui les reproches souvent faits à Zookeeper (que Mesos utilise) ainsi que l’éventualité de rendre Mesos compatible avec etcd; la conclusion a été que oui, ce serait intéressant, mais qu’il fallait que quelqu’un prenne le temps de rendre Mesos compatible avec etcd; zetcd arrive donc à point nommé comme solution de repli pour qui aurait déjà un cluster etcd et souhaiterait s’en servir pour faire tourner Mesos, Kafka ou autre.

Le projet CNI (Container Networking Interface) rejoint la CNCF

La CNCF, déjà mentionnée lors de précédentes revues de presse, accueille désormais le projet CNI en son sein.

Concrêtement, CNI vient se placer entre le runtime des conteneurs et les différents backend réseau afin de fournir une interface standard. Le projet se découpe en 3 parties : une spécification, un ensemble de plugins, ainsi qu’une bibliothèque en Go implémentant la spéficiation sus-mentionnée. Un projet qui est donc le bienvenu dans l’effort de standardisation du monde des conteneurs auquel contribue la CNCF sur tous les fronts.

Google, IBM et Lyft annoncent Istio

Google, IBM et Lyft viennent d’annoncer Istio, un composant ayant pour but de « connecter, gérer et sécuriser des microservices ».

En résumé, il s’agit d’un nouveau linkerd ou Traefik, avec bien sûr quelques différences :

• Contrairement à Traefik mais comme linkerd, Istio supporte la gestion de requêtes gRPC
• Contrairement à Traefik et linkerd, Istio ne se limite pas à la couche 7 et sait directement load-balancer et gérer des flux TCP
• Nouveauté différenciante, et non des moindres, toute la partie « management/sécurité » : rate limiting, gestion d’ACLs, d’authentification et d’authorization

Istio se base sur Envoy (d’où la présence de Lyft dans le trio créateur) et a pour principal but d’en fournir une version plus complète, managée et « out of the box », ciblant pour l’instant Kubernetes.