Construire son cloud privé, c'est possible !

Je vous propose un cheminement vers un système objet de toutes les questions par les équipes IT : le cloud. L'objet n'est pas de répondre à la question de l'intérêt de construire son cloud privé mais de voir comment et par quelle étape cela est possible (*).

 1)  Quel est le sujet  ?  

D'un système centralisé permettant de consommer simplement, via une orchestration, des actions IT plus ou moins complexes de ressources comme : matériel (serveur, baies de disques, réseau ...), O/S, logiciel, middleware, container (**), applicatif ...

 Construire un cloud c'est donc mettre en place une IHM qui en appelant des API pourra agir sur l'ensemble des couches techniques dont évidemment celles virtualisées.

 2) Comme toute bonne recette, il vous faudra les ingrédients et les cuisiniers !

 Dit autrement, votre couche technique devra être de type programmable, c'est à dire disposer de mécanismes permettant de le piloter (ligne de commande, webservices). A ce jour, pour du matériel de classe entreprise, il serait difficile de ne pas ne trouver.

 Le plus difficile sera peut-être au niveau de votre équipe technique, car il faut à minima du dev front-end, back-end (clairement YAML/ JSON, Ansible/ Puppet ...) mais un aussi un Tech leader qui au départ, gérera le catalogue de services et évidemment des équipes systèmes.

 3) Le nerf de la guerre : le catalogue de services.

 Même si à proprement parler, le budget restera le 1er nerf de la guerre (surtout qu'au départ, votre équipe / projet coutera sans rien apporter ...), le second est celui de la valeur ajoutée de ce que vous allez construire.

Bref, quels sont vos clients ? Quels bénéfices vont-ils retirer ? Cela peut être multiple : rapidité, coût, capacité à accompagner un projet, qualité du service fourni ...

 L'avantage du catalogue de services, c'est qu'il vous donne aussi votre expression de besoin (et l'écart par rapport à la source : ce que vous faites actuellement).

 Faites simple : quoi, pour quoi, avec quel engagement (ex : une machine, avec variation de nombre de VM, de la RAM, et des disques + le choix entre deux versions de Linux et ce moins de 4h après la demande)

 4) Regarder ailleurs, faites vous aider !

 Ne nous leurrons pas, dès que vous parlerez cloud avec vos fournisseurs, la tentation sera forte de vendre une solution clé en main et pas nécessairement de vous accompagner dans votre propre mise en place. Le marché est ainsi fait ...

Partant de là, faites le tri parmi vos interlocuteurs. Demandez, des présentations, des REX clients. Comprenez ce qui a été possible par d'autres et qui est peut-être aussi inatteignable chez vous.

 5) Pensez grand, démarrez petit

 Évidemment, chacun voudrait pouvoir déployer, une pile applicative complète sur l'ensemble des environnements avec la répartition de charge qui va bien et la sécurité ad hoc. Hormis la containérisation (**) qui vous permettrait de tout réaliser en même temps, mieux vaut s'en tenir :

• A votre catalogue de services (la cible)
• Vos pratiques actuelles (la source)
• La partie à mettre en place qui fera gagner le plus à vos client (MVP)

5) Concevez, Modularisez, Découplez, Converger

 Même si la tentation est forte de construire un système qui traverse toutes les couches n'oubliez pas jamais que la conception d'aujourd'hui est la solution de demain.

 Évidemment, vous ne pourrez pas démarrer avec un modèle accompagnant toutes vos évolutions, vous passeriez trop de temps à démarrer (certainement plusieurs mois). Néanmoins apprenez à reconnaitre les éléments de jonctions entre deux fonctions que vous allez orchestrer.

 Rien ne vous interdira alors d'introduire du couplage mais au moins de façon maitrisé. Chaque raccourci, chaque couplage entre deux fonctions est la source d'un problème de demain (bugs insurmontable, montée de version croisées, Lock-in fournisseur ...) car un module doit pouvoir être pensé comme interchangeable.

 Pensez votre solution cloud comme une formidable machine à orchestrer ce qui existe peut-être déjà dans votre organisation : un déploiement automatique à partir d'un git, un script d'installation d'image d'OS.

 Dites-vous que, avant de remplacer tout ce qui existe, vous allez peut-être aussi faire communiquer des mécanismes déjà présents chez chacun. Accompagner donc les efforts déjà réalisés pour ce qui marche puisse s'interfacer avec votre système. Dit autrement, ne refaites pas ce qui existe, c'est contre-productif et générera de la résistance au changement, contentez-vous parfois de l'adapter.

6) Surtout, sécurisez

Bien avant de rêver à du DevSecsOps, il conviendra de ne pas fragiliser votre écosystème, car mal pensée, votre solution va être une machine à déployer de la non-sécurisation, voire pire elle sera elle-même le point d'entrée de toute attaque informatique.

 C'est le moment d'aller voir votre équipe sécurité préférée et de penser avec elle ce que vous allez construire. Appuyez sur vous des référentiels (ex : RGS de l'ANSSI) et posez les bases d'un système à minima plus sûr que celui existant.

7) Construisez avec et non pas contre

 N'oublions jamais que faire du Cloud revient à automatiser des gestes techniques. De fait, votre projet risque de générer de l'inquiétude, de la résistance auprès de nombreux profils (admin systèmes, réseaux, base de données, intégrateurs, exploitant ...) bref tout personne qui serait mal accompagnée.

 Votre "équipe" cloud doit dès le départ inclure ceux qui font, et qui on peut être déjà en partie automatiser leur travailler, pour en faire les futurs fournisseurs de votre solution. Ainsi, votre solution sera une extension de votre écosystème et non pas quelque chose à part voir à coté ...

 8) Soyez humble, patient et itérez

Bon, disons-le tout de suite, le chemin vers l'orchestration des ressources IT est pavé de nombreuses embûches. Mais avec de très bons éléments, rien ne sera fera immédiatement.

 Quelques conseils de bases :

• Évitez de positionner ce projet dans le chemin critique d'un projet SI,
• Visez la réussite, choisissez des services facilement atteignables,
• Ne vendez pas du rêve, le retour à la réalité peut être douloureux,
• Communiquez régulièrement sur ce que fait et ne fait pas la solution (une roadmap reste l'idéal)

 Et puis surtout, vérifiez en continu que la solution a une valeur ajoutée. La démarche Cloud doit être centré utilisateur (développeur, intégrateur, exploitant ...)

 8) Est ce que mon cloud va me permettre de faire du DEVOPS ?

Désolé, mais non, en tout cas pas sans effort.

Le devops est une méthode de coconstruction entre les équipes ops et dev (***) basée sur une logique itérative. Orchestrer sera nécessaire mais pas suffisant.

9) C'est bien tout cela, mais comment je démarre ?

De la manière la plus simple possible en lançant un projet (objectifs, jalons, délai, coûts ...) et en trouvant un sponsor car comme tout changement structurant il ne peut s'intégrer que dans une stratégie globale.

 Nota Bene :

(*) Le présent post s'appuie sur un REX pour un SI en milliers de VM (plus proche de 10 000 que de 1000). Je ne connais pas le seuil de VM à partir duquel l'effort devient irréaliste au regard des solutions clés en main.

Déterminer en quoi le passage à une solution Cloud public n'est pas l'objet du post. Cela pourra être un article complet à lui tout seul.

 (**) Le sujet de la containérisation (ex : Docker, Kubernetes) est plus global que le cloud puisqu'il consiste en changement de paradigme. En effet, on passe de la notion de composant applicatif installé sur un système technique globale et parfois virtualisé (VM + O/S) à celle d'un service applicatif uniquement consommateur d'un système optimisé (le container, par nature totalement virtualisé). Pour faire simple, disons que c'est le niveau au dessus de la cloudification.