Ami du jour, bonjour !
Le modèle classique
Cela fait plusieurs années à présent que je travaille pour des grandes entreprises à automatiser la livraison d'infrastructure pour les équipes applicatives.
Tous ceux qui ont travaillé sur le sujet ont déja vu ce type de schéma qui explique la livraison du IaaS, PaaS et SaaS (je ne parlerai pas ici du CaaS ou du FaaS, c'est un tout autre sujet).
Livraison d'applicatif complexe OnPrems
Bien que cette répresentation soit exacte, elle n'est cependant pas représentative de la réalité terrain que l'automatisation apporte ainsi que du modèle OnPrems.
OnPrems, c'est fini aujourd'hui me direz vous, le futur c'est le Cloud ! Hummm non, pas pour tous !
Le Cloud est formidable et permet des économies majeures, mais pour de nombreuses grandes compagnies (comme les banques), il ne peut pas répondre à tous les besoins (entre autres pour des questions légales).
Plusieurs équipes vont donc être imputables de la livraison. On peut distinguer au moins quatre intermédiaires :
- Matériel et virtualisation
- Os
- Middleware
- Application et données
S'il est facile d'identifier que le premier intermédiaire livre du IaaS, que dire de ce que livre le second ? du PaaS ?
PaaS or not PaaS, that is the question
Dans le cadre d'un PaaS, on s'attend à ce que le Middleware soit géré sans égard pour l'applicatif ou les données. Ainsi un PaaS va naturellement faire évoluer ces versions et forcer ses consommateurs à se mettre à jour.
Dans un PaaS on va essayer de limiter au maximum le nombre de versions offertes aux utilisateurs.
En outre, dans le cadre d'un PaaS, les mises à jour des couches Middleware et Os se font indépendamment des couches d'applicatif.
Hors, dans le cadre des grandes entreprises, cela ne peut absolument pas être le cas ! Le travail doit être fait en collaboration, et les équipes chargées de la livraison de l'applicatif doivent être impliquées dans la livraison des couches inférieures.
Pourquoi le modèle est insuffisant ?
Le modèle présenté ci-dessus est insuffisant parce que les compagnies qui utilisent un modèle OnPrems doivent aujourd'hui automatiser toute la chaîne de montage.
Si on pouvait s'entendre que la premiere équipe va effectivement livrer un IaaS à la seconde équipe, comment peut-on appeller ce que va livrer la seconde équipe à la troisième ?
Nommer cela un IaaS est très limitatif, appeler cela un PaaS démontrerait l'incompréhension du modèle PaaS puisque ce n'est pas un vrai PaaS. J'ai vu certains désigner cela un IaaS+... pourquoi pas un PaaS- ou bien un IaaS+-PaaS=PIaaS ?
Et l'automatisation là-dedans ?
Justement, parlons d'automatisation à présent !
S'il y a dix ans, nous avions effectivement une claire séparation entre les étapes et les équipes, aujourd'hui les outils d'automatisation permettent d'avoir des livraisons bout-en-bout d'applicatif fonctionnel qui repose sur une stack complète.
Chaque équipe devient donc responsable de livrer une automatisation de sa partie qui doit répondre au besoin de l'équipe précédente et suivante de façon à former un tout cohérent.
En outre, il faut, dans le modèle actuel, prendre conscience que la sécurité est fondamentale et doit représenter une étape à elle seule.
J'en arriverai donc à décrire un modèle AaaS (Automation as a Service) où les autres étapes ne sont principalement que des sous-étapes.
Le modèle AaaS
L'automatisation est au coeur de ce modèle, et les outils actuels permettent de mettre techniquement cela en place. De plus, cela permet d'appliquer les concepts du DRY (Don't Repeat Yourself).
Dans un prochain article, nous parlerons d'un exemple de chaînage des outils pour livrer un AaaS de qualité.
