En plus d’être une porte d’entrée efficace aux différents clouds, leurs configurations uniformes ainsi qu’une intégration avec leurs services respectifs sont gages de gains de temps importants pour un développeur.
Ils imposent néanmoins des contraintes qui ,dans certains cas, seront bloquantes pour un usage professionnel.
Que l’on travaille sur un cloud public ou privé le besoin d'interaction est quasiment impératif.
Les approches Gitops avec son Everything As Code, censées rendre minimal ce besoin, n'est pas réaliste dans toutes les situations.
Il faut tester les services, s’appuyer sur ces derniers lors de phases de développement, intervenir rapidement sur des incidents de productions, etc.
Plusieurs portes d’entrée existent. Les principales étant les APIs, la CLI via un cloud SDK et la cloud console. Dans un contexte programmatique l’API a du sens mais ne pourra répondre à un besoin interactif beaucoup mieux servi par un SDK et une cloud console (interface web).
Pourvue d’une interface graphique, la cloud console sera le premier choix de nombreux utilisateurs mais sera limitée vis-à-vis d’un cloud SDK plus réactif et avec la possibilité de fournir l’authentification à d’autres outils. Nous pensons en particulier à Docker, Kubectl, Terraform… Autrement dit, des outils généralement utilisés par des profils en interaction avec le Cloud. Se profile alors un environnement de développement commun avec des outils devops, de packaging et autres utilitaires simplifiant les tâches du quotidien.
Avoir une telle configuration prend du temps et doit se tenir à jour. Ce n’est pas la partie la plus productive du métier de développeur ou Ops.
Les Cloud Shells y remédient en apportant la notion de Development Environments As A Service.
Cette idée de Development Environments As A Service n’est pas neuve et est déjà portée par VSCode via son extension remote container. Une version headless de l’IDE démarrée dans un container local ou distant sera contactée à travers une interface graphique locale.
On décrit alors son environnement de développement as Dockerfile avec la possibilité de le partager/versionner via un gestionnaire de source. Nous en parlions ici. Au-delà de l’accès exclusif par le navigateur web, le Google Cloud Shell s’en démarque sur différents points.
Note: Nous accédons au Cloud Shell depuis la Google Cloud Console ou la documentation GCP. Il est nécessaire d’utiliser un compte Google pour s'authentifier.
Techniquement Cloud Shell est hébergé sur une machine virtuelle Compute Engine. La documentation n’en dit pas grand-chose mais nous pouvons avoir certains détails en interrogeant le serveur de métadonnées compute engine depuis le shell lui-même:
curl "http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true" -H "Metadata-Flavor: Google" | jq
Plusieurs points sont à noter:
Cloud Shell utilise un Container-Optimized OS qui se base sur Debian.
Il existe quelques degrés de liberté pour en adapter le contenu à son besoin comme l’installation d’outils spécifiques:
Il est possible de créer un environnement basé sur l’image Cloud Shell. Cependant, il ne s’agit pas de faire pointer le service Cloud Shell vers une nouvelle image mais de reproduire une "expérience" Cloud Shell dans vos propres environnements.
Enfin, nous sommes limités à 50h par semaine afin que ce service gratuit ne devienne pas un gouffre financier pour le provider (il s’agit de “vraies” heures et non pas d’heures VCpu).
Vous devrez attendre le renouvellement d’un quota épuisé.
Cloud Shell a pour finalité d’offrir une expérience “intégrée” à la GCP afin d’être productif dès l’ouverture de la session. Notons quelques points.
Accéder un shell interactif avec un navigateur Web pose assez rapidement le problème de collision sur les raccourcis clavier.
CTRL+W est un raccourci très utilisé tant sur un navigateur Web que sur un Shell… mais avec des conséquences différentes (la fermeture d’un onglet navigateur, ou la suppression d’un élément sous le curseur).
Chromium et ses dérivés proposent une solution en installant la Progressive Web Application qu’est le Cloud Shell. Cela ajoute un lien Desktop lié au Cloud Shell que vous accédez désormais en dehors du navigateur.
Note: Actuellement, seul Chromium et ses dérivés semble proposer cette feature.
L'environnement est provisionné avec un certain nombre d’outils et de langages.
La liste exhaustive se trouve ici et nous souhaitons en noter quelques-uns:
Il est possible de “casser” cet environnement avec sudo rm -rf /*
Forcer le redémarrage de la machine ne réglera rien, car il sera aussi bloqué (potentiellement Google interagit avec la VM avant de la redémarrer ce qui n’est plus possible au vu de la casse). Une astuce consiste à passer en mode éphémère avant de repasser en default mode.
En quoi ce type d’environnement serait-il Cloud Native, c'est-à-dire lui-même porteur de patterns adaptés au cloud et pour le cloud ?
Techniquement, le débat semble assez tranché. Une machine éphémère complètement managée et instanciée au plus proche de vous va dans ce sens.
La réponse est moins tranchée en matière d’usage.
Nous consommons une machine qui ne va pas drastiquement changer nos habitudes de travail par rapport à notre environnement local. Elle va les simplifier mais pas nécessairement les modifier.
Cloud Shell ne serait de ce point de vue qu’une version dématérialisée d’une machine physique.
Il est possible d'appréhender Cloud Shell d’une autre manière. Paradoxalement cette idée vient des limitations imposées par le type de machine provisionnée dont le stockage, mémoire et puissance de calcul sont limités.
On peut clairement penser le Cloud Shell comme un control plane de notre cloud dont chacun des services va prendre la place de notre processeur, disque dur, RAM, système de fichiers, etc.
Prenons l’exemple du stockage. 5Go est assez peu dans l'absolu. Cela convient pour de l’installation d’outils et autres fichiers de configurations mais moins quand on commence à travailler avec des conteneurs voire des projets d’envergure avec de nombreuses dépendances.
Dans ces cas, il est nécessaire de penser “out of the box” et ne pas hésiter à utiliser l’intégration offerte avec la GCP.
Prenons l'exemple du file système intégré que l'on peut étendre:
On pourra améliorer sa RAM et son compute de la même manière.
Nul besoin de lancer des builds ou applications en local à partir du moment où nous avons des feedbacks rapides depuis les services Cloud Build et Stackdriver dont un mode tail est accessible avec gcloud.
Ce sont des exemples parmi d’autres. L’idée à retenir est que la notion d’environnement de développement englobe désormais la plateforme cloud plutôt que de se fermer à un environnement local.
Au même titre que le Cloud a transformé le réseau, le stockage, le compute en services à louer, nous appliquons le même principe aux éléments de notre environnement de développement.
En raisonnant architecture applicative, l'environnement local serait au monolithe ce que notre environnement Cloud Native serait à l’approche micro service.
Il est possible de penser ainsi sur un environnement local mais c’est moins adapté et opportun. D’abord parce que l'environnement local sera à configurer pour trouver le même niveau d’intégration avec le Cloud Provider et surtout à mettre à jour régulièrement. Tout cela est déjà pris en charge dans le Cloud Shell, avec l’avantage supplémentaire de pouvoir casser sa configuration sans trop de conséquences.
On notera aussi que la qualité de la connexion internet est importante dans un tel paradigme. Avec Cloud Shell nous décorrélons la connexion domestique de celle dont nous bénéficions depuis Cloud Shell pour interagir avec les services GCP. On aura alors une expérience similaire que si nous travaillions depuis une bibliothèque municipale (qui par ailleurs pourra bloquer certains protocoles comme SSH) ou un réseau d’entreprise.
Le besoin constant d’une connexion est un élément à avoir en tête.
La réactivité du shell dépendra de la qualité de la connexion et on voit que ce type d’environnement ne pourra jamais complètement remplacer un environnement local qui s’en abstrait plus.
L’approche qui consiste à se baser sur les services managés du cloud provider n’est pas naturelle.
Il faut la mettre en place et c’est un changement d’habitude de travail qui est nécessaire.
Un consensus devra être trouvé au sein d’une équipe et/ou entreprise.
Le seul exemple de se baser sur Cloud Build pour s’abstraire des limitations de compute suppose l’hypothèse forte qu’une intégration est possible entre la plateforme d’hébergement de code et Cloud Build. Pire, que nous acceptions qu’un membre de l’équipe crée son propre remote Cloud Repository pour exposer le code à Cloud Build…
Plusieurs points appellent à ne pas utiliser ce type de service dans un cadre professionnel.
Cloud Shell est un service gratuit ne bénéficiant d’aucun SLA. On apprécierait une version professionnelle qui irait plus loin en donnant la possibilité de choisir son type d’instance, sa configuration ainsi qu’une capacité d’hébergement sur ses VPCs.
D’un point de vue sécurité, Cloud Shell pose les mêmes problématiques qu’une machine personnelle dans un réseau d’entreprise avec l’inconvénient supplémentaire de ne pas pouvoir accéder à la configuration de la machine. Tout le monde n’est pas forcément prêt à des approches Zero-Trust network et ouvrir un réseau à ce type de machine n’est tout simplement pas envisageable. Il est d’ailleurs possible de désactiver le service Cloud Shell au niveau d’une organisation Google.
On gardera en tête que l’usage du Cloud Shell s’impose comme une solution efficace pour tester ou faire des démos de produits GCP.
En ce qui concerne un usage d’entreprise, il reste encore du chemin à parcourir.
Note: Et la concurrence ?
Nous allons retrouver le même type de service chez Azure et AWS. Moins généreux en termes de quota d'usage, il n'en reste pas moins similaire sur le fond malgré l’absence d’un IDE intégré.
Nous avons défini une expérience de développement que l’on pourrait qualifier de Cloud Native à travers l’exemple de Google Cloud Shell.
Simple d’usage, économique, intégré sont autant de qualificatifs qui le rendent attrayant et plaident pour un usage quotidien.
Un changement d’état d’esprit dans la relation que nous avons avec notre environnement de développement est toutefois nécessaire pour dépasser les contraintes de ressources imposées.
Malgré ces avantages apparents, ces environnements s’adaptent difficilement à un cadre de travail en équipe et encore plus à un cadre professionnel.
Reste alors pour le développeur un usage minimaliste pour les tests et démos, domaine sur lequel vous ne devriez pas vous priver d’utiliser cet outil gratuit et performant.
Il existe toutefois d’autres approches de Development Environment As A Service. Elles offrent une vision différente et surtout des solutions aux problèmes pointés.
Une nouvelle façon de travailler en entreprise qui se profile ? C’est ce que nous étudierons dans un prochain article.
Pour aller plus loin: