Quand la baie reste

La question n’est pas si, mais quoi

Il y a dix ans, « part-on dans le cloud ? » était encore une discussion. Ce n’est plus le cas : messagerie, documents, collaboration et la plupart des applications métier tournent mieux et moins cher dans un service cloud que sur un serveur dans un local. Cette partie est tranchée.

Reste le reste, et c’est exactement là que s’arrêtent les conseils standards. Un environnement de production, une application d’un éditeur sans version cloud, un système qui doit dialoguer avec des équipements du même bâtiment. C’est le sujet de cet article.

Quatre raisons pour lesquelles la baie reste

Nous rencontrons réellement ces quatre-là, et toutes les quatre se justifient.

• L’application ne bouge pas. Un éditeur sans version cloud, ou une version à laquelle manquent des fonctions que vous utilisez. Ce retard n’est pas le vôtre mais le sien, et on ne le contourne pas. Nous construisons alors un environnement que vous pouvez continuer à gérer jusqu’à ce que l’éditeur suive.
• La liaison ne suit pas. Gros fichiers, travail de conception, montage vidéo, ou un site où la liaison disponible n’est tout simplement pas assez bonne. Le calcul est vite fait : traiter en local et ne déplacer que le résultat.
• Il existe une exigence sur l’emplacement des données. Parfois réglementaire, plus souvent contractuelle avec un client. Si vous devez pouvoir désigner le bâtiment où se trouve quelque chose, c’est une exigence ferme et non une préférence.
• La charge est lourde et constante. Le cloud facture à l’usage, ce qui vous avantage quand l’usage fluctue. Pour un système qui fait la même chose vingt-quatre heures sur vingt-quatre, ce calcul bascule souvent dans l’autre sens.

Trois raisons qui n’en sont pas

Et voici les trois que nous entendons au moins aussi souvent, et qui n’en sont pas.

• « Nos données sont plus sûres chez nous. » En général non. Une grande plateforme cloud dispose d’une équipe de sécurité plus nombreuse que toute votre organisation. Ce qui est vrai : avec du matériel en propre, c’est vous qui décidez qui y accède, et c’est un autre argument que la sécurité. Appelez-le par son nom.
• « On vient juste d’investir. » Compréhensible, mais c’est une raison d’attendre et non de rester. Nous planifions alors le passage au moment où le matériel devra être remplacé de toute façon. C’est du calendrier, pas du report.
• « Ça marche. » Vrai jusqu’à ce que ça ne marche plus. La question est de savoir si vous connaissez la fin du support et ce qui se passe alors. Si personne ne le sait, « ça marche » est une hypothèse et non un état.

Ce que le matériel en propre implique

Si une baie reste, la marque n’est pas la partie intéressante. Nous fournissons et gérons notamment HPE pour les serveurs et le stockage, et côté virtualisation nous travaillons avec VMware, Nutanix et Proxmox. Quelle que soit votre marque, cela va avec :

• Une surveillance qui alerte d’elle-même. Un disque qui lâche dans un ensemble de quatre n’est pas une panne. Un deuxième disque qui lâche parce que personne n’a vu le premier, si.
• Pièces et délais convenus. Pas « on commandera », mais fixé à l’avance en combien de temps une pièce peut être remplacée, et si cela tient dans votre durée de reprise.
• Une date de fin que vous connaissez. Le matériel a une durée de support. Nous la notons le jour de l’installation, pas l’année où elle expire.
• Un plan de reprise qui n’a pas besoin du bâtiment. Voir ci-dessous ; c’est là que cela échoue le plus souvent.

Le plan de reprise fait la vraie différence

Cloud ou matériel en propre change peu de choses à une journée normale. Cela change tout le jour où quelque chose casse.

Avec un service cloud, la question est : en combien de temps le fournisseur revient-il, et que dit le contrat. Avec du matériel en propre, la question est : où continuez-vous à tourner si ce bâtiment est indisponible. Une sauvegarde rangée dans la même baie que le serveur protège d’un disque en panne et de rien d’autre.

Nous convenons donc par système de la durée d’indisponibilité tolérée et du travail que vous pouvez perdre, et nous testons la reprise dans un environnement reconstruit à partir de rien. C’est un autre test que « le fichier revient-il », et il produit plus souvent des surprises.

La façon dont nous le consignons et le démontrons figure sous sauvegarde et continuité.

Comment nous faisons le choix

Nous n’avons pas de préférence arrêtée d’avance, et ce n’est pas de la modestie : c’est la seule façon de donner un conseil qui tienne encore dans trois ans. En pratique, cela se passe ainsi.

• Nous regardons d’abord quels systèmes existent et ce dont ils ont besoin, pas où ils tournent aujourd’hui.
• Pour chaque système, nous plaçons les quatre raisons à côté. Si aucune ne s’applique, le cloud est le point de départ.
• Là où le matériel reste, nous planifions le remplacement pour le moment où l’équipement actuel arrive de toute façon en fin de vie. Remplacer du matériel qui fonctionne parce qu’un plan le dit coûte cher et rapporte rarement.
• Le résultat n’est presque jamais tout ou rien. La plupart des organisations finissent avec une partie dans le cloud et une partie dans la baie, et c’est très bien tant que vous pouvez expliquer pourquoi pour chaque partie.

La migration et la gestion quotidienne figurent sous services cloud et infogérance.