Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activitĂ©s liĂ©es au dĂ©veloppement d’applications informatiques en entreprise.

Blog d’Ippon Technologies
Syndiquer le contenu
Les experts Java EE, Portail et SOA
Mis à jour : il y a 3 jours 8 heures

Kafka 0.11.0 == ♄

mar, 07/11/2017 - 09:55

Le 22 juin dernier Kafka sortait sa derniÚre version : la 0.11. Je vais revenir sur les nouveautés de cette version, car elle introduit des concepts trÚs intéressants voire innovants pour un outil distribué comme Kafka !

PS : pour ceux n’ayant pas de background avec Kafka je vous conseille de regarder la vidĂ©o suivante qui constitue une bonne introduction, quelques modifications ont nĂ©anmoins eu lieu avec la nouvelle version ! #AutoPub

Headers de message

Allez, on commence doucement avec cette premiĂšre fonctionnalitĂ©. La possibilitĂ© d’ajouter des headers Ă  un message Kafka. La spec provient de la KIP-82. Comment ça marche ? L’ajout de headers se fait via une modification du protocole d’envoi vers le broker Kafka ainsi que d’ajouts d’interfaces de manipulation de ces headers pour les clients (producer / consumer). On a donc maintenant un champ spĂ©cifique comme dĂ©crit ci-dessous :

Message =>

       Length => varint

       Attributes => int8

       TimestampDelta => varlong

       OffsetDelta => varint

       KeyLen => varint

       Key => data

       ValueLen => varint

       Value => data

       Headers => [Header] <------------ NEW Added Array of headers

Header =>

       Key => string (utf8) <- NEW UTF8 encoded string (uses varint length)

       Value => bytes  <- NEW header value as data (uses varint length)

C’est assez pratique pour passer des informations en plus de votre contenu pour une utilisation par le consommateur par exemple. Ce n’est pas trĂšs rĂ©volutionnaire car commun pour les queues de messaging. Mais c’est un ajout sympathique. Je suis personnellement intĂ©ressĂ© par cette feature Ă  des fins de tracing de requĂȘtes asynchrones
 Je dĂ©rive &#x1f642;

Exactly once

Bon maintenant, on rentre dans le vif du sujet. Cet article est un peu une excuse pour vous parler de la fonctionnalitĂ© phare de cette version : le support de la garantie de dĂ©livrance d’un message une fois exactement (ça rend pas bien en français donc je parlerai de “exactly once”).

Avant, il y a bien 1 semaine, “exactly once” ça semblait ĂȘtre de la fiction. De nombreuses personnes considĂ©raient la fonctionnalitĂ© impossible dans un environnement distribuĂ©. En effet, c’est un des problĂšmes trĂšs complexes de garantir l’envoi unique d’un message dans un outil distribuĂ©. Illustrons cela :

J’envoie un message Ă  Kafka, le broker le reçoit, mais met trop de temps Ă  rĂ©pondre. Typiquement c’est le genre de panne que l’on peut attendre du rĂ©seau (CF “Fallacies_of_distributed_computing” ). Kafka prĂ©voyait le coup et permettait (via des options) d’envoyer des messages de retry lorsque l’ACK n’arrivait pas. Ainsi on pouvait choisir entre le fait d’avoir “at most once” si on ne rĂ©essaie  pas et “at least once” si on rĂ©essaie jusqu’à la rĂ©ussite. Pourquoi “at most once” me direz vous ? Et bien si on reçoit un timeout lors de l’ACK, simplement Ă  cause d’une lenteur rĂ©seau et que l’on a rĂ©ellement Ă©crit le message dans le commit log, le producer renvoie et Badaboum, un doublon.

Alors comment contournent-ils cela ?

Idempotence

Ça veut dire que si on envoie deux fois la mĂȘme chose via un producer, on a tout le temps le mĂȘme rĂ©sultat. Le producer va avoir un petit ID dans ses batchs de message permettant de les dĂ©doublonner. Tant que l’on n’a pas de rĂ©ponse de Kafka on renvoie et si Kafka reçoit des doublons il gĂšre ! Pour l’activer rien de plus simple, il suffit de mettre le paramĂštre enable.idempotence=true. En plus de tout ça, les fameux IDs sont Ă©crits dans un log, du coup c’est rĂ©silient en cas de panne.

C’est beau.

Support des transactions

Ça y est, on rentre dans des choses intĂ©ressantes. Kafka, c’est un log distribuĂ© : OK ! On peut produire et lire des messages dans un topic donnĂ© (streaming ou non). Avant on produisait un message et on continuait nos traitements sans avoir de garantie, en cas de prĂ©cĂ©dence entre nos messages, que tous seraient envoyĂ©s. Avec le support des transactions, on a maintenant une syntaxe proche des transactions de nos bases de donnĂ©es :

producer.initTransactions();
try {
  producer.beginTransaction();
  producer.send(record1);
  producer.send(record2);
  producer.commitTransaction();
} catch(ProducerFencedException e) {
  producer.close();
} catch(KafkaException e) {
  producer.abortTransaction();
}
kafka-transactions.java affichage brut

On a donc la possibilitĂ© d’effectuer des Ă©critures atomiques sur diffĂ©rentes partitions d’un topic donnĂ©. C’est plutĂŽt cool et cela apporte de nouveaux use-cases pour Kafka. Vous savez Kafka Streams fait typiquement du “read => transform => send”. Tu fais ça dans une transaction et tu as du streaming en exactly once ! Encore une fois une simple propriĂ©tĂ© permet d’assurer cette garantie : processing.guarantee=exactly-once.

Performances ?

Le support de la fonctionnalitĂ© n’est pas automatique. Du coup si vous ne l’utilisez pas, mĂȘme avec l’ajout des headers, vous aurez de meilleures performances. Un travail a Ă©tĂ© effectuĂ© de ce cĂŽtĂ©-lĂ  notamment au niveau de la compression des messages Kafka sur le rĂ©seau et sur disque. Du coup, on parle quand mĂȘme de 50% d’augmentation en termes de dĂ©bit !

Et lĂ  vous vous demandez, “et pour le exactly once ?”. En fait il y a bien un overhead sur l’utilisation de la fonctionnalitĂ©. On parle d’environ 3% ou 20% pour l’utilisation du ”exactly once” (en comparaison de “at-least“ ou “at-most” respectivement). Mais pas besoin d’ĂȘtre triste, en fait le but avouĂ© est de faire du “exactly once” la norme et donc de l’activer par dĂ©faut. C’est possible grĂące au gain de performance des autres parties du protocole dĂ©crit plus haut ! Alors mangez-en !

Pour conclure : Idempotence + Transactions multi partitions = Exactly once pour tous les usages de Kafka = ♄

Pour une description complĂšte des nouvelles features, des amĂ©liorations ou des bug corrigĂ©s, les releases-notes sont disponibles ici : http://www.mirrorservice.org/sites/ftp.apache.org/kafka/0.11.0.0/RELEASE_NOTES.html. Les articles de Confluent, dont je me suis grandement inspirĂ©, rentrent bien plus dans le dĂ©tail que moi concernant le exactly-once et peuvent ĂȘtre trouvĂ©s dans la KIP-98 (attention c’est long), dans un article de lancement de @nehanarkhede ou dans un blog de @jaykreps pour les septiques.

L’article Kafka 0.11.0 == ♄ est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Retour sur #NCrafts 2017

lun, 07/03/2017 - 08:30

La confĂ©rence NCrafts 2017 s’est dĂ©roulĂ©e durant les 18 et 19 mai Ă  Paris. Une confĂ©rence cette annĂ©e sur le thĂšme Humble Programmers.

Cette confĂ©rence, dont la premiĂšre Ă©dition eu lieu en 2014, cherche Ă  mettre l’accent sur le mouvement du software craftsmanship et le mĂ©tier de dĂ©veloppeur. NCrafts se veut agnostique Ă  la fois vis-Ă -vis des technologies, des pratiques et des langages. Apparaissent alors en guest stars les sujets sur l’agilitĂ©, le domain driven design (DDD), la programmation fonctionnelle et la programmation objet, ainsi que de potentiels nouveaux concepts et des rĂ©flexions sur la vie de dĂ©veloppeur. En terme de langage pour les prĂ©sentations techniques, la majoritĂ© des talks autour du code Ă©tait basĂ©e F#, mais il y avait aussi du C#, Scala, Haskell, Java, Swift, JavaScript, Go et bien d’autres encore.

Je vous propose de vous raconter cette expĂ©rience et de vous partager quelques rĂ©flexions personnelles sur les keynotes de NCrafts 2017, dont j’ai apprĂ©ciĂ© la qualitĂ©.

Talk de bienvenue

Rui Carvalho, le principal organisateur de la confĂ©rence, a commencĂ© par nous parler de concepts de dĂ©veloppement de bon sens et paraissant telle une redite, pour peu qu’on ait une certaine habitude des pratiques agiles. Toutefois, le point de vue prĂ©sentĂ© semblait lĂ©gĂšrement diffĂ©rent des discours habituels sur ce thĂšme.

Puis Rui sort un manifeste nommé The Humble Programmer Manifesto : un manifeste de plus ?!

Il ne s’agissait aucunement d’un Ă©niĂšme manifeste. Rui indique que tout le discours qu’il vient de prĂ©senter avait dĂ©jĂ  Ă©tĂ© Ă©noncĂ© en 1972 par Edsger W. Dijkstra. Plus exactement, il s’agit du discours qu’il a prononcĂ© lors de la remise de son prix Turing ; discours intitulĂ© The Humble Programmer (EWD 340).

Par cette dĂ©monstration, Rui a tentĂ© de faire comprendre que le monde du dĂ©veloppement a besoin de connaĂźtre son histoire pour s’amĂ©liorer et s’Ă©panouir davantage. Une partie des problĂšmes de nos jours peuvent ĂȘtre rĂ©solus grĂące Ă  des solutions plus anciennes que nous.

L’informatique est un domaine rĂ©cent et son histoire est bien souvent mal connue surtout par ceux qui le pratiquent. Ces constats sont encore plus creux dans le cadre du dĂ©veloppement logiciel. Mais quel intĂ©rĂȘt aurions-nous Ă  Ă©tudier notre passĂ© ? Nombre de conseils venant de dĂ©veloppeurs d’expĂ©rience aujourd’hui ont dĂ©jĂ  Ă©tĂ© prononcĂ©s dans les annĂ©es 60, 70 par ces pionniers de l’informatique que sont Dijkstra et ses nombreuses correspondances, Knuth et son oeuvre intitulĂ© The Art of Computer Programming (TAOCP) ou Backus et son plaidoyer pour un style de programmation alternatif dĂ©crit dans Can Programming be Liberated from the von Neumann Style?. Et il s’agit bien de conseils, d’autant que ces personnes ont forgĂ© la perception que nous avons actuellement du dĂ©veloppement logiciel. Ces pionniers ont trouvĂ© les mots qui nous manquent parfois pour dĂ©crire les problĂšmes que nous rencontrons rĂ©guliĂšrement et ont imaginĂ© des solutions pour les rĂ©soudre. De ces Ă©poques reculĂ©es, nous avons beaucoup Ă  apprendre. Comme le disait le philosophe amĂ©ricain George Santayana : Those who cannot remember the past are condemned to repeat it.

Le talk d’introduction de Rui Ă©tait court, mais c’est celui qui m’a probablement le plus intĂ©ressĂ©, tant le sujet m’a passionnĂ© par le passĂ© et me passionne toujours autant actuellement.

Les slides sont disponibles sur slideshare.

What Ever Happened to Being eXtreme? (Rachel Davies)

Rachel Davies est revenue sur une mĂ©thode plus connue pour ses pratiques de dĂ©veloppement que son approche du management : l’eXtreme Programming ou XP. Car, comme je le rappelle assez souvent autour de moi, il ne faut oublier que l’XP couvre un pĂ©rimĂštre plus large que Scrum. Rachel rappelle que cette mĂ©thode, nĂ©e dans les annĂ©es 90 avant le manifeste agile, a pour objectif de livrer de la valeur aussi vite que possible en vue d’optimiser le feedback Ă  l’Ă©quipe de dĂ©veloppement. Pour cela, l’Ă©quipe projet doit ĂȘtre capable de prendre des risques et pour cela elle a besoin de courage ; le courage Ă©tant l’une des plus importante valeur de l’XP.

