cloudgraphdev/cliLo strumento universale per API GraphQL e CSPM per AWS, Azure, GCP, K8s e tencent.
CloudGraph è lo strumento open-source universale API GraphQL e Cloud Security Posture Management (CSPM) per AWS, Azure, GCP e K8s. Con CloudGraph ottieni:
Cloud Graph ti permette di Conoscere il tuo cloud in 5 minuti. Costruito e mantenuto con amore dal team ❤️ AutoCloud ❤️
🌐 Sito web
💰 Vieni pagato per costruire provider CloudGraph
** l'utilizzo non implica approvazione
AWS, Azure e GPC hanno fatto un lavoro fantastico nel creare soluzioni che permettono a ingegneri come noi di creare sistemi per alimentare il nostro mondo sempre più interconnesso. Negli ultimi 15 anni, prodotti come EC2, S3, RDS e Lambda hanno cambiato radicalmente il modo in cui pensiamo a computing, storage e database.
Con la proliferazione di Kubernetes e Serverless negli ultimi 5 anni circa, i servizi cloud sono diventati sempre più astratti al di sopra di rack di server fisici. Per gli utenti finali, tutto nel cloud è solo un'API, quindi non abbiamo necessariamente bisogno di sapere come funzionano internamente Lambda Functions o EKS per usarli nella creazione di applicazioni. Con un po' di documentazione, accesso API o console e un tutorial, chiunque può praticamente creare qualsiasi cosa gli serva.
Queste astrazioni hanno portato a miglioramenti enormi nella comodità e nell'ampiezza delle offerte di servizi CSP. Quello che una volta era un processo faticoso, dispendioso in termini di tempo e soggetto a errori per il provisioning di nuovi server, database o filesystem, ora può essere fatto in secondi con un semplice clic di un pulsante o il deployment di IAC. Poiché tutto è solo un'astrazione API, quando un CAP è pronto per introdurre un nuovo "prodotto", deve semplicemente esporre una nuova API - sì, sto ovviamente semplificando un po' :)
Chiunque abbia familiarità con i CSP sa che le API dei servizi sono quasi sempre suddivise in namespace modulari che contengono decine, se non centinaia, di metodi API separati per singole risorse. Ad esempio, il servizio AWS EC2 contiene oltre 500 metodi API diversi, con l'aggiunta occasionale di nuovi. Qualsiasi azienda che costruisce sistemi sostanziali su un CSP probabilmente utilizza molti, molti servizi diversi.
Sebbene sia un capolavoro di architettura data center, questa scelta di centinaia di servizi e opzioni di configurazione pone l'onere della conoscenza su come utilizzare correttamente questi servizi direttamente su di noi ingegneri. Di conseguenza, ci troviamo a dover costantemente rimanere aggiornati e imparare tutte le offerte di servizi o le nuove modifiche. Questo richiede una quantità significativa di tempo ed energia mentale. Come sviluppatori, può essere difficile, dispendioso in termini di tempo e frustrante usare l'AWS CLI per fare 5 diverse chiamate API per descrivere, ad esempio, un cluster AWS ECS, i suoi servizi, definizioni di task, task, definizioni di container, ecc. Ci troviamo spesso persi nella documentazione e a dover usare mezza dozzina di API per ottenere risposte a domande come "Cosa sta esattamente girando in questa VPC?"
Questo significa che AWS, Azure e GCP possono sembrare travolgenti rapidamente anche per architetti cloud esperti. Mentre i CSP sono fantastici nel costruire i servizi reali che alimentano le nostre attività, non sono stati fatti molti progressi nel semplificare l'UX quotidiana dell'interrogazione di questi centinaia di servizi in modo sensato.
Nuove soluzioni come Cloud Control API per AWS hanno tentato di creare un'interfaccia standardizzata per interrogare molti tipi diversi di risorse AWS. Sfortunatamente, l'utilizzo di Cloud Control API è severamente limitato e gli utenti devono ancora sapere come interrogare correttamente i loro dati. Questo significa più tempo speso a leggere documentazione e a capire come funzionano i servizi e come sono correlati tra loro.
