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.

02 Feb 2016, 13:42

Lektor

J'ai découvert ces dernirs jours Lektor qui se définit comme :

A flexible and powerful static content management system for building complex and beautiful websites out of flat files — for people who do not want to make a compromise between a CMS and a static blog engine.

Pour un projet, j'ai besoin d'un site contenant une partie vitrine et une partie blog. Je recherchais donc un CMS avec lequel je pouvais avoir plusieurs modèles de données et sans rentrer dans la lourdeur d'un site propulsé par Drupal ou eZ Publish. En parcourant le site StaticGen, outre que la liste a considérablement augmenté, je suis tombé sur Lektor. Le nom ne m'était pas inconnu ; je savais que derrrière ce projet se cachait Armin Ronacher, l'homme derrière Flask, Sphinx, Jinja, Pygments, etc.

Après deux soirées passées dessus, je suis assez content du résultat obtenu et au final, on se retrouve avec un bon mix entre un CMS et un générateur de site statique:

  • Facilité pour modéliser ses contenus
  • La flexibilité du modèle à la volée est juste géniale,
  • Possibilité de surcharger le template qui s'applique par défaut à une page
  • Possibilité d'éditer via l'IHM Web ou directement les fichiers
  • Une prévisualisation qui permet de voir le rendu final du site et de naviguer in situ.
  • Un moteur de template puissant
  • Capacité de "requêter" les contenus pour afficher ce dont on a besoin
  • Au final un site purement statique (donc faible besoin en ressources d'hébergement)

Alors certes, on pourrait reprocher à l'inverse que l'UI Web est un peu minimaliste mais globalement, ça fait bien le boulot et Lektor tient bien sa promesse.

 

27 Jan 2016, 09:30

Around the Web - January 2016 - Website obesity crisis, AngularJS & Postgres

Website Obesity

  • Website obesity crisis : transcript of a talk (video can be seen too from the link) about webperformance, bloated websites and how fat sites become for almost no real value for end users. Long but funny and instructive. It makes you think on how complex, fat and bloated the web is nowadays, in terms of tooling, architecture, code and content.

AngularJS

Postgres

  • The most advanced opensource database of the world, ie Postgres for short, was released as 9.5 version (FR / EN) ; it brings the long expected "UPSERT" features, Row level security and some big-data features (improved index, faster sorts, connection to Hadoop/Cassandra via FDW, etc)
  • In French a deeper view of the 9.5 release (part 1, part 2, part 3) to better understand what contains this release.

 

13 Jan 2016, 09:30

Around the Data - January 2016 - Spark & Elasticsearch

Spark

  • Spark-TS is an addon to spark by Cloudera to ease working with time-series data : announce ; code ; website
  • SparkR is the ability to use Spark with R (programming language for statistical computing and graphics) ; a blog post in French to discover this API.
  • Spark 1.6 released (via); beyond bugfixes, improvements and performance:
    • New DataSet API (flagged as experimental) : it brings SparkSQL Engine on top of RDD ; Changes on the API between Dataset and Dataframes will be made post 1.6 release.
    • New models/algorythm for MLlib
  • Introducing Spark Datasets : the blog post presents Datasets and how they are more performant on structured data than RDD or Dataframes.

Elasticsearch