Tag Archives: rest

Github, Cloudbees, Feature Flags

Quand les enfants ne sont pas là le geek code 😉

Mettre en oeuvre un processus d’intégration continue peut se faire rapidement, avoir une suite de test unitaire couvrant de manière satisfaisante son code est une autre histoire… Particulièrement sur un “code  legacy” (qui a été écrit sans test unitaire) ,  trop souvent les bugs sont découvert en production par les utilisateurs finaux.  Il faut alors revenir en arrière, reproduire et corriger le bug dans un environnement et re-livrer plus tard, sans parler d’une éventuelle reprise des données qui auraient été corrompues. Oui il y a du vécu.

Une technique pour réduire les effets néfastes d’un bug en production est de déployer progressivement à des populations restreintes les nouveautés. Pour cela il faut séparer la livraison du code de l’activation des fonctionnalités qu’il contient.

Un simple if/else peut suffire, on parle de feature flags chez Flikr.

if (newStuffIsOn) {
	doIt
} else {
	doNot
}
Voilà donc ce que j’ai codé ce week-end… Bon un peu plus en fait. Car il faut un moyen propre et élégant de gérer, d’activer et de désactiver ces flags en production.

Voici donc Feature Flags

L’idée est de gérer les flags dans un enum:
public enum Flags implements FeatureFlags {
    ONE("First Feature Flag"),
    TWO("Second Feature Flag", FlagState.UP),
    THREE("Third Feature Flag");
}
if (ONE.isUp()) {
	doIt
} else {
	doNot
}
Feature Flags génére dynamiquement à partir de l’enum une page html pour activer désactiver ces flags en live, mais aussi une interface RESTful pour les manipuler comme on souhaite.

RESTful

GET http://yourhost.net/flags/ONE pour connaitre l'état
POST http://yourhost.net/flags/ONE pour inverser l'état
PUT http://yourhost.net/flags/ONE avec UP ou DOWN en contenu pour forcer l'état d'un flag
Rien de fantastique que ce soit fonctionnellement ou au niveau du code mais il s’agissait aussi d’un pretexte pour me mettre à git et github

GitHub

Quelle claque. J’ai mis du temps à comprendre pourquoi Linus disait que svn ne marchait pas par conception, après tout ça a marché pour moi pendant des années. Git est clairement le bon concept. La preuve: github, il n’existera jamais de svnhub, avec github nous sommes tous à un click de pouvoir contribuer à des milliers de projets open source. D’ici quelques années github aura produit un impact majeur sur la croissance et la vitalité de l’open source. En fait c’est déjà le cas, mais j’ai la conviction que l’on a encore rien vu. Un peu comme les moteurs de blogs ont déclenché la vague web 2.0 du web participatif. On peut parler d’open source 2.0.

Cloudbees

Deuxième claque. Le projet Feature Flags contient une webapp de démo, le plus simple pour montrer ce que fait Feature Flags est encore une démo (vous allez pouvoir découvrir mes talents de designer web, please fork it ! du html là aussi). Mais héberger un war java sur Internet a toujours été un problème. Les différents clouds publiques apportent des solutions. Avec cloudbees déployer du code java est presque aussi simple qu’uploader une appli php. Il s’est écoulé une petite 1/2heure entre le moment où j’ai décidé de m’inscrire à Cloudbees et le moment où mon application était live, le plus long a été de lire un peu la doc. Petite déception, il n’est pas possible n’était pas possible hier de déployer directement un war généré dans le jenkins de DEV@cloud vers le tomcat RUN@cloud.

Age d’or du développeur

Ajouter à ça le mobile (android), html 5, l’adoption des méthodes agiles, le développement vit un nouvel age d’or.

Le retour du Web dans les Web services

