Dominique Clairac est architecte chez onepoint. Il accompagne les entreprises dans leur transformation numérique, avec un focus particulier autour des sujets de conteneurisation et de cloud. Ses missions alternent entre expertise technique, définition de stratégies cloud et conteneurs, et accompagnement dans la mise en oeuvre de ces stratégies. Il travaille également avec les partenaires de onepoint pour identifier les produits ayant un intérêt pour ses clients et les usages possibles de ces technologies face aux défis de demain.
CIO : De votre point de vue métier, quel état des lieux peut-on dresser en termes de processus move-to-cloud des entreprises ? Dans quelle mesure les entreprises pensent-elles cloud native aujourd’hui ?
DC : On retrouve plusieurs typologies de clients : d’un côté les petites structures en mode startup, qui appliquent de manière native les recettes agiles, le développement de microservices et le déploiement en environnement cloud. Mais cela ne représente pas la majorité des cas.
D’un autre côté, beaucoup d’entreprises ont un historique « legacy ». Sur cette seconde typologie de clients, il existe une très grande disparité au niveau de la maturité face au cloud. Certaines entreprises sont déjà dans des premières applications multi-cloud quand d’autres commencent à peine leur démarche de découplage via les API.
Pour ces dernières, si la décision d’orienter tout ou partie du SI vers le cloud est simple à prendre, le sort réservé au legacy et la manière de le gérer sont généralement plus complexes. On trouve régulièrement des applications en cours de décommissionnement long, pour lesquelles la capacité d’adaptation est forcément plus limitée. Dans ce cas, nous leur proposons de travailler sur leur stratégie move-to-cloud, en définissant d’un côté les cibles à atteindre (cloud de débordement, cloud hybride, multi cloud…) mais aussi la matrice de compatibilité des applications avec le cloud (no cloud, cloud ready, cloud native, multicloud…). Il devient alors possible de regarder, application par application, le ratio effort/bénéfice et définir ainsi sa cible cloud dans une stratégie propre à l’entreprise.
CIO : Quelles sont les bonnes pratiques pour réussir sa migration cloud et créer des applications dans le cloud ?
DC : L’architecture applicative a un rôle prédominant dans la définition d’applications pour le cloud. Il est nécessaire de bien garder à l’esprit les attentes en termes de scalabilité ou de maintenance.
Une application destinée à plusieurs milliers d’utilisateurs et déployée sur plusieurs CSP ne sera pas conçue de la même manière qu’une application avec 10 utilisateurs sans SLA. Il faut donc bien identifier la cible cloud finale de l’application (no-cloud, cloud ready, cloud native…). L’approche consistant à viser de manière systématique le niveau le plus élevé n’a pas de sens car cela entraînerait des surcoûts exponentiels. On peut facilement faire le parallèle avec le taux de disponibilité des services. Au-delà de 99,9%, chaque 9 supplémentaire après la virgule vient augmenter le coût de manière exponentielle.
Cela s’explique simplement par les moyens devant être mis en œuvre pour atteindre ce résultat (renforcement des équipes, multiplication des sites, réserve de ressources, architectures
complexes…). Lorsque le consommateur achète un service, il cherche le meilleur équilibre entre l’importance du service pour son activité et le coût qu’il est prêt à associer. Le développement cloud native suit cette même règle. On ne crée par une architecture avec une synchronisation de data sur plusieurs datacenters et un routage géolocalisé pour une application non critique visant 20 utilisateurs. Il convient donc de toujours bien identifier la cible finale de l’application, puis d’adapter la conception et le développement en fonction de cette cible.
Chaque situation est unique et doit être adaptée aux besoins et au contexte de l’entreprise, c’est pourquoi nous privilégions une démarche de co-construction, pour travailler de manière agile, avec nos clients, partenaires et prestataires, à la définition de ces cibles et à la meilleure réponse possible à leurs enjeux.
CIO : Quels sont les avantages de l’industrialisation des produits et environnements aujourd’hui ? Quels sont les problèmes de production que l’on peut rencontrer ?
DC : L’avènement du cloud avec le IAAS puis le PAAS, ainsi que l’arrivée de l’infrastructure as code dans les data center ont créé de nouvelles opportunités pour les entreprises. Il est maintenant possible à de toutes petites structures de déployer une application ouverte au monde entier, déployée sur plusieurs continents et utilisable par des centaines de milliers de personnes. Grâce à l‘open source et au cloud, ce qui à l’époque était réservé aux grandes entreprises est maintenant ouvert à tous. L‘open source contribue grandement à créer ce partage et rend accessible beaucoup de ces technologies. Le développement d’applications cloud native est souvent associé avec l’automatisation des usines logicielles (CICD), mais on peut aussi parler des systèmes centralisés de collecte et de traitement des logs, les outils de création de dashboards, les solutions de routage, l’auto scaling… Ce sont tous des outils puissants, pertinents et qui peuvent faire gagner du temps aux équipes et de la stabilité aux produits.
Le revers de la médaille, c’est que l’on se retrouve rapidement dépendant de nombreuses solutions, avec généralement des cycles de vie assez courts (3 à 4 mois), ce qui impose d’avoir des équipes formées en permanence, capables de suivre toutes les évolutions et de les intégrer sur les plateformes. On rencontre alors un autre problème lié aux plateformes, puisque les OPS doivent pouvoir tester sereinement l’automatisation des opérations, alors même que les développeurs ont besoin des plateformes hors production. Il devient nécessaire de créer des environnements « bac à sable » pour permettre aux OPS de tester leurs « développements » avant de les appliquer sur les plateformes.
Enfin, le fait de permettre de créer des ressources par un simple appel à une API masque complètement les problématiques de provisionning et de pricing. Les produits réservent de plus en plus de ressources, indépendamment de leur besoin réel. Ce phénomène n’est pas nouveau et a été rencontré lors de l’arrivée de la virtualisation, avec la facilité de création des VM, ou dans le monde des jeux vidéo, avec la puissance des cartes graphiques… La nature n’aimant pas le vide, nous avons tendance à consommer tout ce qui est à notre disposition. Heureusement, les notions de RSE et de FinOps sont de plus en plus présentes et contribuent à rationaliser l’utilisation des ressources, permettant ainsi de réduire l’impact environnemental tout en réalisant des économies.
CIO : Quelle relation entretenez-vous avec un éditeur comme Red Hat ?
DC : Onepoint est partenaire de Red Hat depuis plus de 10 ans, et partenaire premier depuis quelques années maintenant. Cette relation va même aujourd’hui au-delà du simple partenariat : nous travaillons ensemble chez nos clients et partageons notre goût pour l’expertise et l’innovation, ce qui nous permet régulièrement de réaliser des proofs of concepts autour des challenges de demain, comme ce fut le cas avec MultiPaaS ou MultiCloud.
Nous avons travaillé au fil du temps sur des offres communes qui permettent de proposer aux clients une équipe unique composée d’effectifs onepoint, Red Hat et client. Nos offres portent tant sur les aspects techniques que sur l’accompagnement au changement, qui est essentiel. Nous accompagnons les projets, tandis que Red Hat apporte l’expertise éditeur, facilite l’intégration, permet de sécuriser le dispositif et apporte une vision long-terme sur la roadmap du produit. Cela offre la possibilité d’anticiper les évolutions et de s’y préparer. Nous nous renforçons mutuellement pour offrir aux clients un accompagnement complet et durable.
L’une des plus grandes forces de Red Hat est la capacité d’adaptation de ses produits. Depuis de nombreuses années, l’ensemble de leurs solutions sont scriptables et mettent à disposition des API afin de faciliter leur intégration dans le SI. Pour des intégrateurs, cela permet d’être confiant sur notre capacité à adapter l’outil pour qu’il réponde aux attentes clients. Aujourd’hui, une plateforme comme OpenShift 4 simplifie grandement l’utilisation des composants. Elle propose un Kubernetes avec un grand nombre de fonctionnalités supplémentaires déjà pré-intégrées et supportées, comme un catalogue d’opérateurs, des mises à jour et une installation simplifiée… Ce sont autant d’éléments qui permettent aux clients de se concentrer sur les tâches qui apportent de la valeur métier plutôt qu’en support et intégration.
Comme Red Hat, onepoint croit beaucoup dans le partage de la connaissance, et nous avons créé une école, qui dispense des cours autour de cursus tels que « Architecte de la transformation », « Architecte Cloud » ou encore « DevOps Enthusiastic ». Nous pensons que le meilleur moyen d’accompagner les entreprises aux enjeux de demain passe par un accompagnement mais aussi et surtout par un partage de nos convictions et de notre expérience.
CIO : Quels d’usages / cas clients ont été les plus marquants selon vous, dans l’accompagnement et le conseil fournis, parmi vos clients ?
DC : Nous avons eu de nombreux cas d’usages assez diversifiés autour d’OpenShift, qui représente souvent un point de pivot entre le SI on premise et l’approche move-to-cloud.
Chacune de nos missions est particulière. Nous avons pu accompagner une banque centrale de la zone euro dans sa migration de Kubernetes Vanilla vers OpenShift et l’intégration de ce dernier dans son SI, et nous continuons à les accompagner autour de l’évolution de la plateforme et de ses usages.
Nous avons aussi mis en place pour Franprix une architecture cloud complète, en partenariat avec Microsoft Azure et Red Hat. Elle a pu servir de base au développement et à l’exploitation d’une application cloud native composée de micro-services pour la gestion de leurs commandes. Ce projet a permis de mobiliser nos compétences DevOps, de développer une application cloud native, et de bénéficier de l’écosystème complet Red Hat (Middleware déployé sur OpenShift) [Lire le REX].
Nous avons également accompagné BNP Paribas Real Estate sur une mise en place rapide d’une plateforme et l’adaptation de leur usine logicielle.
Même si l’on retrouve des constantes sur tous ces projets, chacun a été totalement adapté aux spécificités des clients. Cycle court ou long, partage de connaissances, déploiement rapide… A chaque fois, nous prenons le temps de bien comprendre les attentes et d’y répondre au mieux. C’est ce qui nous anime : changer de contexte à chaque mission, découvrir comment travaillent les autres, et montrer comment nous travaillons, pour mettre en place un dispositif commun le plus adapté et efficace possible.