cloudgraphdev/cliL'outil universel d'API GraphQL et de CSPM pour AWS, Azure, GCP, K8s et tencent.
CloudGraph est l'outil gratuit open-source universel d'API GraphQL et de gestion de la posture de sécurité cloud (CSPM) pour AWS, Azure, GCP et K8s. Avec CloudGraph, vous obtenez :
Cloud Graph vous permet de Connaître votre cloud en 5 minutes. Construit et maintenu avec amour par l'équipe de ❤️ AutoCloud ❤️
🌐 Site Web
💰 Soyez rémunéré pour construire des fournisseurs CloudGraph
** l'utilisation n'implique pas d'approbation
AWS, Azure et GCP ont fait un travail remarquable en construisant des solutions qui permettent aux ingénieurs comme nous de créer des systèmes pour alimenter notre monde de plus en plus interconnecté. Au cours des 15 dernières années, des produits tels qu'EC2, S3, RDS et Lambda ont fondamentalement changé notre façon de concevoir l'informatique, le stockage et les bases de données.
Avec la prolifération de Kubernetes et du Serverless au cours des 5 dernières années environ, les services cloud sont devenus de plus en plus abstraits au-dessus des racks de serveurs physiques. Pour les utilisateurs finaux, tout dans le cloud n'est qu'une API, donc il n'est pas nécessaire de savoir comment fonctionnent Lambda Functions ou EKS sous le capot pour les utiliser dans la construction d'applications. Avec un peu de documentation, un accès API ou console, et un tutoriel, n'importe qui peut à peu près créer tout ce dont il a besoin.
Ces abstractions ont conduit à des améliorations massives de la commodité globale et de l'étendue des offres de services CSP. Ce qui était autrefois un processus laborieux, chronophage et sujet aux erreurs pour provisionner de nouveaux serveurs, bases de données ou systèmes de fichiers peut désormais être réalisé en quelques secondes avec un simple clic de bouton ou un déploiement d'IaC. Puisque tout n'est qu'une abstraction API, lorsqu'un CAP est prêt à introduire un nouveau « produit », il lui suffit d'exposer une nouvelle API — oui, je simplifie un peu :)
Quiconque connaît les CSPs sait que les API de services sont presque toujours divisées en espaces de noms modulaires qui contiennent des dizaines, voire des centaines, de méthodes API distinctes pour des ressources uniques. Par exemple, le service AWS EC2 contient plus de 500 méthodes API différentes, avec de nouvelles ajoutées occasionnellement. Toute entreprise construisant des systèmes substantiels sur un CSP utilise probablement de nombreux services différents.
Bien que ce soit un chef-d'œuvre d'architecture de centre de données, ce choix de centaines de services et d'options de configuration fait peser sur nous, ingénieurs, la charge de savoir comment utiliser correctement ces services. En conséquence, nous devons constamment nous tenir à jour et apprendre toutes les offres de services ou les nouvelles modifications. Cela demande beaucoup de temps et d'énergie mentale. En tant que développeurs, il peut être difficile, chronophage et frustrant d'utiliser l'AWS CLI pour effectuer 5 appels API différents afin de décrire, par exemple, un cluster AWS ECS, ses services, définitions de tâches, tâches, définitions de conteneurs, etc. Nous nous retrouvons souvent perdus dans la documentation et devons utiliser une demi-douzaine d'API pour obtenir des réponses à des questions comme « Qu'est-ce qui tourne exactement dans ce VPC ? »
Cela signifie qu'AWS, Azure et GCP peuvent rapidement sembler écrasants, même pour des architectes cloud chevronnés. Alors que les CSP excellent dans la construction des services réels qui alimentent nos entreprises, peu de progrès ont été réalisés pour simplifier l'UX quotidienne d'interrogation de ces centaines de services de manière saine.
