Le IaaS et le PaaS sont morts, vive l’iPaaS !
TL;DR :
Kubernetes réconcilie les ops et les dev, le IaaS et le PaaS, la polyvalence et la simplicité.
Remontons un peu dans le temps.
Le IaaS et le PaaS ont été pendant la fin des années 2000 et le début des années 2010 les deux technologies qui se sont affrontés pour la domination de la production.
Elles ont une histoire et une origine pourtant bien différentes.
IaaS
Premier apparu, le IaaS est une évolution des techniques d’Ops.
Elle repose sur une automatisation extrême des opérations pour pouvoir proposer des machines à un rythme effréné.
Cette automatisation s’est également conjuguée avec la mise en place d’API pour pouvoir piloter la consommation de ressources.
Le principal représentant du IaaS est bien évidemment EC2, troisième service proposé par AWS en 2006.
Le IaaS a l’avantage de réutiliser toutes les technologies pré-existantes et permet de se concentrer sur la problématique de la mise à l’échelle.
Il n’y a pas (beaucoup) besoin d’adaptation du code des applications ou du système.
Les avantages sont en revanche assez limités : on doit toujours s’occuper des mises à jour d’OS, de leur compatibilité hardware (même si simplifié par une interface virtuelle), de la sécurité, du déploiement du logiciel, de sa configuration…
PaaS
À la philosophie diamétralement opposée, le PaaS se concentre sur les outils de développement.
Grâce à une intégration très forte dans le code et le flux de travail des développeurs, le PaaS doit fournir simplement une mise à l’échelle “automagique”.
Lancé en 2007, Heroku est sans doute le PaaS le plus connu. Mais il ne faut surtout pas oublier Google App Engine premier service fourni par GCP !
Pour pouvoir utiliser un PaaS, le développeur va souvent avoir besoin d’un SDK fourni par la plateforme, développer son code autour (accès à la base de données, métrologie, log, etc) puis pousser son code directement chez le fournisseur.
Le PaaS va alors se charger de tester, créer et déployer le logiciel sans intervention d’un “ops”.
Mais bien que très alléchant sur le papier, les inconvénients sont extrêmement forts :
- La portabilité du code n’est pas assurée d’un PaaS à l’autre :
En cas d’augmentation subite des coûts, la mise en concurrence avec un autre service n’est pas immédiatement possible.
- Le test, le débogage et la reproductibilité sont complexes :
Parce que le code est construit et exécuté dans une “boite noire”, en cas de problème, la résolution n’est pas triviale et peut se faire par simple tâtonnement (ou surtout du Stack Overflow). - Le fournisseur a accès en “clair” à tout le code :
La propriété intellectuelle peut donc être compromis.
Mais le principal défaut des PaaS est sa faible capacité à gérer les applications “legacy” ou externes (open source ou d’un éditeur tiers).
En effet l’adaptation peut être difficile (fork complexe) voir impossible (technologie ou contrat de support).
Il est donc souvent nécessaire d’avoir en parallèle une infrastructure IaaS pour toutes ces applications… limitant l’économie réalisée (obligation de conserver une équipe “Ops”).
“Frazelle-complet”
La notion de “turing-complet” est connu dans le développement. C’est la capacité d’un langage à pouvoir implémenter n’importe quel algorithme.
Pour l’infrastructure une telle notion n’existe pas… encore. J'appellerai donc ce concept “Frazelle-complet” : la capacité d’une infrastructure à pouvoir exécuter n’importe quel logiciel.
Bien que très efficace, la structure non Frazelle-complet d’un PaaS va limiter de manière très importante les usages… ce qui sera presque fatal à GCP.
À l’opposé, le IaaS est totalement Frazelle-complet… mais limite l’efficacité opérationnelle.
Après un (relatif) échec sur le PaaS et une arrivée tardive sur le IaaS (2013, 6 ans après AWS !), GCP se devait de proposer une solution innovante et adaptée.
C’est en se reposant sur l'expérience interne acquise chez Google que GCP annonce en juin 2014 Kubernetes, très vite suivie en novembre de la même année d’une première offre hébergée.
Kubernetes : Le Premier iPaaS
Kubernetes est une révolution© dans le secteur.
Totalement déclaratif, il permet via une simple description de pouvoir déployer n’importe quelle architecture logicielle, même la plus complexe !
Reposant sur la technologie des conteneurs, il est totalement Frazelle-complet !
Ce double aspect propose une caractéristique unique et créer même une nouvelle couche logique : l’iPaaS pour infrastructure Platform as a Service.
Comme je l'évoquais dans un précédent post, Kubernetes a tout d’une abstraction d’infrastructure. Il est possible de consommer des ressources matérielles et systèmes de façon transparente.
Mais il reste simple et générique à utiliser.
Kubernetes ne remplace pas votre besoin d’un IaaS, il se repose dessus pour se déployer et monter à l'échelle.
Il ne remplace pas non plus un PaaS pour des applications internes adaptées, à l’inverse un PaaS peut se reposer sur Kubernetes (comme OpenShift).
Il est donc important d’appréhender Kubernetes comme ce premier exemple d’un iPaaS, une nouvelle couche logique pour votre infrastructure :
Aussi puissant qu’un IaaS, aussi compréhensible qu’un PaaS.
