08 Aug 2016, 12:48

Hygiène de vacances

Pendant les vacances familiales, nous avons pris l'habitude depuis trois ans, de nous imposer une cure de produits électroniques. Cette décision avait été prise suite à notre première utilisation du camping-car où l'électricité est limitéée. Cette contrainte avait été transformé en opportunité de passer 100% du temps avec nos deux enfants et tant les parents que les enfants doivent débrancher du portable, de l'ordinateur, de la console, etc. Notre utilisation des téléphones se limitant au GPS et à appeler pour nos activités de vacances si besoin.

Si cela fut (et reste) un peu dur les premiers jours de part les habitudes, on s'habitue assez vite. Les enfants, ayant cru d'abord à une mauvaise blague, puis ayant vécu la chose sont plutôt demandeurs au final. La seule exception à la règle étant les jours de pluie où l'on ne peut rien faire et les sorties au restaurant. En contre partie, nous avons (re)découvert les jeux de sociétés et faisons plus d'acitivités familiales. On ne peut pas en effet demander des efforts à un enfant sans une certaine contrepartie. Elle peut demander un effort aux parents, mais là aussi, une fois sorti des habitudes, on apprécie cet effort de part les bons moments passés ensemble et globalement de l'avis de tous, de bonnes vacances. Chacun y trouve son compte dans l'effort consenti et dans ce qu'il en retire.

Cette année, malgré le fait qu'on ne soit plus en camping-car, nous avons maintenu cette règle et ce sans que les enfants cherchent à la remettre en cause. Les enfants ont même découvert cette année le plaisir de lire au restaurant par exemple (plutôt que d'emmener leur console).

Le retour à la réalité et aux anciennes habitudes semblent assez simple pour les enfants ; même si on essaie de faire durer cette déconnexion un peu au-delà. Pour moi, cela doit être assez progressif ; un retour trop rapide sur twitter par ex est plus vécue comme une "agression" lié à cet afflux d'information à traiter. Et comme chaque année depuis trois ans, je me demande jusqu'à quel niveau de connexion je dois me remettre et considère cette période de déconnexion comme salutaire.

Se déconnecter et prendre son temps pour faire des choses vs être connecté mais ingérer un flux d'information ; un équilibre toujours délicat à trouver et pour lequel les habitudes peuvent ne pas faciliter les choses.

Sur ce, je retourne méditer sur ce sujet et aménager mon sous-sol en vue de mes prochaines aventures à compter de novembre...

27 Jun 2016, 16:23

Farewell !

Hi there,

The bad news : this blog as you knew it wll be inactive from now.

The good news : if you read French, you can follow me on CerenIT's blog. There is of course an RSS feed but mailchimp subscription has been removed.

It was and still is a good exercise as it allows to see trends over months, set dates & facts vs information streaming on twitter & co and of course helped me a lot to have a "technology radar" from which I could follow things over time. Explaining things is also a challenge, hope I did well on this and that you got some value from blog posts.

Except my family"s blog, seems it was my longest and more regular blogging experience so far: Almost 4 years and 110 blog posts !

See you maybe on the other side !

11 May 2016, 00:30

Entreprise 2.0, Entreprise libérée, Transformation digitale ne sont rien d'autre que l'application des principes/effets de l'open source au reste du monde

J'ai eu un long échange téléphonique il y a peu avec un recruteur pour un éventuel poste dans une société accompagnant ses clients dans leur transformation digitale et elle-même évangélisant, voir se revendiquant comme appliquant un certain nombre des principes liés à ces mutations. D'ailleurs on peut se demander pourquoi ce genre d'entreprise fait appel à des recruteurs traditionnels vu qu'elle devrait naturellement attirer du monde, mais ce n'est pas l'objet de ce billet.

Au cours de cet échange, nous avons parlé de transformation digitale, lean startup, entreprise libérée et bien d'autres buzzword du moment, S'il est vrai que j'aime assez peu ces buzzword (même si je peu adhérer à des idées / valeurs sous-jacentes). En effet, ils sont souvent dévoyés et au final, les entreprises adoptent surtout des postures sans que la transformation culturelle ne se fasse. Ces entreprises n'ont alors que la façade "nous sommes agiles / devops / entreprise libérée / des champions du digital / <autre buzzword du moment>" mais au quotidien, rien ou presque n'a changé.