Pour Rachel, l’XP est une mĂ©thode qui doit continuer Ă  Ă©voluer. Aussi, elle nous a donnĂ© une Ă©numĂ©ration de ce qu’est l’XP de nos jours, de part sa propre expĂ©rience. Voici quelques points parmis ceux qu’elle a remontĂ© :

  • Le mob programming pour remplacer le pair programming. Le pair programming incorpore selon elle encore trop de risque d’effet tunnel. On peut le pallier avec une rotation des pairs, mais elle finit par perdre de son efficacitĂ©. Le mob programming consiste Ă  faire travailler toute l’Ă©quipe de dĂ©veloppement sur la mĂȘme fonctionnalitĂ© autour d’une seule machine de dĂ©veloppement (mais avec un vidĂ©o-projecteur Ă  la place de l’Ă©cran). Cette approche offre plus de flexibilitĂ©. Elle rĂ©duit d’autant plus l’effet tunnel au sein de l’Ă©quipe et favorise le partage de la connaissance sur un projet (collective ownership).
  • Pas de branche mais des tokens de dĂ©ploiement. On voit de plus en plus de projets oĂč GitFlow et ses multiples branches (dont les feature branches) sont rejetĂ©s. Sur ces projets, il n’y a plus qu’une seule branche et la livraison se fait au commit prĂšs ou au token prĂšs. Cette approche permet d’avoir une mise en production quotidienne. NĂ©anmoins, elle ne fonctionne que si les intervenants sont colocalisĂ©s.
  • Rencontre entre tous les acteurs concernĂ©s par le projet (du dĂ©veloppeur Ă  l’utilisateur) pour un meilleur partage de la vision.
  • Backlog d’innovation cross-product gĂ©rĂ© par les dĂ©veloppeurs afin d’amĂ©liorer la livraison de valeur.
  • Story time : estimation des user stories quand elles sont prĂȘtes, plutĂŽt que des rĂ©unions d’estimation Ă  pĂ©riode fixe. Le story time permet de diminuer le temps passĂ© dans les rĂ©unions d’estimation et s’avĂšre ĂȘtre moins contraignant.
  • Un jour par semaine aux dĂ©veloppeurs pour apprendre une nouvelle technologie (c’est un thĂšme qui est souvent revenu au cours de NCrafts 2017). Cela permet de rester Ă  l’Ă©coute des innovations et d’ĂȘtre prĂȘt Ă  l’intĂ©grer si le besoin est exprimĂ©.
  • Changement d’Ă©quipe pour les dĂ©veloppeurs qui le souhaitent, tous les 3 mois. L’idĂ©e est d’apporter pour les projets un regard nouveau et Ă©viter d’autant plus l’enlisement. Quant au dĂ©veloppeur, cela lui donne la possibilitĂ© de briser la monotonie et de satisfaire son Ă©panouissement.

L’ensemble des pratiques proposĂ©es par Rachel est particuliĂšrement tentant. Elles montrent notamment que l’agilitĂ© reste un sujet ouvert et qui doit sans cesse Ă©voluer pour aller toujours vers plus d’efficacitĂ©. Par contre, je ne peux m’empĂȘcher de penser que les pratiques prĂ©sentĂ©es ne fonctionnent qu’avec des Ă©quipes capables de s’adapter et de s’Ă©panouir dans un environnement ouvert. Ce qui fut effectivement le cas pour Rachel.

Well-rounded architect (Patrick Kua)

Dans cette keynote, Patrick Kua de ThoughtWorks est venu partager avec nous sa vision de la notion d’architecte. D’entrĂ©e de jeu, Patrick indique que pour lui architecte est un rĂŽle. Il peut trĂšs bien ne pas exister. Il peut aussi ĂȘtre jouĂ© par un ou plusieurs dĂ©veloppeurs, mais pas n’importe lesquels non plus : il faut une certaine expĂ©rience et appĂ©tence sur ce sujet.

LĂ -dessus, Patrick pose la question de la relation entre architecte et architecture. Pour lui, le but de l’architecture est de rĂ©duire le coĂ»t du changement. L’architecte est responsable ou rĂ©fĂ©rent de l’architecture et de la “nourrir”. Par contre, il n’en est pas le propriĂ©taire. L’architecture appartient Ă  l’Ă©quipe. Et l’architecte ne prend pas non plus seul les dĂ©cisions dessus. Pour cela il doit consulter l’Ă©quipe.

Patrick propose un radar Ă  6 axes sur lesquels Ă©valuer la capacitĂ© d’une personne Ă  endosser le rĂŽle d’architecte :

  • il doit ĂȘtre un bon leader technique et ĂȘtre capable d’orienter les participants d’un projet dans la mĂȘme direction,
  • il doit ĂȘtre dĂ©veloppeur, afin de mieux comprendre les difficultĂ©s rencontrĂ©es par les autres dĂ©veloppeurs, ainsi que d’ĂȘtre plus Ă  l’Ă©coute des solutions proposĂ©es par ceux-ci,
  • il doit avoir une bonne perception de l’Ă©cosystĂšme qui entoure l’application issue du projet,
  • il doit au moins penser comme un entrepreneur, se poser des questions sur les bĂ©nĂ©fices que vont engager les dĂ©cisions sur un projet et favoriser une approche fail fast (learn fast ?),
  • il doit mettre au point une stratĂ©gie sur les technologies, en demandant d’essayer de nouveaux produits et en produisant des rapports sur ces expĂ©rimentations (en produisant par exemple l’Ă©quivalent d’un TechRadar Ă  la ThoughtWorks),
  • il doit enfin ĂȘtre un communicant efficace et ĂȘtre capable d’adapter son discours Ă  des personnes techniques et non-techniques.

Patrick a donnĂ© par la suite un ensemble de motifs sur la base de son radar pour montrer des profils types d’architectes qui peuvent poser problĂšme et en mettant en valeur ce qui peut manquer comme compĂ©tence dans chacun des cas.

Ce talk m’a intĂ©ressĂ© parce que j’interviens personnellement en tant qu’architecte sur des missions. Je me pose souvent la question de comment un architecte peut avoir un rĂŽle de facilitateur technique, sans tomber dans l’image du bullshitect (merci Ă  Alexandre Victoor pour le jeu de mot ^^) spĂ©cialiste des slides. Il y avait dans ce talk une vision de ce rĂŽle intĂ©ressante Ă  creuser et Ă  dĂ©velopper.

Readable in a New Language (Laura Savino)

Laura Savino est développeur iOS. Elle nous a proposé dans cette keynote de faire un parallÚle entre sa découverte de Swift, le langage développé par Apple, et la découverte de langues étrangÚres ; Laura ayant enseigné des langues étrangÚres.

Le langage informatique, tout comme le langage naturel, vient avec un certain nombre de nuances, de subtilitĂ©s et de stĂ©rĂ©otypes. Pour l’un, il y a l’accent et la culture locale qui influent sur la langue de base. Pour l’autre, il y a l’adoption de patterns et de frameworks qui dĂ©pendent de la communautĂ© frĂ©quentĂ©e. La traduction directe peut se faire, mais elle donnera des rĂ©sultats inattendus : la simple traduction mot Ă  mot de “thank you” peut se transformer de maniĂšre inattendue en l’Ă©quivalent “Whoaaaaa (gracefully)!” dans d’autres langues. De mĂȘme, dans les langages informatiques, la simple tentative de reproduire les patterns habituels d’un langage dans un autre montrera surtout que vous manquez d’expĂ©rience dans le langage cible.

Suite Ă  ce constat, Laura pose la question de ce qu’est le code lisible ? La notion de lisibilitĂ© dĂ©pend de celui qui lit. Car si une chose est sĂ»re, c’est que nous ne sommes absolument pas d’accord sur ce qu’est un code lisible ; et il est faux de croire que les commentaires aident. Le principe Ă©tant que la lecture du code ne doit pas se transformer en sĂ©ance de dĂ©cryptage, qui implique de rester d’autant plus concentrĂ©, d’avoir suffisamment d’Ă©nergie et de s’isoler. Un code lisible doit ĂȘtre un code que vous ĂȘtes capable de lire rapidement et correctement. Ainsi lorsque vous Ă©crivez du code, vous devez penser Ă  minimiser l’effort que fourniront vos collĂšgues lorsqu’ils vous reliront.

Comment produire un code lisible selon Laura ?

  • Éviter certains idiomes, tout comme vous Ă©viteriez l’argot avec des personnes qui n’ont pas votre culture. Par exemple, tout le monde ne comprend pas cette phrase d’argot : “Il se vissa le bada sur la calebasse et mit les adjas sans moufter…”, qui veut dire “Il mit son chapeau sur sa tĂȘte et partit sans dire un mot…”.
  • N’hĂ©sitez pas Ă  introduire des variables pour clarifier le contexte, par exemple dans le cas de one-lines (i.e. le fait d’Ă©crire un traitement avec un chaĂźnage de mĂ©thodes). Comparez
Map<String, Integer> occurrences = Files.lines(Paths.get(filename))
    .collect(Stream.collector())
    .flatMap(line -> separators.splitAsStream(line).collect(Stream.collector()))
    .map(String::toLowerCase)
    .groupBy(word -> word)
    .mapValues(Stream::size)

Et

Stream<String> lines =
    Files.lines(Paths.get(filename)).collect(Stream.collector())
Stream<String> words =
    lines.flatMap(line -> separators.splitAsStream(line).collect(Stream.collector())).map(String::toLowerCase)
Map<String, Integer> occurrences =
    words.groupBy(word -> word).mapValues(Stream::size)
  • Introduisez les “rĂ©gionalismes” en douceur.
  • Utiliser la rĂ©pĂ©tition de motifs visuels : a priori, des fragments de code qui se ressemblent ont une signification proche.

Quelques pistes pour tester que votre code est lisible.

  • Squint test (plisser les yeux) : prenez du recul, plissez les yeux et regardez globalement ce que donne votre code, en dĂ©tectant des motifs en terme de forme globale.
  • Mettez en correspondance votre code avec des anti-patterns connus. Par exemple : l’action Ă  distance, yo-yo problem, object orgy
 Une liste assez complĂšte se trouve sur WikiWikiWeb.

Le principe est avant tout que vous soyez prévisible lorsque vous écrivez du code.

Optimised for what? (Alberto Brandolini)

Dans ce talk, Alberto revient, non sans humour, sur les problĂšmes rencontrĂ©s en dĂ©veloppement logiciel et sur les potentiels points d’amĂ©lioration, en analysant les mĂ©thodes Waterfall d’une part, ainsi que la mĂ©thode agile et ses diverses interprĂ©tations.

La mĂ©thode Waterfall part bien entendu d’une bonne intention, mais se transforme en une mĂ©thode optimisĂ©e pour repousser les mauvaises nouvelles. Quant Ă  l’agilitĂ©, tout du moins la perception qui ressort sur beaucoup de projets, elle semble ĂȘtre optimisĂ©e pour la prĂ©dictibilitĂ© et rĂ©duite Ă  cet aspect dans la plupart des projets.

Dans les projets, Alberto fait remarquer que le principal goulet d’Ă©tranglement est l’apprentissage. Ici apprentissage est Ă  prendre au sens large : Alberto parle aussi bien du fait d’acquĂ©rir une nouvelle pratique que de comprendre un projet et son contexte. Malheureusement, l’apprentissage n’est pas livrable, n’est pas visible et est fragile (nous ne sommes pas payĂ©s pour apprendre). Mais l’apprentissage est un investissement et c’est ce qui nous fait avancer. D’une maniĂšre ou d’une autre, l’apprentissage est inĂ©vitable. Et le logiciel fonctionnel en est l’effet de bord.

LĂ -dessus Alberto nous fait remarquer les points suivants :

  • L’ennui est le pire ennemi de l’apprentissage. Mais l’inverse est vrai aussi : l’apprentissage est le pire ennemi de l’ennui.
  • L’apprentissage nĂ©cessite de faire des erreurs. Il faut donc mettre en place un environnement oĂč l’Ă©chec est permis pour le pratiquer.
  • Le plus souvent, les nouvelles idĂ©es apparaissent de maniĂšre inattendue et en dehors du travail. C’est pourquoi il est important d’avoir un jour spĂ©cial libre et dĂ©diĂ© Ă  l’apprentissage.
  • RĂ©inventer la roue est une nĂ©cessitĂ© (mais pas en prod, bien sĂ»r). Cela permet de mieux comprendre et maĂźtriser les mĂ©canismes de ce qui est mis en place ou de ce qu’on souhaite mettre en place.

Lorsque nous travaillons sur un projet, nous avons besoin de sentir que nous avons bien travaillĂ©. Pour cela, il faut un objectif. Et la meilleure façon d’y arriver est de rencontrer l’utilisateur de l’application que nous construisons. Cela aussi fait parti de l’apprentissage !

Conclusions

NCrafts c’est aussi des talks, des workshops et des open spaces. Il y a aussi une journĂ©e de formation la veille de l’Ă©vĂ©nement et une soirĂ©e ouverte Ă  tous les participants. En Ă -cĂŽtĂ©, on peut apprĂ©cier la qualitĂ© des repas en self-service, loin du sandwich que nous propose certains services ferroviaires.

NCrafts 2017 fut une session oĂč dans l’ensemble je me suis rĂ©galĂ© et oĂč surtout j’ai appris. Je me donne rendez-vous l’annĂ©e prochaine les 17 et 18 mai 2018 pour la nouvelle session (les sessions suivantes sont effectivement annoncĂ©es un an Ă  l’avance). Entre temps, une session NCrafts aura lieu le 7 dĂ©cembre 2017 Ă  Bordeaux.

Les différentes vidéos ainsi que celles des années précédentes sont disponibles sur le site : http://videos.ncrafts.io/.

L’article Retour sur #NCrafts 2017 est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

AgileFrance 2017, une pause dans le rythme parisien

ven, 06/30/2017 - 10:40

