Mardi 9 avril 2019 j’ai présenté une définition de Cloud Native aux HumanTalks Grenoble.

Voici une (il est possible que je n’ai pas employé exactement les mêmes formules mais le message est similaire) transcription de cette présentation.

A la fin de l’article vous pourrez retrouver le pdf à télécharger.

Cloud Native. C’est un terme qu’on entend partout aujourd’hui dans la tech. Mais qui serait capable de précisément expliquer ce que ça veut dire, quelles en sont les limites, les caractéristiques.

Souvent, dès qu’on va parler de Cloud Native on va penser à des microservices sous forme de conteneurs qui tournent dans kubernetes. Avouez, vous avez tous pensé à ça, non ?

Et pourtant, Cloud Native ce n’est aucun de ces termes.

Et si on commençait par chercher une définition.

Et ça tombe bien, il y a une fondation qui a pour but d’héberger des outils Cloud natifs

Ok, donc la définition nous dit que ça permet de créer et exécuter des applications scalables. Hum, si vous êtes plus avancés avec ça c’est super, moi pas vraiment.

Ok, ça dit aussi que ça peut tourner dans des clouds publics, privés, hybrides. Bien.

Ho ben non, j’avais dit que Cloud Native ce n’était pas des microservices, des conteneurs, etc. Je fais comment moi maintenant ?

Et si on regardait du côté de Pivotal ? Depuis des années ils ont des pages qui présentent leur vision du Cloud Native. Bon à chaque fois que j’y vais la page à changé, mais pourquoi pas.

Donc là on nous dit que du Cloud Native revient à exploiter les avantages du cloud.

Et juste après on retombe sur les microservices en conteneurs. Bien bien…

Ceci est la plus vieille définition de “Cloud Native” que je connaisse.

Au premier abord c’est logique, une application Cloud Native doit bien fonctionner dans un environnement cloud. Mais on commence à rajouter quelques précisions sur ce qu’on entend par cloud, ici on parle d’ Infrastructure as a Service.

Et si on continue la définition, on attaque un point intéressant : il ne suffit pas de s’exécuter dans le cloud pour être Cloud Native. Il faut aller plus loin.

On vient de lire trois définitions de plutôt bonne qualité, l’élément principal qu’on peut en retirer c’est qu’être Cloud Native c’est exploiter les possiblités du cloud.

Merci merci (c’est le moment où tout le monde se lève et applaudit).

Comment ça, c’est pas fini ?

Bon d’accord, on va continuer. Et d’ailleurs si on revient sur la dernière définition, il y a un point vraiment intéressant. Imaginez, la définition a aussi 9 ans…

Ce point c’est la notion d’ infrastructure as a service.

Avant les IaaS, vous aviez un (ou plusieurs) serveurs que vous bichonniez. Vous leurs donniez des petits nom, et quand ça se passait mal vous les répariez.

Avec des IaaS c’est terminé, les serveurs deviennent jetable, ont une faible durée de vie. C’est l’ élasticité.

Vous en avez besoin de plus, hop un appel d’API. Vous en avez trop, hop un appel d’API. Il en faut un plus gros, un plus petit ? Il y en a un qui est plus lent, qui n’est plus à jour et il faut le remplacer ? Hop un appel d’API.

Et au fait, pourquoi on voudrait ça ? Pour aller plus vite, pour moins cher et de manière plus fiable. Et oué.

Plus besoin de provisionner pour une consommation variable, on ne paye que ce que l’on consomme, quand on le consomme. Du matériel qui brule ? Ce n’est plus notre problème, le fournisseur s’en charge.

Ok, on y vient. Exploiter ces nouvelles possibilités, ça a justement des conséquences. Dans un hébergement traditionnel, les serveurs ne sont pas jetable, on en prend soin. Et nos applications qui tournent dessus sont relativement statiques. Mais là, on veut du dynamique de partout.

Vous l’aurez bien compris, il n’est plus question ici de fonctionner sur une seule machine. Il s’agit de pouvoir fonctionner sur plusieurs machines simultanément, et donc cela implique de changer des choses, entre autre au niveau des partages de données, fichiers, etc.

Bien évidemment il faut que votre application soit concue pour être élastique. Votre nombre de serveurs, votre nombre d’instances d’application va fréquement varier. Vos clusters doivent être dynamiques.

Dans le but de mutualiser certains coûts, il n’est plus non plus question de déployer votre application pour chaque client. Au lieu de ça vous allez créer des applications multi tenant, et héberger tous vos clients sur une seule plateforme.

De part la nature dynamique de tout ceci, vous voulez réaliser le moins d’action manuelle possible. Si vous vous basez sur une API pour gérer vos serveurs, ce n’est pas pour avoir besoin d’un humain pour lancer les commandes. Automatisation est le maître mot ici.

Avec tout ça en place, vous voulez aussi aller vers du déploiement incrémental. Déjà parce que c’est à Gilles, mais aussi parce que vous avez tout pour le faire. Fini la corvée de déployer, de gérer les serveurs, tout est automatisé. Le déploiement de votre application aussi.

Ok, c’est bien beau tout ça. Ça fait joli sur les CV, sur les articles de blog (oups) mais comment on fait en vrai ?

Et bien on se base sur un concept clé : l’idempotence

L’idempotence c’est l’idée qu’une opération a toujours le même effet. abs(abs(abs(x))) c’est toujours pareil que abs(x). C’est ça l’idempotence.

Dans ce qui nous intéresse c’est l’idée que démarrer un serveur, ça a toujours le même effet, qui est d’avoir des ressources. Si vous en démarrez 10, et que vous en démarrez un onzième, ça a toujours le même effet, vous ajoutez des ressources.

Si vous avez trois instance de votre application et que vous en démarrez une quatrième, vous avez toujours le même effet qui est que votre application est disponible. Avec plus de ressources, mais l’effet est que démarrer une fois de plus votre application n’aura pas eu de comportement différent à la quatrième qu’à la première.

Et pour ça, au niveau de notre application on va utiliser des conteneurs. Ceux-ci vont permettre de garantir que le fonctionnement, l’effet, est toujours le même, quelque soit l’instance que vous démarrez. Si l’instance démarre à partir de la même image, l’effet est le même.

Et comme on veut quand même automatiser les choses, on va se faire aider d’un orchestrateur dont le but va être de les démarrer à notre place. Self service n’oubliez pas.

Au niveau de notre infrastructure, on va s’appuyer sur des images sytèmes figées. L’idée est que chaque démarrage d’un serveur a toujours le même effet. Et donc pour ça tout est figé. Pas question d’avoir des mises à jours sur un serveur et pas sur un autre. Tout est dans l’image (tout le système, pas votre application) et toutes les machines peuvent se comporter de la même manière. Imaginez l’image système comme un conteneur identique, ça marche aussi.

Et pour organiser tout ça, on va utiliser le concept d’ Infrastructure as Code. Pas question ici d’avoir des actions manuelles. Et si en plus vous avez une solution d’IaC déclarative, avec gestion d’état, vous pouvez appliquer autant de fois que vous voulez votre infrastructure, l’effet sera toujours exactement le même : avoir votre infrastructure.

Quelques outils qui peuvent vous aider. Et oui, on retombe sur nos petits. Mais ce ne sont que des exemples.

Vous pouvez utiliser docker pour vos applications. Mais un jar peut aussi faire le job, pas de problème, tant que tout est contenu.

Kubernetes ou nomad vont permettre d’orchestrer cela.

Packer va vous permettre de définir votre image système.

Et Terraform va vous permettre de gérer toute votre infrastructure de manière déclarative.

On arrive au bout (faut pas oublier que le but était que ça rentre dans un talk de 10 minutes…)

La notion la plus importante à retenir est l’idempotence. C’est elle la clé du Cloud Native. Si vous la respectez, ça devrait bien se passer.

Faut aussi avouer que Cloud Native ça claque un peu plus qu’idempotent, non ?

Vos outils… sont des outils. Ils vous aident, mais ils ne font pas de votre application une application Cloud Native. N’oubliez pas qu’il est tout à fait possible de faire une application avec des conteneurs sur kubernetes qui s’exécute dans un cloud sans jamais ne serait-ce qu’approcher la notion de Cloud Native.

Vous noterez que j’ai soigneusement évité de parler de microservices. Les microservices ne sont ni bon, ni mauvais. Ils sont une réponse à un problème.

Extraire un composant qui a des besoins spécifiques de scalabilité (par exemple un traitement particulier qui a besoin de beaucoup plus de ressources que tout le reste) est tout à fait valable, même couplé à un bon gros monolithe.

Les microservices sont surtout un mode d’organisation et de communication, qui dépasse largement le cadre de l’application mais qui a aussi des conséquences sur vos équipes.

Il est tout à fait valable de créer une application Cloud Native monolithique ou hybride.

Si vous voulez aller plus loin que ce survol, je ne peux que vous conseiller d’aller voir cette conférence de Holly Cummins.

On est arrivé au bout, j’espère que vous aurez appris quelque chose.

Si vous voulez poursuivre la discussion, n’hésitez pas à me contacter sur twitter @crev

Si vous préférez, vous pouvez lire ces slides en ligne ou télécharger la version pdf.