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.

Agrégateur de flux

Microsoft LightSwitch : Créer une application desktop

En entreprise, la grande majorité des applications demandent un développement répétitif de formulaires d’affichage, d’ajout et/ou de modification de données, le tout dans des interfaces utilisateurs le plus souvent redondantes ou dont les particularités sont les relations entre les différentes...
Catégories: Blog Société

Management Agile: 2 ateliers au ScrumDay 2015

Qualitystreet - Jean Claude GROSJEAN - ven, 03/20/2015 - 10:47

Retrouvez- moi les 2 & 3 avril au ScrumDay 2015 , notamment pour un petit tour autour des « Petits Outils de Management Agile Ă  l’usage des Managers ». 2 ateliers prĂ©vus, le Jeudi 2 avril: 14 Ă  15h  15h Ă  16h La description au sein du programme. Le nombre de personnes est limitĂ© Ă  15 pour chaque…

The post Management Agile: 2 ateliers au ScrumDay 2015 appeared first on QualityStreet - Blog Pro de Jean Claude Grosjean.

Catégories: Blog Individuel

La rétrospective : le format Speed Boat

La rétrospective,  un petit rappel

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

La rétrospective est l’un des moments clefs pour une équipe Scrum, c’est un moment dédié à l’amélioration continue, c’est une des boucles de feedback essentielles pour pouvoir être agile.

Cette cérémonie a lieu à la fin de l’itération, juste après la revue de sprint. Elle dure généralement entre 1 et 2 heures et elle est facilitée par le Scrum Master.

Toute l’équipe Scrum participe Ă  la rĂ©union, c’est-Ă -dire l’Ă©quipe de dĂ©veloppement, le Scrum Master et le Product Owner.

Il se peut que d’autres observateurs participent à la rétrospective et il faut bien faire attention à ce que la présence de certaines personnes n’empêche pas de créer le climat de confiance nécessaire à la bonne réussite de la rétrospective.

La rétrospective consiste classiquement à regarder ce qui s’est passé durant l’itération (“inspect”), d’en faire émerger des points d’amélioration puis d’en dériver une liste d’actions à prendre (“adapt”).

Ces actions doivent impĂ©rativement ĂŞtre “actionnables” par l’Ă©quipe elle-mĂŞme, c’est-Ă -dire que l’équipe doit ĂŞtre Ă  mĂŞme de les rĂ©aliser, et ce dès le prochain sprint.

Tout ce qui serait remonté d’important, mais hors du périmètre d’action de l’équipe, peut être pris en charge par le Scrum Master comme un “impediment”, un point de blocage à traiter pour aider l’équipe à mieux fonctionner.

Agenda classique d’une rétrospective:

  • Revue des actions prises Ă  la rĂ©trospective prĂ©cĂ©dente
  • Collecte des donnĂ©es: atelier, innovation game
  • Consolidation et priorisation des sujets
  • Établir le plan d’actions
  • ClĂ´ture / ROTI

Il existe beaucoup de formats de rétrospective, ces formats peuvent s’appliquer sur l’itération qui vient de finir ou sur une thématique ou un sujet particulier (ex: sur les cérémonies agiles,  sur les valeurs, sur l’intégration continue, les tests, etc)

Souvent, une équipe fonctionne avec seulement une ou deux variantes appliquées à l’itération qui vient de finir. Dans ce cas, la cérémonie peut très vite devenir routinière et par conséquent moins créative et efficace pour traiter les problèmes auxquels l’équipe est actuellement confrontée.

Afin d’aider les équipes et les Scrum Masters, nous souhaitons partager avec vous, dans une série d’articles, différents formats de rétrospectives en fournissant un support graphique pour la faciliter.

En effet, selon le format de rétrospective, le facilitateur peut se retrouver à déployer en plus de ses talents d’animateur des talents de dessinateur, c’est le cas pour le format “Speed Boat”.

Le Speed Boat

Cet innovation game peut s’avĂ©rer utile dans diffĂ©rents contextes, il va permettre Ă  l’équipe de rĂ©flĂ©chir Ă  sa vision et ses objectifs, Ă  ce qui les ralentis dans l’atteinte de ces derniers, les risques qu’ils peuvent rencontrer sur le chemin et les bonnes pratiques et les forces qui vont les aider Ă  atteindre leur but.

Capture d’écran 2015-04-02 à 09.33.51

Voici ce que symbolise chacun des éléments :

  • Le bateau : l’équipe
  • L’île : les objectifs Ă  atteindre
  • Les vents : nos forces, ce qui nous fait avancer
  • Les ancres : ce qui nous ralentit, les freins
  • Le soleil : qui je remercie, ce que j’ai aimĂ©
  •  Le rocher : les risques futurs (obstacles Ă  venir)

DĂ©roulement :

  1. Chaque personne dispose de 5 minutes pour préparer individuellement ses post-its pour les différents éléments du dessin.
  2. Chacun des membres de l’Ă©quipe vient coller ses post-its sur le dessin en expliquant rapidement chaque point. Ă€ cette Ă©tape, il vaut mieux dĂ©jĂ  commencer Ă  regrouper les post-its qui parlent du mĂŞme sujet.
  3. L’équipe vote pour le ou les sujets qui lui semble(nt) les plus prioritaires à traiter (dot voting). Limitez votre nombre de sujets, il vaut mieux s’engager sur un seul sujet sur lequel on arrivera à mettre en place les actions rapidement plutôt qu’une multitude de sujets partiellement réalisés. L’amélioration continue doit s’effectuer par petits pas mesurables.
  4. Sur chacun des sujets l’équipe élabore un plan d’action qui seront mises en place dès le sprint suivant.

Nous vous proposons de tĂ©lĂ©charger un support de Speed Boat afin que vous puissiez l’imprimer ou le projeter.

Vous pouvez le faire imprimer dans un magasin spĂ©cialisĂ© (au format A1 par exemple) ou convertir l’image en PDF afin les imprimer sur plusieurs feuilles A4 grâce au logiciel Acrobat Reader.


Speed Boat Xebia Agile

Téléchargez le ! speedboat_agile_xebia.png

Catégories: Blog Société

LCC 120 - J'te dis ou j'te dis pas ?

Les Duchess prennent le micro pour nous faire un tour d’horizon des nouvelles Java. On y discute acquisitions, fermetures, releases, annonces, bref la vie. Elle débâteront aussi de la démocratisation du code et des déconvenues qui peuvent en découler.

Enregistré le 15 mars 2015

Téléchargement de l’épisode LesCastCodeurs-Episode–120.mp3

News

Amira Lakhal
Valtech
Ludwine Probst
Citizen Data
Mathilde Lemée
Aetys
Stéphanie Moallic
Stéphanie Hertrich
Microsoft

Duchess France

Ça bouge

Google a acquis une partie de Softcard
Google Code ferme
Codehaus ferme
Elasticsearch a racheté Found
SigFox

Évènements

Startup Week End Women
Meilleur dev de France
Hashcode
Keynote Apple

Dev mobile

Tabri.js
CoronaSDK
SDK de Windows 10 : dévoilé à //Build
IonicFramework v2
Android 5.1 SDK