Comme chaque annĂ©e, AgileFrance nous permet de faire une pause dans le rythme effrĂ©nĂ© pour s’interroger sur les valeurs et pratiques Agile. Une introspection indispensable pour rester fidĂšle aux valeurs que nous prĂŽnons tous les jours.

Nous avons pu participer Ă  l’Ă©vĂ©nement cette annĂ©e et assister Ă  de trĂšs belles confĂ©rences.

Demander le programme

Les annĂ©es prĂ©cĂ©dentes, les organisateurs nous avaient habituĂ©s Ă  des confĂ©rences plutĂŽt farfelues intitulĂ©s De l’Ă©tat gazeux Ă  l’état plateforme, RĂ©aliser une bonne recette au concombre ou encore Dessinez une tartine. Cette annĂ©e m’a semblĂ© plus sage, du moins dans sa prĂ©sentation, tout en rĂ©servant d’excellente surprise dans le contenu. À l’exception bien entendu de la session “Ce que les Papous peuvent nous apprendre sur les transformations agiles”.

Cette année, Ippon animait 3 sessions :

Ça a Ă©tĂ© un plaisir de prĂ©senter ces sujets et d’Ă©changer sourires et sous-rires (monnaie de remerciement locale) en approfondissant avec les participants.

Nous regrettons juste de ne pas pouvoir revoir en vidéo les sessions qui passaient en parallÚle.

Forum ForAll

Comme les années précédentes, nous avons pu également participer à un grand forum ouvert, durant lequel chaque participant peut proposer son sujet et faire émerger les discussions.

Le temps nous ayant en plus gùté cette année, nous avons pu improviser des échanges passionnés en profitant du soleil.

Les sujets proposés étaient variés. Nous avons opté pour le totem du papillon en allant flùner à plusieurs endroits, pour regarder et écouter attentivement.

Un vrai moment de recul et d’Ă©changes. C’est apprĂ©ciable !

À emporter

Nous repartons avec un ensemble de sujets Ă  creuser.

Si nous devions en citer deux :

  • Le coaching systĂ©mique (et sa mise en pratique concrĂšte dans l’accompagnement des Ă©quipes), brillamment prĂ©sentĂ© par Arnaud Gervais. Il a su prĂ©senter simplement son utilisation concrĂšte du coaching systĂ©mique pour reprĂ©senter des problĂšmes classiques.
  • Le refactoring de spĂ©cifications mis en lumiĂšre par Cyrile Martraire qui permet de remonter les pratiques de refactoring au niveau d’une logique mĂ©tier et en identifiant des modĂšles cohĂ©rents.

Nous repartons Ă©galement avec l’envie de refaire des prĂ©sentations et mettre Ă  dispositions nos atelier en Open Source, en attendant la prochaine fois…

L’article AgileFrance 2017, une pause dans le rythme parisien est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

A la rencontre de Valentin Carmignac, consultant chez Ippon Australie

jeu, 06/29/2017 - 17:25
Peux-tu nous prĂ©senter ton parcours chez Ippon ?  Je suis arrivĂ© chez Ippon Paris en novembre 2015 ou j’ai commencĂ© par une mission de 6 mois pour Sita-Suez en mode projet au siĂšge d’Ippon. Ca m’a permis de rencontrer beaucoup de monde et de bien m’intĂ©grer (Merci Omar <3). Puis j’ai enchainĂ© par une mission de rĂ©gie chez Darty, Ă  Bagnolet. Pas grand chose Ă  dire de ce cĂŽtĂ© lĂ  si ce n’est que j’ai rencontrĂ© Laurent Ba et quelques consultants Arolla bien sympathiques ! A peu prĂšs Ă  cette pĂ©riode les bureaux de Melbourne ont ouverts et j’ai saisi la chance d’y postuler pour un VIE. Parce que je me suis blessĂ© en fin d’annĂ©e, ma mission Darty s’est terminĂ©e et j’ai commencĂ© Ă  travailler avec l’Ă©quipe australienne sur le projet Toyota, ce qui m’a permis de faire connaissance.

 

Travailler en Australie t’y pensais depuis longtemps ? Pas forcĂ©ment l’Australie mais oui, l’idĂ©e de travailler Ă  l’Ă©tranger m’est venue pendant mes Ă©tudes et elle a muri pendant tout ce temps. J’ai initialement postulĂ© chez Ippon pour un VIE a Richmond. Au final ils m’ont proposĂ© un CDI Ă  Paris et j’ai acceptĂ© tout en laissant savoir que mon envie de partir Ă©tait toujours prĂ©sente.

 

La vie Ă  Melbourne c’est comment ?  C’est nul. Non vraiment, ça vaut pas la peine de venir pour ca. Vous feriez mieux de rester en France et me laisser ici je pense. Plus sĂ©rieusement c’est excellent, la vie est douce, et c’est trĂšs cosmopolite. Ce que j’apprĂ©cie particuliĂšrement c’est la sĂ©paration travail/vie privĂ©e. Les horaires sont plus souples, tant que tu fais le travail on te reprochera pas de partir plus tĂŽt. Je fais gĂ©nĂ©ralement des journĂ©es de 7h45 a 16h30 et personne ne me dit rien. Ca me laisse mes soirĂ©es tranquilles pour bouger, rencontrer des gens et tout et tout.

 

Pour toi Ippon en trois mots c’est ? 
  • Esprit d’Ă©quipe
  • Professionalisme
  • Afterwork

L’article A la rencontre de Valentin Carmignac, consultant chez Ippon Australie est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Feedback sur la Product Conf de Paris

mer, 06/21/2017 - 14:41

Voici quelques jours que la confĂ©rence 2017 de Paris est terminĂ©e. Ce jeudi 1er juin lĂ , j’y Ă©tais, vous aussi ? Il faut qu’on parle.

Cette seconde session en quelques chiffres : 16 speakers, 12 talks, 2 salles et plus de 400 participants. Soit le double de l’annĂ©e derniĂšre, ce qui montre l’engouement pour le sujet du Product Management et de ses activitĂ©s. L’organisation nous a dĂ©nichĂ© un lieu magique, la Grande Crypte sous l’Ă©glise Saint HonorĂ© d’Eylau en plein coeur du 16Ăšme arrondissement de Paris. Un lieu que personnellement je ne connaissais pas.

Parlons un peu du casting et des sessions que j’ai pu voir.

La keynote d’ouverture sous forme d’interview a bien lancĂ© la journĂ©e. Paulin Dementhon, CEO de Drivy, nous a expliquĂ© la genĂšse de l’entreprise, son extension pragmatique Ă  l’international, son organisation en Feature Team ainsi que de ses envies et opportunitĂ©s autour de la voiture autonome. Sa crainte Ă©galement qu’un Uber puisse devenir un Drivy, et l’éventuelle arrivĂ©e de ses redoutables concurrents amĂ©ricains sur le marchĂ© français. L’organisation avait mis en place l’application Wisembly pour poser les questions, idĂ©e de gĂ©nie qui permettra de rendre fluide cette phase qui clĂŽture chaque fin de session. A ma grande surprise, ce n’était que le dĂ©but d’une longue journĂ©e, de trĂšs nombreuses questions portaient sur le thĂšme de l’organisation des Ă©quipes et de l’entreprise. Ce thĂšme sera rĂ©current dans plusieurs de mes sessions.

La seconde session de ma matinĂ©e Ă©tait celle de Brian Crofts, VP Produit de Pendo. Rien de particulier Ă  ajouter sur cette session, si ce n’est une question anodine Ă  premiĂšre vue et qui reviendra Ă  plusieurs reprises dans les session suivantes. Vous savez cette question dĂ©licate et gĂȘnante oĂč l’on fait semblant de ne pas l’avoir entendu afin de ne pas y rĂ©pondre. Quelle est la diffĂ©rence entre un Product Manager et un Product Owner ? Brian a prĂ©fĂ©rĂ© parler de Product Leader, intĂ©ressant, cependant cette question est revenue par la suite dans d’autres sessions comme quoi il y a bien un malaise sur ce sujet prĂ©cis.

Finalement nous arrivions Ă  la pause dĂ©jeuner. Un repas simple et lĂ©ger, qu’il fallait nĂ©cessairement clĂŽturer avec une bonne glace et profiter d’une terrasse ombragĂ©e avec mes collĂšgues.

Je dĂ©marrais cet aprĂšs-midi lĂ  par une magnifique session et un speaker hors norme. Cela reste pour ma part LA session de cette confĂ©rence, celle de Luc Behar, CMO de Molotov TV. Une merveille. Difficile d’en faire un rĂ©sumĂ© de peur d’oublier quelque chose, tant la session Ă©tait riche d’enseignement concernant les (contre)vĂ©ritĂ©s sur le Product Management.
Je partage l’idĂ©e de Luc concernant le danger de rĂ©aliser des dĂ©veloppements incrĂ©mentaux, la premiĂšre prioritĂ© reste de corriger les anomalies et de supprimer les frustrations des utilisateurs avant mĂȘme d’ajouter des nouvelles fonctionnalitĂ©s. Il a fait allusion au framework AARRR (Acquisition, Activation, Retention, Referral, Revenue), trĂšs Ă  la mode, notamment le haut de la pyramide (Acquisition, Activation) qu’il met plus en lumiĂšre que la rĂ©tention car un super produit bĂ©nĂ©ficie toujours du bouche Ă  oreille. Également se poser les bonnes questions, notamment celle de savoir si l’on mesure bien l’activation et l’abandon ? Lorsque le client est parti, c’est trop tard.

La session suivante fut celle de Jean-Charles Samuelian, cofondateur et CEO de Alan. Cette startup a l’ambition de devenir leader du secteur de l’assurance santĂ© (souvent appelĂ©e mutuelle). Avec une premiĂšre levĂ©e de fond de 12 millions d’euros et une politique de pricing agressif via du hacking tarifaire chez les concurrents, l’entreprise a obtenu l’agrĂ©ment officiel pour devenir une sociĂ©tĂ© d’assurance notamment via l’entrĂ©e au capital de CNP.
Le message de Jean-Charles est simple mais terriblement percutant et efficace, faire simple et vite dans un secteur sclĂ©rosĂ© et compliquĂ©. En cela le produit va servir l’acquisition, ĂȘtre Ă  l’écoute des utilisateurs en proposant toujours plus de valeur sur l’intĂ©gralitĂ© de la chaĂźne. L’organisation de l’entreprise est inspirĂ© de Google Ventures, cela fait le buzz, et semble tout de mĂȘme assez bordĂ©lique. Objectif Ă  la semaine, pas de Product Management, petite Ă©quipe oĂč tout le monde fait tout. Est-ce que cela peut perdurer dans le temps ? A suivre.

La session suivante fut celle de Jessy Bernal et Florian Duchene, respectivement CTO et PM de Doctolib. IntĂ©ressante session, je suis moi mĂȘme utilisateur du service, on apprend comment l’aventure a dĂ©marrĂ© avec la mise en place de la plateforme technique en moins de 3 mois, la rĂ©alisation des fonctionnalitĂ©s basiques de prise de rendez-vous et de gestion de planning Ă  minima puis la dĂ©marche de trouver 30 clients afin de pouvoir lever les fonds.
AprĂšs 3 ans d’anciennetĂ©, 21 000 praticiens et 9 millions de patients. Un catalogue de quelques 300 fonctionnalitĂ©s juste sur la fonctionnalitĂ© calendrier. Une organisation Ă  taille humaine, 320 personnes dont juste 40 personnes Ă  la DSI et seulement 10 dĂ©veloppeurs. 4 Ă©quipes organisĂ©es en Feature Teams et une seule Ă©quipe Design transverse, des PO organisĂ©s sur les axes praticien et patient. Jessy avouera la complexitĂ© croissante et exponentielle du logiciel.
IntĂ©ressant, les deux speakers nous parlerons des 4 axes d’innovation Ă  venir : organisation des cabinets, relation entre le patient et les praticiens, relation entre les praticiens via doctolib network et la gestion de la santĂ© des patients.

Finalement la journĂ©e se termine par la keynote de clĂŽture, encore une fois sous forme d’interview avec les deux co-fondateurs de Heetch, Teddy Pellerin et Mathieu Jacob.
Le retour d’expĂ©rience est intĂ©ressant car la solution part d’une idĂ©e toute simple, comment se dĂ©placer la nuit dans la capitale. L’aventure dĂ©marre en 2013, l’idĂ©e est de mettre en relation des conducteurs et des particuliers pour se dĂ©placer et ainsi partager les frais. La cible de dĂ©part, les 18-25 ans comme early adopters, pas de communication, pas de presse, juste le bouche Ă  oreille.
La premiĂšre version de l’application sort en septembre 2013 sous forme de marketplace, 2 communautĂ©s qui doivent grossir en mĂȘme temps, celles des conducteurs et celles des passagers. Objectif prioritaire, acquĂ©rir des passagers. Le business model repose sur la mise en relation et le paiement d’une commission.
Le succĂšs du dĂ©but n’est pas le fait du produit, Heetch rĂ©alise plus de trajet que les autres tout simplement. Une part de chance aussi avoueront les deux fondateurs, et un bouche Ă  oreille de folie. Ils seront sur le terrain, Ă  la sortie des boĂźtes de nuit et des bars parisiens tous les vendredis, samedis et dimanches.

