Sam High-Tech Blog

Active MQ dans le cloud – suite

Comme vous avez pu le lire dans le précédent article je n’étais pas arrivé au bout de l’exercice pour déployer ActiveMQ sur des offres PAAS. Et bien c’est chose faite, ça marche !

Mon erreur a été de me focaliser sur un problème réseau entre les VM (configuration, firewall…) En fait le problème était au niveau de l’ouverture des sockets. J’ai donc modifié le code du TCPConnector d’Active MQ pour l’adapter à mes contraintes.

Il faut juste changer le bind dans org.apache.activemq.transport.tcp.TcpTransportServer

public void bind() throws IOException {
  URI bind = getBindLocation();

  String host = bind.getHost();
  host = (host == null || host.length() == 0) ? "localhost" : host;
  InetAddress addr = InetAddress.getByName(host);

en

public void bind() throws IOException {
  URI bind = getBindLocation();

  InetAddress addr = InetAddress.getLocalHost();

C’est plus restrictif, mais suffisant pour mon cas.

J’ai repackagé cela dans un protocole tcpcloud et hop ça fonctionne sur cloudbees du premier coup. Maintenant ma charge est partagée sur les n instances (n=2 pour le moment comme j’utilise l’offre gratuite).

Pour CloudFoundry j’ai eu un peu plus de mal car même si je note dans le fichier de config « localhost », il passe le nom de la machine au runtime. Ca doit être le même système qui remplace l’url et le login/pass de la base de données. Ce côté un peu magique me dérange. Je dois aussi dépendre de leur lib cloudfoundry-runtime pour trouver l’adresse IP de la VM. En plus leur beau plug-in eclipse ne fonctionne pas sur Eclipse Indigo

Je vais pouvoir partir en vacances sereinement !

Active MQ dans le cloud

En ce moment je regarde pour développer une plateforme de push notification iPhone. Le but est d’offrir une surcouche applicative plus simple à utiliser que les sockets d’Apple. Un peu comme le service offert par urbanairship.

Ce qu’il faut bien comprendre avec le push d’Apple, c’est que pour envoyer une notification à 400 000 iPhone il faut ouvrir une socket chez eux et envoyer 400 000 trames avec un token différent par iPhone. En sachant qu’Apple peut banir une IP serveur si on envoie plus de 200 messages par seconde, il est important de répartir la charge sur plusieurs serveurs (ou au moins plusieurs IP publiques).

Donc j’ai pensé à mettre en place une architecture MOM :

Avec cette architecture on peut ajouter des Brokers JMS en fonction de la charge à absorber. L’idée est de profiter au maximum des services de cloud computing et offrant la possibilité d’ajouter/retirer au runtime des VM avec un Broker. C’est donc pour héberger cette solution que j’ai creusé les différentes offres de cloud computing (cf ce post). Mais c’est au moment du déploiement que j’ai rencontré des difficultés (bah oui comme d’habitude en fait…).

Le code qui va envoyer les messages JMS doit connaitre la liste de Broker. Or comme nous sommes dans le cloud, cette liste peut être modifiée au bon vouloir de l’administrateur. Pire je ne connais même pas forcément à l’avance les IP des Broker que je vais ajouter.

Donc imaginez si dans la configuration client je définis une URI du type :

failover:(tcp://primary:61616,tcp://secondary:61616)

Il va falloir modifier le code du client à chaque ajout d’un nouveau Broker. C’est donc impossible. Heureusement pour ce genre de cas Active MQ propose un système de multicast. Ce qui donne au niveau URI du client :

discovery:(multicast://default)

Là c’est magique sur mon serveur en local ça marche très bien. Et oui mais non Sur les offres cloud le multicast (sur UDP) n’est pas souvent supporté. Sur Amazon EC2 (donc sur CloudBees) et CloudFoundry (VMWare) impossible de faire fonctionner le multicast.

Donc comment faire ? Le client JMS a besoin de récupérer une liste de Broker. Il faut donc que chaque Broker vienne se faire connaitre au moment de leur lancement. Comme j’ai déjà un BDD autant l’utiliser pour référencer ces Brokers. J’ai donc développer un module de multicast via une BDD : multicasdb.

Donc on arrive sur une architecture comme celle-ci :

Pour le faire je me suis beaucoup inspiré du code du multicast UDP. Ca fonctionne bien sur mes serveurs de test mais là encore je tombe sur des problèmes spécifiques aux serveurs cloud : l’adresse du serveur. Comme c’est le même war qui est déployé sur tous les serveurs la configuration du broker doit être générique. Pas de pb : j’utilise localhost comme nom de serveur :

Donc oui je peux utiliser cette configuration sur tous les serveurs, mais si je persiste « localhost:8080″ en base le client ne pourra pas y accéder depuis un autre serveur. Donc il faut que mon code trouve l’IP du serveur pour le persister au runtime.

Aujourd’hui même si le code n’est pas finalisé, il fonctionne. Malheureusement j’ai toujours des problèmes pour l’héberger.

Chez Cloudbees la communication tcp entre VM est bloquée. Même si leur support affirme que ça peut fonctionner j’ai toujours des erreurs : java.net.ConnectException: Connection refused

Chez CloudFoundry j’ai même eu du mal à obtenir l’IP des VM. Le code qui fonctionne sur Cloudbees retourne 127.0.0.1 comme IP chez CloudFoundry. Pour trouver cette IP il faut utiliser un SDK fourni. Mais là encore :Connection refused

Bilan

Au final je n’ai pas réussi à faire fonctionner mon code comme je le voulais. Par contre cette petite expérience m’a permis de faire mes premiers pas sur 2 offres de cloud intéressantes. Aujourd’hui je trouve CloudFoundry beaucoup plus agréable à utiliser que CloudBees. Son SDK est très simple et en 20 secondes je peux redéployer une version. Avec CloudBees j’ai beaucoup de mal avec le SDK. Déjà c’est basé sur un script Ant… Alors il y a aussi un plug-in maven mais je n’ai pas pu l’utiliser en mode « Delta » du coup il faut uploader totalement mon War à chaque modification : 10 minutes. Je trouve aussi le plug-in Eclipse de CloudFoundry mieux fait. Par contre CloudBees possède une vrai interface d’administration web et son offre DEV@Cloud est vraiment intéressante. Un bon point pour les 2 : la réactivité du support. Une réponse dans la journée, pour mon compte gratuit de test, c’est vraiment bien (n’est ce pas Nicolas )

Pour revenir à mon problème initial, je vais continuer à creuser ce problème de communication inter VM et si je n’avance pas je vais revoir l’architecture. Peut-être persister les messages à envoyer: c’est moins performant mais ça peut aussi répondre à un besoin de suivi de diffusion.

La phase d’intégration d’un projet est toujours sous estimée J’ai vu des projets où cette phase était même plus importante en terme d’homme/jour que la phase de développement. Mais pour un hébergement dans le cloud il faut vraiment prendre cette problématique dès le début de la conception. C’est loin d’être un détail

Dans Ton Cloud

Depuis 2 semaines je regarde différentes solutions de cloud computing.

Dans un premier temps j’ai regardé les offres « bas niveau » :

MiniCloud d’OVH

C’est une offre abordable mais qui est en test depuis plus d’un an. C’est une facturation « Pay as you go » mais il manque deux fonctionnalités importantes : le load balancing et le clonage d’instance. L’adresse IP des instances change à chaque arrêt/relance ce qui peut être génant.

Amazon EC2

L’offre cloud la plus célèbre, j’ai arrêté l’inscription au moment d’entrer un numéro de carte bleue. Impossible de faire sans et comme le détail des tarifs est assez flou j’ai préféré ne pas le faire.

So Privé

Le site So privé est fermé pour ouvrir OUTSCALE.

Rackspacecloud

L’offre la plus intéressante pour le moment, load-Balancing clonage de VM, « Pay as you go ». Il manque juste des images un peu plus complètes avec par exemple un tomcat ou mysql.

ikoula

Grosse pub pour leur VM à 1 Euro mais c’est uniquement des VM Windows -> Fail

Obtenir une VM avec un OS c’est bien, malheureusement je ne suis pas ingé système mais développeur Java donc si je pouvais utiliser des offres clouds faites pour déployer un war je gagnerais du temps. Et c’est exactement ce que propose Cloud Foundry et CloudBees. Oui Google App Engine le fait aussi mais dans mon cas j’ai besoin d’ouvrir une socket vers un serveur distant et donc GAE est out

Cloud Foundry

C’est l’offre de VM Ware et Spring Source en version Beta pour le moment. En quelques minutes j’ai mis en ligne l’exemple Hello Word. Le plus long c’est de recevoir l’email d’inscription. Le SDK s’installe en 2 minutes grace à ruby (gem est pré-installé sur Mac).

Après le Hello Word j’ai déployé un war plus complexe très rapidement. Le plug-in eclipse est aussi très bien fait, on peut voir les ressources consommées par les applications, ajouter des instances (2 max pour le moment), les arrêter. Par contre j’ai eu un problème au niveau de l’affichage des logs. Sur Eclipse ce n’était pas à jour contrairement à ce qu’affichait la commande « vmc logs ».

CloudBees

Là encore CloudBees propose une solution pour déployer du code Java simplement. Le plus par rapport à Cloud Foundry c’est l’offre DEV@cloud qui propose une solution de GConf (GIT ou SVN) et une plate-forme d’intégration continue Jenkins. Ils sont placés pour Jenkins puisque Kohsuke Kawaguchi a intégré leur équipe.

RUN@cloud est proche de l’offre de Cloud Foundry en se limitant au Java. Le plus c’est le monitoring des instances et la possibilité d’uploader un war depuis l’interface web. Par contre j’ai trouvé le SDK et le plug-in eclipse beaucoup moins faciles à utiliser comparés à ceux de Cloud Foundry.

Le gros problème de ces deux solutions, pour héberger mon application, c’est qu’elles ne supportent pas le multicast UDP. Je vais faire un autre poste plus tard pour détailler mon problème.

Conclusion

J’ai bien aimé tester ces offres rapidement et gratuitement. On peut enfin déployer du code java facilement. Avant il fallait louer un serveur privé pour pouvoir installer un serveur tomcat et ce n’était pas une solution économique (minimum 15 Euros par mois). Maintenant en quelques minutes notre war est disponible sur le net.

Après peut-on utiliser CloudBees ou Cloud Foundry pour déployer une application pro?  C’est à voir puisque je n’ai pas regardé comment affiner la configuration du serveur d’application. En tout cas c’est très prometteur.

Autres articles :

• Premiers pas sur CloudBees par Benoit Courtine
• Blog de Xebia : Lancement du projet PAAS cloud foundry de spring source
• Blog d’octo : Et si nous definissions simplement le cloud computing

Obeo Designer Roadshow

Hier se déroulait à Brest le ObeoDesigner roadshow.

Avant de présenter l’outil, il faut commencer par la base.

Le DSL : Domaine Specific Language

Le principe est de définir son propre langage pour modéliser son environnement. Là où en UML on a (pratiquement) que des classes, dans un DSL on peut utiliser notre langage métier et parler de « Portable », d’ »Avion » etc.. Mais qui dit nouveau langage dit nouvelle représentation graphique. Avec un DSL il faut aussi réinventer vos propres représentations graphiques. Lorsqu’on utilise UML on a l’avantage d’avoir pléthore d’éditeurs graphiques sur le marché.

Mais plus grave à mon avis : on ne partage plus la même représentation graphique. Lorsque je lis un diagramme de séquence UML je sais si un appel est synchrone ou asynchrone en fonction de sa représentation. Avec les DSL il faut non seulement redévelopper ses diagrammes, mais il faut en plus les expliquer à chaque fois.

Obeo Designer

Obeo Designer propose une solution pour le premier problème : réaliser des diagrammes personnalisés s’appuyant sur votre DSL.

Il est basé sur 5 types de représentation :

• Tree
• Edition Table
• Cross Table
• Diagram
• Sequence Diagram

Pour l’avoir pratiqué une après midi, on arrive assez rapidement à construire un diagramme. L’outil est très pratique; dès que l’on fait une modification on peut voir le résultat en live sur le diagramme.

Le gros point faible de l’outil est, à mon avis, le manque d’aide (complétion, coloration..) pour écrire les scripts Acceleo. En plus ce sont des scripts Acceleo 2 (alors que le générateur de code est en Acceleo 3).

www.obeonetwork.com

Cette journée a été aussi l’occasion d’annoncer l’ouverture du site obeonetwork. Cet espace collaboratif va nous permettre de partager nos réalisations Acceleo / Obeo Designer. Même si je pense qu’il vaut mieux réaliser un générateur différent par projet qu’essayer de faire LE générateur générique, rien n’empêche de partir d’un existant pour le spécifier à son besoin (le transformateur hibernate par exemple).

Pour conclure j’ai passé une bonne journée et c’est toujours un plaisir de rencontrer Frederic Madio et Etienne Julio (la star sur les cast codeurs ). Je reste quand même assez attaché à UML. Même si UML est beaucoup trop vaste et très compliqué il a le mérite d’apporter un langage normalisé et beaucoup d’outils s’appuient dessus.

C’est donc sûrement pour me faire plaisir qu’Obeo a annoncé Mardi qu’ils allaient donner gratuitement un modeleur UML construit avec Obeo Designer. Ce module UML est publié sur le MarketPlace obeonetwork et le code source est sur GitHub. C’est donc un exemple très complet sur lequel on peut s’appuyer.

Cerise sur le gâteau, on a eu un bon de réduction de 20% que j’ai bien sur immédiatement mis en vente sur ebay

Le blues du développeur

En revenant d’une conférence sur GIT dans le cadre du BreizhCamp (faite par Sebastien Douche, excellent orateur) je rentre chez mon frère qui m’héberge. Et commence la conversation type que nous développeurs nous avons déjà eu des dizaines de fois:

Mon frère : Alors cette conf, sympa ? C’était sur quoi ?
Moi : Ouep super bien, on nous a présenté GIT
Mon frère : Ah ? C’est quoi GIT
Moi : Un super outil de GConf pour remplacer SVN qu’il est grand temps de virer.
Mon frère (perplexe) : Ah…ok….bon, et sinon les enfants, ils vont bien ?

Et votre femme (oui car souvent le développeur est un homme ) ne vous a jamais demandé comment s’est passé votre journée ? Chez moi ça donne à peu près ça :

Ma femme : Alors ta journée ? bien passé ?
Moi : Oui le top, j’ai complètement refait la gestion transactionnelle du projet pour utiliser de l’AOP en mettant le place spring et Jersey pour l’exposition REST.
Ma femme (perplexe) : Ah… en effet ça a l’air bien.
Moi : Et toi ? bonne journée ?
Ma femme : Oui pas mal, j’ai diagnostiqué un truc grave au plus tôt, ça va sûrement lui sauver la vie.
Moi (perplexe) : Ouais… C’est pas mal non plus…

C’est je trouve le plus frustrant dans notre métier, on peut faire des trucs hyper techniques, c’est très compliqué de l’expliquer et de le faire partager aux non néophytes. Pire : plus c’est technique et moins c’est impressionnant/intéressant pour les autres. Faites une page web avec un GIF animé et vos amis vous prennent pour un dieu de l’informatique. Par contre plus c’est technique et moins on peut montrer un résultat concret.

Personnellement j’ai vu le changement quand je suis passé d’un projet Java sur le Machine To Machine au développement sur iPhone. A expliquer à mon entourage c’est le jour et la nuit

C’est aussi pour ça que des journées comme le BreizhCamp ça nous fait du bien à nous les développeurs, on peut discuter avec d’autres personnes qui comprennent ce que l’on fait. Donc encore merci Nicolas pour l’avoir organisé !

Choisir un développeur

Je viens de lire un article très intéressant : Why the new guy cant code

Comme je l’ai dit dans l’article sur les forfaits, il est indispensable de bien choisir ses développeurs et c’est loin d’être simple. TechCrunch explique bien que le processus de sélection des entreprises n’est pas souvent très performant. Même chez Google il y a des choses à améliorer. J’ai par exemple bien aimé le test technique à faire pour déposer son CV chez Ippon, mais ce n’est pas suffisant.

J’ai aussi souvent cet exercice à faire et ce n’est pas simple. Pour préparer l’entretien je commence par googler le nom du candidat. Je suis en phase avec l’article : aujourd’hui il est juste inadmissible qu’un développeur ne possède pas de site web/blog. Un bon développeur c’est avant tout un passionné, il doit exister sur la toile. Pour une prestation j’ai passé un entretien avec un gars qui avait un site web où il présentait son voyage à Lego Land et des Add-on Counter Strike qu’il avait développés. Avant même de le voir en entretien je savais qu’il était bon car un homme qui aime encore les Legos ne peut qu’être bon J’ai encore le souvenir de sa tête se décomposant au moment où je lui est demandé pendant l’entretien : « Alors ? C’était comment Légo Land ? » (la tête de sa commerciale était pas mal non plus ). Il était un peu gêné au début mais pour moi ce n’était que du positif : il a un site web, il développe des add-on CS sur son temps perso et le contact était bon pendant l’entretien. Résultat : une bonne recrut qui a fait du super boulot.

Pas simple non plus de s’y retrouver avec les CV que l’on reçoit des SSII. Entre les CV retouchés par les commerciaux pour y placer les mots clés recherchés et les CV où le commercial a juste collé l’entête de sa société sur le CV du gars, on est pas aidé. Je ne supporte plus les CV où sont listés les 36 langages informatiques connus, ça ne veut plus rien dire ! Une fois j’ai eu une personne avec sur le CV : « Assembleur Intel et Motorola », sûrement un TP fait il y a 3 ans : super intéressant pour une presta JEE. Et là pas de chance, moi aussi j’en ai fait de l’assembleur ! Et oui n’oubliez jamais que si vous notez quelque chose sur votre CV, il faut assurer après. Du coup au milieu de l’entretien je demande au candidat : « Peux-tu me dire la différence entre l’assembleur Intel et l’assembleur Motorola ». Et là patatras… même pas capable de se rappeler de l’inversion des bits de poids faible et des bits poids fort pour les octets. Donc pitié, sur les CV ne mettez que l’essentiel et indiquez le niveau de compétence (Java : 3 ans, C# : 1 an, etc…)

Autre expérience intéressante. Je cherchais un développeur JAVA en urgence (genre pour demain) et bien sûr avec de la bouteille. A cause des délais je n’ai eu le CV que d’une personne avec peu d’expérience mais avec des mots clés intéressants comme Maven. L’entretien se passe bien mais j’avais encore des doutes sur ses compétences. Devant son commercial je lui demande : « Tu as une heure de dispo ? J’ai justement un problème avec un appel WS avec Axis, tu m’aides à le coder ? ». Là encore je les ai un peu surpris, mais on s’est mis à deux devant un écran et on a corrigé le problème.

Le plus important ce ne sont pas les réponses aux questions mais comment ils répondent. J’ai sélectionné de très bons développeurs qui savaient répondre « Ah non ça je ne connais pas » au lieu d’essayer de m’embrouiller. Un autre point à ne pas négliger non plus c’est bien sûr le relationnel. Un excellent développeur peut devenir un poids mort s’il ne s’intègre pas facilement dans une équipe.

Pour résumer mes critères perso pour choisir un bon développeur :

• Avoir un blog, un site, une activité informatique sur son temps perso
• Pour les développeurs iPhone/Android : avoir publié une application à titre perso.
• Un bon contact lors de l’entretien.