Principes fondamentaux Flashcards
Qu’est-ce qu’une application cloud native?
Application distribuée et qui utilise l’infrastructure cloud. Il s’agit de la façon dont l’application fonctionne, pas son emplacement. Tendance à être composées de plusieurs microservices distribués et coopérants ensemble.
Vrai ou Faux? Le simple fait de prendre une application existante et de l’exécuter sur une instance de calcul cloud ne la rend pas cloud natives
Faux
Qu’est-ce que sont les microservices?
- Style architectural
- Composition de petits services non couplés et indépendants
- Chaque service a une seule fonction du point de vue affaire
- Interactions entre les services via APIs
Quelles sont les principales caractéristiques d’une application cloud native?
- Gestion et déploiement automatisés
- Omniprésent et flexible (conteneurs fcilement déplacables d’un noeud à l’autre)
- Résilience et scalabilité (pas de single point of failure, possibilité de redondance)
- Dynamique
Quels sont les principaux défis d’une application cloud native?
- Système distribué
- Réseau non fiable (doit développer le logiciel en tenant compte des pannes de réseau)
- Latence et bande passante (caching, besoins en bande passante)
- Topologie ne change pas (ajouter des machines sans problème)
- Pets Vs cattle (on ne traite pas une machine comme une entité connue, mais comme un membre d’un troupeau)
Quelles sont les compétences nécessaires pour créer des applications cloud natives?
- Clean code: Code propre, bon nombre de tests automatisés et refactorisent constamment
- DDD: Garder conception aussi proche du monde réel, avoir interfaces faciles à utiliser et des APIs bien conçues, base d’une conteneurisation et d’une automatisation réussies plus tard
- Microservices: Devient la norme, concevoir des applications distribuées évolutives, difficile de décider des limites des services, quantité importante de théorie
- Kubernetes Patterns: conteneurisation, nombre croissant de conteneurs donc doit les gérer avec patterns et outils efficaces, Kubernetes plateforme la plus populaire.
Quelle était l’idée initiale des conteneurs sous Linux?
Découper un système d’exploitation afin d’exécuter en toute sécurité plusieurs applications sans qu’elles n’interfèrent les unes avec les autres
Quels sont les avantages des conteneurs?
Déploiements déterministes permettant la portabilité entre les environnements, Très légers en termes de mémoire et d’espace disque ce qui accélère les temps de démarrage. Idéal pour scale out
Quelle est la différence entre l’image et le conteneur?
- Image: unité de fonctionnalité qui répond à une seule préoccupation bien définie. Porte dépendances d’exécution (comme la classe en Java)
- Conteneur: Généralement un seul processus Unix. Jetable et peut être mis à l’échelle facilement et en toute sécurité à tout moment (comme l’objet en Java)
Vrai ou faux? Les conteneurs partagent le même noyau lorsqu’ils sont exécutés sur le même hôte
Vrai
Pourquoi il est préférable d’utiliser des conteneurs vs des VM?
VM prend un temps considérable à démarrer car démarre OS au complet, scaling up demande nouvelle machine virtuelle plus volumineuse, scaling out peut ne pas être assez rapide car démarrage nouvelles instances prend du temps
Vrai ou faux? Les conteneurs sont conscients les uns des autres? Comment peuvent-ils être orchestrés et pourquoi?
Faux. Besoin orchestrateur pour planifier le déploiement, déplacer les conteneurs, suivre l’allocation des ressources
Quelles sont les 3 propriétés du théorème CAP qui ne peuvent être garanties en même temps?
Cohérence (Consistency), Disponibilité (Availability), Tolérance au partitionnement (Partition Tolerance)
Qu’est-ce que la cohérence selon CAP?
Tous les noeuds du système voient exactement les mêmes données au même moment
Qu’est-ce que la disponibilité selon CAP?
Une requête renverra toujours des informations, renverra toujours des données, mais il se peut que ce ne soit pas la dernière à jour. Ex: caching
