C'est à travers le billet de Cyrille que j'ai connu SoCraTes (Software Craftsmanship and Testing). J'ai eu l'occasion de participer à la quatrième édition qui s'est tenue du 7 au 10 Aout en Allemagne. C'est une anticonférence dont originalité repose tant sur l'état d'esprit des participants que sur l'organisation informelle des sessions. On est loin de la rigidité des conférences traditionnelles, hyper structurées, avec des diapos taillées sur mesure, où pour la plupart la forme l'emporte sur le contenu. Pas de CFP, pas de programme, on sait juste que 150 personnes vont se rencontrer, quelque part à Soltau, pour parler de Software Crafstmanship. Et c'est tout. Les détails du contenu seront discutés une fois sur place. Ils seront adaptés en fonction de l'attente des participants et du déroulement de la conférence. Beaucoup parlent de “unconference” (anti-conférence) pour son côté informel. On peut aussi choisir le terme "meta-conference" puisque c'est pendant la conférence qu'on décide de ce que sera la conférence, ou de “collaborative conference” du fait de la participation de tous à l'organisation.
Cette édition, tout comme les précédentes, a connu un grand succès. Elle a vu le nombre de participants doubler par rapport à la troisième édition. Les gens venaient de différents pays, comme la France, la Roumanie, l'Autriche, l'Angleterre, les USA, l'Inde, et l'Allemagne pays hôte. La conférence est gratuite. Les seuls frais à supporter sont l'hébergement (repas inclus) et le transport. Il y a des sponsors mais sans présence physique (pas de pub, pas de stand).
La première idée qui nous traverse quand on sort de Socrates c'est d'expérimenter l'idée ailleurs, comme l'ont déjà fait les anglais avec SocratesUK.
Le lieu : Soltau
La conférence s'est tenue à Soltau, une ville située à une heure de Hamburg, au Nord de l'Allemagne. L’hôtel se trouve en plein milieu de la forêt, bien isolé et assez grand pour assurer la tranquillité. Les participants avaient à leur disposition des salles de conférence, des chambres, un restaurant, un bar, un sauna, une piscine et un très grand parc... quasiment tout l'hôtel. Un cadre qui offre assez de liberté, qui favorise l'échange et stimule l'émergence de nouvelles idées.
World-café
La conférence démarre officiellement avec le World-café. C'est le moment où les participants se rencontrent pour la première fois. Le Word-café est une forme d'échange qui offre un cadre de discussion informel dans une ambiance de café. Son but est de faciliter l'implication de tous les participants d'une discussion sur un topic. De petits groupes de 8 personnes se forment autour de tables disposées dans plusieurs salles pour échanger sur leurs attentes et motivations à participer à Socrates (What are we here for ? Where do we want to go ?) . Chaque table a un chef “fixe” qui joue le rôle de facilitateur. Au bout de 15 minutes, les groupes se dispersent, de nouveaux groupes s'organisent pour un nouveau round. Le processus se répète plusieurs fois. A la fin, les résumés des différentes discussions sont affichés sur des tableaux mis à la disposition du public.
Les sessions
Jusqu'à la veille, les sessions d'une journée ne sont pas connues. C'est le jour J à 09h30 que les intéressés proposent leurs sujets avec l'intitulé, l'heure, la salle et la durée. Les formats des sessions varient entre Workshop, Hand-on, Kata, Rex et Open door. Ce qui laisse à chacun la possibilité d'adapter sa présentation. Aucun format n'est imposé, on voit très peu de slides, pour la plupart ce sont des flipcharts et des projections de live-coding. On s'en fout pas mal de la forme. Le plus important à SoCraTes c'est d'avoir une idée qui intéresse les autres. Les contenus ne sont pas figés, ils 'adaptent en fonction de l'attente de l'audience. On est loin de la passivité des publics des grandes conférences très “académiques”. Chacun peut participer à une session, en apportant des informations supplémentaires, et parfois en donnant une autre orientation au sujet. Une session peut donner naissance à une nouvelle session pour le lendemain, et ou se poursuivre le soir sous forme de discussion, de Hands-on ou de Kata.
Deux sujets choisis
Il y avait jusqu'à six sessions simultanément, avec comme principaux thèmes Test, Design, Architecture, Programming et Tooling. Je vous présente ici deux sujets qui ont été très suivis.
Event sourcing
Une introduction de l'Event Sourcing par une comparaison avec les RDBMs. En RDBMs les objets sont mappées sur les tables. Tout changement, même partiel, d'état de l'objet en mémoire entraîne une mise à jour complète de la table en base. La table ne contient donc que le dernier état de l'objet. Avec l'approche Event Sourcing pas besoin de faire du mapping Object-Relanionnal, ce sont les événements (Event) - Création, Suppression et Modification - qu'on stocke dans la base. Le gain en performance peut être assez considérable. On maintient l'historique des différents états intermédiaires de la table de sorte à pouvoir construire son état courant ou retrouver différents états avec des Revert et des Rollback comme dans un SGV.
On peut lire sur le blog de Martin Fowler :
The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.
Exemple d'un compte bancaire : source http://ookami86.github.io/event-sourcing-in-practice/
En RDBM on aura un seul objet pour la table
Account (accountNumber, owner, amount)
En Event Sourcing on créera un objet Event pour chaque événement sur l'objet
AcountCreated(accountNumber, owner) pour la création de compte
DepositedPerormed(accountNumber, amount) pour le crédit
WithdrawPerormed(accountNumber, amount) pour le débit
Restauration : Retrouver l'état courant à partir des Events
AcountCreated(accountNumber, amount)
.applyTo(EmptyAccount)=> Account (accountNumber, owner, 0)
DepositedPerormed(accountNumber, 100)
.applyTo(Account (accountNumber, owner, 0))=> Account (accountNumber, owner, 100)
Architecture Micro-services
Très tôt dans le développement logiciel une conception de l'architecture s'est imposée naturellement, comme allant de soi. L'Architecture Monolithique qui se caractérise par un découpage technique en trois parties - IHM, Métier et BD - obéit à une organisation des équipes en Technical Unit (DBA, Dev et IHM travaillent séparément). Son implémentation est très simple et facilitée par la prolifération de différents frameworks. Mais elle montre très tôt ses limites dans un contexte de cloud computing de scalabilité récurrente. Elle se heurte également à la culture Devops, toute modification - même partielle - entraîne un déploiement global de l'application.
L'Architecture Micro-services promeut un découpage fonctionnel. L'application est composée de services “autonomes” pouvant être déployés et scalés indépendamment les uns des autres. Ce style d'Architecture implique une organisation des équipes autour de Business Unit (Dev, Admin et IHM travaillent ensemble). Elle permet aussi la cohabitation dans l'application de plateformes technologiques différentes avec des sources de données hétérogènes (RDBMs, NoSQL, XML, JSON, ...).
In a microservice architecture a large number of very small services are deployed and linked up to build systems, with the services mapping closely to business concepts and value.
En complément de l'absence de définition formelle, Heroku, s'inspirant de retours d'expériences acquis sur plusieurs projets, publie sous forme de manifeste The Twelve Factors. Le document décrit en 12 points les caractéristiques et bonnes pratiques (déjà connues des développeurs web) d'une architecture micro-services. C'était notre sujet de discussion de la première session sur les architecture micro-services.
I. Codebase : Le code doit être versionné dans un Repository, de préférence un par service.
II. Dependencies : Les dépendances doivent être déclarées explicitement et isolées.
III. Config : Tout changement qui dépend d'un environnement (DB, password, niveau de log, …) doit être géré en dehors du code.
IV. Backing Services : Les services tels que DB, SMTP, Rabbit MQ, … doivent être traités comme des ressources externes accessibles via des URL, qu'ils soient sur la même machine ou ailleurs sur le réseau.
V. Build, release, run : L'application doit passer par les phases de build et de release avant son utilisation.
VI. Processes : L'application doit être exécutée comme un ou plusieurs processus sans état.
VII. Port binding : Les services doivent être exposés à travers des ports.
VIII. Concurrency : Si l'application doit déléguer du traitement (requête http, tâche de fond, ...) il ne faut pas que ce soit à un processus fils ou à daemon mais à un processus de premier niveau.
IX. Disposability : Les processus de l'application doivent pouvoir être démarrés/arrêtés rapidement pour faciliter la scalabilité, rendre les déploiements fluides et assurer une reprise après pannes.
X. Dev/prod parity : Les différents environnements (Dev, Test, Prod, …) doivent être similaires, même version d'OS, de BD, ... Ce qu'on est capable de faire en prod, on doit être capable de le reproduire en développement.
XI. Logs : Les logs sont gérés comme des streams. L'affichage sur console ou l'écriture sur disque doivent être gérés en dehors de l'application.
XII. Admin processes : Les tâches administratives (migration de BD, execution de script shell, ...) doivent être exécutées dans des processus (à travers un script par exemple) et non manuellement.
Il y a de multiples raisons objectives de trouver dans les architectures micro-services un futur possible du Système d'Information. En revanche elles exigent des effort supplémentaires pour leur mise en œuvre, dans la prise en main de nouveaux outils (provisionning, monitoring, déploiement continu), et l'adoption de la culture Devops. Martin Fowler explique dans son article les cas d'utilisation.