Cette confĂ©rence est un bon cru : une belle journĂ©e, une belle organisation, des sujets passionnants et des speakers pertinents. Pour autant, je dois reconnaĂźtre que j’ai quelques remarques. J’ai entendu, notamment lors des diffĂ©rentes pauses, que certains participants semblaient un peu déçus du contenu. Certes il y a beaucoup de storytelling et un peu de discours commercial, il faut le reconnaĂźtre, mais certains participants s’attendaient Ă  plus de concret. C’est Ă  dire de la mĂ©thode et des outils afin de se perfectionner. Est-ce le lieu pour cela ? Je pense que oui mais il faut prĂ©ciser qu’il ne s’agit pas d’une confĂ©rence Agile.
Cette confĂ©rence doit exister et perdurer car nĂ©cessaire mais elle doit s’amĂ©liorer. Je serai fidĂšle au poste, prĂ©sent. Je vous dis donc Ă  l’annĂ©e prochaine.

L’article Feedback sur la Product Conf de Paris est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

BizDevOps, véritable marqueur du Time to Market

ven, 06/16/2017 - 08:16

 

Un KPI majeur de la Transformation Digitale, le Time To Market

L’Experience Economy amĂšne de nouveaux modes de consommation dans lesquels la logique consumĂ©riste s’impose avec un rapport de force inversĂ© avec les clients. Ces derniers deviennent acteurs des produits qu’ils consomment. Ils sont proactifs, responsables de leurs choix et dĂ©cident avec qui, quand et comment ils vont consommer un produit qu’il soit bancaire, d’assurance, de grande consommation ou de luxe. SimplicitĂ©, rĂ©activitĂ©, disponibilitĂ© et immĂ©diatetĂ© sont devenus le standard. Aussi, dans cette course effrĂ©nĂ©e, le Time To market, Ă  savoir l’écart entre la crĂ©ation ou l’émergence d’un usage et le moment oĂč il est disponible sur le marchĂ©, devient le KPI principal. Ce nouvel usage est soit une rĂ©ponse Ă  un besoin du marchĂ©, soit la crĂ©ation d’un avantage compĂ©titif face aux concurrents. La rapiditĂ© d’une entreprise Ă  apporter des amĂ©liorations rapides, incrĂ©mentales et continues devient un facteur dĂ©terminant pour conserver l’avantage concurrentiel.

 

MaĂźtriser la chaĂźne de valeur complĂšte

Le seul moyen d’agir efficacement sur ce KPI est de maĂźtriser toute la chaĂźne de valeur de construction. Ainsi, idĂ©ation pour faire Ă©merger les nouveaux usages, comprĂ©hension des besoins utilisateurs, segmentation clients, POC (Proof Of Concept), validation des usages et stack technique au travers d’un  Minimum Viable Product (MVP), pĂ©rennisation du Go To Market via un Minimum Marketable Feature (MMF), industrialisation du Soft disponible en production constituent le cercle vertueux d’adressage du Time To Market. Il convient de disposer des dispositifs permettant de rendre les actions concrĂštes et de matĂ©rialiser rapidement la vision produit.

 

Cette vitesse d’exĂ©cution doit, Ă  l’heure du Fail Fast, intĂ©grer la  limitation des risques par la rĂ©sorption du cĂŽne d’incertitude afin d’accroĂźtre la maturitĂ© du Business Model. Pour cela, dĂ©cideurs MĂ©tiers, Études et surtout Production doivent avoir une vision commune et partagĂ©e du produit tant dans sa finalitĂ© et sa mise en oeuvre que dans la façon dont il sera dĂ©ployĂ© puis consommĂ©. L’articulation la plus efficiente consiste Ă  dĂ©ployer agilitĂ© et devops au travers de l’alignement MĂ©tier – Etude – Production. C’est la genĂšse de BizDevops : “Business”, “Development”, “Operations”.  BizDevOps, encore appelĂ© Devops 2.0 encourage cet alignement pour la production logicielle de façon Ă  ce que les organisations dĂ©veloppent plus vite, soient plus sensibles aux demandes des utilisateurs et maximisent leurs revenus. L’association de clients, lorsque c’est possible, et donc l’approche centrĂ©e client permet d’opĂ©rer et de complĂ©ter cet alignement. On parle alors de UserBizDevOps.

 

Sur quels axes adresser BizDevops ?

BizDevOps doit ĂȘtre adressĂ© au niveau culturel, processus et technologique.

  1. Culturel car nous avons tous dĂ©jĂ  entendu des responsables mĂ©tiers dire que leur IT n’était pas en capacitĂ© de leur dĂ©livrer des projets de qualitĂ© dans les dĂ©lais souhaitĂ©s et inversement l’IT se targuer d’ĂȘtre garant de la dĂ©marche industrielle de l’entreprise et ne pas pouvoir prendre en charge des dĂ©veloppements rapides et pas complĂštement dĂ©finis, demandĂ©s par le marketing et les mĂ©tiers.
    Il faut donc abattre les murs, faire sauter les cloisons qui coexistent dans l’entreprise. Plus que jamais, cette transition culturelle s’effectue avec les femmes et les hommes de l’entreprise. Des notions importantes telles que la confiance, la dĂ©lĂ©gation, la responsabilitĂ© vont ressurgir. On passe ainsi du mode Leader-Follower au mode Leader-Leader. La rĂ©flexion et le plan d’action de cette Ă©volution doivent intĂ©grer une dĂ©marche itĂ©rative et transversale pour que chacun s’exprime et que la cible soit collective.
  2. Processus car le point d’induction Ă  partir duquel il faut agir est l’usage. Cet usage prĂ©figure l’offre et le marketing qui en dĂ©coulent. Cela oblige Ă  maĂźtriser le cycle de vie des rĂšgles mĂ©tiers (sans oublier les contingences rĂ©glementaires et rĂ©galiennes) dans une agilitĂ© mĂ©tier qui doit ĂȘtre acquise et partagĂ©e avec l’IT afin de mettre en oeuvre les dĂ©veloppements agiles et les environnements Ă  la demande. Ce dernier point permet de boucler la chaĂźne devops.
  3. Technologique car il faut mettre  en oeuvre et gĂ©rer les nouveaux usages en s’affranchissant des contraintes liĂ©s Ă  l’infrastructure. Ainsi, il faut utiliser la souplesse apportĂ©e par le Cloud pour non seulement accĂ©lĂ©rer les processus de dĂ©veloppement, mais aussi simplifier et assouplir l’exploitation.
    Aussi, les architectes doivent proposer des environnements qui soutiennent productivitĂ©, Ă©volutivitĂ© et sĂ©curitĂ©, avec maĂźtrise des coĂ»ts et des risques. Les plateformes applicatives et les suites d’automatisation de nouvelle gĂ©nĂ©ration doivent disposer de mĂ©canismes d’installation, de configuration et d’intĂ©gration automatisĂ©es.
    Les dĂ©veloppeurs peuvent ainsi se concentrer sur la valeur mĂ©tier et la pertinence de mise en oeuvre applicative. Par exemple, grĂące aux conteneurs lĂ©gers, les dĂ©veloppeurs peuvent dĂ©composer leurs applications en microservices qu’ils peuvent exĂ©cuter sur des infrastructures bien plus modestes que prĂ©cĂ©demment. L’approche Platform As A Service permet dans le mĂȘme temps de simplifier dĂ©ploiement, maintenance et Ă©volution indĂ©pendante des microservices. Technologiquement, le triple adressage conteneurs, microservices, Platform As A Services constituent l’axe nĂ©vralgique d’évolution.

La combinatoire des trois axes “Culturel”, “Processus” et “Technologique” constitue la clĂ© de voĂ»te pour que les entreprises puissent crĂ©er et mettre Ă  disposition de leurs clients, dans des Time To Market agressifs, des usages clivants et structurants par rapport Ă  leur segment de marchĂ©.

 

Comment opĂ©rer l’alignement BizDevops?

Plusieurs Ă©tapes peuvent ĂȘtre envisagĂ©es pour opĂ©rer l’alignement BizDevOps. Le point structurant est que la transition doit se faire pas Ă  pas et de façon itĂ©rative. Ensuite, il est important d’impliquer le top management et de ne laisser aucun mĂ©tier sur la touche. Il y a, enfin, des moments privilĂ©giĂ©s qui peuvent servir de laboratoire Ă  la mise en oeuvre de l’alignement BizDevOps.   

  1. Le cadrage stratĂ©gique : Dans le cas de la construction d’une proposition de valeur pour l’entreprise par exemple, l’alignement doit ĂȘtre opĂ©rĂ© dĂšs les phases de cadrage stratĂ©gique. Cette proposition de valeur qui doit permettre soit de faire Ă©voluer, soit de rĂ©inventer le business model de l’entreprise est le catalyseur parfait. Tous les mĂ©tiers (Marketing, MĂ©tier, Etude, Exploitation) doivent ĂȘtre alignĂ©s sur trois piliers :
    • La cible, Ă  savoir, la proposition de valeur proposĂ©e aux clients.
    • Le moyen, la façon dont l’entreprise Ă©labore et dĂ©livre la proposition de valeur.
    • Le montage Ă©conomique, l’identification d’un modĂšle de revenus viable.

La rĂ©flexion commune sur ces 3 piliers va faire Ă  ce que la contribution de chacun apporte Ă  la stratĂ©gie globale,  à ce que chacun s’identifie Ă  cette stratĂ©gie et reconnaisse la valeur ajoutĂ©e des autres mĂ©tiers, et surtout que chacun perçoive la puissance de l’intelligence collective.

Les objectifs Ă©tant communs et partagĂ©s, ce premier niveau d’alignement BizDevOps tant dans la cible que dans les moyens mis en oeuvre, constitue le point de dĂ©part d’une chaĂźne de transformation rĂ©ussie.

  1. L’idĂ©ation : un autre use case intĂ©ressant pour favoriser l’alignement BizDevops est la participation Ă  des ateliers d’idĂ©ation. En effet, pour favoriser l’émergence d’idĂ©e et ainsi faciliter l’innovation, des ateliers de brainstorming avec facilitateurs et spĂ©cialistes de la transformation digitale sont d’excellents catalyseurs. Il convient que les grands mĂ©tiers de l’entreprise soient reprĂ©sentĂ©s pour crĂ©er un terrain propice Ă  l’innovation. Des approches telles que le brainstorming par le jeu (gamestorming) avec Proof Of Concept (POC) Ă  la volĂ©e sont particuliĂšrement adaptĂ©es. Ce POC doit ĂȘtre disponible dans le Cloud sous quelques jours et manipulable par tous. Ce modus operandi favorise l’échange, permet de comprendre les contraintes des uns et autres et surtout une fois encore, de mesurer la puissance de l’intelligence collective.
  2. La construction d’un MVP constitue un test “grandeur nature” de l’alignement BizDevops. Les Ă©quipes MĂ©tiers travaillent directement avec les dĂ©veloppeurs afin de faire converger la vision produit et pensent dĂ©ploiement et exĂ©cution (run) dĂšs le dĂ©part. C’est ensemble qu’ils vont rĂ©duire le cĂŽne d’incertitude, rĂ©duire les risques tant fonctionnels, qu’au niveau de la stack technique que pour le dĂ©ploiement. C’est aussi ensemble qu’ils vont pouvoir expĂ©rimenter rapidement et, soit identifier les Ă©checs (fail fast) pour apporter les modifications nĂ©cessaires, soit continuer sur les bonnes pratiques. Cette concrĂ©tisation effectuĂ©e avec les diffĂ©rents mĂ©tiers de l’entreprise, quelque soit leur domaine d’obĂ©dience (Business, DĂ©veloppement et Exploitation), est structurante. C’est elle qui est le point de dĂ©part de la dĂ©marche d’industrialisation et donc de la rĂ©alisation du logiciel.
  3. Durant la phase d’industrialisation, tous les prĂ©ceptes du BizDevOps acquis dans les phases prĂ©cĂ©dentes sont mis en oeuvre.
    • Ainsi, les dĂ©partements mĂ©tiers peuvent exprimer et revoir leur exigences de façon trĂšs efficace, rĂ©duisant le transfert de connaissances et permettant des cycles de retours  extrĂȘmement rapides, le Biz
    • Les Ă©quipe IT pilotent le processus de dĂ©veloppement de façon complĂštement corrĂ©lĂ©e aux besoins des mĂ©tiers et  peuvent se concentrer sur la qualitĂ© de la valeur Ă  produire, le Dev.
    • Les Ă©quipes d’exploitation offrent une automatisation complĂšte de la chaĂźne d’intĂ©gration et de la phase de dĂ©ploiement, ce qui permet encore d’accĂ©lĂ©rer le rythme des dĂ©veloppements, les Ops.

 

VĂ©ritable marqueur du Time to Market et de la satisfaction client

