D I F F U S E R L E S CO N N A I S S A N C E S E T L’ I N N O VAT I O N D A N S L E D E V E LO P P E M E N T LO G I C I E L D ’ E N T R E P R I S E

Startup Architecture Retour d’Expérience et Best Practices de 4 Top Startups soutenues par Microsoft

ARTICLE

ARTICLE

ARTICLE

ARTICLE

Hadoop, Spark & Elasticsearch chez Realytics.io

R, DocumentDB & Java chez Brennus Analytics

PostgreSQL, Hadoop & Elasticsearch chez Clic2Buy

Vert.x & Kubernetes chez Coursier Privé

ÉDITORIAL Quatre startups issues du programme BizSpark Plus – l’offre premium Microsoft pour les startups – se sont prêtées au jeu de l’interview technique pour InfoQ FR. A travers le regard de leur architecte technique, découvrez l’univers de Realytics.io, Brennus Analytics, Clic2Buy et Coursier Privé dans les articles suivants.

Realytics.io : Hadoop, Spark & Elasticsearch Fondée en 2013 par 4 amis ingénieurs, la startup développe des solutions de mesure de la performance et du ROI de campagnes publicitaires télévisées via plateforme SaaS.

Brennus Analytics : R, DocumentDB & Java Fondée en 2015, la startup développe des solutions d’optimisation du pricing pour industriels via intelligence artificielle.

Clic2Buy : PostgreSQL, Hadoop & Elasticsearch Créée en 2013, la startup lilloise permet aux marques de rendre leurs supports de communication (site web, newsletter, vidéos Youtube, Facebook) marchands sans devenir e-commerçant: les consommateurs ont la possibilité d’acheter directement les produits de ces marques en étant redirigés vers des distributeurs grâce au bouton «acheter maintenant ».

Coursier Privé : Vert.x & Kubernetes Décrite comme « le Uber de la livraison », la startup fondée en 2015 développe des solutions d’optimisation des flux de livraison dans un écosystème donné.

Pour rappel : BizSpark Plus, c’est l’offre premium Microsoft pour les startups, lancée en juillet 2015 en partenariat avec les meilleurs incubateurs et accélérateurs dans 47 pays. Le but ? Aider ces startups à se développer, détecter les stars de demain et aider les clients historiques Microsoft à se transformer en favorisant les synergies. Ces startups, qui font le choix de Microsoft Azure pour leur architecture technique et le support de leurs technologies open sources, bénéficient de plus de $120,000 de crédit sur le cloud Microsoft Azure, des licences Office 365, et l’accès à de nombreux logiciels Microsoft (Visual Studio, SQL Server, …). Cette offre est complétée par un accompagnement technique personnalisé, un accès direct à l’équipe Startup Microsoft France et un programme Go To Market reposant sur la puissance des réseaux Microsoft. 2

Startup Architecture

LIRE EN LIGNE sur InfoQ FR

Hadoop, Spark & Elasticsearch chez Realytics.io À l’occasion de Microsoft experiences ‘16, InfoQ FR a pu échanger avec Sébastien Monteil de Realytics.io sur leur architecture technique de tracking et de mesure de performance des campagnes de pub télé. InfoQ FR : Bonjour Sébastien, est-ce que vous pouvez nous présenter l’historique et le concept de Realytics.io ? Sébastien Monteil : A l’origine, je suis le fondateur d’une société qui s’appelle Kobojo qui propose une technologie de social gaming. Je l’ai créée avec mes associés il y a sept ans et nous avions rencontré à Kobojo des problématiques qui étaient de traiter une grosse volumétrie de données le plus rapidement possible. Nous devions en effet réaliser des opérations marketing in-game, pour faire par exemple des promotions rapides sur un item qui marchait moins bien que d’autres. La difficulté majeure était de pouvoir analyser une population de 60 millions de joueurs de manière ultra-rapide. A l’époque, il n’y avait pas grand chose sur le marché quand je suis sorti de Kobojo début 2013. Je me suis alors lancé sur ce projet et la promesse de départ était de créer une solution de Big Data analytics en temps réel ou pseudo temps réel pour tous les types de marchés. J’avais déjà travaillé avec Guillaume un associé et nous nous sommes fédérés autour de ce projet. Nous avons commencé par tester notre concept auprès de sociétés et clients que nous connaissions. Nous avons rencontré des sociétés comme Aéroport de Paris, qui nous a dit qu’ils allaient pouvoir optimiser le tri des bagages à Roissy avec ce concept, d’autres sociétés comme ALLO RESTO qui avait acheté pour des centaines de milliers d’euros de publicité télé et qui voulait savoir si notre concept leur permettrait de savoir s’ils gagnaient de l’argent. Au final nous avons décidé de prendre notre produit et de le spécialiser sur la mesure de la performance des publicités télé sur tous les environnements digitaux. Nous sommes partis des études et du constat que 75% des gens regardent leur télé avec un deuxième écran, soit leur PC, soit leur tablette, soit leur téléphone.

Nous avons en fait deux technologies, une technologie d’analytics qui est l’équivalent d’un Google analytics mais avec une précision à la seconde, puisqu’en effet une publicité à la télévision dure entre 10 et 30 secondes. Notre deuxième technologie est un robot qui regarde la télévision pour identifier les spots de nos clients. En effet lorsqu’un annonceur achète de la publicité à la télévision, il achète en fait des créneaux et des positions. Il sait par exemple qu’il va passer à 20h50 en 3ème position, mais le 20h50 peut être en réalité à 20h55 ou 20h42. Dès que notre robot détecte un spot de l’un de nos clients, il déclenche une phase de calcul qui dure 6 minutes. Pendant cette période nous analysons tout ce qui se passe sur le site de l’annonceur sur les applications mobiles et nous essayons de déterminer le nombre de visiteurs qui sont venus sur le site suite à la diffusion du spot. On fait ce calcul sur chaque spot mais aussi sur une période plus longue, afin de voir si des visiteurs sont venus quelques jours après. C’est ce que l’on appelle l’effet de halo. Realytics fournit donc un service sous forme d’une plateforme SaaS de mesure de performance et de calcul du ROI d’une campagne de pub à la télévision. InfoQ FR : Proposez-vous le service pour d’autres médias ? Sébastien Monteil : On propose le service pour la télévision. Pour la radio nous disposons d’un robot équivalent qui écoute la radio. InfoQ FR : Comment fonctionne la reconnaissance des spots de vos annonceurs ? Sébastien Monteil : Le robot fait de la

reconnaissance de pattern. C’est le principe de l’algorithme de Shazam. Pour la reconnaissance du spot télé, on est sur de la reconnaissance

Startup Architecture

3

d’images. A partir de la vidéo de notre client, nous faisons une signature numérique et ensuite on recherche cette signature, c’est un peu plus long à traiter que pour la voix. La particularité de cette reconnaissance est qu’elle doit être temps réel. InfoQ FR : Quelle est votre particularité par rapport aux autres solutions d’analytics ? Sébastien Monteil : Par rapport aux autres solutions, on ne se contente pas simplement de savoir combien de visiteurs sont venus et ont acheté après avoir vu le spot de télévision. On va essayer de trouver qui sont ces personnes, en calculant l’équivalent d’un scoring par rapport à une multitude de paramètres, leurs devices par exemple et par rapport à des modèles mathématiques que l’on a accumulés depuis des années. Nous avons aujourd’hui plus d’un demi-million de spots analysés et nous commençons à avoir de l’expérience sur l’analyse du comportement des visiteurs. Ces modèles mathématiques nous permettent ainsi de déterminer les probabilités qu’un visiteur ait vu le spot de télévision. Pour les visiteurs pour lesquels nous avons un scoring, nous sommes aujourd’hui les seuls sur le marché à pouvoir les retargeter. Si un visiteur a vu par exemple le spot télé et revient trois jours après sur youtube ou Facebook, s’il n’avait pas été converti à l’époque, nous pouvons lui réafficher le spot télé ou un message complémentaire. Les annonceurs prévoient souvent de raconter une histoire qui accompagne le visiteur sur internet après la diffusion du spot télévision. InfoQ FR : Pouvez-vous nous parler de votre architecture technique ? Sébastien Monteil : Nous avions une forte expérience Cloud issue du gaming social. Nous sommes partis tout d’abord sur Amazon Web Services. Une des particularités de notre business est que nous avons eu très tôt des leads et des clients à l’international, aux ÉtatsUnis, en Australie et au Brésil. Nous avons donc été obligés d’avoir une présence technique globale dès le départ à l’international. L’architecture Cloud est aujourd’hui pour nous indispensable et nous permet d’avoir des points de présence, ce qui est vital pour nous comme pour tout outil de tracking.

4

Nous avons en effet besoin d’être proche du client pour éviter la latence et de perdre de l’information. Aujourd’hui nous avons une partie de l’infrastructure sur AWS et une partie sur Microsoft Azure. A Paris, pour des raisons de réglementation, nous avons les données qui concernent les utilisateurs, notamment dans les banques et la finance. On a procédé à un découpage fonctionnel entre ces deux infrastructures Cloud. Toutes nos APIs de tracking sont sur AWS. Toute la partie compute, le traitement et l’analyse des données, les dashboards sont sur Microsoft Azure. Ces deux mondes communiquent via des VPN. InfoQ FR : Pourquoi avoir fait ce choix de deux infrastructures ? Sébastien Monteil : Je veux pouvoir migrer à tout moment sur une infrastructure. Nous avons développé la possibilité de migrer complètement une infrastructure, sur l’un des deux clouds en cas de problème. L’objectif est que la plateforme de captation de données (le tracking) soit toujours disponible. InfoQ FR : Comment avez-vous géré cette migration d’infrastructure ? Sébastien Monteil : On utilise pour cela Ansible. InfoQ FR : Vous n’avez pas eu de problème de pairing entre AWS et Microsoft Azure ? Sébastien Monteil : Non à ma grande surprise, même sur toutes les configurations de zones. On a bricolé un Openswan entre les deux, puisqu’il n’y avait pas à la base de solution technique toute prête pour le faire. Au final, nous avons mesuré moins de 2 ms de latence entre Microsoft Azure et AWS en Irlande. Les data centers doivent être très très proches. Nous avons du coup aucun problème pour nos transferts de données. InfoQ FR : Quelles stacks techniques utilisez-vous ? Sébastien Monteil : Nous sommes essentiellement sur des technologies open source. On est partis très vite sur le mode ARM d’Azure (Azure Resource Manager). Nos APIs

Startup Architecture

Ensuite sur la partie traitement de la donnée, nous sommes sur un cluster Hadoop et Spark qui tourne dans Azure.

dire que si un client arrive avec un plan média et des chaînes cibles, nous aurons la capacité, une fois qu’il aura entré ses données dans notre calculateur, de prévoir le nombre de visiteurs. Ce sont des choses que nous testons depuis 4 mois en interne. Cette approche ne demande pas de technologie particulière mais c’est du domaine de la data science pure.

InfoQ FR : Pour le cluster Hadoop, vous le faites tourner vous-mêmes ?

InfoQ FR : Merci Sébastien !

sont développées en Node.js et sont déployées sur AWS, derrière un HAProxy pour gérer toute la plateforme de captation des données de tracking.

Sébastien Monteil : Oui nous le faisons tourner nous-mêmes. La seule ressource managée que nous utilisons c’est Redis pour la partie caching. Nous avons également 4 clusters Elasticsearch, maintenus par nous, hébergés sur Azure et alimentés par le cluster Hadoop.

Sébastien Monteil : Merci et à bientôt !

InfoQ FR : Et pour le front, qu’est ce que vous utilisez ? Sébastien Monteil : En front nous avons une API en .Net qui communique avec MySQL et les clusters Elasticsearch. Cette API est interfacée avec une application en ReactJS. InfoQ FR : De combien de serveurs disposezvous ? Sébastien Monteil : Entre quarante et cinquante machines pour Microsoft Azure et une vingtaine dans AWS. Nous sommes présents en Australie, aux Etats-Unis, en Irlande, en France et Amérique du Sud. InfoQ FR : Pour la partie Dashboard, vous utilisez une solution ? Sébastien Monteil : Non on a tout fait nousmêmes en React et en icharts. InfoQ FR : Combien de clients avez-vous aujourd’hui ? Sébastien Monteil : En deux ans, on a un demimillion de spots analysés pour 150 annonceurs. On arrive à scorer 9 000 visiteurs par minute. InfoQ FR : En ce qui concerne la roadmap technique, quelles sont les prochaines étapes pour vous ? Sébastien Monteil : Aujourd’hui, les enjeux sont pour nous surtout scientifiques. Nous allons bientôt sortir un module prédictif, c’est à Startup Architecture

5

LIRE EN LIGNE sur InfoQ FR

R, DocumentDB & Java chez Brennus Analytics À l’occasion de Microsoft experiences ‘16, InfoQ FR a pu échanger avec Florent Dotto et Thomas Sontheimer de Brennus Analytics sur leur architecture technique et notamment leur stack R, DocumentDB, Java, API App sur Azure. InfoQ FR : Bonjour Florent, Thomas, estce que vous pouvez tout d’abord nous expliquer le produit avant de parler architecture technique ? Florent Dotto : Brennus Analytics développe une solution SaaS d’optimisation dynamique des prix, pour les industriels, basée sur l’analyse de données : du choix de cette politique par segment client et produit, jusqu’au calcul du prix optimal pour chaque demande de devis reçue. Nous utilisons une technologie d’intelligence artificielle permettant d’apprendre en continu le comportement des clients à partir de l’historique des données commerciales, et d’optimiser en temps réel les prix de chaque offre en prenant en compte ses coûts spécifiques. L’ensemble garantit à l’industriel une politique de prix optimale et toujours en prise avec les évolutions du marché. InfoQ FR : Pouvez-vous nous décrire le use case global du produit, et comment l’architecture en découle ?

6

Florent Dotto : Alors déjà le use case du produit, c’est de fournir une solution industrielle, un accès qui permet à leurs équipes commerciales de faire des quotations à des demandes de devis. Donc les équipes commerciales reçoivent des demandes de quotations de clients, elles doivent fixer un prix à proposer à leur client. Quelque part, notre système vient juste s’intégrer au processus de pricing de ces équipes commerciales, et la valeur ajoutée, c’est que le prix qui va être calculé va prendre en compte des historiques, enfin des données, un historique de données de notre industriel, pour modéliser le comportement, la probabilité que le client accepte le deal à un certain prix qui va être proposé, c’est ça qui va nous permettre de calculer un prix optimal pour maximiser l’espérance de marge de l’industriel pour chacun des deals en temps réel. Donc la problématique qu’on a c’est que l’industriel puisse uploader, ou qu’on puisse récupérer les données de notre industriel sur notre serveur.

Startup Architecture

Qu’on puisse travailler avec ces données là pour modéliser le comportement du client, qu’on puisse aussi calculer les notions de marge et de coût de notre industriel, et une fois qu’on a tout ça, qu’on fasse de l’optimisation pour croiser les deux courbes et sortir un résultat. Il faut ensuite, ce résultat, l’afficher, donc là c’est une app web, pour simplifier on a pu fixer un navigateur qui soit Chrome. Et la problématique qu’on avait initialement, c’est qu’on ne savait pas si les industriels seraient OK pour que ce soit en SaaS, initialement on se disait qu’il fallait qu’on soit déployé aussi bien sur Azure, puisqu’on avait choisi de travailler avec eux, ou chez eux en local. Donc c’était une première approche. La seconde, c’est qu’au final on ne voulait pas avoir à gérer une infrastructure physique, car ça présente plus d’inconvénients que d’avantages pour nous. Et justement Azure permet de ne pas s’embêter avec ça. Donc autant l’utiliser. InfoQ FR : Vous avez commencé il y a combien de temps ? Florent Dotto : Les réflexions ont commencé il y a... 10 mois, et on a commencé à implémenter il y a environ 8 mois, vers février 2016. InfoQ FR : Comment sont structurées les différentes parties du système ? Thomas Sontheimer : L’application compose des éléments suivants :

se

- Un frontend déployé sur App services (Web App) ; implémenté avec Angular2 en utilisant Swagger pour générer le code client de l’API REST, - Une API REST déployée en standalone sur App services (API App) ; implémentée avec Sparkjava pour le service, Jackson pour le JSON et JWT pour l’authentification, - Un cœur d’analyse déployé sur une VM ; actuellement implémenté en R et servant une API avec FastRWeb, on travaille à son remplacement par une version intégrant la technologie AMAS avec Sparkjava pour servir l’API,

- Une base DocumentDB avec support du protocole MongoDB à laquelle l’API REST et le cœur d’analyse accèdent avec Jongo. Thomas Sontheimer : Et en termes d’évolution, on était pris au début plutôt sur de l’IaaS pour utiliser Azure, donc déployer des machines virtuelles et ensuite déployer une webapp en Angular, et qui ensuite allait taper directement sur des VM qui elles déployaient à la fois une API, et en back-end derrière un serveur de calcul, qui est un serveur R.

Petit à petit, on a fait évoluer cette architecture pour profiter justement d’Azure au maximum et donc pousser le plus de choses possibles en Platform as a Service, donc notre API, ce qui était à la base déployée sur une machine virtuelle, on est en train de la migrer vers une API App qui nous permet finalement d’exposer au front-end toute l’API de notre application sans avoir à gérer la machine virtuelle, sans avoir la maintenance du système d’exploitation, les mises à jour, ce genre de choses. Et gérer aussi la redondance. InfoQ FR : Vous tirez parti de plus en plus de services managés, on parlait de l’API ; est-ce qu’il y a d’autres exemples de choses que vous avez, comme ça, migrées, ou que vous pensez migrer à un moment ? Thomas Sontheimer : Non, c’est principalement sur ce point là, après on va utiliser de plus en plus les fonctionnalités de ces services, à la fois au niveau front-end pour ce qui est du déploiement à travers des slots de déploiement, plutôt que de déployer plusieurs web applications, l’idée c’est de pouvoir déployer la même web application et ensuite de faire des switchs entre les slots pour avoir des déploiements plus fluides. Et après sinon, de toutes façons on prévoit

Startup Architecture

7

quand même de rester sur un serveur R pour tout ce qui est analytique, l’idée ça va être de déployer notre propre technologie, qui elle est développée en Java et qui nécessite des ressources quand même relativement importantes, et donc ça on va pas pouvoir le déployer sur des App Services a priori. On pense rester pour cette partie là toujours sur une sorte de machine virtuelle, sachant que ce qu’offre Azure là-dessus, c’est intéressant pour nous, c’est la possibilité d’avoir un gateway entre le réseau virtuel sur lequel sont déployées les machines virtuelles, et l’App Service qui fournit l’API finalement, et qui nous permet d’avoir une connnexion sécurisée en HTTPS, plus que sur notre point d’entrée qui est notre API qui est déployée comme une application, un App Service, et ensuite tout se passe sur un réseau virtuel qui donc est sécurisé et qui nous permet de ne pas gérer ça. InfoQ FR : Pour les données clientes, avezvous un tunnel vers la data source client ou est-ce que c’est une copie ? Florent Dotto : Pour l’instant, c’est une copie. A terme, il faudra que ce soit un tunnel. InfoQ FR : Qu’est-ce que vous utilisez comme storage ? Florent Dotto : Nous utilisons DocumentDB. Thomas Sontheimer : Ensuite, pour la partie R, c’est un snapshot qu’on utilise aujourd’hui. L’API a elle un accès direct à DocumentDB, ce qui nous permet pour de la navigation de ne pas avoir à passer par notre serveur R. A terme, notre technologie qui sera déployée sur une machine virtuelle avec la partie Java pourra directement interroger la base de données, là on prévoit d’avoir une connexion directe. L’idée étant de ne pas dupliquer d’accès aux données, mais de passer par le même pipe. InfoQ FR : Utilisez-vous R en interactif ou en batch pour générer des sortes de prédiction ? Florent Dotto : Les deux. Tu peux expliquer Thomas ? Thomas Sontheimer : C’est les deux effectivement, c’est-à-dire qu’on calcule des courbes d’acceptabilité. 8

En fait pour chaque produit que notre client va pouvoir proposer, on va pouvoir calculer des courbes d’acceptabilité et leurs caractéristiques (c’est quelque chose qu’on va calculer en batch), et par contre, une fois qu’on aura fait ces calculs-là, on va pouvoir les interroger directement en fonction des caractéristiques qui peuvent varier, en fonction des demandes de produit. Florent Dotto : En fait, dans le process métier, les utilisateurs importent une demande de devis. A ce moment-là, lorsque c’est chargé sur notre système, c’est là qu’une surface d’acceptabilité est calculée pour ce devislà, et puis voilà, c’est fait. Et ensuite lorsque l’utilisateur a chargé son devis, il va voir ses prix optimaux, et on peut jouer avec en fait, sur chacun des produits, le système peut recalculer en temps réel, à la volée, les courbes d’acceptabilité réelles qui sont associées au prix et à la quantité du produit, car l’utilisateur peut changer la quantité, ce qui va changer la valeur de la courbe en fonction du prix au kilo. Le prix au kilo varie en fonction de la quantité demandée. Donc en fait, on fait un prix batch, on calcule une partie du problème au chargement, puis ensuite on calcule une autre partie du prix à la volée parce qu’on a “extrapolé” les paramètres de la courbe, et on peut calculer à la volée la valeur à cet endroit-là. InfoQ FR : Et en termes de visualisation de tout ça, pouvez-vous nous décrire votre front-end ? Florent Dotto : On a une appli Angular. Pour l’instant, c’est pas notre métier, notre valeur elle est dans l’algo, et pour l’instant, les clients qu’on a, ce sont des applications métier et ils travaillent avec Excel, donc dès qu’on a un truc un peu mieux qu’Excel, ça a une forte valeur ajoutée, et ça suffit. On sait ce qu’il faudrait faire pour bien le faire, mais on a pas mis de temps là-dessus, donc on a de l’Angular, on a des tableaux, des cellules et les personnes peuvent naviguer. Bon là, on utilise le minimum dont on a besoin d’Angular pour pouvoir travailler. On est passé à Angular 2 récemment pour effacer un peu de dette technique, et résoudre des petits problèmes. On utilise une librairie particulière qui s’appelle PrimeNG. On a un petit souci, c’est que les gars sont habitués à travailler

Startup Architecture

sous Excel, donc on clique sur une cellule et tout est sélectionné automatiquement à l’intérieur de la cellule, une sélection all, et donc ils peuvent faire directement une sélection et copier-coller. Ça, en fait, ça fonctionne pas dans la librairie PrimeNG, c’est bête mais ça fait un changement d’habitudes, ça fait perdre du temps car les gars sont toujours en train de faire des copier-coller. C’est un truc, en passant sur Angular 2, on a des chances de pouvoir l’adresser, donc on est passé dessus et on va chercher comment addresser ce problème. InfoQ FR : Et la migration Angular 1 / JavaScript vers Angular 2 / TypeScript, ça a été simple ? Florent Dotto : Angular 2, on a migré en deux ou trois jours. Thomas ? Thomas Sontheimer : Oui, le passage de Angular 1 en Angular 2 a été fait en moins d’une semaine. Florent Dotto : Après, on n’avait pas d’interface compliquée, il n’y avait pas beaucoup de code. Il y a trois pages avec peu d’interactions. InfoQ FR : Comment vous fonctionnez en terme de CI ? Thomas Sontheimer : En fait, on utilise Jenkins, forcément classique, qu’on a couplé avec SonarQube qui nous permet d’avoir des métriques. Ce à quoi on est passé récemment, comme on est sous Eclipse, c’est utiliser le plugin SonarLint, c’est le dernier plugin sorti par SonarQube, et qui permet d’avoir de l’analyse de code en direct, de ne pas avoir besoin de déclencher toute la chaîne pour avoir un retour, c’est quelque chose qui est vraiment très agréable.

une duplication de code de la version pour les clients, et ensuite en fin de sprint on bascule. InfoQ FR : Donc aujourd’hui, votre CI est orientée qualimétrie, et question repository manager ? Thomas Sontheimer : Non pas encore, c’est pareil : c’est dans les tuyaux, ça fait partie des choses à faire, sur notre expérience précédente on avait utilisé un Nexus, la question se pose là de prendre un Artifactory ou de repartir sur un Nexus. InfoQ FR : Aujourd’hui, vous avez des “Data Scientists” dans l’équipe ? Florent Dotto : On a tous un profil mixte, même moi j’ai un diplôme en intelligence artificielle, Thomas aussi. Donc on est une grosse équipe en intelligence artificielle, avec des profils développeurs web, développeurs tout ce que tu veux, et on a même un data scientist spécialisé en biologie. On est bien armé là-dessus, il n’y a pas de souci ! On a tous aussi une expérience entreprenariale importante. Thomas et les autres ont travaillé dans une autre boîte, qui utilisait la même techno qu’on a validé sur notre projet, et là on les a motivés pour repartir sur un nouveau projet, en changeant le paradigme business parce que le leur était pas suffisamment efficient. Donc on repart là-dessus, on y croit. Initialement, le business était on fait des applis dédiées aux problématiques de chaque client, mais ça ne crée pas de récurrent. Donc là on veut créer du récurrent sur un produit SaaS. InfoQ FR : Merci Florent et Thomas !

Et aussi des projets mavenisés, et dès qu’on fait des commits sur Git, c’est récupéré par Jenkins, qui nous fait tout le passage des tests. Pour l’instant, on fait pas encore de déploiements automatisés, c’est la prochaine étape. Le but étant d’automatiser au maximum et de réduire les temps à chaque fois entre ce que le développeur va coder et le retour qu’il pourra avoir des tests utilisateurs. Florent Dotto : Après, on a dupliqué les machines pour pouvoir être organisé avec un déploiement blue/green, on travaille avec Startup Architecture

9

LIRE EN LIGNE sur InfoQ FR

PostgreSQL, Hadoop & Elasticsearch chez Clic2Buy À l’occasion de Microsoft experiences ‘16, InfoQ FR a pu échanger avec Guillaume Fraybin de Clic2Buy sur leur architecture technique et notamment leur stack Big Data sur Azure. InfoQ FR : Bonjour Guillaume, en préambule, peux-tu nous parler de Clic2Buy et des fonctionnalités métier de votre produit ? Guillaume Fraybin : En synthèse, Clic2Buy est une startup lilloise basée à Euratechnologies, qui permet aux consommateurs d’acheter directement depuis les supports de communication des marques (site web, réseaux sociaux, vidéos, print...) en les redirigeant vers les distributeurs. Concrètement, nous ajoutons un widget qui géolocalise le consommateur, référence les distributeurs qui ont le produit (en livraison à domicile, en clic&collect ou en magasin) et in fine ajoute au panier le produit sélectionné.

10

InfoQ FR : Peux-tu nous décrire l’architecture technique globale ? Guillaume Fraybin : Notre architecture est actuellement divisée en 3 couches : Une partie data qui collecte et agrège l’ensemble des données issues de nos partenaires distributeurs ; Une partie application métier qui nous permet de travailler la donnée, en extraire les informations pertinentes pour nos clients ; Une partie front qui comprend l’ensemble des outils que nos clients installent sur leurs sites ainsi que l’accès au back-office.

Startup Architecture

Nous nous appuyons sur Azure dans une optique plus orientée IaaS que PaaS même si nous utilisons ponctuellement quelques briques services ; la raison principale est qu’en débarquant sur Azure, il y’a un peu moins d’un an, nous avons passé pas mal de temps à tester les scenarii qui fonctionnaient le mieux avec nos applications mais de trop nombreuses spécificités nous ont poussé à opter pour une utilisation IaaS. Au fur et à mesure, nous nous intéressons aux web et worker roles mis à disposition sur la plateforme Azure mais nous avançons avec parcimonie. Côté technos, l’équipe de dev utilise selon les projets : Ruby on Rails, nodejs, Go, Angular, Postgres, MongoDB, Hadoop, Java, pdi, Redis, nginx, Elasticsearch. Chaque développeur a la liberté de proposer un nouvel outil après l’avoir testé et validé le bénéfice que ce soit en termes de qualité ou de gain de temps. Nous avons ainsi complété notre pool d’outils SaaS avec Datadog, Runscope, Mailgun, Opbeat, Coveralls, Travis, Gemnasium, GitHub bien sûr, et Aurélien notre super stagiaire. Côté trafic, 4 millions de personnes activent nos services tous les mois, et plusieurs dizaines de millions d’informations sont mises à jour quotidiennement. Nous avons des ambitions internationales mais nous avançons avec pragmatisme en accompagnant nos clients et sur ce point, les équipes Azure France nous ont fait profiter de leurs compétences pour nous aider dans nos choix d’infra hors France.

InfoQ FR : Pour le monitoring technique et métier, comment avez-vous géré ? Guillaume Fraybin : Pour ce qui est du monitoring technique, nous avons complété Nagios par Datadog qui apporte une vision applicative plus précise. Avec l’augmentation du trafic, nous avions le choix soit d’augmenter les capacités machines, soit de mettre le doigt où ça coince et de trouver une solution plus pertinente côté dev. Nous avons choisi la seconde... Côté métier, nous avons développé un outil maison permettant de prendre des mesures sur l’ensemble de la chaîne de valeurs qui sont affichées dans nos bureaux et permettent d’intervenir si la qualité de nos données ou du service rendu est dégradé. InfoQ FR : Un petit aperçu de la roadmap technique ? Guillaume Fraybin : L’industrialisation de tous nos process est le maître mot pour cette fin d’année, et à court terme nous envisageons la mise en place d’un auto-scaling horizontal. Nous travaillons également à la conception d’un outil permettant à n’importe quel partenaire distributeur de rejoindre notre écosystème. InfoQ FR : Merci Guillaume et à bientôt. Guillaume Fraybin : Merci, et à l’occasion, passez prendre un café à Euratech pour y découvrir l’écosystème d’entreprises incroyable qu’on y trouve !

InfoQ FR : En termes de déploiement et d’infrastructure-as-code, qu’avez-vous fait comme choix ? Guillaume Fraybin : Rien que du très classique du fait de notre utilisation typée IaaS, l’objectif était pour nous de pouvoir automatiser une partie des tâches récurrentes à savoir : contrôle automatique de version pour mises à jour de sécurité validées, mises à jour des configurations de composants applicatifs, déploiement automatique par couche de VM (data, métier, front) et paramétrage, upstart des applications, déploiement automatique du monitoring et des backups.

Startup Architecture

11

LIRE EN LIGNE sur InfoQ FR

Vert.x & Kubernetes chez Coursier Privé À l’occasion de Microsoft experiences ‘16, InfoQ FR a pu échanger avec Vincent Wuhrlin et Théo Bolognini de Coursier Privé sur leur architecture technique et notamment leur stack Vert.x, packagée en Docker et déployée via Kubernetes sur Azure. InfoQ FR : Bonjour Vincent, bonjour Théo, avant d’entrer dans l’architecture technique, pouvez-vous nous parler de votre service en termes métier ?

à chaque fois donc plusieurs instances du microservice. On a ensuite quatre applications qui tournent autour :

Vincent Wuhrlin : Coursier Privé est un outil flexible et modulaire qui optimise les flux de livraison au sein de son écosystème, en centralisant et en coordonnant tous les acteurs (donneurs d’ordre, entrepôts urbains et prestataires de livraisons) sur une seule et unique interface.

notre site web, qui peut aussi interagir avec ces microservices, un autre dashboard, puisqu’on a une plateforme SaaS de mise en relation, une API mobile, qui est une API spécifique aux terminaux mobiles pour pouvoir gérer les courses, un petit peu à la Uber, et enfin une API REST, qui est l’API donneurs d’ordre qui permet de commander des courses via l’application. Donc quatre applications qui gravitent autour des microservices, et qui interagissent entre elles grâce à l’Event Bus de Vert.x, qui repose lui-même sur un cluster Hazelcast. C’est l’architecture, en vue bas niveau.

Basée sur l’automatisation de la gestion d’activité, combinée à des briques de service améliorant l’expérience utilisateur, la technologie est disponible sous forme de modules à forte valeur ajoutée. Chaque acteur peut ainsi : 1. Connecter son propre réseau de livreurs pour contrôler et améliorer le service rendu à ses utilisateurs. 2. Faire appel au réseau déjà connecté à la technologie pour faire livrer ses colis. CoursierPrivé.com s’appuie sur ses propres algorithmes d’optimisation et des méthodes d’analyse big data pour apporter des solutions en temps réel aux problématiques de livraisons urbaines. InfoQ FR : Est-ce que vous pouvez nous décrire votre architecture globale ? Vincent Wuhrlin : Commençons par l’architecture fonctionnelle : typiquement, aujourd’hui, on a une architecture qui est simple, avec des microservices dans le cloud, load-balancés, avec

12

Startup Architecture

On a donc cinq applications : les microservices et composants qui tournent autour, et ces cinq applications ont des cycles de vie, comme tout logiciel informatique, différents, avec des dépendances entre eux. Ensuite, on a une architecture plus technique, qui est là plutôt liée à une technologie, Kubernetes. On a été les premiers à l’intégrer dans Azure puisque Théo travaille sur cette technnologie depuis maintenant septembre, c’était une technologie qui était à peine en 1.0 en septembre, qui était proposée bien sûr sur Google Cloud puisque c’est Google, qui commençait je crois à être sur AWS, par contre sur Azure il n’y avait strictement rien, et Théo a travaillé avec une personne à Seattle de chez Microsoft qui commençait à travailler sur la gestion native des services Azure dans Kubernetes. Théo Bolognini : Pour la petite histoire, Azure a commencé à développer ses services de conteneurs Docker en offre services avec une technologie qui s’appelle Mesos, et qui est donc l’orchestrateur de conteneurs Docker qu’Azure avait mis en avant. À la base, Azure voulait développer leur service de conteneur avec Kubernetes, mais à cause du développement qui était un peu tardif, à cause des versions qui étaient assez peu développées à ce momentlà, ils n’ont pas vraiment choisi cette voie là, et donc ça fait un peu près un an qu’il y a du travail qui est fait chez Microsoft Seattle pour intégrer Kubernetes (qui est donc un projet libre) sur Azure et permettre de pouvoir utiliser cette technologie là en mode un peu plus natif, sans avoir besoin de faire des tweaks, des hacks, des déploiements custom pour pouvoir utiliser cette technologie.

Engine comme il est développé de base. Ça permet en gros, si on revient un peu sur l’aspect applicatif, sur ces quatre applications qui marchent entre elles, nous notre objectif a été en termes d’architecture de porter ces applications et de les intégrer dans des conteneurs Docker. Toutes nos applications Vert.x Java sont intégrées dans un conteneur Docker spécifique qui va être facilement déployable sur n’importe quelle machine ayant le Docker Engine. InfoQ FR : Vous avez donc quatre conteneurs : un conteneur par application ? Théo Bolognini : Exactement. On va avoir donc un conteneur par application, un conteneur pour le Dashboard, un pour l’API, un conteneur pour les services qui nous permettent de faire fonctionner tout ça en même temps, et donc on se retrouve avec cinq conteneurs qui sont maintenus et qui sont gérés indépendamment les uns des autres. Et c’est pour ça qu’on part sur une architecture dite microservices puisque chaque application et chaque conteneur sont indépendants l’un de l’autre, et sont capables de fonctionner de manière indépendante. Il y a des mises à jour au niveau de ce fonctionnement, on peut mettre à jour un conteneur sans que cela n’impacte forcément un autre qui est dans le même environnement. InfoQ FR : Les quatre applications sont-elles toutes en Vert.x ? Théo Bolognini: Oui, et Hazelcast clusterise l’Event Bus.

Pour rester un peu sur Kubernetes, il va permettre l’orchestration des conteneurs Docker au travers de plusieurs machines, que ce soit à travers le monde, à travers des data centers, ou de clusteriser sur un même data center, et Kubernetes permet ce que ne permet pas Docker tout seul, c’est-à-dire la gestion de la communication entre conteneurs Docker sur plusieurs machines, ce que ne permet pas par défaut le Docker Startup Architecture

13

InfoQ FR : Et votre storage ? Vincent Wuhrlin : On a du MongoDB pour tout ce qui est, comment dire, données propres au métier. On a aussi de l’elasticsearch parce qu’on a une petite partie des data qui sont visualisées sur Kibana, mais plutôt exploitation ; et là on est en train de développer sur Azure une partie data plutôt métier qui sera sur PowerBI directement. Mais en tous cas, on utilise elasticsearch pour une partie Big Data et bien sûr pour un aspect recherche dans les données. Théo Bolognini : On utilise elasticsearch surtout dans le cluster. Toutes nos applications sont des conteneurs Docker, quoi qu’il arrive, MongoDB, elasticsearch, Kibana, etc. Et on utilise forcément elasticsearch dans tout ce qui est cluster, pour faire une centralisation des logs, puiqu’on va se retrouver avec énormément de replicas des mêmes applications, et elles vont toutes générer du log, et donc il va falloir qu’on aie des solutions de monitoring de logs et de centralisation. C’est pour ça qu’on utilise la technologie qu’on appelle ELK (elasticsearch, Kibana & Logstash), et donc elasticsearch va nous permettre de stocker la Data, Logstash va nous permettre de la shipper et Kibana va nous permettre de l’afficher, tout simplement. C’est vraiment une brique qui a été importante à implémenter pour faciliter l’utilisation, quand on se retrouve avec 40 replicas, c’est pas possible... InfoQ FR : Vous l’utilisez en SaaS (Elastic Cloud) ? Théo Bolognini : Non pas du tout, on a customisé les images Docker et on a créé des images Docker pour notre propre besoin en utilisant des produits Elastic, dont elasticsearch. C’est vraiment intéressant justement, avec l’environnement Kubernetes qui nous permet vraiment de clusterer des conteneurs, c’est qu’elasticsearch en production on l’a en répliqué en trois parties, c’est-à-dire qu’on a la partie Client, la partie Data qui va stocker de la Data, et on a la partie Master qui va gérer le cluster elasticsearch. Et tous ces nodes là, on peut les répliquer, les scaler, vers le haut, les scaler vers le bas, et derrière ça on a aussi des solutions de backup, là par exemple notre Data va être backupée sur du storage répliqué Azure qui va nous permettre d’assurer la pérénnité 14

des données si jamais on a des problèmes au niveau des VM, si on a des problèmes au niveau du cluster. Si quelque chose se passe mal, on a toujours la data qui est en backup de manière linéaire depuis les nodes d’elasticsearch. InfoQ FR : Vous faites donc des Snapshots sur storage, c’est bien ça ? Théo Bolognini : Exactement et même plus que ça en fait, on a un système sur Kubernetes qui nous permet de monter directement sur un conteneur Docker, et sur Kubernetes le concept appelle le conteneur Docker un pod, le pod est un conteneur Docker. Et on a la possibilité de monter un disque Azure directement sur un pod spécifique. Et donc de s’abstraire de toute problématique de montage sur la machine en elle-même, de montage sur un système de fichier spécifique, on a juste à monter ce VHD et lui, il est déjà répliqué puisqu’il fait partie du service Azure Storage, qui lui-même est répliqué dans le Data Center. Notre application écrit directement en fait, utilise ce filesystem nativement, comme un système local, mais il est répliqué et sauvegardé dans les storages Azure, ce qui est vraiment intéressant. Au lieu d’utiliser les stockages de la machine directement, on va utiliser un stockage externe déjà répliqué. Vincent Wuhrlin : Juste pour rebondir sur le système Vert.x plus event bus et Hazelcast, on a pris beaucoup de temps à stabiliser tout ça, parce que c’est encore neuf, il n’y a pas beaucoup de documentation en prod sur clusters, etc, c’est un peu dommage. Il y a des astérisques qui disent parfois “attention”, bon bref c’est un peu caché. Mais on apprécie énormément. Avant on était sur Redis, on avait une architecture master/slave dessus, là on est passé sur Hazelcast qui est un autre système avec n noeuds qui sont tous reliés les uns aux autres, il y a quand même un master mais chacun peut devenir master par un système d’élection, et du coup aujourd’hui, orchestrer un besoin fonctionnel dans le cluster, on a un besoin tout simple, par exemple on a 30 instances d’une application, si on doit en killer 20 pour réduire à 10 pour réduire notre charge, faire un verrou distribué, synchronisé pour que chaque application se locke les unes par rapport aux autres, c’est fait en vingt lignes de code. C’est ça qu’on apprécie maintenant, c’est que c’est très simple de synchroniser plusieurs instances, alors que c’est quand même des

Startup Architecture

problématiques cloud qui sont complexes. Et puis au final, là aujourd’hui on veut par exemple des microservices, on peut upscaler 40, 50, 60 instances, on peut downscaler jusqu’à zéro, là si on veut downscaler jusqu’à zéro, on va avoir des erreurs techniques sur le Dashboard, avec les microservices, on peut de nouveau upscaler jusqu’à 10, les clusters se stabilisent automatiquement à 10 et ça re-marche. On a vraiment une totale souplesse, simplement en un clic de souris, et bien sûr l’usage à terme c’est d’automatiser sa descente de charge et s’adapter aux métriques d’exploitation. Théo Bolognini : Et ce qui est hyper intéressant c’est qu’on a une scalabilité sur toute la chaîne, c’est-à-dire du front jusqu’à l’infrastructure. Pour être capable de pouvoir scaler nos machines, qui font partie de notre cluster d’exploitation, on va être capable de scaler nos conteneurs Docker, qui sont donc nos applications, et ça va nous permettre d’avoir une infrastructure qui suit les demandes aussi du front et des applicatifs au final. Ça c’est hyper intéressant. On a de l’autoscale qui est possible sur Azure, c’est vraiment pas loin car Kubernetes intègre une sorte de technologie d’autoscaling en fonction de l’utilisation de CPU de chaque node, donc on peut faire de l’optimisation CPU. Le truc étant que ça continue de se développer et que toutes ces problématiques là sont déjà gérées sur GCE par exemple, parce que Kubernetes est obligé de pouvoir le faire. Vincent : Aujourd’hui on a les métriques CPU et mémoire de l’addition de tous les pods, donc on sait en temps réel ce qui se passe, il suffit de récupérer cette API Kubernetes et d’augmenter le nombre d’instances. Théo Bolognini : En une seule ligne en fait, c’est que nos ressources Kubernetes sont définies par des fichiers de déploiement, tout simplement, et ces ressources sont dynamiques. Donc en fait un déploiement peut être édité à la volée et donc le nombre de replicas de notre application sont éditables à la volée. Donc à partir ce moment là, on peut totalement avoir un autoscaling dynamique de nos applications. Après c’est un peu dangereux parce que l’autoscaling est un peu bancal, parce que des fois il réagit mal.

InfoQ FR : Quelle est votre stratégie de construction de votre environnement Kubernetes ? Théo Bolognini : Aujourd’hui dans Kubernetes, s’il y a vraiment quelque chose de compliqué, c’est l’installation, c’est-à-dire le “bring up” sur des machines quelconques. Tous les cloud providers en fournissent, mais ce qui est compliqué c’est d’automatiser tout ça : la création des machines sur la plateforme, et l’installation de manière automatique de Kubernetes avec le master et les nodes qui s’ensuivent. Tout ça, on appelle ça le “bring up” et il y a des solutions qui existent sur lesquelles on bosse aussi en contribution parce que ce sont des projets open source. Il y en a une en particulier qu’on utilise actuellement qui s’appelle kubernetes-anywhere, et cette solution justement est développée par Kubernetes et nous permet de déployer des clusters sur Azure, mais aussi sur GCE et sur Amazon. Et donc on utilise la technologie Terraform dans cet outil là pour avoir un sampling, un templating de déploiement infrastructure, et ensuite un templating de déploiement Kubernetes. Il y a vraiment deux niveaux : l’infrastructure et ensuite Kubernetes. InfoQ FR : Vous utilisez Terraform sur Azure ? Théo Bolognini : Oui, exactement. À la base on utilisait Ansible, et on a abandonné Ansible pour Terraform, et derrière ça on utilise une image Docker custom qui s’appelle Ignition, qui va nous permettre d’automatiser le déploiement de Kubernetes sur notre cluster de machines. Ça c’est vraiment la partie qui est intéressante parce que ce petit outil est très facilement modifiable et on peut ajouter des fonctionnalités en fonction de nos besoins, comme justement le déploiement de disque dur persistant en ajout, des choses dont on aurait vraiment besoin en fonction de nos besoins personnels. Actuellement, nous, sur nos machines, on utilise des disques durs éphémères que propose Azure, toutes les machines qui sont de la série DS ou DS GS ont des disques durs SSD locaux qui nous permettent d’avoir des perfs en termes d’entrée/sortie sur le disque énormes, que ne propose pas Azure en service pur. Et donc on arrive à atteindre des 40.000 entrées/sorties

Startup Architecture

15

sur disque, qu’onne pourrait pas avoir en termes de stockage classique, et donc on a tweaké ce petit outil, kubernetes-anywhere, qui nous permet de monter sur chaque node de notre cluster, à chaque fois, ce fameux SSD éphémère, et on monte donc le coeur de Docker sur ce SSD là. Et donc toutes nos applications ont accès à ce vivier d’entrées et sorties. Vincent Wuhrlin : Ça c’est un concept un peu tordu, mais aujourd’hui on a pas trop de recul sur ça, mais on peut se dire qu’avec l’architecture à disposition des ressources (la réplication), on pourrait avoir une base de données éphémères, parce que la probabilité que toutes les machines de base de données se crashent en même temps est faible. Théo Bolognini : Le seul risque étant que si le data center se casse la gueule, là ce mécanisme ne marcherait plus. Mais il y a encore des possibilités de faire du multi clustering à travers différents datacenters qui sont de la réplication aussi et qui nous permettent encore de voir plus loin. Kubernetes permet ça : d’avoir un cluster à un endroit T, et un autre cluster à un autre endroit. InfoQ FR : Y-a-t-il dans Azure le concept de multi-datacenters dans une même région (une AZ au sens AWS par exemple) ? Théo Bolognini : Oui, sur Azure, ils appellent ça le “failure domain”, et chez Kubernetes aussi on a ça, donc lors du déploiement, nos machines sont déployées dans trois failure domains différents. Donc on a cette sécurité là. Azure fournit cette brique là, c’est-à-dire qu’on déploie des virtual machines dans un “availability set”, donc en gros ces machines là font partie de l’availability set, et en gros ne peuvent pas être mises à jour en même temps et sont toutes dans un failure domain différent, et Kubernetes aussi dans son déploiement intègre cette ressource là de failure domain. Donc on a un link entre ces deux ressources là, qui permettent vraiment d’avoir une sécurité à ce niveau là. Et on a aussi les persistent disks qui nous permettent d’externaliser la donnée sur du vraiment service Azure. Donc après si le data center tombe, on est d’accord que ça a énormément de problématiques là-dessus. Je pense qu’à terme, quand le développement du business sera important, on aura beaucoup de data à gérer, on sera répliqué à travers 16

plusieurs datacenters ce qui nous assurera une pérennité des données encore plus forte. InfoQ FR : Quels sont les plus gros avantages de Kubernetes, pour vous ? Vincent Wuhrlin : Ce qui est marrant dans Kubernetes, c’est un peu l’aspect “virus”, c’est-àdire que quand on connaît pas trop Kubernetes, souvent on arrive, on déploie un pod, si on le tue, automatiquement il se redéploie n’importe où. Il revit automatiquement. Théo Bolognini : Il y a plusieurs niveaux de gestion, c’est-à-dire que Kubernetes abstrait plusieurs concepts, abstrait le conteneur Docker en rappelant le pod, mais abstrait aussi tout ce qui est réplication en... le fait est qu’un pod est géré par un replication controller ; et donc ce replication controller dans le cluster s’assure que tu as demandé trois pods, tu auras toujours trois pods. Tu en as un qui se fait killer, le replication controller va être obligé d’en redéployer un autre, et va assurer la pérennité de ton redéploiement. Ça c’est hyper intéressant parce que ça c’est pour les conteneurs Docker, mais il y a aussi ce même mécanisme là pour tout ce qui est exposition de nos applications vers l’extérieur, le load-balancing, et le fait de pouvoir dispatcher le trafic réseau entre tous nos pods. Et ce qu’on fait, c’est que dans notre architecture, on a un load-balancer Azure en entrée, à l’entrée de notre cluster, notre balancer va prendre le trafic entrant, et lui va le dispatcher ensuite vers Kubernetes. Kubernetes en fait abstrait la couche et le link que tu as entre le load balancer Azure, et sa propre ressource de load balancer à lui. Parce que lui il a une ressource qui s’appelle le service, et le service c’est lui qui s’occupe d’attribuer des adresses IP, et de les load balancer entre les différents replicas de ton pod. Et ça en gros, ce qui est hyper intéressant c’est que l’intégration, vraiment pour avoir un exemple concret d’intégration Kubernetes dans Azure, c’est ça, c’est que dans GCE, quand tu définis un service Kubernetes, tu dis que tu veux un type load balancé. Et en gros, GCE va automatiquement sur son infrastructure, te faire un lien, te créer un load balancer, et t’attribuer une adresse publique pour ce pod que tu as voulu load balancer.

Startup Architecture

Et ça, ce n’était pas le cas sur Azure au début. Il y a donc eu une intégration de faite, ce qui fait qu’aujourd’hui maintenant quand je dis que je veux un type de service load balancé, Azure automatiquement va me fournir une adresse IP publique et va me load balancer mon application et va me créer ce lien-là. Ça, ça fait partie des travaux que fait un certain Cole (NdR: Cole Mickens) qui travaille à Microsoft Seattle, qui est en train de développer ça encore et encore. Et c’est aussi le persistent disk qui abstrait toute la problématique de montage de disque et ainsi de suite, ça aussi c’est de l’intégration native Azure Kubernetes, qui est disponible sur notre plateforme, mais qui n’était pas disponible sur Azure. Tout ça, ça répond quand même à des problématiques de base, on ne peut pas utiliser une techno comme Kubernetes si on a pas ce genre d’intégration. Mais on a eu la chance de tomber sur ce fameux Cole, par hasard sur Slack, parce que j’avais justement des problèmes d’intégration sur Azure, et on a commencé à discuter, et c’est vrai que ça a matché, et on est vraiment au plus proche du développement parce qu’on a vraiment ce contact là à Microsoft Seattle. Lui-même a été embauché dans le pôle Azure

Container pour apporter Kubernetes à Azure, et faire en sorte que les choses aillent plus vite, parce qu’Azure a compris, du moins Microsoft a compris, que Kubernetes était vraiment une brique très importante, et que Mesos reste encore trop lourd. Et avec une différence d’inertie forte. InfoQ FR : Et en termes de CI/CD (Intégration Continue et Déploiement Continu) ? Théo Bolognini : On a beaucoup travaillé pour avoir un pipeline de build et de déploiement automatisé. On utilise Jenkins, qui d’ailleurs est déployé lui-même en tant que conteneur Docker. On a même un master Jenkins qui instancie des slaves dans notre cluster, dynamiquement, selon les jobs en cours. Jenkins surveille donc les repositories GitHub et BitBucket, builde, puis pushe les images Docker construites sur DockerHub. Jenkins exécute ensuite les commandes Kubernetes nécessaires pour qu’en quelques minutes, les développeurs puissent voir leur nouvelle version s’exécuter sur notre cluster de dev. Donc intégration continue et déploiement continu.

Startup Architecture

17

Ensuite en préproduction et production, ce qui est important pour nous c’est de déployer de façon sélective. On va pouvoir dire que l’on prend le tag v0.2 sur Jenkins pour le déployer sur la pré-prod par exemple, et Kubernetes va récupérer ce tag automatiquement. Il faut garder cet aspect humain. Et tout ça apporte un confort et une flexibilité hallucinante en termes de dev. Pour info, from scratch, de vraiment zéro, on peut tout redéployer en 15 minutes. InfoQ FR : Merci Vincent et Théo et à bientôt ! Vincent Wuhrlin et Théo Bolognini: : À bientôt !

18

Startup Architecture