Cette année, je fais vraiment du cloud

Le cloud est malheureusement mal approché d'une manière générale car non adressé au bon niveau. En effet, celui-ci est généralement confié aux infrastructures alors qu'il serait plus pertinent que les études soient fortement impliquées. Voyons pourquoi.

Le cloud est au centre des discussions chez les DSI mais j’ai remarqué que des notions sont galvaudées, des raccourcis sont faits. Cela amène hélas à de mauvaises décisions. Rassurez-vous, rien de tragique et nous pouvons y remédier. 

En effet, le discours du cloud est généralement porté par les divisions infrastructure chez les ESN et l’exploitation (donc l’infra également) chez les clients. Réunissez deux personnes qui parlent le même langage et qui ont le même métier, elles vous apporteront une solution qui est en parfaite adéquation avec ce qu’elles connaissent déjà. Et c’est là que le bât blesse. Je m’explique. 

Si nous remontons aux origines de la philosophie DevOps (autre mot galvaudé qui apporte de la confusion mais non, ce n’est pas une méthode, c’est un état d’esprit), les Ops (opérations) sont réticentes au changement car celui-ci implique potentiellement un risque d’instabilité, ce qui est contraire à leur mission (assurer un bon fonctionnement). De ce fait, nos équipes infrastructure voient dans le cloud un énorme data center en le regardant sous le prisme du IaaS (Infrastructure as a Service). Elles proposent donc une migration d’un data center (le vôtre ou chez un hébergeur) vers un autre. L’approche est celle du Lift & Shift, où vous remplacez une machine virtuelle pour une autre, et cela en masse. Où se trouve le gain ? Je mets volontairement à part l’approche Capex (votre data center avec amortissement) vs Opex (chez un clouder en récurrent) car, même si cette partie est tout aussi intéressante, elle n’est pas le centre de mon propos. Pour résumer, vous avez pris en charge une migration de x machines virtuelles pour en reconstruire x autres, à laquelle vous avez ajouté les coûts de réseau (virtual gateway et autres), que vous n’aviez pas auparavant. Sachant qu’en réalité vous n’éteindrez jamais vos VMs, vous ne faites pas d’économies réelles, voire vous augmentez vos dépenses. Vous avez en revanche l’assurance d’une disponibilité matérielle fournie par le clouder. 

Alors, pourquoi cet engouement vers le cloud et pourquoi devez-vous y aller ? 

Revenons aux basiques. Informatique veut dire "relatif au traitement de l’information". Pour cela, nous avons deux grandes familles : l’infrastructure qui permet le transport de cette information et l’applicatif qui permet le traitement et l’affichage de cette information. Qu’est-ce qui importe donc à l’utilisateur ? Ce qu’il voit ! L’utilisateur final est sensible à la pertinence des informations présentées, l’ergonomie de celles-ci et la vitesse d’acquisition / traitement de ces demandes. Pour lui, peu importe ce qui se trouve "dessous". C’est comme un véhicule. L’utilisateur lambda va regarder le confort, l’équipement, s’il se sent en sécurité dans son nouveau véhicule. Il ne va pas regarder les détails de conception du moteur du moment que celui-ci rende le service qu’il attend, en général consommation modérée et puissance délivrée suffisante. 

Vu ainsi, vous comprenez que l’infrastructure sous-jacente de vos applicatifs est certes importante mais n’offre pas de réelle valeur ajoutée. Pourquoi donc ne pas confier cette partie totalement au clouder ? Sur du IaaS, c’est à vous de dimensionner vos VMs et les maintenir : update d’OS, patchs de sécurité, anti-virus, etc. (le provider ne prend en charge que le matériel). En passant une catégorie au-dessus, vous vous affranchissez de tout le bas-niveau pour ne vous concentrer que sur le plus important : votre applicatif. Cette solution existe, elle s’appelle PaaS (Platform as a Service). Dans cette configuration, vous n’avez la main que sur la partie supérieure des éléments, mais celle qui vous intéresse. Prenons un exemple : une base de données Microsoft SQL sur Azure (le principe est le même pour les autres clouders tels Amazon AWS ou Google GCP). Avec une approche IaaS, vous montez votre VMs (ou vos VMs et faites un cluster), configurez l’OS, installez le serveur applicatif SQL et dimensionnez ce dernier (RAM consommée sur le serveur, etc.) et, ensuite, vous paramétrez la base de données en tant que telle (schéma, procédures stockées, etc.). Le dimensionnement réalisé est basé sur l’usage que vous estimez au maximum. Vous avez donc plus de puissance matérielle que nécessaire au quotidien pour vos besoins. Avec une approche PaaS (SQL Online), vous n’avez accès qu’à la dernière partie évoquée lors de la description du IaaS : le paramétrage de la base : schéma, procédures, triggers et autres. Tout le reste est dimensionné et géré par le cloud provider ! Mieux, vous pouvez mettre des déclencheurs qui ajusterons à la hausse ou à la baisse le dimensionnement de l’infrastructure sous-jacente de manière automatique et extrêmement rapide (quelques secondes à quelques minutes en fonction du service PaaS consommé). 

Cela vous apporte de l’élasticité, une justesse du prix car vous ne payez que ce que vous consommez sans surdimensionnez "au cas où" et vous ne vous souciez plus de toute la maintenance (patchs, montée de version, etc…). C’est là que vous faîtes des gains. De plus, vos équipes sont concentrées sur ce qui a le plus de valeur aux yeux des métiers, la présentation et le traitement de l’information, des données. 

Il existe des couches différentes avec le CaaS, FaaS, etc. Le principe de dimensionnement infrastructure reste toujours le même, à la charge du clouder. Il est le propriétaire du DataCenter et il est le seul à pouvoir jouir de son matériel comme bon lui semble pour proposer une mutualisation intéressante pour tous, tout en respectant, bien évidemment, la sécurité d’accès aux données, ce qui est le nerf de la guerre. 

Au travers de cette chronique, j’espère que vous ne ferez plus l’amalgame entre un hébergeur et un clouder et aurez saisi la profonde différence de service apportée, pour peu que nous allions sur des couchez « hautes » du modèle du cloud. Quant à la dernière couche, la plus évoluée et façonnable, ne serait-ce pas celle du Low-code ? 

En 2021, faisons tous "vraiment" du cloud !