En dĂ©veloppant une culture de la collaboration entre les Ă©quipes, BizDevOps vise Ă  favoriser les intĂ©rĂȘts partagĂ©s dans une entreprise. BizDevOps met ainsi un objectif “Business” au centre des diffĂ©rents corps de mĂ©tiers qu’il responsabilise, de surcroĂźt, autour du processus d’alignement. Ainsi, il assure que les Ă©quipes IT, Exploitation et MĂ©tiers restent concentrĂ©es sur la performance de l’entreprise et l’expĂ©rience des utilisateurs. Les pratiques rĂ©ussies de DevOps associĂ©es Ă  une approche unifiĂ©e de l’expĂ©rience utilisateur permet Ă  ces entreprises une meilleure exĂ©cution des objectifs “Business”, d’accroĂźtre la satisfaction client, d’avoir des Time To Market trĂšs optimisĂ©s, de renforcer la compĂ©titivitĂ© et enfin d’amĂ©liorer les rĂ©sultats d’exploitation.

 

Patrick Jean-François Digital Consulting Director chez Ippon

 

L’article BizDevOps, vĂ©ritable marqueur du Time to Market est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Ippon @Agile France

mer, 06/14/2017 - 15:05

Les 15 et 16 juin à Paris, trois de nos consultants seront speakers à Agile France la grande conférence agile francophone, de la communauté pour la communauté.

L’article Ippon @Agile France est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Les architectures Serverless

ven, 06/09/2017 - 08:52

Nous le savons tous, le monde informatique est en constant changement. Que ce soit les Ă©volutions matĂ©rielles, l’avĂšnement de l’IoT ou encore les services proposĂ©s par les Cloud Providers. Le monde du dĂ©veloppement logiciel n’échappe pas Ă  cette tendance. Outre les nouveaux frameworks Web qui sortent plus vite que notre courbe d’apprentissage, les architectures applicatives elles aussi se voient repensĂ©es, remaniĂ©es. Il y a encore peu de temps, nous pensions tous qu’un bon vieux monolithe Ă©tait “LA” solution simple, efficace et pas chĂšre.

Hors avec l’émergence de la conteneurisation et du DevOps, un nouveau panel  d’architectures a vu le jour. Nous avons ainsi hĂ©ritĂ© des architectures Microservices. Simples, scalables et rapides Ă  dĂ©velopper lorsque l’on se base sur des gĂ©nĂ©rateurs tel que JHipster, elles ont ouvertes de nouvelles voies dans le dĂ©veloppement d’applications Web. Mais comme toute nouvelle architecture, celle-ci venait avec son lot  de contraintes. L’une d’entre elles est la gestion de l’infrastructure. MĂȘme si le DevOps et la conteneurisation ont apportĂ© beaucoup dans cette problĂ©matique, ils ne l’ont pas rĂ©solue pour autant.

Aujourd’hui, une nouvelle architecture fait parler d’elle dans le monde de l’IT, c’est le Serverless

Alors qu’est-ce que le Serverless exactement ? DĂ©finition

Les architectures sans serveur se réfÚrent à des applications qui dépendent de maniÚre significative de services tiers (connue sous le nom de Backend en tant que service ou «BaaS») ou sur un code personnalisé exécuté dans des conteneurs éphémÚres (Function as a Service ou «FaaS»), le fournisseur de ce service le plus connu est actuellement AWS Lambda.

De nos jours la migration de nombreuses fonctionnalitĂ©s cĂŽtĂ© FrontEnd nous a permis de supprimer nos besoins de serveurs “Always On”. Selon les circonstances, de tels systĂšmes peuvent rĂ©duire considĂ©rablement le coĂ»t et la complexitĂ© opĂ©rationnels et ainsi se rĂ©sumer Ă  payer uniquement les frais d’utilisations  (bande passante, volume de stockage). Ainsi on ne paie ainsi que ce que l’on consomme, connu aussi comme le pay-as-you-go.

Comme de nombreuses tendances dans le logiciel, il n’y a aucune vision claire de ce qu’est ‘Serverless’, et cela n’a pas Ă©tĂ© aidĂ© par le fait qu’il s’agisse vraiment de deux domaines diffĂ©rents, mais qui se chevauchent:

  • Serverless a d’abord Ă©tĂ© utilisĂ© pour dĂ©crire des applications qui dĂ©pendent de maniĂšre significative ou totale Ă  des applications / services tiers (‘dans le cloud’) pour gĂ©rer la logique et l’Ă©tat du serveur. Ce sont gĂ©nĂ©ralement des applications «client riches» (pensez Ă  des applications Web en une seule page ou Ă  des applications mobiles) qui utilisent le vaste Ă©cosystĂšme de bases de donnĂ©es accessibles sur le cloud (comme Parse, Firebase, AWS DynamoDB, …), les services d’authentification (Auth0, AWS Cognito), etc. Ces types de services ont Ă©tĂ© prĂ©cĂ©demment dĂ©crits comme Backend as a service (j’utiliserai le terme BaaS comme abrĂ©viation dans le reste de cet article).
  • Serverless peut Ă©galement symboliser des applications oĂč une certaine quantitĂ© de logique serveur est toujours Ă©crite par le dĂ©veloppeur, mais contrairement aux architectures traditionnelles (exemple: Monolith), elle est exĂ©cutĂ© dans des conteneurs stateless qui sont dĂ©clenchĂ©s par le biais d’évĂ©nements, Ă©phĂ©mĂšre (uniquement une invocation) et entiĂšrement gĂ©rĂ© par une 3rd party. Une façon de penser Ă  ceci est le terme Function as a service ou Faas. AWS Lambda est l’une des implĂ©mentations les plus populaires de FaaS Ă  l’heure actuelle, mais il y en a d’autres (Google Functions).

Nous parlerons principalement de la deuxiĂšme dĂ©finition du fait qu’elle soit plus rĂ©cente et qu’elle possĂšde le plus de diffĂ©rence avec la vision que l’on a d’une architecture technique traditionnelle (elle est tout simplement plus hype !!)

Attention Ă  l’Ă©tymologie

Le terme «Serverless» est source de confusion car, dans de telles applications, il existe Ă  la fois du matĂ©riel et des processus serveur. La diffĂ©rence avec les approches basiques est que l’entreprise crĂ©ant et prenant en charge une application dite Serverless ne s’occupe pas du matĂ©riel ou des processus, ils externalisent cela Ă  un fournisseur (AWS, Google, 
) et ainsi se concentrent uniquement sur la partie fonctionnelle de l’application.

Quelques exemples

Afin d’illustrer le fonctionnement et l’approche Serverless, voici des exemples de Use Cases.

Application Web

Prenons l’exemple d’un site e-commerce. Il s’agit d’une application Web 3-tiers avec la logique cĂŽtĂ© serveur.

Avec cette architecture, le client ne contient pratiquement aucune logique comparé au serveur (authentification, navigation de page, recherche, transactions).

Avec une architecture Serverless, cela pourrait finir par ressembler davantage Ă  ceci:

