[SOA] Microservices vs Monolithic

Hello,

Aujourd’hui, breve introduction sur les microservices (Wikipedia):

In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnosticAPIs.[1] These services are small, highly decoupled and focus on doing a small task,[2] facilitating a modular approach to system-building

Microservices est un terme « a la mode », mais qui n’est en fait qu’une evolution naturelle d’un environnement SOA.

L’avenement des microservices part d’un constat, qui est que parfois, la  notion de SOA n’est pas suffisamment bien mise en place. La SOA devait permettre au developpeur une evolutivite aisee du SI, par l’utilisation et reutilisation de services, mais bien souvents, ceux si sont mal dimensionnes ce qui resulte apres quelques annees en une couche de services « tout-en-un » : le bloc monolithique

monolithic                            Une couche de service mal implementee

Puis, viennent repondre a cela les micro sized services, qui repondent aux besoins suivants:

  • Applications scalables, flexibles et hautes performances
  • Un service specialise dans une tache particuliere
  • Un systeme de communication leger (client service et service/service)
  • Pas de technologie specifique pour un service
  • Business driven developpement (Vous specifiez vos micro services en mirroir avec le business, si le business change, seul votre microservice doit etre change)
  • Stockage de donnees independant
  • Evolution du service independant
  • Deploiement du service independant (cherry on the cake)

 

On comprends alors mieux pourquoi les GAFA ne jurent plus que par cela (Twitter egalement).

 

Prochain post: un exemple de microservice en C# .NET

[Agile] Scrum: Estimer les stories, quelle echelle choisir?

Hello,

Une des choses les plus troubles pour un developpeur, est l’estimation du temps necessaire pour livrer une feature. Un manager vient vous voir et vous demande:

Combien de j/h pour cette feature?

Bien sur, les methodes agiles nous aident a repondre a ce genre de questions, car on « casse » les grosses stories en plein de petites stories, plus facilement estimables et viables par elles memes: minimum viable product, ou MVP.

Mais les methodologies agiles nous poussent a aller plus loin et privilegier une estimation relative. Il est plus facile d’estimer une story par rapport a une autre (deux fois plus de boulot, trois fois etc).

A ce moment la se pose la question de quelle echelle choisir?

Un grand nombre d’equipes choisisent d’utiliser une suite de Fibonacci : 0, 1, 1, 2, 3, 5, 8, 13, 21, etc…

C’est en general un systeme simple, et qui est cense couvrir tous vos besoins (rappel: il faut morceler les stories…). L’interet est qu’il vous evite les debats inutiles (20 ou 21 points) et envoi un signe aux stakeholders sur la relative taille de la story et non pas une estimation gravee dans le marbre.

Mais ce systeme n’est pas le seul, petit florilege de ce qui est utilisable:

  • Systeme de feux : rouge, vert, orange suivant la complexite de la story.
  • Tailles de vetements: XS, S, M, L, XL…
  • Tailles des boissons chez Starbucks (demi, short, tall, grande, venti, trenta)

[Projet C#] Bot black jack avec Strategie de base et comptage de carte HiLo

Hello,

Un des jeux que je pratique enormement depuis plusieurs annees est le Black Jack. D’une part car il vous soumet a des choix difficiles, et d’autres part pour son aspect mathematique.

Le but du black jack est de battre la banque. Pour cela, chaque carte a une valeur (de 2 a 9, 10 pour le 10/Valet/Dame et Roi, et l’As peut valoir 1 ou 11 au choix), et il faut depasser le compte de la banque, sans « sauter », cad depasser 21.

On donne deux cartes de depart a chaque joueur (qui jouent chacun contre la banque, a la difference du poker) et la banque se voit attribuee une carte face visible.

En fonction de votre compte et de la carte visible de la banque, vous devez faire un choix:

Tirer une carte supplementaire : Hit

En rester la : Stand

Abandonner : Surrender

Separer les cartes (sur deux cartes de meme valeur, vous pouvez le faire a condition d’ajouter une mise supplementaire egale a votre mise de depart) : Split.

Doubler (vous ajouter une mise supplementaire egale a votre mise de depart mais on ne vous sert qu’une carte) : Double down.

Le black jack est un jeu particulier car il est joue avec plusieurs paquets de cartes (souvent 6 soit 312 cartes) et c’est un jeu ou les « meilleurs choix possibles » ont etes mathematiquement calcules depuis des lustres. On appelle ca la strategie de base

H pour Hit, S pour Stand, P pour Split, D pour Double…

On considere que les mains contenant un As sont Soft (molles) car l’As peut valoir 1 ou 11 et les autres mains sont Hard (dures). Cela influt sur les choix car un 15 Hard est joue differement d’un 15 Soft (qui peut valoir 5 et donc vous eviter de depasser 21 en tirant une carte additionnelle…) : C’est ce que j’appelle le hand type

Un autre hand type possible est la Paire: en effet vous jouerez une main a 16 differement si elle est composee d’un 10 + 6 ou de deux 8 (que vous pouvez Splitter…)!

Cette strategie de base est bien sur toujours a l’avantage de la banque globalement pour un joueur qui la jouerai parfaitement.

Comment concevoir un simple Bot qui pourrait appliquer cettre strategie de base en C#?

Je me suis amuse a imaginer un Bot evolutif, voici une des nombreuses implementations possible:

 

  1. J’ai decide de dumper la strategie globalement dans un fichier CSV explicitant les choix a faire:

csv Cela permet en fonction du hand type, des cartes du joueur et de celle du dealer de choisir un move a faire. Ce n’est rien d’autre que ce qu’il y a dans le tableau precedent.

2. J’utilise ensuite une interface IStrategy qui decrit un contrat pour ouvrir et parcourir un modele de strategie (csv):

IStrategy

Cette interface permet d’implementer des methodes pour recuperer la meilleure action dans un modele.

openModel

Voici un exemple de code qui en fonction des cartes du joueur et de la carte visible du croupier parcours le modele afin de recuperer la meilleure action.

La gestion des mains Soft (avec As) est particuliere donc je vous laisse parcourir le code source..

 

consoleApp

Voici un exemple de programme instanciant la strategie, ouvrant le modele et renvoyant le meilleur move pour une main donnee.

Vous me direz: C’est bien beau mais l’avantage est toujours a la banque et non au joueur?

 

C’est la qu’entre en jeu une autre strategie, le comptage de carte, et plus particulierement le HiLo, qui permet de retourner l’avantage au joueur (pas grand chose, au mieux 52% pour le joueur, mais il s’agit d’alterner le montant des mises en fonction du moment ou l’avantage est au joueur, on appelle ca la Spread Strategy) :

Comme le jeu de black jack est sans remise (une fois les cartes jouees, elles ne sont pas remises en jeu), on peut suivre la valeur des cartes, et estimer que quand un nombre plus important de petite cartes sont sorties, les cartes restantes sont a l’avantage du joueur (je n’entrerais pas en detail dans le pourquoi elles ne seraient pas a l’avantage de la banque, mais il y a d’autres regles dans le jeu du banquier qui differe du notre).

Le HiLo attribue la valeur -1 a chaque carte entre 10 et As, +1 du 2 au 6 et le 7/8/9 sont neutres (ne changent pas le compte).

Autrement dit, si vous suivez (dans votre tete) les cartes sorties, en fonction du compte, vous avez un jeu a votre avantage ou non. La plupart des compteurs de carte estiment qu’il faut compter un paquet de carte de 52 cartes en moins de 20 secondes (18 dans mon cas..) pour etre assez rapide afin de ne pas perdre le fil des cartes en live.

Les choix a faire en fonction du compte sont legerement differents de la strategie de base pour quelques mains seulement et se resument a 18 choix que l’on appelle les Illustrous 18:

La colonne index represente le compte si l’on joue avec un seul jeu de carte, c’est le True Count (compte vrai).

Seulement comme l’on joue avec 312 cartes, notre compte n’est pas fiable. Le compte avec 312 cartes est appele Running Count (compte courant)

Pour obtenir le true count a partir du running count, il suffit de diviser le running count par le nombre estime de paquet de carte restant a jouer. Pour obtenir ce nombre de paquet a jouer, il suffit de jeter un oeil au cartes deja jouee dans le receptacle prevue a cet effet :

Comme l’on compte developper cela, nous n’aurons pas ce soucis car nous aurons acces facilement au true count..

Je n’ai pas terminer la classe HiLoStrategy (qui herite de notre interface IStrategy), mais celle-ci devrais etre triviale car il s’agit du meme comportement que la classe BasicStrategy, a ceci pres que le modele est different (moins de choix) et que si l’on ne trouve pas le choix que l’on souhaite dans le modele, il faudra se rabattre sur la BasicStrategy.

La maniere de definir les modeles ainsi est assez souple car elle permet l’ajout de nouvelle strategies d’une maniere aisee…

 

Le code source du Bot est disponible ici: https://github.com/assyadh/BlackJackBot/

Octopus Deploy et la gestion des fichiers de configuration app.config

Hello,

Aujourd’hui je vais aborder la maniere dont Octopus Deploy gere les differentes variables presentes dans un fichier de configuration.

L’interet de la maniere dont Octopus Deploy gere la transformation des variable est que cela ne necessite de maintenir que deux fichiers app.config pour le developpeur.

Le premier est le fichier app.config classique, contenant des variables pointant vers les environnements/valeurs de developpement

Le deuxieme est un fichier additionnel (app.config.deployment) par exemple, dans lequel les variables sont renseignees avec une syntaxe particuliere:

Octopus fichier configuration

On notera ici l’utilisation de la syntaxe #{ } pour des variables definies par l’utilisateur et { } pour des variables proposees par Octopus

Il ne reste alors plus qu’a renseigner au sein d’Octopus Deploy les valeurs que l’on souhaite en fonction de chaque environnement, et specifier l’utilisation du fichier app.config.deployment comme fichier de configuration (Octopus permet de le renommer en app.config).

Ce processus permet la gestion d’un nombre X d’environnements de maniere centralisee au sein de deux fichiers et d’Octopus.

Diffy, tester des services sans ecrire de tests

Aujourd’hui, je ne fais que reprendre un projet rendu open-source par Twitter : Diffy

Diffy permet de tester les regressions sur trois instances de services: 2 instances valides (simili prod) et une release candidate.

L’interet est que Diffy propose un seul et meme proxy, pour lequel on peut scripter un seul appel au service. Cet appel est repercute sur les trois instances, et grace a une interface on peut inspecter les regressions:

Grace aux deux instances valides, Diffy parvient a detecter les faux positifs.

L’ensemble est propose sous un seul package scala, compilable et executable grace a java.

Il vous reste plus qu’a ecrire un script massif de requete curl (ou wget if windows) de ce que vous souhaitez tester.

Cet outil teste les regressions d’une version a l’autre.

Source:

https://blog.twitter.com/2015/diffy-testing-services-without-writing-tests

Paket et la gestion de dependances sur .NET

Une des betes noires des projets .NET reste la gestion de dependances: Comment les mettre a jour de maniere automatisee? Comment valider que l’on utilise bien une version specifique? Comment centraliser la gestion des references des projets .NET, et avoir une vision claire de qui utilise quoi?

A toutes ces questions, il y a une reponse : Paket.

Paket est un utilitaire open source developpe en C# et qui permet d’accomplir cela grace a la gestion de chaque reference au sein d’un fichier par projet : le fichier paket.references.

L’idee globale est de mettre a jour ce fichier suivant les dependances necessaires pour un projet C# par exemple.

Exemple de contenu pour un fichier paket.references :

CommonServiceLocator
Moq
NUnit
Unity

 

A chaque build, les references vers ces packages (nuget) seront verifiees et mises a jour si necessaire.

On peut specifier les sources pour les packages nuget a un niveau superieur, au sein de la solution meme dans un fichier packet.dependencies, ce qui permet la prise en compte de repo interne au SI.

Exemple de contenu pour un fichier paket.dependencies :

source http://nuget.org/api/v2
source http://monrepolocal/nuget

nuget Nuget.CommandLine
nuget AutoMapper framework: net45
nuget RavenDB.Client < 3.0 framework: net45

L’idee ici est de specifier des versions specifiques, des repos specifiques etc.

Enfin, le fichier paket.lock liste toutes les versions actuellement utilisees dans la solution:

NUGET
remote: http://www.nuget.org/api/v2
specs:
Microsoft.Bcl (>= 1.1.9) – framework: >= net40 < net45
System.Diagnostics.Debug (>= 4.0.10)
System.Linq (>= 4.0.0)
CommonServiceLocator (1.3)
CsvHelper (2.13.2.0)

 

 

Enfin, Paket permet la conversion d’une solution sln existante en solution incorporant paket, avec la creation automatisee des fichiers paket.references, paket.dependencies et paket.lock en fonction de ce qui est actuellement en place

The best interface is no interface

Aujourd’hui, place a un livre: The best interface is no interface par Golden KRISHNA:

The best interface is no interface by Golden KRISHNA

« If Silicon Valley doesn’t read this book, we’re all ****ed. »
– Doug LeMoine, Managing Director, Cooper

Je suis assez d’accord avec le point de vue de Doug LeMoine.

Ce livre traite de la necessite cruelle de revoir la maniere dont nous apprehendons la creation des interfaces (au sens premier mais aussi au sens IHM).

Beaucoup de developpeurs sont desormais recrutes sous des termes fancys (UX/UI) mais se retrouvent a pondre un maximum d’UI (User Interface), au detriment de l’UX (User Experience).

La question fondamentale que Krishna pose est: Est-ce que la course a l’interface est necessaire afin de garantir une experience accrue?

Poubelle electronique permettant de savoir qu’il fait beau alors qu’on est plante devant.

Ce livre est pour moi interessant car il nous oblige a prendre du recul sur ce qu’un developpeur produit, et sortir la tete du guidon 2.0 peut tres souvent nous rendre compte que l’on doit delivrer des logiciels apportant de la valeur, et que l’interface n’est pas le seul moyen de le faire…

Question: Si vous avez le choix entre une app iPhone pour ouvrir votre voiture ou une cle permettant l’ouverture sans la sortir de la poche, que choisiriez vous? La meilleure experience ne passe pas forcement par l’interface…

http://www.amazon.com/The-Best-Interface-brilliant-technology/dp/0133890333