Pour revenir au titre du billet et si on regarde plus attentivement les principes et/ou effets de l'open-source, on peut lister notamment (liste non exhaustive) :

  1. La désintermédiation : l'open source a permis à tout un chacun d'apporter son bout de code et de casser le modèle du logiciel propriétaire. Il n'est plus nécessaire d'être un gros éditeur pour que son code/logiciel soit utilisé.
  2. La gratuité : même si la gratuité n'est pas obligatoire dans l'open source, c'est la majorité des cas. Pour un coût faible ou nul, vous disposez d'un logiciel pour en faire ce dont vous avez besoin.
  3. la fin des hiérarchies : le modèle communautaire a applati les hierarchies d'un projet. Même s'il reste des rôles de commiters, ils sont limités et globalement tout le monde peut dire son opinion.
  4. Méritocratie et expertiste plutôt que le management : conséquence du point précédent notamment, la communauté étant ouverte, on obtient ces lettres de noblesses en faisant ses preuves plutôt que par son titre
  5. Approche communautaire/plateforme : chacun apporte et contribue selon son besoin
  6. Transparence : tout est ouvert

Si nous prenons nos sujets du moment :

  • Entreprise 2.0 (ie collaboraiton en entreprise) : reprend les points 1, 3, 4 voire 6 en favorisant la connection directe entre les employés, valorisant le partage d'expérience/expertise et contournant le manager (souvent).
  • Entreprise libérée : reprend les points 1, 3, 4 et 6 : des hiérarchies plus plates, les "sachants" contribuent aux décisions, les décisions sont partagées, etc.
  • Transformation digitale: reprend l'ensemble des points 1 à 5 : désintermédiation, faible cout de transaction pour les utilisateurs finaux, les petits prennent le pas sur les gros, approche plateforme/communautaire, élimination des barrières à l'entrée, etc.

On peut je pense faire pareil pour les Civictech ou encore la blockchain et surement encore d'autres mouvements en cours pour une tendance plus globale en fait d'un "Opensource everything"(tm)(c)(r).

Après, pour être honnête, il y a des principes / effets de l'opensource qui ne sont pas (encore ?) repris comme l'interopérabilité (au mieux, on pourrait retenir la notion d'API mais cela reste des silos fermés globalement), la perpétuité (cela reste des entreprises...) ou encore la sécurité (valable pour la blockchain par ex mais pas ou peu pour le reste).

Si je ne nie pas ces tendances/transformations, j'ai l'impression que l'origine est plus vieille que ce que l'on veut bien nous faire croire et que l'open source peut expliquer une bonne partie de ces tendances appliqués à d'autres domaines...

27 Apr 2016, 09:30

Web, Ops & Data - April 2016

Infrastructure

Container

  • Elastikube : an infrastructure management solution for Kubernetes ; seems a lighter version of Openshift.
  • Containers are not VM : Docker precise the difference between a container and a VM with the analogy between Flat and House. A houste (VM) is full featured whereas the flat share some resources with its building.
  • Docker announced Docker pour Windows/Mac (beta) ; it provides a more native experience of Docker on Mac/Windows machine. On Windows, it requires Windows 10 at least to benefit from the Hyper-V hypervisor. On this topic, the Hypriot team, in their Docker for Mac review and Docker for Windows review introduces the easter egg of this version: it's now possible to run ARM containers on OSX/Windows environments ; It will allow to build containers for Raspberry or IoT projects in a faster and easier way. I can't test it now but seems far les complex to use than Docker Toolbox.
  • Rancher, another container orchestration solution, announced first their support of Kubernetes and then the release of the version 1.0. Project to follow, even if the concept of environment may not allow an optimialistic allocation of ressources (each environment would have its own hosts) whereas Kubernets may allow this with their global namespace approach.
  • Kubernetes, the container orchestration solution (for Docker/Rocket containers), built by Google, was just released as version 1.2 with lots of improvements and especially a new GUI (for the one not at ease with CLI).
  • Kubernetes on ARM also released their 0.7 version ; an easy way to learn kubernetes on your Raspberry box. ;-) ; A rancher image is also available.
  • Docker en production : la bataille sanglante des orchestrateurs de conteneurs : To conclude, OCTO compared Docker Swarm, Kubernetes and Openshift and states Kubernetes as the current winner. From my point of view, as we can use Docker container with both solutions, it may be more intersting to use both : Docker swarm in a dev/lab oriented manner and Kubernetes more for operations. Kubernetes was initially built for ops and tries to be also developper friendy, with Docker doing the opposite.

