Canal+ troque son mainframe contre un SI Cloud

18 mois pour redévelopper le SI Distribution « from scratch »

Le DSI veut frapper fort et surtout aller vite. « Au départ, nous avons estimé qu’il nous faudrait  cinq ans pour mener à bien cette transformation. Cinq ans, c'est très long. Alors nous nous sommes donné 18 mois pour y parvenir, ce qui permet de réduire les budgets. Dans ce genre de programme, plus vous avez d’argent, moins vous êtes efficace ! »

Le projet KISS, qui signifie Keep It Simple and Smart (faire simple et rester malin) est lancé.

Nous avions mis en place la signature électronique en Afrique, mais pas en France

Pierre Houles, DSI de Canal+

Le premier enjeu de KISS est d’apporter de l’agilité au groupe. Le pari pris par Pierre Houles est de diviser par 2 le « Time to Market » de la DSI, c'est-à-dire réduire de moitié le temps de mise en production des nouvelles fonctionnalités. Un objectif plutôt conservateur sachant que le cœur du mainframe bat au rythme d’une mise à jour tous les 6 mois.

Autre enjeu, homogénéiser le SI. « Nous avions de multiples outils dédiés à certains utilisateurs, une myriade d’outils divers alors qu’in fine, lorsque vous venez souscrire à une offre Canal, que ce soit sur le site Web, au téléphone ou en boutique, il s’agit du même service. Il n’y a pas de raison que ce soit des outils différents, nous devions réuniformiser nos modèles de fonctionnement. »

Le DSI veut aussi profiter des synergies internes au groupe qui s’est largement internationalisé depuis sa création. « Ainsi, en Afrique nous sommes très présents en boutiques. Nous avions mis en place la signature électronique en Afrique, alors que ce n’était pas encore le cas en France. Il fallait que nous parvenions à avoir les mêmes outils partout et pouvoir les déployer très rapidement partout. »

Enfin, le DSI veut remettre à plat la stratégie d’externalisation de l’informatique du groupe. Cette refonte est l’occasion de repenser les process mis en place avec son infogérant et réinternaliser en partie de la compétence sur un SI qui était externalisé à 80% environ.

MongoDB, Elastic Search, Mule, HTML5 et Angular.js

Et même si ce n’est pas le moteur principal du projet, la réduction des coûts figure parmi les objectifs du projet. « Nous n’avions pas des coûts particulièrement élevés chez Canal, mais nous nous sommes fixés comme objectif de diviser par deux les coûts d’exploitation de notre outil de demain, ce qui nous permettait aussi de justifier le projet. »

Nous nous sommes intéressés au Cloud par opportunité

Pierre Houles, DSI de Canal+

Initialement le projet KISS n’est pas un projet de migration vers le Cloud mais de redéveloppement des applications mainframe, le Cloud étant une des pistes étudiées pour le déploiement.

« Nous nous sommes intéressés au Cloud par opportunité. Notre besoin n’était pas tellement la flexibilité en termes de capacité, mais c’est l’approche qui nous a intéressés. Nous nous sommes fixés cet objectif de 18 mois et nous voulions démarrer très vite. Nos équipes de développement étaient disponibles, et nous avons démarré sur le Cloud pour ne pas attendre une semaine le provisionnement des environnements de développement. Dès le lendemain, les développeurs avaient la liberté de créer, et de détruire leurs machines sur Amazon Web Services, sans passer par des intermédiaires. »

Toutes les nouvelles applications du SI Distribution ont été redéveloppées « from scratch ».

Parmi les choix techniques réalisés, l’équipe Canal+ a choisi la base de données NoSQL MongoDB, le moteur de recherche Elastic Search, Mule comme bus de données et tous les frontaux d’applications ont été développés en HTML5 / Angular.js.

« Nous avons choisi ces solutions pour être compatibles avec Amazon. C’était une contrainte que nous nous étions fixée, même si nous n’étions pas encore sûr que nous irions effectivement sur Amazon » précise le DSI.

Le Cloud s’est imposé dans le projet pour des raisons de vitesse

Plusieurs éléments vont alors militer en faveur du Cloud, notamment la maitrise des coûts, mais aussi la présence de plusieurs ingénieurs dans l’équipe de Pierre Houles qui connaissant bien la plateforme Cloud Amazon. Des compétences qui vont permettre au projet de démarrer très rapidement sur AWS.

De plus, le support de l’équipe d’Amazon France va accompagner activement Canal+ dans son virage vers le Cloud.

Alors que le projet démarre, les développeurs de Canal+ vont largement puiser dans le catalogue de services Amazon pour constituer le SI cible. Celui-ci exploite une dizaine de services, dont les instances EC2, les bases de données MongoDB et RDS, mais aussi l’équilibrage de charges Amazon ELB (Elastic Load Balancing), le VPC Peering, Elastic IP, Amazon Cloud Watch, CodeDeploy, et même l’AutoScaling d’Amazon, une fonction qui semblerait plus utile sur des frontaux B2C que pour des applications internes.

« L’AutoScaling d’Amazon était vu comme un gadget pour nous car nous n’avons pas de fortes variations de charge sur le SI distribution. Néanmoins, nous avons fait en sorte que nos applications soient compatibles avec cette fonctionnalité et, avec le recul, on s’est rendu compte que c’est très pratique pour piloter finement l’allocation d’infrastructures. »

L’équipe de Pierre Houles a aujourd’hui porté toutes les applications du SI distribution qui ne contiennent pas de données nominatives. Tous les contacts avec les clients, les frontaux pour les téléconseillers, l’API d’entreprise, une dizaine d’applications en tout. L’API Canal+ permet de séparer le back office du groupe des frontaux internes et externes. L’espace Client sollicite les Web Services de cette API de même que Free par exemple lorsqu’un de ses abonnés souscrit à une offre Canal+.

Un alpha test a été lancé fin 2014 sur une petite partie des 10 millions d’abonnés avec leurs 14 millions d’abonnements que compte le groupe dans le monde. « La date de mis en production fixée au 18 mai approchait à grand pas, nous n’avions toujours pas d’infogérant Cloud. Nous avons beaucoup travaillé pour au moins avoir une répartition des rôles entre nous et Steria ainsi que les outils techniques en place pour le 18 mai ».

L’approche Devops remet en cause les pratiques de l’infogérance classique

« 80% du chiffre d’affaires de Canal passe par ces applicatifs nous ne pouvions pas nous permettre d’avoir le moindre problème en production. Nous avions besoin de robustesse, d’engagements sur la qualité de service. Nous nous sommes tournés vers notre partenaire de l’époque, Steria, aujourd’hui racheté par Sopra, pour faire entrer ces développement Cloud dans notre contrat d’infogérance « historique ». »

Très rapidement, les deux partenaires vont comprendre que les règles de mise dans les contrats d’infogérance traditionnelle ne s’appliquent plus dans un projet Cloud - un projet fortement teinté par l’approche DevOps. « Avec le Cloud, nous avons foncé dans la mouvance DevOps. Entre la création d’une fonctionnalité et sa mise en production, tout doit être automatisé. »

Or ajouter un infogérant dans la boucle complique notoirement les choses. « Ce que nous avons proposé, c’est un portail où l’on demandait à Canal de refaire ce qu’il faisait sur Amazon, ce dont ils n’avaient absolument pas besoin » explique Vincent Coudrin, directeur exécutif de Beamap, société de conseil en Cloud Computing rachetée par Sopra/Steria en 2014. « Il ne voulait plus avoir de point d’arrêt, ne plus avoir ce guichet qui matérialise traditionnellement le passage en production. »

Canal + est passé par toutes les phases de l’externalisation

L’équipe de Vincent Coudrin a donc imaginé une solution neutre pour les équipes DevOps de Canal+. Beamap a déployé ses propres proxy dans le Data Center virtuel qu’à mis en place Canal sur Amazon, avec ses propres instances EC2 qui collectent les flux de données relatives à la supervision des composants du SI Canal+ et les données d’infogérances.

Des instances qui fonctionnent « à l’insu » des applications Canal. « Lorsqu’une application entre en production, l’équipe Canal place un Tag qui vient caractériser le groupe d’instances. Nous détectons ces instances et cela vient alimenter les bases nécessaires à la supervision. Nous sommes complètement effacés dans le process de delivery mais aussi dans la supervision. Nous récupérons les métriques automatiquement, et nous réalisons la supervision sans même être sollicité par Canal+. »

Le système fonctionne totalement à l’inverse du portail d’un infogérant classique où le client réclame une ressource parmi le catalogue de services de son infogérant et peut en bénéficier quelque temps plus tard. Ici, l’équipe Devops Canal+ déploie son service directement au moyen des API Amazon Web Services et Sopra/Steria assure l’infogérance du composant a posteriori, lorsque celui-ci est lancé. Une démarche où les deux partenaires doivent faire preuve d’une solide confiance l’un envers l’autre et surtout où les processus doivent être parfaitement rodés. « Canal + est passé par toutes les phases de l’externalisation, par l’industrialisation des processus » rappelle Pierre Houles.

« Nous avions des règles de mise en production bien définies, et cela passait par des Request, par un guichet. Or livrer une fonctionnalité dans le Cloud, ce n’est pas que livrer du code, c’est aussi de l’infrastructure. Avec les outils traditionnels, c’est compliqué. »

Le DSI souligne en effet qu’une plateforme de production dans le Cloud ne se gère pas de la même façon que des serveurs dans un datacenter. Vincent Coudrin ajoute : « En informatique traditionnelle, l’état normal du serveur, c’est de fonctionner de telle heure à telle heure. Chez Amazon, c’est différent. Le serveur peut être éteint, en surcapacité, dupliqué, avoir différents états non prédictibles et sur lesquels nous allons devoir faire en sorte que cela fonctionne 24h/24, et dire s’il y a un problème ou pas. De plus quand le client joue sur la configuration de son infrastructure sans nous demander notre avis, l’infrastructure est pilotée par l’application et non pas par nos outils de gestion d’infrastructure. »

Trouver le bon modèle économique

Restait aux partenaires à trouver un modèle économique pour évaluer au mieux la valeur de l’infogérance de la plateforme Cloud.

Si le Cloud permet de disposer d’une plateforme 24/7 sans interruption de service « par design », une telle haute disponibilité est très couteuse en termes d’infogérance et ne s’impose pas pour toutes les applications.

De même, faut-il payer l’infogérance d’instances qui ne sont que des réplicas ou des clones d’instances de production ? 

Vincent Coudrin résume la démarche adoptée entre Beamap et Canal+ pour trouver le meilleur modèle économique pour les deux partis. « Les premiers modèles étudiés étaient linéaire, avec un % sur la facture d’infrastructure Cloud pour assurer des services managés. C’est un modèle simple mais nous pouvions faire mieux et moins cher. Quant on fait de l’Autoscaling, de la résilience avec des clones, des réplicas, cela ne demande à peu près aucun effort à surveiller des réplicas. Cet « à peu près », nous l’avons chiffré. Passer de 50 à 100 serveurs ne doit pas couter deux fois plus cher. Il faut payer un cout marginal. Il faut partir de composants simples, alignés sur les patterns d’Amazon et non pas partir sur notre catalogue de services. »

Le plus difficile, c’est de faire entrer le Cloud dans votre architecture réseau [...] Il faut se faire accompagner par les bons experts

Pierre Houles, DSI de Canal+

Outre ce travail d’ingénierie financière, l’infogérant a dû s’adapter à ce nouvel environnement Cloud. « Pour le projet Canal, Sopra/Steria a formé 35 ingénieurs systèmes sur les technologies Amazon. Ce n’est pas naturel pour un infogérant où on a des spécialistes Base de données, Stockage, Réseau, OS, etc. Chacun doit être expert Amazon Web Services. Le Cloud, ce n’est pas de l’infrastructure, ce n’est pas de l’applicatif, mais c’est les deux. Pour le monitoring, il a fallu faire collaborer les équipes de Canal avec les équipes Sopra/Steria, et de la même manière avec les équipes d’Amazon. » 

Le nouveau SI « Distribution » du groupe Canal+ est en production depuis le 18 mai et l’agilité attendue est, semble-t-il, au rendez-vous « nous réalisons aujourd’hui deux releases par mois, et nous montons des correctifs tous les deux jours. La tentation est grande aujourd’hui de vouloir tout corriger, tout mettre en production très rapidement. On doit prendre du recul là-dessus et trouver le bon équilibre. »

Actuellement ce SI s’appuie sur 500 instances Amazon, avec une variation de charge de l’ordre de 20%. Il est encore trop tôt pour le DSI de tirer des conclusions définitive sur les gains en termes de coûts et d’efficacité de la nouvelle plateforme, mais celui-ci cite une petite anecdote. « Il s’est passé quelque chose d’incroyable dans le cadre de ce projet, c’est qu’un jour AWS nous a communiqué qu’ils allaient baisser leurs prix. Je n’avais jamais vu ça de ma vie de DSI ! »

Néanmoins, Pierre Houles souligne : « Tout n’est pas rose non plus. En termes de sécurité, une fois que vous mettez un pied chez Amazon, que vous ouvrez une API vers l’extérieur, il y a un risque de sécurité. Il faut se faire accompagner par les bons experts. Mais les avantages du Cloud compensent largement les risques. Le plus difficile, c’est de faire entrer le cloud dans votre architecture réseau existante, c’est un travail assez important à ne pas sous-estimer et dont il faut penser dès le début du projet. Enfin, les machines que nous utilisons sont en Ireland, ce qui représente un temps de latence de 20ms, ce n’est pas énorme mais ça s’est vu. »

L’enjeu pour Pierre Houles est de poursuivre la modernisation du SI Groupe sur les autres applications mais aussi aller plus loin sur l’innovation avec les autres directions techniques, sur la numérisation et sur le moteur de recommandation, pour rivaliser avec les meilleurs du secteur, y compris sur le plan technologique.