26 septembre 2014

Bye Bye RUN@Cloud

Vous êtes nombreux à me contacter pour connaître les tenants et aboutissant de l'arrêt de l'offre RUN@Cloud de CloudBees. Certains s'inquiètent même de me voir pointer aux Assedic. Explications

Disclaimer: ce billet n'engage évidement pas mon employeur, il n'exprime que ma perception des choses, bla, bla, bla 


Donc voilà, jusqu'à cet été, CloudBees était connu pour 3 offres, certains d'entre vous n'ayant d'ailleurs jamais entendu parler de l'une voir de deux d'entre elles :
  • RUN@Cloud, la "Plateform as-a Service" qui justifiant le sous-titre "CloudBees, the Enterprise Java PaaS"
  • DEV@Cloud, le "Software as-a Service" de continuous deployment basé sur Jenkins et la virtualization de l'infrastructure de build.
  • Jenkins Enterprise, une offre plus "traditionnelle" avec une souscription support et une version "entreprise" de Jenkins (plugins spécifiques, etc...)

L'activité sur RUN est (était) en croissance régulière, donc le marché existe, par contre nous avons toujours été confronté à plusieurs freins, tantôt techniques - ceux là encore c'est facile - tantôt politiques ("mes données ne sont pas en sécurité"), tantôt liès à la maturité du milieu. 

En particulier, nombreuses sont les entreprises qui préparent un "Private Cloud" qui n'est parfois qu'un IaaS à base de VMWare ou d'OpenStack, et dont les APIs sont remplacées par un formulaire rose. D'autres ont un peu mieux compris l'idée d'un PaaS mais ne voient pas ce qui différencie l'offre d'un CloudBees/Heroku/Google comparée à installer Dokku ou un truc de ce genre. Bref, de longues heures d'avant-vente, pour grignoter des parts d'un marché qui existe bien, mais fortement concurrentiel et en croissance finalement assez lente, ou plus précisément LINEAIRE.

A côté de ça, DEV@Cloud progresse lui aussi avec les mêmes contraintes (concurrences de divers services *-ci.io, craintes diverses "mon code n'est pas en sécurité", etc), mais surtout le marché Jenkins Enterprise explose. 

Jenkins devient un élément stratégique dans de nombreuses entreprises, et l'équipe ventes de CloudBees a du sensiblement grossir pour adresser la demande. La continuous integration passe progressivement dans le monde du continuous delivery, autrement dit l'outil de l'équipe de DEV devient l'outil de la DSI, avec ne nouvelles ambitions et un tout autre niveau d'exigences. Par ailleurs, l'annonce de Jenkins Operation Center laisse entrevoir un "DEV@cloud privé" qui plait à beaucoup de nos clients. Le marché ici est EXPONENTIEL

Par ailleurs, Jenkins Enterprise tend à fusionner avec DEV@Cloud. Nous pouvons associer des machines on-premises à un master DEV@Cloud, nous pourrons bientôt décharger un jenkins on-premises en allouant nos esclaves de build, l'infrastructure de DEV@Cloud profite des développements sur Jenkins Enterprise et Operation Center (vous avez une ferme de 10.000 Jenkins ? non ? nous si !). Bref, ces deux offres vont évoluer ensemble et profiter l'une de l'autre, effaçant progressivement la barrière "Cloud / pas Cloud".

RUN@Cloud dans l'équation est donc le mouton noir. Le projet est passionnant mais nécessiterait une équipe dédiée pour le faire évoluer rapidement et suivre le marché, sans permettre aux autres offres CloudBees de profiter de l'effort investit. D'où la décision un peu abrupte pour nos clients d'arrêter le service. L'offre PaaS est riche, aussi déménager leurs applis ne devrait pas être un soucis. Cela nous libère aussi pour établir des partenariats plus clairs avec des fournisseurs PaaS comme Pivotal (annoncé au même moment)

DotCloud a eu le même problème avec le succès de Docker. Investir à 200% sur un projet qui croit en puissances de 10, ou maintenir en tâche de fond un PaaS juste pour être sur de ne pas louper un marché à venir ? 

Voilà, donc pas de panique, j'ai encore du boulot pour un bon moment (mais bon, si vous avez une offre avec 6 zéros à me faire ... :P)

22 septembre 2014

Docker on Raspberry

Docker is such a lightweight virtualization solution that it make sense even running on a raspberry.

BreizhCamp's voting machine "LikeBox" uses such a device, and our embedded software is modularized into subsystems. Was a cool challenge to run them inside docker containers, don't you think so ?

Raspberry default OS "raspbian" don't offer a docker system package. As we are more familiar with Debian/Ubuntu I wish I could find one, or maybe use some cross-compilation (docker uses docker to build, so no-way to built it from sources on the target platform). Anyway, as a Proof-of-Concept I'm relying on ArchLinux, as this one has a Docker package !

So first step is to download the system image and copy it into a SD card (when you type such a command, double check the target device ID - also double check the SD card isn't the one with last summer holidays pictures... :-\)

sudo dd bs=1m if=ArchLinuxARM-2014.06-rpi.img of=/dev/disk5

this takes some time ...

new installing Docker is just trivial thing : Arch's package manager PacMan will handle it for you

[root@alarmpi ~]# pacman -S docker
resolving dependencies...
looking for inter-conflicts...

Packages (2): sqlite-3.8.6-1  docker-1:1.2.0-1

Total Download Size:    3.07 MiB
Total Installed Size:   15.02 MiB

:: Proceed with installation? [Y/n] Y


et voilà, I now can start a raspbian container on my Arch Linux :

[root@alarmpi ~]# docker run -ti --rm resin/rpi-raspbian /bin/bash
root@b088dc9a7e31:/#

Have now to test how to enable docker container to access raspberry GPIO and I2C bus, so I can actually package the apps into a container.

What's the benefit for this ?

During development, we use some mock library to emulate the i2c connected 2 line display and the GPIOs capturing user input (i.e. red / green voting buttons). I wonder I could make the application fully agnostic, and encapsulate those technical implementation details into containers, I would link at runtime to application code, resulting in some micro-micro-service architecture :-D

The other reason is ... fun :)