Elasticsearch & friends

InfluxDB & Friends

Sysadmin

  • Teleport ; A SSH gateway which allows to access to servers via SSH or HTTPS with a Web GUI.

Security

  • VNCFail ; vous reprendrez bien un peu de non sécurité: The analysis of 4 billion IPV4 addresses from which 5 millions hosts have VPN (remote control software) opened and at the end 2.246 hosts for which you can access systems without any password. Systems as air condionnting, electricity factory, etc.

30 Mar 2016, 09:30

Around the Web - March 2016 - Javascript, Citus DB and Dependencies

Javascript

Postgres

Dependencies

16 Mar 2016, 09:30

Around the Data - March 2016 - Kafka Connect and Streams, Hortonworks HDP 2.4, Elasticsearch cluster sizing, Spark Graph Frames, Flink 1.0

Kafka

  • Kafka 0.9.0.1 and Confluent 2.0.1 were released (bugfix release)
  • A more detailled presentation about Kafka Connect.
  • Confluent released a custom version of what will be in Kafka 0.10 and it's called Kafka Streams ; it aims to manipulate data within Kafka without requiring any external system such as Spark & co. Interesting move to make it feature richer and more autonomous to enirch data but challenge may be that kafka was performant due to it's low level of features. Will it remain performant with such additions ?

Hortonworks (Hadoop Distribution)

Elasticsearch

Spark

  • Databricks introduces Graph Frames ; it"s built on top of Spark Data Frames (and related APIs) and aim to ease manipulating graph data.

Flink

09 Mar 2016, 17:01

Porn Data

Explorant depuis quelques mois le sentier du Big Data, j'avoue pour le moment rester sceptique à plusieurs niveaux et ceci amenant ce titre. Je ne nie pas cependant l'intérêt de Big Data pour certains cas d'usage.

Les points ci-dessous sont un point à date, avec ma connaissance actuelle de l'écosystème ; il y a forcément des choses ajustables / améliorables ; que les personnes plus avancées que moi dans le domaine se fasse un plaisir de commenter pour partager leurs visions.

Commodity hardware (ou pas)

Pour moi, du Commodity Hardware, c'est plutôt une VM du genre 2 vCPU/ 4 Go RAM et dans les versions les plus gourmandes, 4 vCPU / 8 à 16Go RAM.

Dans leur livre blanc sur le Big Data (dont je recommande la lecture par ailleurs), OCTO, pour une configuration moyenne, annonce:

Master node : 4 CPU / 96 Go RAM / n To / 2 NIC

Slave node : 6 CPU / 96 Go RAM / n To / 2 NIC

Quand ont sait qu'un cluster Hadoop, c'est un minimum de 10 machines environ. Si on prend les couts AWS pour des profils autour de 64 Go de RAM, nous sommes vite à un minimum de 500$ / mois / machine, soit 5.000$ / mois ou 60.000$ / an pour le cluster. A comparer avec un profil moyen (2 vCPU/4 Go RAM) autour de 40$ / mois / VM.

Il est heureux de savoir qu'avec une infra qui te coute jusqu'à / voire a minima 10 fois plus cher par VM, tu es en mesure d'analyser beaucoup plus de choses. Certes, on peut démarrer avec des profils plus modestes mais on tombe vite à 4 à 5 fois le prix d'une VM moyenne.

Enlarge your infrastructure

J'ai déjà abordé le point précédemment, mais avec le nombre de composants à installer et le jeu des quorum pour garantir la résilience des données et assurer la distribution des jobs, on se retrouve vite avec :

  • 2 Master nodes
  • 3 Data nodes
  • 4 workder nodes (replication factor des data nodes +1)
  • 1 Edge node pour les IHM d'admins, etc.
  • 1 à n nodes pour d'autres composants.

Il y a plusieurs typologies possibles (on peut mutualiser Worker node et data node pour avoir des traitements au plus près des données, mais la scalabilité est moins évidente par ex) mais globalement, en dessous de 10 VMs ; point de salut.

Un écosystème complexe

Je fais l'impasse sur le coté mature, ne m'attachant pas particulièrement à ce que les projets soient en version 1.0+ pour les utiliser. Je préfère une solution en 0.x qui est utilisée massivement par un ou plusieurs gros acteurs  (ex de Kafka 0.x avec LinkedIn et plus de 1000 milillars de message par jour) qu'une version 1.0+ moins éprouvée.

On peut certes monter sa plateforme hadoop soit-même en prenant les composants à droite et à gauche en fonction de ses besoins. Néanmoins, cela demande une certaine maturité. Pour pallier à cela il existe des distributions, qui à l'image des dristributions linux, font un packaging complet et une intégration permettant un déploiement rapide. On peut d'ailleurs saluer l'éditeur Hortonworks qui fournit une solution opensource de bout en bout, bien packagée et avec des composants très à jour.

I want more data / all your data

Le principe du datalake veut que l'on stocke tout dans le format le plus brut possible et décider plus tard du mode d'utilisation. Il arrive même qu'on redécoupe les données reçues en plus petites données pour une manipulation ultérieure. Outre le fait que l'on duplique les données de système existants, peut-on aller vers un SI où toutes les données de toutes les applications sont dans le datalake et consommé par les applications ? Cela me parait plus aller vers un SPOF (malgré la réplication et distributions des données) qu'autre chose. Cette tendance à remettre tous ses oeufs dans le même panier ne va pas de soi pour moi ; surtout quand on voit l'émergence des architectures microservices en parallèle.

A l'inverse, faire n datalake en fonction de domaines et des usages me parait prohibitif du fait de l'infrastructure sous-jacente requise.

Par ailleurs, plutôt qu'une donnée brute, je serai plutôt à la structuer à minima pour qu'elle soit plus facilement exploitable ensuite. Par exemple, une ligne brute de log devient un "objet" log avec des attributs.

Ok, mais le cluster Hadoop traite vite les données

Pour être totalement cynique, c'est bien le minimum que il puisse faire en fait. Si 1 seul job spark s'alloue minimum 4 Go de RAM, il a bien intérêt à être rapide et il peut bien envisager de faire du temps réel.

Jusqu'à présent, je n'ai rien à dire à ce sujet ; ça fait bien le job, il faut le reconnaître mais nous n'en sommes qu'à nos premiers cas d'usages et sur des volumétaires encore faibles.

Licences Editeur qui ne sont pas élastiques

Dans un modèle qui veut favoriser l'autoscaling, les éditeurs proposent des licences qui est fonction du nombre de VM. Si je reconnais qu'il n'est pas évident de trouver un modèle de licensing, avoir un modèle à la VM est plutôt dissuasif (mais dans l'intérêt de l'éditeur) puisque si tout se passe bien, votre cluster Hadoop doit forcément s'aggrandir...

Conclusion partielle

A ce stade :

  • Je me demande si dans bon nombre de cas, en occtroyant à une application une architecture simplement plus puissante ou bien en achetant les options qui vont bien pour des solutions propriétaires, on ne fera pas tout aussi bien pour moins cher. Se pose la question de la volumétrie réelle à partir de laquelle une plateforme big data est vraiment nécessaire et en vaut le coût.
  • Quand on compare un cluster hadoop à l'essai sur "Digital technology and infrastructure for the post growth time" qui promeut plutôt une logique minimaliste voire frugale, on peut se poser la question de la cohabitation de ces deux mondes.
  • Au regard de l'approche "microservices", on pourrait certes voir un cluster hadoop comme une plateforme microservice. Cela peut se valider de part la multitude des composants utilisables et la relative indépendance des composants. C'est peut être un peu abusif depart la complexité de l'ensemble et de Yarn comme ordonnanceur global et point de passage obligé (ainsi que Zookeeper).
  • L'omniprésence de Java ; Cela peut être vu comme une force (toute grosse entreprise a des compétences Java) mais aussi comme une faiblesse. Il y a certes des API en Python, R, Scala, etc mais n'empêche que le socle reste en Java et demande des compétences à ce niveau. Cela exclut de fait beaucoup de petites/moyennes entreprises je pense d'un tel projet.
  • Une approche encore trop piloté par la technologie et pas assez par les usages. Les enthousiastes de Big Data mettent en avant leur solution pour trouver de nouveaux terrains de jeux et justifier leur existence. Pour autant, est-ce vraiement la bonne solution ou bien un tank pour tuer un moucheron ?

Reste à voir si cette perception va perdurer avec le développement des usages ou si au contraire, les usages grandissant vont me permettre de voir cette plateforme rentabilisée, utile et adaptée aux besoins.

A suivre...

[Edition du 31/3] Big Data 2.0: Open Source Becomes A Converged Product : présentation intéressante sur les mutuations possibles autour de l'écosystème big data avec une approche plus orientée produit et moins plateforme. Avec pour conséquence une mutuation nécessaire pour les éditeurs des distributions Hadoop généralistes comme MapR, Hortonworks et Cloudera.

24 Feb 2016, 09:30

Around the Web - February 2016 - MySQL, Docker, Security & Webapps/API

MySQL

Docker

  • Official images are to move from Ubuntu to Alpine : main arguements are about disk space saving (and so bandwith and time to launch a container) and security (lower surface of attack).
    • "Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox" according to the site
    • First, I was sceptical as it requires the whole ecosystem to move from ubuntu to alpine ; indeed, wether you like it or not, people are used to ubuntu/debian and other mainstream distribution and all packages we are used to have are not yet available in alpinelinux also. To be honest, main packages are available.
    • Then, a debian or whatever base image will still exist, be safe with that ; however, if you want to "hack" / inherit from a docker base image, you'll have to switch to Alpine.
    • Third, we could consider that once your docker host has the base image in cache, the ~180M size of base image is not an issue. But starting from 5M may be a good argument however.
    • Starting testing it on ARM device and especially Raspberry Pi, I'm quite pleased with its reactivity and packages available.
  • Some tips to reduce the size of your docker image and also understand how size and layers impacts your docker image. Following the instructions, I could reduce my influxdb-chronograf docker image by 70M approx (from 360 to 290M if I'm correct)

Security & API/Web App

 

23 Feb 2016, 22:33

InfluxDB 0.10.x sur un Raspberry Pi (arm)

Après la série sur les version 0.9.x d'InfluxDB, le mode opératoire ayant changé un peu, cela mérite un nouveau billet :

$ wget https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer
$ chmod +x gvm-installer 
$ ./gvm-installer
Cloning from https://github.com/moovweb/gvm.git to /home/pi/.gvm
No existing Go versions detected
Installed GVM v1.0.22
Please restart your terminal session or to get started right away run
 `source /home/pi/.gvm/scripts/gvm`
$ source /home/pi/.gvm/scripts/gvm
$ gvm install go1.4.3
Downloading Go source...
Installing go1.4.3...
 * Compiling...
$ gvm use go1.4.3 --default
Now using version go1.4.3
$ mkdir $HOME/gocodez
$ export GOPATH=$HOME/gocodez
$ go get github.com/influxdata/influxdb
$ cd $GOPATH/src/github.com/influxdata/influxdb
$ ./build.py --package --version=0.10.3 --arch=armhf
$ sudo dpkg -i build/influxdb_0.10.3-1_armhf.deb

Et voilà !

Validé & testé sur un RPi2.

10 Feb 2016, 09:30

Around the Data - February 2016 - ELK, Kafka, Flink, Spark

Elasticsearch

Kafka

Flink

Spark

  • Spark 2015 year in review : Databricks (core developper of Spark) made a review of 2015 : the 4 release, the features, how spark is used, etc. I was surprised to see that majority of spark usage was as a standadlone cluster and not in an Hadoop context.