Sommaire
Faisant partie de tout déploiement sur le cloud, les services managés sont très appréciés pour leur facilité de mise oeuvre, pour la réduction du time to market et la simplicité d'utilisation. Plus besoin d’être un expert de bases de données pour installer en quelques minutes, un serveur PostgreSQL répliqué sur plusieurs zones de disponibilité, avec du failover et des backups automatiques. Tout est géré par le cloud provider, les Ops se dégagent du temps pour travailler sur d’autres sujets.
Nous entendons souvent dire “La base de données? Elle est gérée par AWS et l’auto-failover est activé, pas besoin de s’en occuper”. On pourrait effectivement penser que l’utilisation de services managés nous libère de toute tâche d’exploitation. Néanmoins, comme nous allons le voir, ça n’est pas encore le cas.
Idée reçue n°1 : Je n'ai pas besoin de monitorer les services managés car mon provider le fait pour moi
La responsabilité partagée
C'est vrai que le cloud provider monitore les services qu'il met à disposition, et qu'il peut fournir un haut niveau de disponibilité. Mais me préviendra-t-il le jour où un applicatif sera indisponible parce qu’une instance de cache Redis n’a plus de mémoire disponible, ou qu’une base de données relationnelle n’accepte plus de connexions ? Non, car ça n’est pas de sa responsabilité. Comme tout service cloud, il y a un concept de responsabilité partagée AWS, GCP et Azure. Les cloud providers s’engagent sur ce qu’ils maîtrisent et dans un cadre d’utilisation donné (limites de services, quotas, modèle de facturation).
Métriques et notifications
C'est pour cela que les métriques exposées par les services doivent être suivies par votre stack de monitoring. Mises à la disposition des équipes Dev et Ops, elles seront un outil indispensable pour observer l'état du système, diagnostiquer les problèmes de performance et ajuster le dimensionnement de l'infrastructure.
En complément des métriques, vous aurez un ensemble de notifications auxquelles vous pourrez souscrire. Citons par exemple, une bascule failover, une mise à jour système ou un backup en erreur. C’est selon le service utilisé.
Alertes
Métriques et notifications serviront à mettre en place des alertes, pour intervenir en cas d’incident. Se pose la question de la déduplication des alertes pour éviter le syndrome sapin de Noël, mais c’est un tout autre sujet qui doit faire l’objet d’un article dédié.
Le traitement des alertes nous ramène à la problématique de responsabilité en interne : qui intervient en cas d’incident ? Qui garantit la disponibilité de l’application ?
Idée reçue n°2 : Grâce aux services managés, je n’ai plus de problématiques d’exploitation
Le dimensionnement
Nous voyons apparaître des options de dimensionnement automatique de l’infrastructure sur certains services : espace disque sur une base de données relationnelle ou nombre de shards sur une base de données NoSQL. Mais cela se limite à certains axes (CPU ou disque), pour quelques services et souvent à un coût supplémentaire. L’aspect à la demande se fait payer par rapport à une capacité réservée.
Une activité d’exploitation est de dimensionner au mieux les ressources pour garantir un niveau de performance au meilleur coût.
Ce qui nous amène au sujet Finops : comment déterminer si le modèle de facturation à la demande est pertinent par rapport au modèle avec réservation, sans suivre l’usage des ressources?
Qui est responsable de ce sujet ?
Les montées de versions et patchs
Les montées de versions des stacks techniques sont toujours un sujet avec des services managés. En général, nous avons la possibilité de définir la politique de mise à jour : patchs, versions mineures ou versions majeures et fenêtre d’application. Dans d’autres cas, ce sera à vous de faire la mise à jour avant une date butoire définie par le fournisseur Cloud.
Mais ces services s’imbriquent avec des composants qui embarquent des clients eux-mêmes avec des versions données.
La question n’est donc pas comment je mets à jour ma base, mais comment je mets à jour mes applications qui comprennent la base et ses clients ?
Comment faire un rollback si, malgré la campagne de tests, le déploiement ne se passe pas comme prévu?
Enfin, quid des services “partiellement managés”, dont le meilleur exemple sont les clusters Kubernetes ? Le cloud provider assure la mise à jour des masters, à vous de gérer les noeuds d’exécution.
Les sauvegardes
Pour finir sur la partie exploitation : le sujet de sauvegarde/récupération de données, qui passe souvent à la trappe. On pourrait être tenté de se dire : “pas de problème, il y a des backups automatisés”.
Des backups c’est bien, mais qu’ils soient “utilisables”, c’est mieux :
- Comment se fait la récupération des données ?
- Combien de temps va durer la restauration d’une base de 3To ?
- Faut-il mettre l’application hors ligne pendant la récupération ?
- Si l’application intègre plusieurs systèmes de données, quel est l’ordonnancement à suivre ?
On répondra à ces questions lors de la mise en place d’un plan de sauvegarde. Ce dernier définira également les objectifs de RTO (durée maximale d'interruption admissible) et de RPO (perte de données maximale admissible). Il devra être testé régulièrement pour vérifier le bon fonctionnement des procédures de restauration.
Idée reçue n°3 : Si les services que j’utilise sont HA, mes applications sont HA
Non, et ce pour les mêmes raisons que pour les montées de version : le service cloud n’est pas seul et fonctionne avec d’autres composants qui s’y connectent.
Qu’il s’agisse de failover et/ou d’actif-actif, on parle de haute disponibilité mais l’un des deux suppose une bascule qui peut générer une coupure de service. Il sera donc important de s’assurer que l’application se re-connecte au service de manière transparente, et qu’elle fonctionne en mode dégradé pendant la coupure.
Avec les systèmes distribués complexes (merci les micro-services et le serverless), attention aux réactions en chaîne lorsqu’un élément ne répond plus parce qu’il n’arrive pas à se connecter à sa base de données.
Le meilleur moyen de s’assurer de la résilience du système sera de déclencher une bascule manuellement via l’API du cloud provider, et d’observer ce qu’il se passe. Pour être totalement représentatif, le test pourra être fait en production et ritualisé dans le cadre de la pratique du chaos engineering.
Idée reçue n°4 : Plus de problème de sécurité avec les services managés
Vous pouvez toujours faire une mauvaise configuration qui va exposer votre base de données sur Internet, lancer des conteneurs en mode privilégiés, exposer un object storage sur Internet … les exemples concernant de grandes entreprises ne manquent pas.
On en revient au concept de responsabilité partagée. En dehors du périmètre géré par le provider, la sécurisation des ressources sera de votre responsabilité.
Pour se protéger, on utilisera les outils mis à notre disposition : monitoring des changements sur les ressources et règles de remédiation, réception de notifications de sécurité.
Enfin, considérons le niveau le plus “managé” sur la partie calcul : le serverless. Certes, la surface d’attaque est plus réduite que sur un serveur, mais êtes-vous certains que votre API NodeJS n’embarque pas de librairies douteuses qui permettraient de récupérer les credentials du compte de service associé ?
Idée reçue n°5 : Il y a des services managés
Vous vous demandez sans doute : pourquoi n’ont-ils pas défini les services managés ?
Nous ne le ferons pas car :
- Parler de service managés, sous-entend qu’il y a des services “non-managés”.
- C’est ouvrir la porte à des débats sans fin concernant toute une nuance sur le concept “managé”. Ainsi, un cluster dont seul le plan de contrôle est géré par le fournisseur cloud est-il managé ou partiellement managé (ECS /EC2 ou GKE) ?
Nous considérons qu’il y a des services proposés par des fournisseurs, chacun arrivant avec un modèle de responsabilité donnée. Point.
Qu’en retenir ?
Nous allons être tranchant mais pour nous le terme service managé est à bannir car il n’a pas vraiment de sens.
Un service cloud, quel qu’il soit, s’intègre avec d’autres composants pour former une application et génère donc des adhérences car il est consommateur ou producteur de données.
Que l’on parle de serverless, d’object storage, de cache Redis ou de bases relationnelles fournies par le cloud provider, le sujet est le même : le service doit être mis en oeuvre pour correspondre au contexte de l’application selon son SLA, ses limites, ses quotas et ses fonctionnalités. On pourrait parler de qualification du service.
Ensuite, vient l’aspect opérationnel remis à plat par les bonnes pratiques poussées par les 3 principaux clouds publics :
- Well Architected Framework d’AWS
- Cloud Adoption Framework de GCP
- Pillars of a great Azure Architecture de Microsoft Azure
On y retrouve les axes : sécurité, contrôle de coûts, réponse aux incidents que nous avons parcourus.
Sur une échelle de 1 à 5 comment jugez-vous votre niveau d’exploitation de ressources cloud ?