Data

La nouvelle version 1.3.0 de Spark vient de sortir !
DataFrames API dans Spark
Spark summit en juin Ă  SF
http://ignite.incubator.apache.org
Druid passe dans la fondation apache
MongoDB 3.0

Open Source

Groovy chez Apache
Spock en version 1.0
Microsoft et l’OpenSource

Outils de l’épisode

Slack

Blog à découvrir

Une vie de dev

DĂ©bat

Est-ce que coder c’est si facile ? Démocratisation du code ?

Conférences

Hacking Health Camp, Strasbourg les 19–22 mars
Code Motion Rome les 25–28 mars
NoSQL Matters, Paris les 26/27 mars
Devoxx France du 8 au 10 avril
Mix-it 16–17 avril
//build Conférence Développeurs Microsoft, San Francisco le 29 avril
Berlin Buzzwords, Berlin du 31 mai au 3 juin
Sud Web, Montpellier les 29–30 mai

CFP du BreizhCamp 2015
http://2015.javazone.no

Nous contacter

Contactez-nous via twitter http://twitter.com/lescastcodeurs
sur le groupe Google http://groups.google.com/group/lescastcodeurs
ou sur le site web http://lescastcodeurs.com/
Flattr-ez nous (dons) sur http://lescastcodeurs.com/
En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Catégories: Blog Individuel

Le nouveau TechTrends dédié au Data Lab débarque avec son mini-site !

Découvrez vite le nouveau Techtrends, dédié au Data Lab. 

Depuis quelques années maintenant, les « Big Data » font le buzz : impossible de passer à côté de ce phénomène né des nouveaux usages du Web, de l’explosion des données personnelles et des avancées technologiques dans le calcul distribué. Au-delà du mot et de la tendance, comment en tirer profit au sein de votre entreprise ? En construisant un Data Lab.

En quoi cela consiste ? Comment le mettre en place ? Quelle est sa valeur ajoutée ? Toutes ces questions trouveront une réponse dans notre nouveau TechTrends. 

Ce TechTrends a Ă©tĂ© fait en collaboration avec Thiga et UX Republic. Pour cette nouvelle offre Alliance, venez dĂ©couvrir comment ensemble, nous pouvons vous aider sur la mise en place d’un Data Lab chez vous. Toutes les informations sur le mini-site Data Lab. 

Catégories: Blog Société

Lancement du site recrutement de Zenika

Zenika - jeu, 03/19/2015 - 16:23

Zenika est heureux de vous présenter son nouveau site dédié au recrutement jobs.zenika.com

Jobs

Découvrez nos opportunités de carrière ! Que vous soyez Consultant, expérimenté ou junior, en région ou à Paris, à la recherche d’un poste au sein de nos fonctions supports (Commerce, Finance, Logistique, Marketing, Ressources Humaines), boostez votre carrière en postulant sur notre site. Rejoignez Zenika, une équipe de passionnés partageant... Read Lancement du site recrutement de Zenika

Catégories: Blog Société

nanograms

odelia technologies - jeu, 03/19/2015 - 13:53

nanograms est un jeu de logique dont je suis l'auteur ; il est basé sur les Nonograms connus également sous les noms de Picross, Hanjie, ou Griddlers.
nanograms est disponible sur Goople Play !

Je l'ai dĂ©veloppĂ© avec l'excellent framework ionic, qui s'appuie lui mĂŞme sur Apache Cordova et AngularJS.

Catégories: Blog Société

Control a presentation remotely with a Vert.x module written in Groovy

odelia technologies - jeu, 03/19/2015 - 13:38

The screencast bellow shows my project odelia-remote-reveal in action.

It's a porting of the code described in Smartphone Remote Control with Node.js and Socket.io tutorial, but by using Vert.x framework with JavaScript and Groovy (for the server part) languages.

I would like to give a lot of kudos to article's author Nick Anastasov!

Catégories: Blog Société

Revue de Presse Xebia

blog-xebia
La revue de presse hebdomadaire des technologies Big Data, Cloud et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Agilité The Eight Most Common Big Data Myths http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

L’agilitĂ© c’est avant tout une vision de l’organisation qui remet le client au centre. Comprendre le client, ses besoins, ses dĂ©sirs est loin d’ĂŞtre facile et lorsqu’il n’est pas accessible directement, ses reprĂ©sentants (aka: les Product Owners) ont bien du mal Ă  adopter la bonne vision.

Avec l’avènement du Big Data, on a cru voir une solution miracle Ă  ces problèmes. Enfin, nous allions comprendre nos clients, prĂ©dire leurs moindres rĂŞves.

Ă€ travers cet article (en anglais),  Joerg Niessing(@JoergNiessing), INSEAD Affiliate Professor of Marketing, et James Walker, Partner Demand Analytics, Strategy& dĂ©mystifient les Big Data en s’attachant Ă  nous en rĂ©vĂ©ler 8 croyances fausses.

Une lecture à ne pas rater pour qui veut mieux comprendre cette hydre à 8 têtes !

The Case for Scrum Dying in a Fire http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Pour ceux d’entre vous qui suivent l’actualitĂ© Agile sur Twitter vous avez peut-ĂŞtre entraperçu tout un dĂ©bat entre Ron Jeffries, et Gilles Bowkett au sujet de Scrum.

Gilles a manifestement rencontrĂ© un de ces monstres de Scrum-But que l’on prĂ©fĂ©rerait Ă©viter, une pure forme d’Agile Washing (qui ne lave pas plus blanc que blanc!). Et de fait, de son point de vue, Scrum n’est bon qu’Ă  pĂ©rir dans les flammes…

En rĂ©ponse aux articles de Gilles, Ron a publiĂ© une sĂ©rie de billets sur son blog. S’ils sont tous intĂ©ressants, je n’en retiens que le dernier qui s’attache rĂ©ellement au problème de Scrum-But auquel on a tous certainement pu assister.

Dans ce billet Ron, prend un peu de hauteur et revient sur la nature de Scrum et sur les raisons qui peuvent expliquer que nous puissions si facilement en voir l’idĂ©e dĂ©voyĂ©e.

Si vous avez pu vous aussi, vous posez des questions sur des implĂ©mentations de Scrum plus que hasardeuses et vous demandez comment cela peut bien fonctionner, c’est une lecture que je ne peux que vous conseiller!

No. Agile Does Not Scale (but agility scales quite well, thank-you-very-much) http://www.gravatar.com/446d657538e086173eac4467a91c9d86http://blog.xebia.fr/author/omarquethttp://twitter.com/omarquetPar Olivier Marquet

L’agilitĂ© Ă  l’Ă©chelle est une des problĂ©matiques du moment des agilistes. Les diffĂ©rents frameworks Ă  l’Ă©chelle qui sortent essayent tous de l’adresser et ce plus ou moins dans le respect du manifeste d’origine.

Dans son article, l’avis de Jurgen Appelo est que l’AgilitĂ© au sens du Manifeste Agile ne scale pas, il n’Ă©tait pas fait pour Ă  l’Ă©poque.

Par contre l’agilitĂ© tout court (avec un petit "a"), celle d’un système complexe est toujours possible, et elle, scale. Et pour rĂ©concilier les 2, il suffirait de faire Ă©voluer le manifeste en consĂ©quence.

Un point de vue intéressant que je vous conseille de lire dans sa globalité en suivant le lien.

Hierarchies remove scaling properties in Agile Software projects http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

A l’approche du ScrumDay 2015, qui mettra clairement en avant les problĂ©matiques d’AgilitĂ© Ă  l’Ă©chelle, je trouve intĂ©ressant de se replonger dans cet article de Vasco Duarte(une des voix les plus Ă©coutĂ©es du mouvement #NoEstimates).

Dans cet article, Vasco Duarte amène une rĂ©flexion intĂ©ressante qui ouvre le chemin d’une autre vision de l’AgilitĂ© Ă  l’Ă©chelle. Pour cela, il Ă©tudie plus particulièrement une problĂ©matique, celle de la communication.

Avec l’accroissement des tailles des Ă©quipes, les besoins en structuration et en communication (notamment pour synchronisation ou information) augmentent de manière Ă©vidente. Et cela plus particulièrement au sein d’Ă©quipes Agiles, qui se veulent capables de s’adapter au changement au moindre coĂ»t et au plus tĂ´t.

Pour ce qui est des besoins de structuration, la mise en place d’une hiĂ©rarchie forte a Ă©tĂ© la rĂ©ponse classiquement adoptĂ©e en entreprise (ce qui a permis jusqu’Ă  aujourd’hui le dĂ©veloppement d’entreprises de plusieurs centaines de milliers d’employĂ©s).

Pour ce qui est de la communication, je laisse Vasco Duarte vous montrer les impacts pernicieux de la hiérarchie qui nuisent à notre capacité à la faire grandir (et en conséquence posent la question de la pertinence de la hiérarchie pour "scaler").

Au passage, je vous recommande de jeter un oeil aux commentaires pour y dĂ©couvrir une idĂ©e intĂ©ressante sur le rĂ´le des rĂ©seaux informels de communication (basĂ©s sur les relations sociales), lorsque la hiĂ©rarchie vient empĂŞcher celle-ci de bien s’exprimer.

Craftsmanship Sortie de AssertJ 2.0.0 – Craftsmanship http://www.gravatar.com/e68d07551341bbbe95fa509a7104cc94http://blog.xebia.fr/author/slemerdyhttp://twitter.com/seblmhttps://github.com/seblmPar Sébastian Le Merdy

La toute nouvelle mouture d’AssertJ est une majeure et contient de nombreuses nouvelles fonctionnalitĂ©s très intĂ©ressantes. L’une d’entre elle retient tout particulièrement notre attention : cette nouvelle fonctionnalitĂ© vous permet de dĂ©limiter très prĂ©cisĂ©ment le code dont vous vous attendez Ă  ce qu’il lance une exception. Un exemple sera plus parlant qu’un grand discours :

@Test
public void should_throw_exception() {
   Throwable thrown = catchThrowable(() -> { throw new Exception("boom!") });

   assertThat(thrown).isInstanceOf(Exception.class)
                     .hasMessageContaining("boom");
}

Évidemment, l’utilisation des lambdas en java 8 sera un plus non nĂ©gligeable pour la lisibilitĂ©. Adieu donc le paramètre expected sur l’annotation @Test de JUnit.

Nous vous invitons à consulter la release note et à mettre à jour vos poms au plus vite.

Front Angular 2.0: Mais pourquoi pas Dart ? http://www.gravatar.com/b48c1ee560ff6432a574dceb746dff79http://blog.xebia.fr/author/romain-niveau%2Fhttp://twitter.com/RomainNVhttp://github.com/rniveauPar Romain Niveau

La semaine dernière, nous remontions l’information indiquant que la team Angular a dĂ©cidĂ© d’abandonner AtScript pour TypeScript dans le dĂ©veloppement d’Angular 2.0.

Mais une question se pose : pourquoi ne pas choisir Dart ? Après tout, il s’agit d’un langage dĂ©veloppĂ© par Google et il aurait pu ĂŞtre cohĂ©rent que le framework de Google utilise le langage de la mĂŞme entreprise.

En effet, TypeScript est dĂ©veloppĂ© par Microsoft, dont les relations avec Google n’ont pas toujours Ă©tĂ© cordiales.

Cet article tente d’apporter une rĂ©ponse Ă  cette question et revient sur les forces de TypeScript comparĂ© Ă  Dart.

Back Quel futur pour Spring ? http://www.gravatar.com/b48c1ee560ff6432a574dceb746dff79http://blog.xebia.fr/author/romain-niveau%2Fhttp://twitter.com/RomainNVhttp://github.com/rniveauPar Romain Niveau

Spring, le framework Java mainstream par excellence et utilisĂ© par une multitude de projet continue d’Ă©voluer.

Parfois critiquĂ© pour ses choix ou sa complexitĂ©, Spring reste nĂ©anmoins incontournable pour bon nombre d’entreprises.

Dans cet interview, Juergen Hoeller (co fondateur de Spring) revient sur le passé de Spring et sur la direction prise par le framework.

Juergen répond avec détails aux questions suivantes:

  • Pourquoi tant de projets dans Spring ?
  • Comment sont fait les choix Ă  l’intĂ©rieur de l’Ă©quipe ?
  • Quelles sont les relations avec Pivotal, et notamment Cloud Foundry ?
  • Comment se compare Spring avec d’autres frameworks plus jeunes comme Play ?
  • Quelles Ă©volutions attendre avec Java 8, Docker ou encore les microservices ?
Le coin de la technique Adieu Google Code – Technique http://twitter.com/jeremmartinezhttp://github.com/jeremiemartinezPar Jeremie Martinez

Jeudi dernier, Google a annoncĂ© l’arrĂŞt de son service Google Code. En ligne depuis 2006, le service avait pour but de fournir un service d’hĂ©bergement de code gratuit pour la communautĂ©. Afin de faciliter la transition, Google met Ă  disposition un outil afin de pouvoir transfĂ©rer les sources vers d’autres services d’hĂ©bergements comme Github ou BitBucket par exemple. Enfin cette migration devra ĂŞtre faite avant le 26 Janvier 2016, deadline imposĂ©e par Google.

Catégories: Blog Société

[PO Dojo] Finalisation de la story map et rédaction des users stories

Agile Nantes - mer, 03/18/2015 - 13:36

Nous vous proposons pour cette session de finaliser la story map unifiĂ©e : voir ensemble si le pĂ©rimètre nous convient, si les prioritĂ©s sont bien partagĂ©es … Et dĂ©tailler les Ă©pics encore trop macro pour ĂŞtre rĂ©alisables.

Ces diffĂ©rentes activitĂ©s nous permettront ensuite de dĂ©buter l’Ă©criture des users stories priorisĂ©es.

Ces sessions PO Dojo s’adressent aux personnes connaissant dĂ©jĂ  l’agilitĂ© et souhaitant progresser dans ce rĂ´le de Product Owner.

podojo

Le PO Dojo est l’espace des Product Owners pour apprendre par la pratique. L’objectif est de rĂ©aliser les actions du product Owner pour passer d’une idĂ©e marketing Ă  une user story prĂŞte pour la planification.

A cette session, nous souhaiterions que chaque participant propose un icebreaker au groupe (titre et objectif). Un vote permettra de choisir et le participant pourra alors animer ce début de session permettant de découvrir chaque membre du groupe.

A bientĂ´t,

Le groupe PO Dojo nantais

OĂą et quand ?

> OĂą: Chez Alliance Libre, 12 avenue Jules Verne Ă  Saint SĂ©bastien sur Loire

> Quand: lundi 23 mars de 19h à 21h

> Faut il s’inscrire ? Oui, grâce à ce lien

L’association Agile Nantes

Catégories: Association

Participez à un entraînement de boxe avec Brahim Asloum chez Ippon

Blog d’Ippon Technologies - mer, 03/18/2015 - 12:32

D’ici quelques semaines, nous allons tous nous retrouver pour Devoxx France :  3 jours de confĂ©rences de qualitĂ©, oĂą les dĂ©veloppeurs peuvent venir apprendre, travailler en rĂ©seau, hacker du code, faire de la veille, et venir s’inspirer.

Ippon est fier d’ĂŞtre encore Sponsor et Speaker ( 5 Talks retenus ) de ce rassemblement de passionnĂ©s. La nouveautĂ©, cette annĂ©e, c’est qu’Ippon invite quelques dĂ©veloppeurs Java pour une soirĂ©e unique. Ils profiteront de 2 heures pour se dĂ©fouler, se dĂ©passer et se dĂ©tendre après une longue journĂ©e de confĂ©rence.

En effet, une vingtaine de développeurs seront sélectionnés pour participer à un entraînement de boxe qui sera encadré par le Champion Brahim Asloum chez Ippon [tweet this] ( à 5 minutes à pied du Palais des Congrès ).

Le sport, l’esprit d’Ă©quipe et le goĂ»t du challenge sont au coeur des valeurs de l’entreprise. Nous avons envie de partager avec le plus grand nombre cet Ă©tat d’esprit qui fait aussi la force des consultants Ippon en mission.

Si ces valeurs vous ressemblent, si Sport et Innovation sont des mots qui vous parlent, si vous avez envie de passer une soirĂ©e exceptionnelle en compagnie d’un athlète de haut niveau, il vous suffit d’Ă©crire Ă  Victoria de Belilovsky : vdebelilovsky@ippon.fr ( prĂ©nom/nom + tĂ©lĂ©phone + compte twitter si vous en avez un )

Nous préviendrons les heureux privilégiés par mail avant le lundi 6 avril 2015.

initiation boxe brahim asloum

 

 

 

Catégories: Blog Société

PerfUG : Riemann, de l’event processing pour devops

Riemann est un projet open source crĂ©Ă© par Kyle Kingsbury (aphyr). Riemann permet le traitement et l’agrĂ©gation de flux d’Ă©vĂ©nements et de mĂ©triques provenant d’un système complexe ou d’une infrastructure entière.

Très lĂ©ger et performant, et orientĂ© supervision, il permet de programmer les règles pour fournir mĂ©triques sophistiquĂ©es ou d’alertes aux critères complexes. Il ne se substitue pas Ă  la supervision classique mais y ajoute une couche programmatique temps rĂ©el.

Ses applications sont nombreuses, du classique tableau de bord de mĂ©triques système aux profiling distribuĂ© d’une application tournant sur un cluster. Nous verrons aussi comment Riemann fait peu Ă  peu sa place dans l’infra de Criteo.​

 

Yann Schwartz expert en systèmes distribuĂ©s/rĂ©partis chez Criteo depuis plus d’un an, animera cette session. Il prĂ©sente un fort intĂ©rĂŞt pour les systèmes distribuĂ©s et le Big Data oĂą on le retrouve dans de nombreux Ă©vĂ©nements; au scala.io en 2014 pour de l’architecture streaming ou encore des meetups tels que ParisDataGeek et Alt.Net.

 

La session aura lieu le 26 mars dans les locaux d’OCTO Technology.
Inscriptions et informations sur Meetup. Cette session sera suivie d’un pot dans les locaux d’Octo.

Articles suggested :

  1. Compte-rendu du Performance User Group #3
  2. PerfUG : Hadoop et HDFS : Stockage, RequĂŞtage et Performances
  3. PerfUG : DynaTrace pour monitorer tous vos problèmes de performance

Catégories: Blog Société

OCTO est une Great Place To Work ! 4 participations, toujours sur le podium !

C’est officiel ! OCTO Technology est la seconde Greatest Place To Work en France. Le palmarès de la cĂ©rĂ©monie d’hier au Trianon compte nombre d’exemples et de sources d’inspiration pour faire en sorte que OCTO reste une entreprise oĂą « il fait bon travailler ».  Petit aperçu de la soirĂ©e telle que nous l’avons vĂ©cue.

Après une petite attente devant le Trianon, le temps d’une pause cafĂ© pour certains d’entre nous, nous entrons enfin dans la salle, qui affiche complet. Il faut dire que l’affiche est allĂ©chante, OCTO fait son come-back aux GPTW et veut le faire savoir. Tel un wolf pack, bien accrochĂ© au balcon, nous assistons Ă  la remise des trophĂ©es de l’annĂ©e. Suite Ă  une prĂ©sentation formelle et un Ă©loge apprĂ©ciĂ© Ă  l’optimisme, nous voyons s’Ă©grainer les noms des entreprises nous prĂ©cĂ©dents et l’excitation monter. Blablacar, Sarenza, le bon coin… ĂŞtre devant ces entreprises populaires et apprĂ©ciĂ©es renforce le sentiment de fiertĂ© d’appartenir Ă  une boĂ®te qui se place en exemple dans le domaine du bien-ĂŞtre en entreprise.

À chaque description des points forts des lauréats, un seul sentiment : OCTO le fait aussi.

Arrive notre tour : deuxième. La meute se lève et donne de la voix. Ludo (aka Ludovic Cinquin notre DG France) monte sur les planches sous l’ovation des Octos, ça  n’est pas passĂ© inaperçu. Et dans son discours encore, il se dĂ©marque en parlant du modèle d’organisation n’existant pas chez nos collègues, les tribus. (Nous attendons de voir avec hâte qui de nos collègues de podium tenteront l’aventure tribu !)

IMG_7521

Ce qu’il faut retenir :

  • le Nord est en force : Decathlon, Kiabi, Leroymerlin… sont des GPTW !
  • Anne-claire (une ancienne de la famille) est venue nous faire un petit coucou, c’Ă©tait cool
  • OCTO est la première entreprise dans le domaine ! Bravo Ă  Accuracy pour sa première place.

OCTO a notablement Ă©tĂ© remarquĂ© pour sa rĂ©organisation cette annĂ©e en Ă©quipes autogĂ©rĂ©es autour de sujets stratĂ©giques : les fameuses tribus. Bien sĂ»r, cette rĂ©organisation n’est pas le seul facteur de fiertĂ© Ă  OCTO, c’est pourquoi nous vous proposons dans les semaines qui viennent une sĂ©rie d’articles, tous Ă©crits par nos consultants pour constituer le dossier remis pour le concours GPTW, qui explique ce qui fait d’OCTO une Great Place to Work !

 

IMG_7520

 

IMG_7522

Catégories: Blog Société

Polymer, vers un composant plus dynamique

L'actualité de Synbioz - mer, 03/18/2015 - 00:00

Dans le précédent article nous avions réalisé un composant simple et inerte, aujourd’hui nous allons le rendre un peu plus intéressant.

Nous allons d’abord faire un petit nettoyage. Ensuite, nous utiliserons les « data binding » pour avoir un compteur dynamique basé sur une fonction.

Lire la suite...

Catégories: Blog Société

JIRA alerts at the speed of light

Le blog de Valiantys - mar, 03/17/2015 - 09:50

JIRA dashboards can’t auto-refresh with a refresh interval of less than 15 min. Consequently, a support user won’t be alerted immediately if an issue with a critical level of emergency is created. As a result, the team at Valiantys decided to create a lighting system triggered by issue creation or updates based on a set of rules. In this article […]

The post JIRA alerts at the speed of light appeared first on Valiantys Blog.

Catégories: Blog Société

Chapitre 16 du livre de Sandro Mancuso sur le Software Craftsmanship

Voici le rĂ©sumĂ© du dernier chapitre du livre Software Craftsmanship – Professionalism Pragmatism Pride dĂ©crivant la carrière d’un Software Craftsman. Ainsi s’achève notre sĂ©rie sur les rĂ©sumĂ©s de l’excellent livre de Sandro Mancuso. Nous espĂ©rons que vous avez eu un bon aperçu du mouvement Software Craftsmanship. Nous vous encourageons Ă  approfondir tout cela en vous procurant le livre de Sandro, Ă  participer Ă  des meetups, des event brites ou des code retreats. Il est de notre responsabilitĂ© Ă  tous, nous, dĂ©veloppeurs, de continuer Ă  amĂ©liorer notre industrie et ainsi prendre du plaisir dans notre mĂ©tier tout en donnant entière satisfaction Ă  nos clients.

Pour approfondir le Software Craftsmanship vous pouvez également souscrire à une formation donnée par Sandro dans le catalogue de formation de Xebia Training.

Déjà publié :

  1. Software Development
  2. Agile
  3. Software Craftsmanship
  4. The Software Craftsmanship Attitude
  5. Heroes, Goodwill and Professionalism
  6. Working Software
  7. Technical Practices
  8. The Long Road
  9. Recruitment 
  10. Interviewing Software Craftsmen  
  11. Interview Anti-patterns 
  12. The Cost of Low Morale 
  13. Culture of Learning
  14. Driving Technical Changes
  15. Pragmatic Craftsmanship

A Career as a Software Craftsman

Le logiciel est partout. Il occupe une part importante de nos vies. C’est pourquoi le mĂ©tier de dĂ©veloppeur est si spĂ©cial.

ĂŠtre un craftsman

ĂŠtre un craftsman, c’est avant tout ĂŞtre passionnĂ© par son mĂ©tier. C’est Ă©galement savoir ĂŞtre professionnel, enthousiaste et exigeant. Ce n’est pas qu’un mĂ©tier, c’est un style de vie.
Un vrai software craftsman se focalise sur la rĂ©solution des problèmes. Quand ses problèmes doivent ĂŞtre rĂ©solus par du code, il Ă©crit de l’excellent code.

Les valeurs d’honnĂŞtetĂ© et de courage d’un craftsman se retrouvent dans sa capacitĂ© Ă  dire non Ă  son client, en proposant des alternatives valides et argumentĂ©es.

Progression de carrière

Bien que ça ne soit pas le cas partout, de plus en plus d’entreprises prennent conscience que le mĂ©tier de dĂ©veloppeur est un vrai mĂ©tier et que les dĂ©veloppeur expĂ©rimentĂ©s sont une valeur pour l’entreprise. Si un dĂ©veloppeur souhaite devenir manager ou business analyst, il ne s’agit pas d’une Ă©volution mais bien d’un changement de carrière.

Routes et Ă©tapes

Le plan de carrière d’un software craftsman est très important. Puisque son travail est souvent plus que ça, le choix d’une entreprise, d’une Ă©quipe et d’un environnement de travail est primordial. Puisqu’un software craftsman cherchera toujours Ă  apporter plus que ce qu’on attend de lui, il attendra en retour que cela lui apporte de nouvelles compĂ©tences technologiques, de nouveaux types de projets, de rĂ´les dans la sociĂ©tĂ© ou une plus grande rĂ©munĂ©ration.

La carrière d’un software craftsman est une route semĂ©e d’embĂ»ches et de voies sans issue. La fin de la route est une promesse : la maĂ®trise. On ne sait jamais si on fait le bon choix. Il faut se faire guider par ses aspiration et ne pas hĂ©siter Ă  changer.
Le turn over est souhaitable pour le software craftsman : ses aspirations, comme celles de sa sociĂ©tĂ©, Ă©voluent. Le turn over est Ă©galement souhaitable pour l’entreprise car elle lui permet d’apporter de nouvelles idĂ©es et de nouvelles Ă©nergies.

Ă€ un moment dans sa carrière il est possible qu’un software craftsman ne sache pas oĂą il doit aller. Une fois cette situation acceptĂ©e, le plus simple est de s’ouvrir aux autres, Ă  la communautĂ©, rencontrer de nouveaux groupes ou trouver des personnes qui vous inspirent.

Diversité du travail

Travailler dans l’IT, c’est rencontrer d’innombrables projets, Ă©quipes, manières de travailler et technologies diffĂ©rentes.
Une manière de diversifier au maximum ses expériences est sans doute de travailler pendant quelques années dans une société de consultants. Ses nombreux clients vous permettront de rencontrer des projets, des équipes et des sociétés diverses tout en vous permettant de vous créer un réseau.
Ce n’est pas non plus un mal de se spĂ©cialiser, mais il faut savoir rester ouvert Ă  tout ce qui se fait par ailleurs.

Une mission

Les software craftsmen sont investis d’une mission : ils s’amĂ©liorent constamment et font Ă©voluer les autres avec passion pour amĂ©liorer leur profession dans sa globalitĂ©.
Ce n’est pas seulement Ă©crire du joli code ou ĂŞtre de bons dĂ©veloppeurs, mais c’est surtout ĂŞtre fier du rĂ´le qu’ils jouent dans l’amĂ©lioration de la sociĂ©tĂ© toute entière.

Catégories: Blog Société

Quentin, 26 ans, Développeur : “Pourquoi j’ai rejoint Ippon”

Blog d’Ippon Technologies - lun, 03/16/2015 - 18:25

Le recrutement, c’est avant tout une rencontre entre deux professionnels : deux personnes, deux projets.

S’il est très important pour une société de bien choisir ses collaborateurs, il est tout aussi important pour un professionnel de choisir l’entreprise qui lui correspond.

L’une de nos dernière recrues, Quentin Monmert, revient sur son processus de recrutement avec Ippon.

 

JMC : Hello Quentin, peux-tu te présenter ?

QM : Je m’appelle Quentin, j’ai 26 ans et j’ai intégré Ippon au mois de Février.

Ça fait 2 ans et demi que je travaille, après 6 mois de stage.

 

JMC : Comment as-tu connu Ippon ?

QM : Au tout début j’ai connu Ippon par l’intermédiaire d’un prof à la fac, il m’avait proposé de postuler à un stage chez Ippon.

L’entretien s’était très bien passé, mais je n’avais envie de quitter la Normandie à ce moment-là.

Plus récemment Ippon a repris de mes nouvelles, et on est rentrés en contact via Twitter car je suivais les projets Jhipster avec Julien Dubois et Apache Spark avec Alexis Seigneurin.

Le recrutement s’est passé de manière naturelle.

 

JMC : Qu’est-ce qui t’a donnĂ© envie de rejoindre Ippon ?

QM : C’est une société très innovante, à la pointe des technologies. Surtout que sur ma dernière mission chez mon ancien employeur, j’avais vraiment le sentiment d’être sur des technologies vieillissantes. Là, je sais que ce sur quoi je travaille est au top. Et puis chez Ippon, j’ai la certitude de rester dans l’univers Java.

Mais surtout, on sent que les experts d’Ippon sont vraiment à la pointe, ils sont passionnés et ont envie de partager leur savoir.

Je regardais pas mal l’actualité d’Ippon sur Youtube, et en plus j’avais envie d’aller sur Paris, donc c’était vraiment la bonne opportunité pour moi.

 

JMC : Tu venais de Rouen et tu travailles et vis Ă  Paris maintenant, Ippon t’a accompagnĂ© ?

QM : Clairement, Ippon m’a accompagné et m’a permis de me relocaliser facilement, grâce à un partenariat qu’ils ont avec des « chasseurs d’appartements ». C’était un des gros avantages dès le début du processus de recrutement de savoir qu’on allait m’aider. C’est dur de trouver un logement quand on démarre un nouveau travail !

Ça s’est très bien passé avec le « chasseur d’appartements », j’ai rempli un formulaire pour dire ce que je voulais et choisir mes critères : sur le prix, la superficie, les quartiers où je voulais vivre… Et ils m’ont présenté 5 appartements qui y correspondaient, j’ai pu tous les visiter en une journée. Et j’ai eu mon premier choix :-)

Et ça ne m’a rien coûté !

 

 

JMC : Tu viens de démarrer, sur quoi tu vas travailler ?

QM : Après une première semaine de formation, je suis sur le site d’un client dans une équipe front-end. Je travaille sur la refonte d’un portail grand public à fortes volumétries.

Je fais de l’AngularJS et du Java EE sur le CMS du client. C’est une mission qui me plaît !

 

JMC : Quel conseil tu donnerais Ă  d’autres dĂ©veloppeurs Java qui souhaiteraient entrer en contact avec Ippon ?

QM : Je leur dirai de venir ! Parce que depuis que je suis chez Ippon, tout se passe très bien. Je suis parti en mission rapidement et c’est ce que je voulais. J’ai adoré les Ippevents, et c’est une société où il y a de quoi faire, sur des technos vraiment innovantes, et ça c’est top !

 

JMC : Merci Quentin pour ton témoignage :-) 

Catégories: Blog Société

Facilitation Graphique : rencontre autour d'un marqueur avec Roberta Faulhaber

Zenika - lun, 03/16/2015 - 16:45

Zenika est heureux de vous annoncer l'ajout Ă  son catalogue d'un cycle de formation autour de la « Facilitation Graphique ».

Ces sessions seront animĂ©es par Roberta Faulhaber et auront lieu Ă  Paris :

Facilitation Graphique1

Roberta s’est prêtée au jeu de l’interview pour présenter les enjeux de la facilitation graphique, nous vous proposons d’en lire un extrait ! Qu'est-ce que la facilitation graphique en deux mots ? En deux mots (et un peu plus !), il s'agit d'utiliser la pensée visuelle et le dessin pour animer, coacher, organiser, faciliter la création de sens... Read Facilitation Graphique : rencontre autour d'un marqueur avec Roberta Faulhaber

Catégories: Blog Société

Microservices – Des pièges

MicroServices.001

Microservices. C’est une architecture dont on entend beaucoup parler, mais que se cache-t-il derrière ce terme ?

Avec une sĂ©rie de trois articles, nous allons tenter de dĂ©couvrir ce qu’est une architecture microservices et ce qu’elle change par rapport Ă  une architecture "classique".

Le fil directeur de cette article sera une application imaginaire. Elle va nous aider Ă  mettre en situation certaines erreurs qu’il faut Ă©viter dans les architecture microservices. Cette application est particulièrement critique et se doit d’assurer un taux de disponibilitĂ© important. Par ailleurs, le client est conscient que le besoin est changeant et donc qu’il faut une architecture hautement Ă©volutive. Ayant Ă©tĂ© sĂ©duit par une prĂ©sentation de l’architecture microservices lors d’un Ă©vĂ©nement, la dĂ©cision est prise : l’application sera un système de microservices.

J’ai regroupĂ© plusieurs services en un seul "macroservice"

PassĂ© l’enthousiasme de la dĂ©couverte, certains aspects de la mise en Ĺ“uvre d’une architecture microservices jugĂ©s "difficiles" sont mis de cotĂ©. En particulier en ce qui concerne la granularitĂ© du dĂ©coupage. Certaines fonctionnalitĂ©s qui, bien que distinctes, se ressemblent, sont agrĂ©gĂ©es au sein de macroservices, d’une part pour avoir moins de services Ă  dĂ©ployer et d’autre part pour pouvoir factoriser des traitements communs. Deux mois après avoir dĂ©butĂ© le dĂ©veloppement de l’application, le comportement attendu d’une fonctionnalitĂ© doit changer radicalement. L’Ă©quipe se rend alors compte que cette fonctionnalitĂ© ne ressemble plus du tout aux autres fonctionnalitĂ©s du macroservice. La factorisation que le macroservice apportait n’est plus d’actualitĂ© et on ne peut plus faire Ă©voluer la fonctionnalitĂ© voulue indĂ©pendamment de celles prĂ©sentent au sein du mĂŞme macroservice.

L’un des principaux bĂ©nĂ©fices des architectures microservices est l’Ă©volutivitĂ© qu’elles apportent. Chaque service est totalement isolĂ© des autres, ne communique qu’au travers d’un contrat d’interface souple, devant permettre Ă  un service d’Ă©voluer sans que les autres le sachent. C’est pour cela qu’il est important que chaque microservice puisse disposer de sa propre base de donnĂ©es, de ses propres API "utilitaires" et de ses propres schĂ©mas de donnĂ©es. Le principe d’isolation Ă©tant Ă  la base des microservices, il est prĂ©fĂ©rable d’Ă©viter les dĂ©pendances transverses aux diffĂ©rents services. Dans l’idĂ©al, l’application du principe DRY ne devrait donc se faire qu’au sein d’un mĂŞme service.

Chaque méthode de mon application est devenue un microservice

EmballĂ©e par les principes des microservices, l’Ă©quipe de dĂ©veloppement dĂ©cide de les pousser au maximum. L’application est donc dĂ©coupĂ©e et redĂ©coupĂ©e en services toujours plus petits jusqu’au point oĂą chaque mĂ©thode est isolĂ©e dans un "nanoservice". Les premiers tests donnent de mauvais rĂ©sultats. Les Ă©changes entre ces "nanoservices" sont extrĂŞmement complexes Ă  comprendre et Ă  surveiller, les performances sont mauvaises et le nombre de serveurs nĂ©cessaire est important.

En effet, les nanoservices, qui sont un antipattern notoirement connu, poussent le principe des microservices tellement loin que les inconvĂ©nients finissent par surpasser les bĂ©nĂ©fices. DĂ©couper l’application en diffĂ©rents services a un coĂ»t. Un coĂ»t en terme de ressources serveurs. Un nouveau service signifie au minimum un nouveau processus, sinon plusieurs, voire un nouveau serveur. Ce dĂ©coupage prĂ©sente aussi un coĂ»t au niveau des performances. En effet, la communication entre les services se fait au travers du rĂ©seau, ce qui implique une lĂ©gère latence. Plus les services sont dĂ©coupĂ©s finement, plus la latence se fait sentir. Enfin, la multiplication trop importante des services finit par rendre très difficile la surveillance du système.

Une question se pose alors. Comment trouver une taille de service prĂ©sentant un bon compromis ? Il n’ y a pas de rĂ©ponse dĂ©finitive, mais des pistes peuvent ĂŞtre suivies.

Tout d’abord en faisant l’analogie entre une architecture microservices et un système UNIX. Dans un système UNIX, chaque commande fait une seule chose, mais le fait bien. On peut obtenir un rĂ©sultat très complexe en "composant" plusieurs commandes à l’aide de pipes. Ici les commandes sont les microservices, et les pipes, le bus (ou les interfaces REST). Un service se dĂ©finit alors par un verbe ou un nom. Il s’agit donc ni plus ni moins d’appliquer le "single responsibility principle" au niveau des services.

Mon Ă©quipe ne s’adapte pas aux microservices

L’Ă©quipe de dĂ©veloppement, forte d’une trentaine de dĂ©veloppeurs, a dĂ©jĂ  rĂ©alisĂ© d’autres applications pour le client. L’Ă©quipe est composĂ©e de sous Ă©quipes qui se rĂ©partissent les tâches. La première regroupe les spĂ©cialistes backend, la seconde les DBA et la dernière les spĂ©cialistes frontend. La rĂ©alisation de l’application est bien entamĂ©e, mais beaucoup de problèmes apparaissent. Il est difficile de dĂ©terminer qui est en charge d’un service donnĂ© dans chacune des sous Ă©quipes. Lors de la rĂ©alisation d’un service, tous les intervenants ne sont pas disponibles en mĂŞme temps car soumis Ă  des impĂ©ratifs dans leur Ă©quipe et aucun suivi des services n’est fait après la rĂ©alisation.

En effet les microservices ne sont pas Ă  aborder que du point de vue technique, mais aussi d’un point de vue organisationnel. La loi de Conway stipule que l’architecture d’une application est le reflet de l’organisation des Ă©quipes qui l’ont crĂ©Ă©e. Or les architectures microservices promeuvent un dĂ©coupage en unitĂ©s fonctionnelles ayant chacune leur propre pile technologique, plutĂ´t qu’un dĂ©coupage en couches. Cela impose donc d’avoir des Ă©quipes pluridisciplinaires, capables de rĂ©soudre des problèmes tant au niveau du middleware que de la base de donnĂ©es. Il faut donc adapter l’organisation.

Les microservices encouragent aussi une approche produit plutĂ´t que projet. L’Ă©quipe de dĂ©veloppement est alors responsable de chaque service de bout en bout, crĂ©ant un lien entre le dĂ©veloppeur et l’utilisateur. L’idĂ©e Ă©tant que l’Ă©quipe de dĂ©veloppement ne pense plus l’application comme un ensemble de fonctionnalitĂ©s, mais comme un moyen de faciliter le travail de l’utilisateur. La difficultĂ© est ici que l’accroissement des responsabilitĂ©s de l’Ă©quipe implique des compĂ©tences accrues elles aussi, des compĂ©tences DevOps.

Enfin, sur le mĂŞme principe que la loi de Conway, la taille de l’Ă©quipe doit ĂŞtre proportionnelle Ă  la taille des services. Il est donc fortement recommandĂ© d’avoir des Ă©quipes relativement rĂ©duites, ceci pour faciliter l’appropriation du service.

Impossible de relancer ou ajouter rapidement des instances de mes services

Le système tourne dĂ©sormais en production depuis deux semaines sans problème apparent. Les responsabilitĂ©s sont bien dĂ©coupĂ©es entre les diffĂ©rents services qui sont tous redondĂ©s. Cependant, une nuit oĂą elle est particulièrement sollicitĂ©e, une instance d’un service critique tombe. Puisqu’il n’y aucun mĂ©canisme de relance automatique d’instance de service suite Ă  une alerte remontĂ©e par le monitoring, il faut lancer cette instance manuellement. Heureusement, une personne est d’astreinte et s’y attelle rapidement. Le problème est que la procĂ©dure manuelle de dĂ©ploiement d’une nouvelle instance est longue de plusieurs dizaines de minutes. Trop long, la dernière instance du service dĂ©jĂ  sinistrĂ© vient de tomber Ă  son tour. Le système n’est plus opĂ©rationnel, il y a rupture de service.

Une architecture microservices est pourtant censée être résistante à la panne, alors pourquoi est-ce arrivé ?

Il faut tout d’abord ne pas perdre de vue que rĂ©sistant Ă  la panne ne veut pas dire infaillible. Ensuite, la rĂ©silience des architectures microservices se rĂ©sume ainsi : des services Ă©phĂ©mères pour un système durable. Parce que les services sont faillibles, ils failliront. Et quand ils tombent, d’autres doivent pouvoir reprendre leurs places immĂ©diatement. Un mĂ©canisme de surveillance doit permettre de dĂ©tecter ces dĂ©faillances et lorsqu’elles se produisent, d’autres instances du service concernĂ© doivent ĂŞtre lancĂ©es pour que le système continu Ă  remplir sa mission.

Cette résilience des architectures microservices passe donc par :

  • Un mĂ©canisme de surveillance suffisant
  • Un dĂ©marrage et une configuration des serveurs automatisĂ©s
  • Un dĂ©ploiement des services automatisĂ©

Pour l’automatisation des tâches de dĂ©ploiement des serveurs et des services, des outils comme Docker, Puppet ou encore Ansible sont des solutions Ă  Ă©tudier. Le Cloud est quant Ă  lui l’infrastructure la plus "naturelle" pour une architecture microservices car c’est cet environnement qui est le plus adaptĂ© Ă  la souplesse exigĂ©e par une architecture microservices. En ce qui concerne la surveillance, nous allons aborder le sujet dans le point suivant.

Il est très difficile de comprendre ce qu’il se passe entre mes services

Depuis une heure environ, le système connaĂ®t de forts ralentissements, le service est toujours assurĂ© mais il est fortement perturbĂ©. Une première analyse sur les serveurs ne donne rien. Un service est-il saturĂ© ? Y-a t’il des problèmes de rĂ©seau ? Est-ce un bug applicatif ? Très difficile de le savoir. Les perturbations finissent par disparaĂ®tre, mais sans que la cause du problème n’ait Ă©tĂ© identifiĂ©e. L’Ă©quipe est inquiète. Comment savoir si, ou plutĂ´t quand, ce problème se reproduira ? Est-il le symptĂ´me d’un problème plus global et plus grave?

La surveillance est un point critique des architectures microservices. Tout d’abord, comme nous l’avons vu prĂ©cĂ©demment, les services doivent pouvoir "mourir" sans compromettre le bon fonctionnement du système dans son ensemble. Cette capacitĂ© implique d’avoir une liste de tous les services frĂ©quemment mise Ă  jour. Il faut ensuite savoir si les services sont saturĂ©s ou non, pour pouvoir adapter la taille du système Ă  la charge. Obtenir des informations fonctionnelles sur les services pourra aider Ă  qualifier rapidement un problème rencontrĂ©. Par exemple, si un service indique qu’un grand nombre de donnĂ©es qu’il reçoit sont incomplètes ou erronĂ©es, cela peut indiquer que les producteurs de ces donnĂ©es rencontrent des difficultĂ©s ou ont un bug. Enfin, le fait que les services soient rĂ©partis sur des serveurs diffĂ©rents complexifie l’exploitation du système. Les flux rĂ©seaux entre les serveurs doivent ĂŞtre surveillĂ©s, de mĂŞme que tous les serveurs actifs.

Sans ĂŞtre exhaustif, voilĂ  un ensemble de caractĂ©ristiques importantes d’un système de surveillance pour une architecture microservices :

  • Automatisation importante
  • Bonne intĂ©gration avec les environnements techniques des diffĂ©rents services
  • Supervision de l’Ă©tat "technique" des serveurs
  • Supervision fonctionnelle de chacun des services.
  • DĂ©tection de la "mort" ou de la "naissance" des services

Vous l’avez compris, plus la quantitĂ© de donnĂ©es obtenue est importante, plus facile et rapide sera la gestion des problèmes en production. Pour faciliter ce monitoring, des outils sont rĂ©cemment apparus, tel que Marathon / Mesos.

Il est Ă©galement possible de mettre en Ĺ“uvre un bus secondaire, utilisĂ© par les services pour remonter toutes les informations pouvant ĂŞtre utiles au monitoring. CouplĂ©es avec un mĂ©canisme de keep alive, ces informations vont vous permettre de dĂ©tecter les montĂ©es en charge de vos services et leurs crashs. Il est alors possible de relancer des instances d’un service venant de tomber, et d’adapter le nombre de services lancĂ©s au niveau de charge de l’application, et ce, sans dĂ©pendre des capacitĂ©s d’auto scaling des fournisseurs de solutions Cloud.

Un autre usage intĂ©ressant d’un système de surveillance est de pouvoir fournir l’ossature d’un catalogue de services. Un tel outil devient très pratique lorsque le nombre de services devient important. Il peut alors ĂŞtre possible de connaĂ®tre toutes les fonctionnalitĂ©s offertes par le système à un moment donnĂ©.

La recherche d’information dans les logs est trop longue

Grâce au mĂ©canisme de surveillance mis en place, un bug potentiel a Ă©tĂ© dĂ©tectĂ© dans le système. En effet un service a remontĂ© l’information selon laquelle un service "appelĂ©" rĂ©pondait mal Ă  un certain type de requĂŞte. Le service potentiellement dĂ©fectueux ne remontant aucune information concernant les dites requĂŞtes, une analyse des logs est nĂ©cessaire. Un membre de l’Ă©quipe va donc se connecter aux serveurs hĂ©bergeant les instances du service "appelant" pour rĂ©cupĂ©rer les logs, puis fait de mĂŞme pour les instances du service "appelĂ©". Une fois les fichiers rĂ©cupĂ©rĂ©s, il doit encore faire correspondre les traces du service "appelant" avec les traces correspondantes dans le service "appelĂ©", le tout sans garantie que les logs donnent plus d’informations que ce que le mĂ©canisme de surveillance a dĂ©jĂ  signalĂ©.

Cette façon de procĂ©der est bien trop longue, et peut faire perdre un temps prĂ©cieux. C’est pour cette raison qu’il est très recommandĂ© d’avoir un mĂ©canisme de centralisation des logs.

Ce mĂ©canisme prĂ©sente dans, l’idĂ©al, les propriĂ©tĂ©s suivantes :

  • RĂ©cupĂ©ration automatique du maximum de logs possible
  • Bonne intĂ©gration avec les environnements techniques des diffĂ©rents services
  • Consolidation des donnĂ©es pour faciliter leur exploitation

Flume, ELK et Kafka sont des outils fréquemment utilisés pour cet usage.

Conclusion

Les pièges sont donc nombreux, et ce, à toutes les étapes du cycle de vie du système. On peut néanmoins les classer en deux grandes catégories.

Tout d’abord les difficultĂ©s rĂ©sultant du changement dans la façon de penser qu’impose l’architecture microservices. Changement dans la façon de concevoir des services bien sĂ»r, mais aussi dans la façon de penser l’Ă©quipe de dĂ©veloppement et le rĂ´le du dĂ©veloppeur. Les Ă©quipes deviennent transverses, DevOps Ă©galement. Et les organisations doivent accompagner et suivre cette mutation. La responsabilisation des Ă©quipes de dĂ©veloppement est au cĹ“ur des microservices. Il s’agit d’un gage de qualitĂ©, mais aussi d’une importante remise en question des organisations traditionnelles. Enfin, certaines pratiques communes telles que la mise en commun des schĂ©mas de donnĂ©es ou du code entre les services ne sont pas forcĂ©ment compatibles avec l’esprit de l’architecture microservices.

Ensuite, la distributivitĂ© et la souplesse de cette architecture apportent plusieurs difficultĂ©s. En effet, si du point de vue de la rĂ©silience et de l’Ă©volutivitĂ©, une telle approche apporte de grands bĂ©nĂ©fices, elle est difficile Ă  mettre en Ĺ“uvre et demande une grande rigueur et un niveau d’exigence Ă©levĂ©. La maintenance de la cartographie des services et de la cohĂ©sion de l’ensemble peuvent poser problèmes.

MalgrĂ© ces risques, l’architecture microservices est une option de choix lorsqu’il y a un besoin d’Ă©volutivitĂ© important, comme dans le cas des applications B to C oĂą l’adaptation rapide au marchĂ© est un critère primordial, ou dans les applications soumises Ă  une forte charge et devant assurer un service continu.

 

Références

http://martinfowler.com/articles/microservices.html

http://microservices.io/patterns/microservices.html

http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

http://www.infoq.com/news/2015/01/microservices-sharing-code

 

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux