Très souvent lorsqu’on me parle de Cloud, on me parle de IaaS. C’est un aspect important mais pas le seul. Entre les différentes briques “as a Service”, les différents Cloud providers et les outils Cloud agnostique, comment faire une architecture dite Cloud native ?
Cet article n’a pas la prétention de montrer toutes les bonnes pratiques et d’éliminer certaines idées. C’est plutôt l’ouverture d’une discussion qu’on aimerait continuer avec vous pendant un entretien ou sur un stand dans une conférence ;-) ou en commentaire de cet article ou par email si vous le souhaitez !
La plupart d’entre vous vont sûrement sauter ce chapitre, après tout le Cloud aujourd’hui tout le monde connaît ! Mais c’est quoi le Cloud au final ?
Le Cloud est un ensemble de data centers, gérés par un provider qui fournit des fonctionnalités.
Certaines fonctionnalités sont à la base de toutes les autres :
Un mot sur le PaaS : c’est un ensemble d’outils qui nous permettent de déployer du code facilement et sans tenir compte des infrastructures. Tout est conçu suivant des standards et est automatisé. Le PaaS s’appuie sur les trois catégories précédentes pour son infrastructure. Certains PaaS existent en dehors du Cloud comme OpenShift - ce dernier a d’ailleurs son implémentation dans le Cloud (cf OpenShift Online). Le PaaS pourrait être vu comme l’origine du serverless : lorsqu'il n’est pas à ma charge de maintenir les instances.
Les services managés sont des services fournis par le provider pour accélérer nos développements et diminuer la maintenance. Ils sont bien pratiques : ils nous garantissent un service et évitent une montée en compétence sur des sujets particuliers que nos opérationnelles ne maîtrisent pas encore. Ces services sont par essence limités dans leur cas d’utilisation et pour un usage particulier il faudra revenir aux fondamentaux et redéployer sur du IaaS (ou du CaaS pour un cas stateless).
Une fois ce constat posé et très simplifié, il est important de changer sa vision de l’architecture.
Un terme très à la mode aujourd’hui est d’avoir une approche “lift and shift”. Si c’est une bonne idée d’un point de vue organisationnel et pour la montée en compétence des équipes, c’est une aberration technique en terme de design dans le Cloud. Trop souvent la facture est beaucoup plus chère au final car les équipes développent les fonctions déjà offertes par le provider. Par exemple une équipe réutilise le déploiement d’une instance PostgreSQL via Ansible au lieu d’utiliser une instance managée… Il faut également comparer le coût de l’infrastructure migrée à la Qualité de Service que l’on a augmenté : répartition multi-AZ, sauvegarde des instances, ...
Un des prérequis pour un passage facilité au Cloud est la bonne mise en place de la culture DevOps dans votre entreprise.
Je parle de culture DevOps mais également de culture Agile (et le respect de sa méthodologie). Vous devez être à même de profiter du Cloud pour faire évoluer vos applications et à remettre en question l’existant.
Dans un contexte où tout est éphémère, il n’est plus utile d’imaginer devoir se connecter aux instances pour déployer un serveur, de même qu’il n’est plus possible d’imaginer se connecter à une console pour créer une instance.
Il va donc falloir mettre en place plusieurs outils de la culture DevOps : l’Infrastructure as Code, la gestion de configuration et des serveurs pour orchestrer ces lancements.
Cet état d’esprit Devops additionné à la mise place de l’agilité et conjugué aux nombreux services mis à disposition par un Cloud provider vous permettront d'améliorer la qualité de vos services et la vitesse de leur évolution.
C’est une des fonctions les plus évidente du Cloud mais également la plus compliqué à implémenter dans notre définition d’infrastructure voir dans notre architecture fonctionnelle.
Un cas d’étude est la problématique suivante qui nous est soumise régulièrement : “Comment faire pour sécuriser l’accès à mes machines dans le Cloud ?”
Ce n’est pas la bonne question… en effet les instances sont toutes éphémères. Les instances applicatives doivent être dans un groupe auto-scalable et donc peuvent être détruites, les instances créées pour votre Kubernetes également. Dans un des cas où une connexion SSH doit être faite, il faut alors que les bastions n’existent que temporairement.
Les environnements de développements, de tests, de recettes et de démonstrations doivent également être éphémères.
Ce n’est pas “que” pour une question de budget. Créer des environnements vous permet également de tester votre Infrastructure as Code, votre gestion de configuration ou vos manifests Kubernetes.
Il faut également penser éphémère pour vos fonctions métiers. Par exemple une instance éphémère est parfaite pour lancer un processus de type “batch” ou encore une fonction asynchrone qui ne serait lancée que rarement par un utilisateur et qui va au delà du besoin fourni par le FaaS.
Le passage à la création d’environnements multiples doit être pensé bien avant l’infrastructure. Il faut mettre en place les bonnes pratiques du CI/CD. Dans de trop nombreux cas il existe des liens entre le SCM (git) et les environnements. Cette approche, promu par le mouvement GitOps, a l’avantage de fournir une implémentation rapide mais trouve très rapidement sa limite avec la multiplication des environnements. La multiplication des environnements est cependant nécessaire pour une meilleure couverture de vos tests !
Continuous Integration : cette étape permet de tester, construire, versionner et stocker un package applicatif ;
Continuous Delivery : c’est associer une version d’un package applicatif avec un environnement particulier.
Continuous Deployment: c’est l’automatisation du développement à la production de l’ensemble des étapes de Continuous Integration, de l’ensemble des tests possibles et de Continuous Delivery.
Respecter ces règles simples vous permettra de mettre en place des environnements en diminuant la complexité des processus.
Le Cloud peut vite devenir cher à l’usage si l’on ne se pose pas dès le début les bonnes questions sur ce que l’on attend comme qualité de service. La bonne lecture des SLAs des services fournis par votre provider vous donnera une vision des SLAs que vous pouvez apporter à vos clients.
Il vous faudra également bien réfléchir à la séparation des environnements et à une stratégie d'identification des ressources (tagging, group, env .. ) entre les équipes pour suivre le budget de chacune.
Dès le début du projet il faudra gérer les utilisateurs de votre Cloud provider. On distingue plusieurs type d’utilisateurs :
les utilisateurs de la console et des APIs du provider, ceux là doivent avoir des privilèges en lecture de préférence, de manière à ne jamais utiliser la console pour créer des éléments et donc toujours passer par des processus de création automatisés ;
les utilisateurs assurant les audits, la comptabilité et les rapports d’utilisation qui doivent être de type “lecteur” ;
les utilisateurs “techniques” permettant aux serveurs de Continuous Deployment de créer l’infrastructure en utilisant l’Infrastructure as Code. Ces utilisateurs techniques ne doivent être présents que sous la forme de “rôle” associé à des machines ;
les utilisateurs des éléments créés dans le Cloud (connexion SSH, vers Redis,...): ceux-là n’ont pas besoin d’avoir des utilisateurs gérés par le provider.
La sécurité c’est également la bonne gestion des règles de firewall et des ACL. De plus certains providers proposent l’activation de certains services pour se prémunir d’une explosion des coûts due à la scalabilité lors d’une attaque.
C’est l’architecture qui correspond le mieux aux capacités du Cloud : des services stateless et scalables associés à des données découplées.
Cette architecture est une excellente façon de promouvoir la scalabilité de vos applications et de d’adapter le coût de votre infrastructure à la demande de vos clients. Une densification de votre Système d’Information, en passant par un CaaS est un atout supplémentaire à cette approche.
Le découplage des besoins de chaque microservice vous permettra également de choisir la meilleure technologie et également le meilleure service managé pour chaque besoin.
L’utilisation de services managés peut conduire votre application à n’être installable que chez un certain Cloud provider, ce qui pose le soucis de la dépendance à celui-ci. Un autre problème souvent posé est celui de l’augmentation des tarifs. De mon point de vue la concurrence et le sens de l’histoire (brève) du Cloud indique plutôt une décroissance du prix des services de base.
Une des approches des entreprises est donc aujourd’hui d’être agnostique au Cloud c’est à dire ne pas être dépendant d’un certain provider.
C’est clairement une approche qui conduit à une impasse, à vouloir n’utiliser que ce qui est commun à deux ou trois Cloud providers, il n’est alors possible que de faire du IaaS sans tenir compte des avantages ou des particularités de chacun des providers.
Une autre approche serait d’utiliser au mieux la spécificité de chaque Cloud. Il est tout à fait possible d’interconnecter différents Clouds voir la saga ici avec Nomad pour orchestrer vos conteneurs dans ce cas ou avec Kubernetes en utilisant la fédération de clusters.
Ainsi la “bonne” question sera sûrement de savoir dans quel Cloud déployer mon service en fonction de ses caractéristiques. Vous profiterez ainsi de l’ensemble des avantages du Cloud.
De mon point de vue ce sont l’agilité et l’approche microservice qui rendent une entreprise agnostique au Cloud. La capacité à pouvoir se remettre en question et à re-développer rapidement un service qui nous pose trop de problèmes (par exemple : qui coûte trop cher) sur un Cloud vers un autre.
Une application Cloud ready c’est surtout des développeurs (d’applications et d’infrastructure), des architectes et des chefs de projet qui ont compris le Cloud. La première phase est donc la formation.
La deuxième phase est la dé-normalisation des environnements de développements. Ceux-ci doivent être soumis à des contraintes de qualité, de tests et de disponibilités mais pas des contraintes de technologie. Chaque équipe doit pouvoir utiliser le bon outil pour résoudre sa problématique.
Cela inclut forcément le test des services managés qui peuvent amener une réponse rapide à une problématique.
La troisième phase est l’obligation de tester dès le développement en mode stateless, soit sur un environnement éphémère, soit sur des conteneurs en local (avec un Traefik local ?) et avec au moins deux réplicas.
Enfin, c’est aussi le suivi des bonnes pratiques agiles car des use cases bien compris et bien documentés permettent de faire les bon choix techniques.
Enfin je vous recommande l’utilisation de The Twelve Factors pour vérifier que votre architecture et vos développements sont sur la bonne voie.
Je vous invite à découvrir ou re-découvrir la loi de Conway sur Wikipédia.
En plus des difficultés qu’elle met en avant sur l’architecture, il vous faudra en tenir compte dès le choix de la structuration de vos différents projets ou comptes chez votre provider.
Une culture à la fois Agile et DevOps vous guidera vers le choix d’équipe orienté produit et en charge de comprendre, développer et de maintenir les besoins de vos équipes métier.
Enfin dans le cadre d’une architecture microservice, le choix de votre définition d’un micro-service sera structurel pour définir la taille de vos équipes. Ce choix est une problématique complexe entre une vision métier et une vision agile où le facteur du temps de développement et de re-développement est plus mis en avant.
Le passage vers le Cloud est toujours un virage complexe pour une entreprise, quelle que soit sa taille.
Il faut réapprendre une nouvelle façon de faire, sans oublier ce qu’on a mis en place auparavant. Ce point induit une gestion du changement qui impact les personnes, l’architecture et même l’organisation de l’entreprise.
Avant même de commencer votre migration, il faut vous poser les questions suivantes : quels sont les objectifs de cette migration ? Quelle qualité de service j’attends de mon application dans le Cloud ?
Vous pourrez aussi trouver d’autres informations dans notre TechTrend Cloud.
Et surtout, n’oubliez pas de penser KISS ! Keep It Small and Simple ! Et à vos commentaires !