L’architecture d’entreprise est une sorte mammouth, pas très agile, beaucoup d’inertie. Elle met du temps à changer de cap et avance tête baissée. Ce sont bien souvent les éditeurs et les analystes qui fixent le cap. Depuis plusieurs années tout le monde suivait les panneaux SOA. Je connais pas beaucoup d’entreprises qui soit arrivées à destination, certains commencent même à abandonner la route. Il est donc temps de fixer un nouveau cap.

Le Web a depuis longtemps adopté les principes RESTful ils sont au coeur de GData l’api de Google. En 2008 IBM a pris la direction de la RESTful SOA, La plateforme .net 4.0 de Microsoft prend elle aussi le virage REST. Les éditeurs ont pris la route REST.

Depuis plusieurs années Pete Lacey du cabinet d’analyste Burton évangélise REST. Et la semaine dernière la bible des DSI a sauté le pas. Le Gartner recommande enfin les approches RESTful:

Gartner: Web-Oriented Architecture: Putting the Web Back in Web Services

Les analyste ont pris la route REST… Toute l’architecture d’entreprise va suivre. Je ne vous cache que j’attend celà depuis un moment. Ca ne fait jamais que 4 ans que je m’intéresse au sujet

Je suis très agréablement surpris par la note du gartner qui a su mette le doigt sur la valeur de REST

  • “Unexpected reuse is the value of the Web” (Tim Berners-Lee)
  • “Engineer for serendipity” (Roy T. Fielding)

Ca reste des consultants… Ils inventent le concept d’application neutrality pour expliquer qu’une interface réutilisable doit être neutre et non pas spécifique à une application. REST pemet et encourage la construction de telles interfaces. Il parle aussi de “wide top” pour bénéficier de l’effet de réseau. Je parle de surface de contact, la multiplication des URI dans une application RESTful augmente la surface de contact de l’application et les possibilités de réutilisation imprévues (serendipineuses même!).

Enfin Gartner utilise le terme WOA pour Web je préfère le terme ROA pour Ressources, car le paragdime central de REST est bien la ressource.

Il est donc temps de s’y mettre, voici quelques points de départ:

Atom Publishing Protocol, indispensable ?

Il existe des compétences indispensables dans nos métiers, comme SQL ou XML. Atom Publishing Protocol, APP pour les intimes est en passe de devenir l’une d’elle.

Qu’est Atom Publishing Protocol (APP) ?

atomlogo.gifAtom est un format xml de syndication de contenu, comme les flux RSS, mais plus récent et plus abouti.

APP est un protocole de manipulation de ressources sur le Web.

Sans surprise, les messages échangés par le protocole APP sont au format Atom. APP suit les principes des services web RESTful et utilise naturellement le protocole HTTP.  Alors qu’HTTP traite principalement des problèmes de transfert de ressources, APP adresse des notions applicatives (gestion de collections d’entrées).

APP aurait dû s’appeler “Web services”, mais le terme est déjà pris par quelque chose qui n’a rien à voir avec le Web bien qu’issu du W3C.

Pourquoi APP va t-il devenir indispensable ?

Google base toutes ces APIs d’accès aux données qu’il conserve sur Gdata, Gdata est une extension d’APP.
Après avoir commencé par développer son propre protocole (W3SE) Microsoft vient d’annoncer qu’il adoptait en masse APP.

Le web devient la plate-forme, APP sera l’un des protocoles phare de LA plate-forme. APP est parfaitement en phase avec l’architecture du Web: ROA

La bonne nouvelle.

APP est une techno simple, rapide à comprendre et à maitriser mais très puissante.

Pour aller plus loin:

L’indispensable wikipédia: Atom Publishing Protocol

Le site AtomEnabled

Besoin de démêler une question à propos de REST ?

Roy Fielding, qui est à l’origne de REST, a désormais son blog: untangled.

L’occasion de rappeler que Tim Berners Lee, à l’origine du Web, a lui aussi son blog. Ainsi que Tim Bray, l’un des principaux contributeurs d’xml. Et il y en a certainement bien d’autre de la même trempe.
Ces gens changent le monde et ils sont à portée de clic… Nous vivons une époque formidable.