Il s’agit d’un exemple de transposition de l’architecture prĂ©cĂ©dente en Serverless. Il y a un certain nombre de changements importants qui se sont produits ici. S’il vous plaĂźt notez que ce n’est pas une recommandation d’une migration architecturale, je l’utilise simplement comme un outil pour exposer certains concepts sans serveur.

  • Plus besoin d’hĂ©berger nos fichiers Web sur un serveur, un simple bucket et un outil de gestion du cache peuvent suffir.
  • Nous avons supprimĂ© la logique d’authentification et l’avons remplacĂ©e par un service tiers BaaS (Auth0, AWS Cognito, 
).
  • En utilisant un autre exemple de BaaS, nous avons permis Ă  un client d’accĂ©der directement aux donnĂ©es (listes de produits), hĂ©bergĂ©es par un tiers (AWS Dynamo, Firebase). Nous pouvons aussi Ă©tabli des rĂšgles de sĂ©curitĂ© strictes liĂ©es aux profils utilisateurs et ainsi gĂ©rer les restrictions d’accĂšs aux donnĂ©es.
  • Les deux points prĂ©cĂ©dents impliquent un changement important des rĂŽles des tiers : la logique est passĂ©e du serveur au client (exemple : suivi d’une session utilisateur, UX, lecture de donnĂ©es et affichage dans une vue utilisable.
  • Certaines fonctionnalitĂ©s sont Ă  garder cĂŽtĂ© serveur, par exemple, si elles impliquent des calculs intensifs ou nĂ©cessitent l’accĂšs Ă  des quantitĂ©s importantes de donnĂ©es (recherche de produits). Pour cette fonctionnalitĂ©, au lieu d’avoir un serveur toujours en cours d’exĂ©cution, nous pouvons implĂ©menter une fonction FaaS qui rĂ©pond aux requĂȘtes HTTP via une API Gateway.
  • Finalement, nous pouvons remplacer la fonctionnalitĂ© “Achat” par une autre fonction FaaS, en choisissant de la garder sur le cĂŽtĂ© serveur pour des raisons de sĂ©curitĂ©.

Avec ce changement d’architectures, nous avons un nouveau panel d’outils Ă  notre disposition comme l’API Gateway. Pour faire simple, cet outil permet de dĂ©finir des endpoints sĂ©curisĂ©s accessible de l’extĂ©rieur et de rediriger l’appel vers un service de traitement (gĂ©nĂ©ration d’un Ă©vĂ©nement, lancement d’une fonction) qui une fois fini pourra retourner des donnĂ©es selon les besoins.

Application basée sur les événements (Event-driven)

Un autre Use Case d’architecture Serverless est l’analyse et le traitement de donnĂ©es asynchrones. Prenons un cas que nous connaissons tous, le tracking d’activitĂ©s des utilisateurs d’une application. Le besoin est d’arriver Ă  connaĂźtre les activitĂ©s prĂ©cises d’un utilisateur sans impacter les performances de l’application. Nous pourrons ainsi dĂ©porter la logique permettant l’envoi/rĂ©ception d’un Ă©vĂ©nement de navigation et son enregistrement au sein d’une base de donnĂ©es de type BaaS.

Voici l’exemple d’une architecture d’application Web basique possĂ©dant une fonction de tracking Serverless (zone rouge)

Ce service est assurĂ© Ă  l’aide d’une API Gateway, fonction permettant la dĂ©claration d’endpoint et son mapping vers un service de traitement, ici une fonction de type FaaS. Elle-mĂȘme est en charge de l’enregistrement des donnĂ©es auprĂšs d’une base de donnĂ©es de type BaaS.

Un autre exemple trĂšs en vogue de nos jours concerne l’IoT et son envoi d’informations effectuĂ© par des milliers de capteurs. Nous n’avons aucun besoin d’une communication synchrone entre la partie serveur et les capteurs, en revanche l’objectif est la rĂ©cupĂ©ration des informations, son stockage et son analyse. Un exemple de ce Use Case est la maintenance prĂ©dictive. AprĂšs la rĂ©cupĂ©ration des donnĂ©es brutes issues des capteurs, des algorithmes vont les analyser et pouvoir conjecturer et “prĂ©dire” une panne ou un besoin de maintenance d’un Ă©quipement.

Dans cette architecture nous utilisons des systĂšmes BaaS pour la gestion des flux de donnĂ©es (exemple : AWS Kinesis ou Google Cloud Pub/Sub) puis des systĂšmes FaaS pour le prĂ©traitement, le prĂ©-calcul ainsi que l’enregistrement de celles-ci dans une base de donnĂ©es fournis par un systĂšme BaaS.

Vous pourrez voir de nombreux exemples d’architectures Serverless Ă©ditĂ© par Werner Vogels, CTO chez amazon.com sur le lien suivant:

http://www.allthingsdistributed.com/2016/06/aws-lambda-serverless-reference-architectures.html

Qu’est-ce qui ne fonctionne pas en Serverless ?

Jusqu’Ă  prĂ©sent, j’ai dĂ©fini le terme Serverless pour signifier l’union de 2 principes – «Backend as a Service» et «Functions as a Service».

Avant de commencer Ă  examiner la promesse que peut offrir ce nouveau type d’architecture, j’aimerais d’abord expliquer ce qui n’est pas Serverless. Actuellement lorsque l’on recherche ce terme, nous pouvons trouver de nombreuses dĂ©finitions ou assimilations erronĂ©es.

#PaaS (Platform as a Service)

On peut en effet trouver des similitudes entre certains services PaaS comme Heroku et les services FaaS, certaines pensent mĂȘme que FaaS est une extension de PaaS. Mais comme dit Mike Roberts, co-fondateur de l’entreprise Symphonia.

La plupart des applications PaaS ne sont pas destinĂ©es Ă  ramener des applications complĂštes vers le haut et vers le bas pour chaque demande, alors que les plates-formes FaaS font exactement cela. 
 La diffĂ©rence opĂ©rationnelle clĂ© entre FaaS et PaaS est la mise Ă  l’Ă©chelle . Avec la plupart des PaaS, vous avez encore besoin de rĂ©flĂ©chir Ă  l’Ă©chelle, par exemple avec Heroku combien de Dynos vous souhaitez exĂ©cuter. Avec une application FaaS, cela est complĂštement transparent. MĂȘme si vous configurez votre application PaaS Ă  l’Ă©chelle automatique, vous ne le feriez pas au niveau des demandes individuelles (sauf si vous avez un profil de trafic trĂšs prĂ©cisĂ©ment façonnĂ©), et donc une application FaaS est beaucoup plus efficace en matiĂšre de coĂ»ts . #Container

La conteneurisation subit une popularitĂ© croissante de nos jours, surtout depuis l’arrivĂ©e de Docker. Nous pouvons en effet trouver certaines similaritĂ©s entre FaaS et la conteneurisation. Mais rappelons le, FaaS offre une couche d’abstraction telle que nous n’avons plus la notion de processus systĂšme au contraire de Docker qui est basĂ© sur du la notion de processus unique.

Parmis ces similitudes, nous retrouvons l’argument de la mise Ă  l’échelle. FonctionnalitĂ© disponible niveau conteneur grĂące aux systĂšmes tels que Kubernetes, Rancher ou Mesos. Dans ce cas nous pouvons nous poser la question du pourquoi faire du FaaS alors que nous pouvons faire du conteneur ?

Il faut savoir que malgrĂ© le buzz autour de cette technologie, elle reste toujours immature et de nombreuses entreprises ont encore du mal Ă  basculer leur infrastructure de conteneur en production. De plus les systĂšmes de mise Ă  l’échelle niveau conteneur est encore loin d’arriver au niveau de celle des FaaS mĂȘme si cette Ă©cart tend Ă  se rĂ©duire avec l’arrivĂ©e de nouvelles fonctions telles que Horizontal Pod Autoscaling pour Kubernetes.

Finalement, le choix de la technologie se fera selon les cas d’utilisations.

#NoOps

Il ne faut pas confondre Serverless et NoOps. Si on prend le mot Ops (OpĂ©rations) cela ne signifie pas uniquement des opĂ©rations d’admin systĂšmes. Cela signifie Ă©galement au moins le suivi, le dĂ©ploiement, la sĂ©curitĂ©, le rĂ©seautage et aussi souvent une certaine quantitĂ© de dĂ©bogage de production et de mise Ă  l’Ă©chelle du systĂšme. Ces problĂšmes existent toujours avec des applications Serverless, je dirais mĂȘme qu’elles sont plus compliquĂ©es Ă©tant donnĂ© la jeunesse de la technologie et les nouvelles fonctions et paramĂštres Ă  prendre en compte.

Je vous conseille de lire la conversation faite par Charity Majors sur le sujet ici.

La promesse d’une architecture Serverless

Nous verrons dans cette partie la promesse que peut offrir une architecture Serverless. Pour cela nous listerons les avantages et les inconvénients inhérents à celle-ci.

Avantages Coût opérationnel réduit

Serverless est de nature une solution simple d’externalisation. Il vous permet de payer quelqu’un pour gĂ©rer les serveurs, les bases de donnĂ©es et mĂȘme la logique des applications. Etant donnĂ© que votre service fait parti d’un ensemble de services similaires, la notion d’économie d’échelle va alors s’appliquer – vous payez moins cher vos coĂ»ts de gestion vu que le mĂȘme service est utilisĂ© par de nombreux autres ce qui permet de rĂ©duire les coĂ»ts.

Les coûts réduits apparaissent comme le total de deux notions:

  • le coĂ»t d’infrastructure
  • le coĂ»t des employĂ©s (opĂ©rations / dĂ©veloppement).

Alors que certains des gains de coĂ»ts peuvent venir uniquement de l’infrastructure de partage (matĂ©riel, rĂ©seau) avec d’autres utilisateurs, l’attente derriĂšre peut aussi se traduire dans une rĂ©duction des coĂ»ts liĂ©s Ă  l’utilisation du personnel d’exploitation du fait de l’utilisation de technologies managĂ©es.

Cet avantage, cependant, n’est pas trop diffĂ©rent de ce que vous obtiendrez en utilisant des technologies de type Infrastructure as a Service (IaaS) ou Platform as a Service (PaaS).

BaaS – CoĂ»t de dĂ©veloppement rĂ©duit

Afin d’illustrer ce point, prenons en exemple le cas de l’authentification. De nombreuses applications codent leur propre service d’authentification et de gestion des utilisateurs, implĂ©mentant par la mĂȘme occasion leur propre niveau de sĂ©curitĂ©. Parmis les fonctionnalitĂ©s implĂ©mentĂ©es, nous pouvons retrouver :

  • L’enregistrement et la validation d’un utilisateur (Enregistrement Suppression)
  • La rĂ©cupĂ©ration d’un mot de passe
  • La connexion et l’accĂšs aux services

Dans l’ensemble nous retrouvons Ă  peu de choses prĂšs ces fonctionnalitĂ©s dans la plupart des applications actuelles. MĂȘme si des solutions de type gĂ©nĂ©rateurs d’application comme JHipster existent et permettent de gĂ©nĂ©rer rapidement plusieurs types d’authentification, il n’en reste pas moins Ă  la charge de l’entreprise de maintenir ce code et de les faire Ă©voluer. A ce jour, nous voyons l’émergence de services tels que Auth0 qui fournissent des fonctionnalitĂ©s d’authentification “prĂȘte Ă  l’emploi”. L’application peut ainsi se dĂ©charger de ces fonctionnalitĂ©s et laisser le fournisseur du service ĂȘtre responsable de leurs maintien.

Un autre exemple qui se prĂȘte bien au jeu est l’utilisation de services de base de donnĂ©es tels que Firebase. On retrouve principalement ces cas d’utilisations au sein des architectures mobiles qui prĂ©fĂšrent crĂ©er une communication directe entre le client (mobile) et la base de donnĂ©es et ainsi supprimer tous les tiers, et par ce fait l’administration de la base de donnĂ©es et son optimisation. Ce systĂšme apporte aussi une nouvelle couche de sĂ©curitĂ© et permet ainsi une gestion plus fine des donnĂ©es accessibles en fonction des diffĂ©rents profils utilisateur.

FaaS – CoĂ»t de mise Ă  l’Ă©chelle

Pour ma part l’un des avantages les plus importants du Serverless est la mise Ă  l’échelle horizontale automatique, Ă©lastique et surtout gĂ©rĂ©e par le fournisseur. Cela peut se traduire par plusieurs avantages, principalement au niveau infrastructure, mais surtout cela permet d’avoir une facturation trĂšs fine et de ne payer que la charge dont vous avez besoin, que ce soit en temps de calcul utilisĂ© (Ă  partir de 100 ms pour AWS Lambda) ou en quantitĂ© de donnĂ©es rĂ©cupĂ©rĂ©es ou analysĂ©es. Selon votre architecture et vos Use Cases cela peut engendrer une Ă©norme Ă©conomie pour vous.

Un des cas d’exemple d’économie est l’utilisation occasionnelle d’une fonction. Par exemple, disons que vous exĂ©cutez une application serveur qui ne traite que 1 demande chaque minute, qu’il faut 50 ms pour traiter chaque requĂȘte et que votre utilisation moyenne de CPU pendant une heure est de 0,1%. D’un point de vue charge de travail serveur, cela est extrĂȘmement inefficace.

La technologie FaaS capte cette inefficacitĂ© et vous permet ainsi de ne payer que ce que vous consommez, c’est-Ă -dire 100ms (valeur minimum) de calcul par minute, soit moins de 0,5% du temps global.

Pensons optimisations

MĂȘme si cette nouvelle architecture propose des nouvelles fonctionnalitĂ©s telles que la mise Ă  l’échelle, elle n’en subit pas moins les contraintes inhĂ©rentes au dĂ©veloppement d’applications.  Ainsi la phase d’optimisation des fonction prends encore plus de valeurs vu qu’elle permettra, en plus d’amĂ©liorer le temps de rĂ©ponse aux utilisateurs, d’économiser de l’argent sur la facturation. Par exemple pour une opĂ©ration qui initialement prend 1 seconde et qui aprĂšs optimisation prend 200ms, nous aurons une rĂ©duction immĂ©diate de notre facture de 80% du coĂ»t de calculs.

Une informatique plus “verte”

Etant donnĂ© que l’écologie est un sujet phare du moment, je ferai un paragraphe dĂ©diĂ© Ă  cette partie.

De nos jours, nous avons vu le nombre de datacenters augmenter de plus en plus au fil des annĂ©es. La consommation en Ă©nergie de ceux-ci est Ă©norme et de plus en plus de Cloud providers se sensibilisent Ă  l’écologie et aux Ă©nergies renouvelables. Ainsi Google, Apple, 
 parlent de construire et d’hĂ©berger certains de leurs datacenters dans des zones Ă  fort potentiel en Ă©nergies renouvelables afin de rĂ©duire l’impact sur l’environnement de ces sites.

L’une des causes de cette hausse du nombre de serveurs est due au maintien et à la consommation des serveurs dits “inactifs” face à une demande toujours croissante des entreprises.

Comme le stipule le magazine Forbes

Typical servers in business and enterprise data centers deliver between 5 and 15 percent of their maximum computing output on average over the course of the year.

Ces charges non utilisĂ©es viennent principalement de dĂ©cisions faites par les entreprises sur les capacitĂ©s nĂ©cessaires au fonctionnement d’une application et des “marges de sĂ©curitĂ©â€ faites afin de palier aux fluctuations de charges. Avec une approche Serverless, nous ne prenons plus de dĂ©cision sur la capacitĂ© nĂ©cessaire Ă  l’exĂ©cution d’une fonctionnalitĂ©, cette charge revient dĂ©sormais aux fournisseurs du service. Il se doit de fournir une capacitĂ© de calcul suffisante pour nos besoins en temps rĂ©el. Il pourra ainsi avoir une vision globale des capacitĂ©s nĂ©cessaires pour l’ensemble de ces clients. Ils pourront par ce biais optimiser la gestion des ressources et permettre une rĂ©duction du nombre de serveurs et en consĂ©quence l’impact environnemental des datacenters.Cela reprĂ©sente un fonctionnement extrĂȘmement inefficace et surtout un impact environnemental non nĂ©gligeable.

Les inconvénients

Et oui nous ne sommes pas lĂ  que pour vanter les mĂ©rites de cette nouvelle technologie et dire qu’elle peut rĂ©soudre tous nos problĂšmes (on compare d’ailleurs souvent celle-ci par un arc-en-ciel et une licorne). Comme toute technologie, elle vient aussi avec son lot d’inconvĂ©nients qui ne sont pas Ă  prendre Ă  la lĂ©gĂšre car ceux-ci pourrait devenir votre pire cauchemar selon vos Use Cases.

Il faudra toutefois sĂ©parer ces inconvĂ©nients en 2 types, ceux inhĂ©rents Ă  ces nouvelles architectures et cette technologie et ceux qui ont pour origine sa jeunesse et son manque d’outillages et de solutions.

Verrouillage des Cloud Providers

Le premier et pas des moindres pour moi est la dĂ©pendance forte que l’on crĂ©e avec le fournisseur de service. A ce jour aucune spĂ©cification n’est sortie afin d’adopter un langage commun entre les fournisseurs. MĂȘme si certains frameworks (Serverless.io) essaient de briser ces limitations, lors de la conception de votre solution et du choix des fonctionnalitĂ©s, vous devrez faire le choix d’un fournisseur unique afin de garantir une certaines homogĂ©nĂ©itĂ© de communication entre les diffĂ©rentes couches et pour palier au vĂ©rouillage que les fournisseur font de leurs services. Par exemple pour la liaison API Gateway > AWS Lambda, vous ĂȘtes contraint d’utiliser les 2 technologies AWS pour garantir son fonctionnement. Vous pourrez toujours trouver des passerelles afin d’utiliser plusieurs fournisseurs de services diffĂ©rents (Authentification via Auth0, DB via Firebase et API + Lambda via AWS) mais dans ce cas, cela compliquera fortement l’administration et la facturation de votre solution.

Il en va de mĂȘme pour le code utilisĂ© au sein des fonctions, il est propre Ă  chaque fournisseur et il vous faudra donc prĂ©voir un coĂ»t de rĂ©Ă©criture lors de son changement.

Optimisations des serveurs

A partir du moment oĂč vous dĂ©cidez d’utiliser des technologies Serverless, vous abandonnez par ce fait le contrĂŽle de certains systĂšmes tiers et de leur configuration. MĂȘme si cette gestion par le fournisseur vous conviendra dans 99% des cas, il reste 1% des cas ou votre solution nĂ©cessitera d’avoir une configuration spĂ©cifique du service afin d’amĂ©liorer ses performances ou une meilleure qualitĂ© de services.

Sécurité

Je ne pouvais pas Ă©crire un article sur le Serverless sans parler de la sĂ©curitĂ© de cette technologie. De nombreuses entreprises se sensibilisent de plus en plus aujourd’hui Ă  la sĂ©curitĂ© de leurs applications et Ă  l’accĂšs Ă  leurs donnĂ©es. Les services Serverless ne vont pas Ă©chapper Ă  la rĂšgle et vont apporter leur lot de questions. Je vais tenter d’en expliquer 3 mais de nombreuses autres sont Ă  considĂ©rer.

  1. En sĂ©curitĂ©, on parle souvent de pĂ©rimĂštre ou de surface d’action d’une solution. Cela correspond Ă  l’empreinte que celle-ci Ă  sur Internet. Plus l’empreinte est grande, plus la surface d’attaque est importante. Or l’utilisation de plusieurs services Serverless va augmenter votre empreinte et crĂ©er une certaine hĂ©tĂ©rogĂ©nĂ©itĂ© dans vos politiques de sĂ©curitĂ©. Par ce fait vous augmenterez votre probabilitĂ© d’intention malveillante Ă  l’encontre de votre solution et la probabilitĂ© qu’une de ces attaques soit rĂ©ussie.
  2. Si vous utilisez le service de base de donnĂ©es de type BaaS et permettez l’accĂšs direct Ă  vos donnĂ©es via une API cliente, vous perdrez la barriĂšre de protection qu’une application serveur traditionnelle peut fournir de part sa configuration rĂ©seau ou ses restrictions d’accĂšs au serveur. Cependant, mĂȘme si ce problĂšme n’est pas une fin en soi, il est Ă  prendre en compte lors de la conception de votre application.
  3. De part le fait que les services que vous utilisez sont mutualisĂ©s, vous hĂ©ritez des problĂ©matiques de sĂ©curitĂ© inhĂ©rente au service multi tenant. Par exemple l’accĂšs aux donnĂ©es d’autres clients du fait du partage des processus.
Problùmes à l’utilisation

Passons maintenant aux inconvĂ©nients inhĂ©rents aux solutions actuellement disponibles. Ceux-ci pourront en effet ĂȘtre corrigĂ©s avec l’évolution de la technologie et de l’Ă©cosystĂšme qui l’entourent.

DurĂ©e d’exĂ©cution

Un problĂšme actuel concerne la limitation faite sur la durĂ©e d’exĂ©cution des fonctions. Actuellement nous avons une durĂ©e limite de 5min pour AWS et 9min pour Google Cloud. Cette contrainte restreint le pĂ©rimĂštre d’actions des fonctions et ainsi empĂȘche leur utilisation pour un grand nombre de Use Cases comme le traitement vidĂ©o par exemple.

Latence de démarrage

Un autre inconvĂ©nient que certaines implĂ©mentations de FaaS provoquent est la latence au dĂ©marrage. En plus du temps d’exĂ©cution de la fonction, vient s’ajouter une latence pouvant aller jusqu’à 10 secondes selon les cas de figure (exemple lors de l’utilisation d’une JVM ou lors d’un premier lancement). C’est pourquoi certains fournisseurs comme Google contraignent  le langage de dĂ©veloppement de leurs fonctions et ainsi permettent uniquement l’utilisation du Javascript (ce qui se comprend vu les performances de leur moteur). 

De mĂȘme nous pouvons observer des latences rĂ©seaux lorsque l’on met en sĂ©rie plusieurs fonctions lambda.

Tests

Vu que l’on parle beaucoup de dĂ©veloppement il en est de mĂȘme pour les tests. MĂȘme si certains pensent que “Tester c’est douter”, nous nous devons de traiter ce point, d’autant plus qu’il s’agit d’un lourd inconvĂ©nient lors de l’utilisation de ce type de services.

Certains peuvent penser qu’en raison de l’isolation de chacune des fonctions, il peut ĂȘtre relativement facile de les tester. Ceux-lĂ  ont raison pour le pĂ©rimĂštre des tests unitaires vu qu’il s’agit simplement d’un bout de code, cependant lorsque l’on aborde le sujet des tests d’intĂ©gration c’est une autre paire de manches. De nouvelles notions et questions vont alors apparaĂźtre venant principalement du fait que vous dĂ©pendez de services externes (base de donnĂ©es, authentification). Nous pouvons nous interroger sur leur pĂ©rimĂštre et sur la pertinence d’effectuer ces tests bout en bout. Si tel est le cas, est ce-que ces services sont compatibles avec vos scĂ©narios de tests comme la gestion des Ă©tats avant et aprĂšs ? De plus, est-ce qu’une grille de coĂ»ts spĂ©cifique est prĂ©vu par les fournisseurs lors de tests de charge par exemple ?

Si votre volontĂ© est au contraire de vous soustraire Ă  ces services temporairement, il vous faudra alors des systĂšmes de stub local qui ne sont pas forcĂ©ment fournis par le fournisseur. Sur ce point, Google se diffĂ©rencie des autres par le fait que ses solutions sont gĂ©nĂ©ralement basĂ©es sur des systĂšmes Open Source, de ce fait l’écosystĂšme qui gravite autour fournit assez rapidement des moyens de stub ces services. D’autres questions apparaissent alors sur le niveau de confiance que l’on peut avoir dans ces stubs et s’ils ne sont pas fournis, comment faire pour les implĂ©menter.

Il en va de mĂȘme pour l’intĂ©gration des services FaaS. Il est encore difficile de trouver une implĂ©mentation locale de la structure qui embarque les fonctions. Il va donc falloir utiliser directement l’environnement final. MĂȘme si des notions de staging permettent de sĂ©parer l’utilisation en test de l’utilisation en production, celles-ci ne s’appliquent pas Ă  tous les services.

DĂ©ploiement et versionning

Actuellement aucun pattern probant n’est sorti sur la phase de packaging et dĂ©ploiement. C’est pourquoi nous avons rapidement des contraintes sur le dĂ©ploiement atomique des fonctions. Prenons le cas d’une sĂ©rie de fonctions qui s’exĂ©cutent, afin de garantir un dĂ©ploiement uniforme, il va falloir arrĂȘter votre service Ă  l’origine des Ă©vĂ©nements de dĂ©clenchement, puis livrer l’ensemble de vos fonctions pour ensuite activer de nouveau le service. Cela peut reprĂ©senter un problĂšme important pour les applications nĂ©cessitant de la haute disponibilitĂ©. Il en va de mĂȘme pour le versionning “applicatif” et la phase de rollback.

Supervision

A ce jour les seuls solutions possibles pour effectuer la supervision et le dĂ©boggage de vos fonctions sont celles fournies par votre fournisseur et il faut se le dire, elles ne sont pas encore au niveau attendu. MĂȘme si des efforts Ă©normes sont faits comme avec la sortie en preview de AWS X-Ray, il reste encore du chemin Ă  parcourir afin d’avoir une solution complĂšte et spĂ©cifique FaaS.

Conclusion

Nous avons vu dans cet article que l’approche Serverless peut en effet apporter beaucoup de simplification et d’avantages mais ce n’est pas la solution miracle Ă  tous les problĂšmes. Il faut bien Ă©tudier au prĂ©alable ses Use Cases et ses contraintes afin de pouvoir peser le pour et contre de cette nouvelle technologie.

Il faut aussi retenir qu’à ce jour la technologie Serverless est relativement jeune. A titre d’information, la technologie AWS Lambda existe uniquement depuis 2 ans et les Google Functions viennent tout juste de sortir de la phase BĂȘta. Nous avons donc peu de REX rĂ©els sur des architectures Serverless massives c’est pourquoi nous avons simplement exposĂ© les promesses qu’elle a Ă  nous offrir. Mais nous pouvons supposer un avenir radieux Ă  cette technologie vu l’effervescence des acteurs autour de celle-ci et l’émergence chaque jour de nouveaux systĂšmes ou frameworks qui nous permettrons une utilisation et une supervision simplifiĂ©e.

Dans un prochain article nous dĂ©taillerons plus prĂ©cisĂ©ment Comment faire du Serverless et nous expĂ©rimentons certaines de ces technologies et frameworks avec des cas concrets d’utilisation.

L’article Les architectures Serverless est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

L’infogĂ©rance est morte ! (ou presque)

mer, 06/07/2017 - 21:43

Par Jean-Marie Simonin, en charge du Cloud & DevOps Business Development chez IPPON

Adieu veau, vache, cochon, couvĂ©e, l’infogĂ©rance est morte, la rente s’est envolĂ©e ! Il y a prĂšs de 30 ans, l’utilisation de l’informatique au sein des entreprises a crĂ©Ă© un secteur drainant des milliers d’emplois : l’InfogĂ©rance. Service de maintenance RĂ©seau, Hardware, SystĂšme et Applicatif, l’infogĂ©rance permet aux entreprises d’externaliser la gestion de leur parc informatique.

DĂšs les annĂ©es 2000, des milliers d’informaticiens ont rejoint des plateaux de production afin d’installer et de maintenir des systĂšmes d’informations, appelĂ©s actuellement des « Ops ». Toujours dans les annĂ©es 2000, les premiers administrateurs SI furent dĂ©signĂ©s comme des « couteaux suisse », mais rapidement relĂ©guĂ©s pour raison d’organisation empirique du Delivery et surtout de raretĂ© des profils
 Progressivement, des normes et bonnes pratiques d’exploitation ont vu le jour dont la plus connue s’appelle ITIL.

Des centres de services structurĂ©s ont vu le jour; toute une organisation s’appuyant sur des savoir-faire, rĂ©pondant au besoin d’assemblage d’une IT stable et pĂ©renne, s’est affairĂ©e pour installer des architectures de serveurs physiques ou virtuels, Ă  maintenir des rĂ©seaux physiques ou virtuels, dĂ©ployer des environnements systĂšmes et applicatifs, les maintenir en condition de sĂ©curitĂ©.

Autour de ces services, les infogĂ©reurs ont dĂ©veloppĂ© des offres commerciales, des catalogues de services des forfaits d’exploitation, du pilotage projet
 Les contrats se sont empilĂ©s, constituant des revenus aux marges souvent allĂ©chantes.

Le jour oĂč tout a basculé 

Pourtant, ce mĂ©tier Ă©prouvant Ă  l’organisation complexe mais aux marges attrayantes, a Ă©tĂ© tuĂ© un matin de 2006, lorsqu’un gĂ©ant de la vente en ligne Ă  annoncĂ© la sortie de son offre d’hĂ©bergement : Amazon EC2. Amazon Web Services, en revendant une partie de l’infrastructure qui ne lui servait que lors des pĂ©riodes de fort trafic, a identifiĂ© un moyen simple de mettre Ă  disposition ses ressources de calcul : l’API.

L’API est un ensemble normalisĂ© de classes, de mĂ©thodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services Ă  d’autres logiciels. On parle de Software defined infrastructure. C’est Ă  partir de ce moment lĂ  que l’infrastructure est devenue pilotable par du code.

L’arrivĂ©e de l’API a bouleversĂ© les usages et permis l’apparition de  :

  • L’abstraction, rĂ©pandue dans le monde du dĂ©veloppement logiciel. Elle est devenue un des attributs du Cloud, facilitant les manipulations du rĂ©seau, des machines virtuelles, des volumes disques, des environnements systĂšmes ;
  • La programmatique, qui permet d’enchaĂźner des commandes afin d’automatiser le fonctionnement de l’infrastructure ;
  • Le mode On-Demand, qui a satisfait le besoin de disposer de ressources immĂ©diatement ;
  • La consommation horaire, qui rĂ©pond aux besoins de montĂ©e en charge, et permet la bonne gestion des investissements IT pour les nouveaux projets.

Pour rĂ©sumer, le Cloud a permis de mettre Ă  disposition des entreprises un outillage permettant d’industrialiser, d’automatiser, de stabiliser l’IT et surtout de simplifier sa gestion quotidienne.

Les pionniers du Cloud : les devs

Du cĂŽtĂ© des DSI et des infogĂ©reurs, le Cloud n’a pas rencontrĂ© un franc succĂšs, et Ă  ce jour encore trop peu d’administrateurs l’utilisent. Les premiĂšres consommations de Cloud sont venues de la part d’une population jusqu’alors trĂšs Ă©loignĂ©e du monde des ops : les devs.

Les dĂ©veloppeurs furent les premiers utilisateurs du Cloud. En quelques secondes, ils avaient Ă  disposition des environnements pour faire fonctionner leurs projets, plus d’investissement initial, des coĂ»ts extrĂȘmement rĂ©duits et surtout, plus d’ops avec qui dĂ©battre de la meilleure version d’Apache ou de Tomcat. Plus « d’install’ machine », plus d’attente. Tout est lĂ  et surtout : tout est code !

Infrastructure as code = architecture polymorphe et « vivante »

L’Infrastructure as code ou l’art de fabriquer, de lancer et de faire vivre une infrastructure avec le moins d’intervention humaine. L’enchaĂźnement des lignes de commandes permet de scĂ©nariser le fonctionnement d’une production, les outils permettent d’anticiper des incidents, des montĂ©es en charge et rĂ©sout les problĂšmes en temps rĂ©el. Tout ce qui justifiait une organisation complexe constituĂ©e d’experts divers et variĂ©s pour opĂ©rer le « Run » est dĂ©sormais dĂ©suĂšte car inutile.

Autrefois, les contrats d’infogĂ©rance Ă©taient constituĂ©s comme tels : pour une somme de 100  dĂ©pensĂ©s sur 12 mois, 20 Ă©taient dĂ©diĂ©s au montage de l’infrastructure (Build ) et 80 pour son entretien courant (Run). Pour un infogĂ©reur, la marge se dĂ©gage durant cette phase de Run, le Build servant souvent de levier de nĂ©gociation pour « appĂąter le chaland ». Le Build est souvent dĂ©ficitaire, mais qu’importe. La marge c’est le temps. Plus un client reste, plus les marges s’accroissent.

L’infogĂ©rance est morte, vive le Cloud building !

Le paradigme du Cloud dĂ©membre ce modĂšle Ă©conomique.  L’automatisation entraĂźne des phases de Build consĂ©quentes. Il faut penser Ă  tout, anticiper, documenter, l’objectif Ă©tant ici de rĂ©duire la quantitĂ© d’intervention durant la phase de Run.

De nouveaux acteurs, souvent trĂšs jeunes, ont investi le terrain. Ayant compris l’importance du mĂ©tier de Cloud Builder,  ils opĂšrent cette transformation en proposant des contrats Ă  trĂšs haute valeur ajoutĂ©e, incluant une plus grande flexibilitĂ©, une meilleure gestion du risque et surtout une production toujours disponible. Les entreprises elles mĂȘmes suspendent leurs contrats d’infogĂ©rance et internalisent le management de leurs infrastructures.

Si l’infogĂ©rance est morte, les infogĂ©reurs ne le sont pas et ça n’est pas souhaitable. Accompagner ses Ă©quipes Ă  ce changement, faire comprendre les bĂ©nĂ©fices d’une infrastructure as code, reconstruire un business model calquĂ© sur l’inversion des phases de Build et de Run : tel est le dĂ©fi Ă  relever ces prochaines annĂ©es.

L’article L’infogĂ©rance est morte ! (ou presque) est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Un mois de juin 100% DevOps

mar, 06/06/2017 - 13:00

Découvrez le programme de notre temps fort :

Le 21 juin : Ippevent “REX dĂ©ploiement d’OpenShift dans une grande compagnie d’assurance” avec Charles Sabourdin. Le 27 juin : Ippevent “Be or not to be Serverless” avec Steve Houel Ă  Lyon. Le 29 juin : Ippevent “Le service discovery avec Consul” avec Yann Degat Ă  Nantes. 

L’article Un mois de juin 100% DevOps est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Vue.js 2.0 : petit tutoriel (volume 4)

lun, 05/29/2017 - 09:00

Nous voilĂ  dĂ©jĂ  au quatriĂšme volet du tutoriel Vue.js 2.0 ! Au menu aujourd’hui : le pattern gestionnaire d’Ă©tat dans Vue.js et une implĂ©mentation officielle avec Vuex.

Les précédents volets sont toujours accessibles :

  • Volume 1 : pour crĂ©er un projet, crĂ©er un composant et transmettre des donnĂ©es d’un composant parent Ă  un composant enfant ;
  • Volume 2 : pour apprendre Ă  modifier les donnĂ©es d’un composant et de quelle façon invoquer un service REST ;
  • Volume 3 : pour transmettre des donnĂ©es d’un composant enfant à un composant parent et dĂ©couvrir la communication par Ă©vĂ©nements.

Le code source est quant à lui toujours disponible ici. Enjoy !

Gestionnaire d’Ă©tat

NB: cette partie décrit les composants se situant dans src/components/chap8 et dans src/pages/chap8

Pattern

Dans les Ă©tapes prĂ©cĂ©dentes, nous avons utilisĂ© la communication entre composants par l’intermĂ©diaire d’évĂ©nements pour transmettre un mĂȘme objet utilisĂ© dans chacun des composants.

Cependant, ce “pattern” n’est pas toujours pertinent, en particulier dĂšs lors qu’on souhaite partager entre plusieurs composants un objet dont l’état est amenĂ© Ă  Ă©voluer. Avec ce “pattern” :

  • il faudrait nĂ©cessairement rĂ©-Ă©mettre un objet mis Ă  jour, faire en sorte qu’il soit captĂ© par tous les composants intĂ©ressĂ©s,
  • potentiellement l’état de l’objet peut ĂȘtre modifiĂ© Ă  diffĂ©rents endroits dans l’application,
  • l’état le plus rĂ©cent de l’objet peut ĂȘtre perdu si l’instance du composant qui le porte est dĂ©truite,
  • etc.

On obtiendrait donc rapidement un plat de spaghettis rendant l’analyse et la maintenance difficiles, avec accessoirement une probable sur-consommation mĂ©moire cĂŽtĂ© client avec l’accumulation d’instances d’objets inutiles.

Un pattern plus adaptĂ© Ă  ce cas de figure est le Gestionnaire d’état dans lequel un objet unique (le store) centralise un Ă©tat (un ensemble d’attributs) qui sera partagĂ© entre les diffĂ©rents composants d’une application. Les composants en question ne manipulant l’état du store qu’à travers les fonctions dont ce dernier dispose.

statemanagerpattern

Une implĂ©mentation trĂšs simple de ce pattern est proposĂ©e sur le site de Vue.js. Elle consiste Ă  dĂ©finir un objet store contenant un attribut state regroupant toutes les donnĂ©es constitutives de l’état du store et un ensemble de fonctions permettant de modifier ces donnĂ©es :

Cet objet est ensuite accédé par différents composants de la façon suivante :

Cependant, une implĂ©mentation de ce genre n’assure en rien que les dĂ©veloppeurs modifieront le store uniquement par l’intermĂ©diaire des fonctions proposĂ©es par l’objet : dans l’exemple proposĂ© sur le site de Vue.js il n’existe aucun garde-fou pour empĂȘcher une modification directe de store.state.message ailleurs dans l’application et le “point unique de vĂ©ritĂ©â€ qu’est supposĂ© constituer le Gestionnaire d’état n’est donc pas garanti.

Une implĂ©mentation plus stricte du pattern Gestionnaire d’état est disponible Ă  travers Vuex, l’implĂ©mentation officielle de ce pattern pour Vue.js, l’équivalent de Redux pour React.

Vuex : concepts

A la maniĂšre de Redux (et du pattern architectural Flux de Facebook dont il est largement inspirĂ©), Vuex impose un flux de donnĂ©es unidirectionnel, dont le principe est opposĂ© au magique “two-way bindings” de la directive v-model de Vue.js :

vuexconcepts

Les concepts manipulés sont les suivants :

  • le state, l’arbre unique des attributs constitutifs de l’état qui sera partagĂ© entre les composants ;
  • les mutations, les seules fonctions par lesquelles on peut passer pour modifier le state et dans lesquelles seules des actions synchrones peuvent ĂȘtre effectuĂ©es ;
  • les actions, des fonctions qui dĂ©clenchent une ou plusieurs mutations et faisant potentiellement des appels complĂ©mentaires, en particulier des appels asynchrones.

En complĂ©ment, les getters sont les fonctions par lesquelles ont peut “lire” le state.

Tous ces Ă©lĂ©ments sont regroupĂ©s dans le store de Vuex, unique pour une application donnĂ©e. La possibilitĂ© de rĂ©partir le state dans plusieurs modules permet de gĂ©rer plusieurs Ă©tats diffĂ©rents dans l’unique store de l’application.

Contrairement Ă  Redux, le state demeure donc “mutable” par l’intermĂ©diaire des mutations et toute modification est automatiquement rĂ©percutĂ©e par Vue.js sur les Ă©lĂ©ments des composants nĂ©cessitant un nouveau rendu.

Vuex en pratique

Passons à la pratique en commençant par installer les modules nécessaires pour utiliser Vuex via la simple commande npm install vuex --save

Définissons à présent le store de notre application en créant un fichier AppStore.js :

/src/components/chap8/AppStore.js

Dans notre application nous avons besoin que le citoyen sĂ©lectionnĂ© soit partagĂ© entre tous les composants. C’est donc le citoyen sĂ©lectionnĂ© qui constituera le state. On va modifier le store pour faire en sorte d’ajouter :

  1. une action permettant d’appeler l’API de dĂ©tail d’un citoyen sur le citoyen sĂ©lectionnĂ© (cet appel Ă©tait prĂ©cĂ©demment dans Citizen.vue) ;
  2. une mutation invoquĂ©e par l’action prĂ©cĂ©dente pour affecter le rĂ©sultat obtenu au state (NB : la convention Flux a Ă©tĂ© conservĂ©e, le nom des fonctions de mutation est en majuscules) ;
  3. un getter pour récupérer les informations du citoyen sélectionné.

Le store devient alors :

/src/components/chap8/AppStore.js

Le store dĂ©fini, il faut Ă  prĂ©sent le dĂ©clarer dans notre application. Pour qu’il puisse ĂȘtre utilisĂ© par tous les composants de l’application, on le dĂ©clare dans main.js :

/src/main.js

L’import et l’utilisation de Vuex par Vue donnent la possibilitĂ© d’injecter une instance de store dans le composant racine en le rendant automatiquement accessible Ă  tous ses composants enfants.

Il ne reste plus qu’à manipuler le store dans les composants Citizens.vue et Citizen.vue.

Si on repart du composant Citizens.vue construit au chapitre prĂ©cĂ©dent, des changements ne sont nĂ©cessaires que dans la partie script, simplement en invoquant l’action selectCitizen du store dans la mĂ©thode selectCitizen de notre composant au lieu d’émettre un Ă©vĂ©nement :

/src/components/chap8/Citizens.vue

PlutĂŽt que d’invoquer directement le store pour exĂ©cuter une action, il est Ă©galement possible de rattacher les actions du store au composant via le handler mapActions. De cette façon les actions du store peuvent alors ĂȘtre invoquĂ©es dans le composant comme s’il s’agissait de mĂ©thodes du composant lui-mĂȘme :

/src/components/chap8/Citizens.vue

Cliquez ici pour quelques explications sur l’opĂ©rateur de dĂ©composition …

Le code de Citizen.vue, amputĂ© de la rĂ©ception d’un Ă©vĂ©nement et de son traitement par l’appel au service de dĂ©tail d’un citoyen dĂ©sormais Ă  la charge du store, est quant Ă  lui trĂšs simplifiĂ© puisque sa section script se rĂ©sume Ă  :

/src/components/chap8/Citizen.vue

Si on compare cette version à la précédente :

  1. on constate que le hook created a Ă©tĂ© supprimĂ©, puisqu’il n’est plus nĂ©cessaire de faire rĂ©agir le composant Ă  l’émission d’un Ă©vĂ©nement lors de la sĂ©lection d’un citoyen de la liste ;
  2. que les data de la version prĂ©cĂ©dente du composant, constituĂ©es de l’objet citizen stockant le citoyen sĂ©lectionnĂ©, ont Ă©tĂ© supprimĂ©es au profit de l’invocation du getter selectedCitizen du store ; on notera que le fait de rattacher ce getter au composant en l’intitulant citizen (via le handler mapGetters) permet de ne pas toucher au template qui est donc identique Ă  la version prĂ©cĂ©dente du composant ; de plus, positionner ce mapping en computed permet de profiter Ă  nouveau du two-ways-binding puisque dĂšs qu’un nouveau citoyen est sĂ©lectionnĂ© dans la liste, donc dĂšs que le state du store est modifiĂ©, le composant rĂ©agit automatiquement en affichant les informations du nouveau citoyen sĂ©lectionnĂ©.

En fait Ă  ce stade, toujours rien ne garantit l’impossibilitĂ© d’accĂ©der directement au state pour le modifier. Par exemple, ajoutons dans le composant Citizen.vue une mĂ©thode mettant Ă  jour l’attribut prĂ©nom du citoyen sĂ©lectionnĂ© directement en accĂ©dant au state, ainsi qu’un bouton exĂ©cutant cette mĂ©thode lors d’un clic :

/src/components/chap8/Citizen.vue

RĂ©sultat : le clic sur le bouton “Do update” modifie bien la valeur du prĂ©nom du citoyen dans le store.

Vuex permet d’alerter lorsqu’une modification directe du store est effectuĂ©e dans le code en activant simplement le paramĂštre strict dans la dĂ©finition du store :

/src/components/chap8/AppStore.js

Avec ce paramĂ©trage activĂ©, le message suivant apparaĂźt dans la console du navigateur lorsqu’on clique sur le bouton “Do update” :

Attention : le mode strict doit ĂȘtre positionnĂ© Ă  false en production pour Ă©viter les problĂšmes de performances.

A suivre…

Avec ce quatriĂšme article de notre sĂ©rie, vous savez dĂ©sormais comment partager des donnĂ©es entre vos composants sans utiliser exagĂ©rĂ©ment une communication Ă©vĂ©nementielle qui risquerait de rendre rapidement vos applications, mĂȘme de taille raisonnable, difficiles à maintenir. Nous avons encore de nombreux sujets Ă  aborder concernant Vue.js 2.0 et parmi eux je vous proposerai d’ici peu d’Ă©tudier de quelle façon faire du routage. A trĂšs bientĂŽt !

L’article Vue.js 2.0 : petit tutoriel (volume 4) est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Meetup Open Space AgilitĂ© Ă  l’échelle

ven, 05/26/2017 - 08:19

Mercredi 31 mai nous aurons le plaisir d’accueillir dans nos locaux le Scaling Agile Group Paris Meetup avec pour sujet : Open Space AgilitĂ© Ă  l’Ă©chelle.

Le Meetup sera animé par Rafik Mekki (coach agile chez Ippon).

Pour vous inscrire, c’est ici &#x1f609;

L’article Meetup Open Space AgilitĂ© Ă  l’Ă©chelle est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux