Aperçu
Améliorer l’agilité de l’entreprise en migrant vers le Cloud
Améliorer le time to market des unités commerciales
Apporter un soutien en matière de sécurité
Le challenge
Avec plus de 8 000 collaborateurs et 500 boutiques, Bouygues Telecom s’efforce de fournir à ses 20,5 millions de clients un accès facile aux meilleures offres en matière de technologie numérique.
Afin d’améliorer le temps de mise sur le marché des unités commerciales et d’apporter de la valeur à la fois aux clients et à l’entreprise Bouygues Telecom, une transformation numérique sous la forme d’une migration vers le Cloud était cruciale.
La solution
Devoteam a apporté une valeur ajoutée à Bouygues Telecom grâce à plusieurs facteurs. Le premier consistait à fournir un soutien dans l’élaboration d’une stratégie sur la manière d’introduire ce changement monumental.
Le second était d’ordre opérationnel. Ce changement s’est produit par la migration du portail de vente. Il a permis de réduire de 50 % le coût total de possession, grâce à la facturation à l’usage et à l’augmentation de la vitesse et de l’évolutivité.
Témoignage client : Maël Louvet
Quelles sont les grandes étapes de votre migration vers le cloud ?
En 2017, une étude comparative a été réalisée pour comparer une évolution vers OpenStack avec une évolution vers le cloud public. Suite à ces études, il a été décidé de basculer un asset significatif sur AWS, le portail ventes bouyguestelecom.fr.
Suite aux enseignements tirés de cette migration, Bouygues Telecom a lancé un programme GoToCloud visant à migrer 50% des applications pérennes et critiques sur AWS en 3 ans. Cet objectif a été atteint en 2,5 ans.
Depuis que ce seuil a été atteint, la migration n’est plus systématique. Nous migrons uniquement les applications qui vont bénéficier pleinement du Cloud. C’est une approche dite “best of breed” où l’on migre sur le cloud quand on sait justifier la valeur apportée en termes de QoS, suivi des coûts, et surtout scalabilité et agilité des déploiements.
Quel est l’arbre de décision pour décider du mode d’hébergement d’une application ?
Nous sommes dans une stratégie multi cloud hybride assez ambitieuse :
- On premise avec 3 data centers
- Cloud chez AWS (principal fournisseur)
- Cloud chez Google (principalement sur BigQuery et Firebase)
- Azure (principalement sur Office365)
- IBM (principalement sur Watson Studio)
Il n’y a pas d’arbre de décision forgé dans le marbre mais en revue d’architecture, nous revoyons différents critères comme les ressources requises, l’urbanisation, la consommation de ressources ainsi que les aspects sécurité et règlementaire, ce qui nous permet de choisir.
Où réside la complexité du multi-cloud ?
Il convient d’adopter une approche itérative. Il faut d’abord maîtriser une première plateforme Cloud (pour nous AWS) ainsi que tout l’outillage associé (CI/CD, observabilité,…) et y atteindre une masse critique.
Ensuite, on est en mesure d’utiliser d’autres services sur d’autres fournisseurs Cloud.
Bien évidemment, cela nécessite des compétences, une maîtrise des interconnexions et une validation de cette stratégie en COMEX IT.
Quels sont les pré-requis à l’adoption d’une approche multi-cloud ?
Dans un premier temps, il est indispensable de bien maîtriser ses déploiements applicatifs. Il faut également avoir des équipes suffisantes qui maîtrisent l’agile et qui soient dans une approche produit. Il faut également avoir une bonne idée sur l’urbanisation du SI cible.
Néanmoins la stratégie métier peut imposer une solution : par exemple, le fait pour Bouygues Telecom d’adopter des box Android a contribué à renforcer le partenariat avec Google.
Avec votre niveau de maturité, est-ce que la “décarbonisation” devient un sujet ?
Elle est abordée à deux niveaux :
- Au niveau marketing
- Au niveau infrastructure en liaison avec le FinOps pour consommer des ressources au plus juste. On s’appuie sur les différents fournisseurs Cloud au niveau des scopes 1 et 2. En France, c’est plus facile car, avec le nucléaire, une bonne partie de l’énergie consommée est décarbonée.
A propos des scopes
Généralement, on emploie les mots scope 1, scope 2 ou scope 3 dans le cadre de bilan d’émissions de gaz à effet de serre (GES) d’un produit ou d’une organisation. Le bilan GES sert à déterminer combien de gaz à effet de serre sont émis lors de la fabrication d’un produit, ou au cours des des activités d’une organisation sur une période donnée.
Par exemple, si l’on cherche à connaître les émissions de gaz à effet de serre générées par un produit, on mesure ces émissions en trois niveaux distincts :
Scope 1 : les émissions directes
Scope 2 : les émissions indirectes liées aux consommations énergétiques
Scope 3 : les autres émissions indirectes
Comment on pilote sa facture Cloud ?
La facture est pilotée avec les outils natifs des cloud providers. Sur AWS, avec Cost Explorer et en complément : QuickSight, Athena et Glue.
Cela nécessite une bonne connaissance du SI, un tagging automatisé dès le déploiement des ressources, et de fortes interactions avec les MOE et les métiers.
Par exemple, sur le site Bouygues Telecom Entreprises, nous avons réussi à optimiser la facture de 10% sur la dernière mise en production avec un travail étroit avec les métiers, les équipes de développement et le webmaster du site.
FinOps : est-ce un rôle au sein de l’organisation ou une compétence ?
Pour Bouygues Telecom, les deux :
- Un rôle avec une équipe centralisée de trois personnes
- Une méthode de travail pour optimiser les coûts de manière collaborative.
Nous avons accéléré le “showback” vers le métier et les équipes de développement. Aujourd’hui nous avons une parfaite connaissance des coûts d’une application ce qui amène à une prise de conscience et permet les décisions d’optimisation.
Il n’y a pas encore de “chargeback”. Cela nous permettrait de responsabiliser encore plus les métiers et les équipes de développement. Mais aujourd’hui, nous avons une équipe FinOps centrale et nous pensons que c’est plus efficace qu’une stratégie “périmétrique” et, en particulier, cela limite les effets d’aubaine ou effets de bord et la perte de vue des gains au niveau de l’ensemble du SI.
Les différentes entités se sentent acteurs et concernées. Bien sûr, on a souvent à arbitrer entre :
- Un design/déploiement plus rapide et moins optimisé
- Un design/déploiement plus élaboré, moins rapide mais plus optimisé
Est-ce que vous avez la capacité de revenir sur des architectures en production pour des raisons FinOps ?
Les métiers sont, en général, ouverts à la discussion, tant qu’il n’y a pas d’impact sur la production et sur les performances de l’application.
Bien sûr, c’est mieux s’il on peut anticiper au niveau du design initial mais une transformation majeure est possible (changement de moteur de base de données, transformation de serverless vers architecture plus “monolithique”, etc.).
Le pré-requis est :
- Une agilité et une chaîne CI/CD qui permettent les déploiements sans interruptions de services
- Des applications stateless
L’optimisation FinOps de l’application fait partie de son cycle de vie.
A propos des applications Statefull/Stateless
Quels indicateurs utilisez-vous dans votre pilotage FinOps ?
Trois niveaux d’indicateurs sont utilisés :
- La facture globale AWS (en liaison avec l’Enterprise Discount Programme : EDP)
- La consommation des comptes (en production et en banc de tests)
- Les coûts IT4IT (Transfert réseaux, NAT Gateway, Firewall, …) : tous les coûts indirects non liés à une application
Avec en compléments, les indicateurs classiques de
- Couverture des instances réservées
- Utilisation des instances réservées
Y a-t-il un relais FinOps au niveau des MOE ?
Les relais les plus naturels sont les architectes techniques et logiciels car ils sont les plus conscients des enjeux et les plus pertinents sur la mise en œuvre des optimisations.
As-tu des bonnes pratiques FinOps à partager ?
Par rapport à celles qui nous ont le plus apporté, je citerai :
- Sur AWS
- Privilégier l’utilisation d’instances Spot (l’effet induit, c’est que cela renforce la réflexion sur des architectures stateless)
- Utiliser les savings plan
- Arrêter et démarrer les environnements de tests uniquement lorsqu’ils sont nécessaires.
- Sur Google
- Utiliser le “flat rate” sur BigQuery
A propos des instances spot
Les instances Spot Amazon EC2 vous permettent de profiter des capacités EC2 non utilisées dans le cloud AWS. Elles sont disponibles avec une réduction allant jusqu’à 90 % par rapport aux tarifs des instances à la demande.
Vous pouvez utiliser les instances Spot pour diverses applications statiques, tolérantes aux pannes ou flexibles comme le Big Data, les workloads conteneurisés, le CI/CD, les serveurs web, le calcul haute performance (HPC) et les workloads de test et de développement.
Vous devez mettre en veille prolongée, arrêter ou mettre un terme à vos instances Spot en à peine deux minutes lorsqu’EC2 a besoin de récupérer la capacité utilisée.
Quelles sont les limites du FinOps ?
Quand on est en mode projet, il faut arriver à trouver de la capacité des équipes pour travailler sur les chantiers d’optimisation.
Les possibilités d’optimisation sont liées aux mécanismes mis à disposition par les fournisseurs cloud.
Les opérations d’optimisation peuvent être parfois limitées. Il est important de bien intégrer l’impact de l’optimisation sur les limites.
Y a-t-il une volonté ou un souhait d’utiliser des outils tiers pour le FinOps ?
Pour l’instant, il n’y a pas encore de volonté au niveau Bouygues Telecom. Les outils tiers FinOps sont déconnectés du fonctionnel et il n’y a pas réellement d’intérêt à faire de comparaison cross-cloud, car le fait de transférer un service d’un fournisseur à un autre n’est pas uniquement lié au coût du service mais à d’autres éléments comme la maturité des équipes, le niveau de maturité du service lui-même,…
Le fait d’avoir un outil tiers peut se révéler intéressant en fin de phase de lift and shift pour optimiser le dimensionnement des ressources consommées, mais, par rapport à la maturité actuelle de Bouygues Telecom, il est difficile d’identifier une valeur ajoutée à mettre en regard des coûts induits.
Tes préconisations sur la démarche FinOps ?
Le facteur clé principal de succès est de se rapprocher des métiers et de comprendre les usages de l’application. Il est important de récupérer ces éléments en amont pour concevoir l’architecture la mieux adaptée et la plus optimisée plutôt que d’avoir à faire du refactoring ultérieurement.
Etre pragmatique : constater des dérives sur une application, identifier et mettre en place les solutions d’optimisation puis définir les patterns que l’on est en mesure de reporter sur d’autres applications qui utilisent les mêmes services.
Est-ce que le cloud est encore un vecteur d’innovation pour Bouygues Telecom ?
Bouygues Telecom a acquis un bon niveau de maturité en termes d’automatisation, cybersécurité, standardisation et n’évoluera plus beaucoup sur ces sujets.
En revanche, sur des sujets comme le “serverless”, le “service mesh”, nous avons encore une marge importante d’innovation.
Quels sont les facteurs de succès d’une démarche cloud hybride ?
Avoir un fournisseur principal et limiter les périmètres sur les autres fournisseurs là où les services sont uniques, ou ont une réelle valeur ajoutée et pas uniquement pour des soucis de réversibilité ou de limiter la dépendance à un fournisseur. S’il y a des chevauchements de périmètre, les critères de choix deviennent plus complexes et difficilement compréhensibles de l’ensemble des équipes.