cloudgraphdev/cliУниверсальный инструмент GraphQL API и CSPM для AWS, Azure, GCP, K8s и tencent.
CloudGraph — это бесплатный универсальный инструмент с открытым исходным кодом для GraphQL API и управления положением безопасности в облаке (CSPM) для AWS, Azure, GCP и K8s. С CloudGraph вы получаете:
Cloud Graph позволяет вам узнать своё облако за 5 минут. Создано и поддерживается с любовью командой ❤️ AutoCloud ❤️
🌐 Веб-сайт
💰 Получите вознаграждение за создание провайдеров CloudGraph
** использование не подразумевает одобрения
AWS, Azure и GPC проделали замечательную работу по созданию решений, которые позволяют таким инженерам, как мы, создавать системы для управления нашим всё более взаимосвязанным миром. За последние 15 лет такие продукты, как EC2, S3, RDS и Lambda, коренным образом изменили наше представление о вычислениях, хранении данных и базах данных.
С распространением Kubernetes и Serverless за последние примерно 5 лет облачные сервисы стали всё более абстрактными поверх стоек физических серверов. Для конечных пользователей всё в облаке — это просто API, поэтому нам не обязательно знать, как работают Lambda Functions или EKS под капотом, чтобы использовать их для создания приложений. С небольшой документацией, доступом к API или консоли и учебным пособием любой может создать практически всё, что ему нужно.
Эти абстракции привели к значительному улучшению общего удобства и широты предложений облачных сервисов. То, что когда-то было трудоёмким, затратным по времени и подверженным ошибкам процессом предоставления новых серверов, баз данных или файловых систем, теперь можно сделать за секунды одним нажатием кнопки или развёртыванием IAC. Поскольку всё это абстракция API, когда CAP готов представить новый «продукт», ему просто нужно предоставить новый API — да, конечно, я немного упрощаю :)
Любой, кто знаком с CSP, знает, что API сервисов почти всегда разделены на модульные пространства имён, содержащие десятки, если не сотни, отдельных методов API для отдельных ресурсов. Например, сервис AWS EC2 содержит более 500 различных методов API, и время от времени добавляются новые. Любая компания, создающая серьёзные системы на CSP, скорее всего, использует множество разных сервисов.
Хотя это шедевр архитектуры центров обработки данных, выбор сотен сервисов и опций конфигурации возлагает бремя знаний о том, как правильно использовать эти сервисы, непосредственно на нас, инженеров. В результате нам приходится постоянно быть в курсе и изучать все предложения сервисов или новые изменения. Это требует значительного времени и умственных усилий. Как разработчикам, бывает сложно, трудоёмко и раздражает использовать AWS CLI для выполнения 5 различных вызовов API для описания, например, кластера AWS ECS, его сервисов, определений задач, задач, определений контейнеров и т.д. Мы часто оказываемся в документации и вынуждены использовать полдюжины API, чтобы получить ответы на вопросы вроде «Что именно работает в этой VPC?»
Это означает, что AWS, Azure и GCP могут быстро показаться ошеломляющими даже опытным облачным архитекторам. Хотя CSP отлично справляются с созданием реальных сервисов, обеспечивающих работу нашего бизнеса, не так много прогресса было достигнуто в упрощении повседневного пользовательского опыта при запросах к этим сотням сервисов разумным образом.
Новые решения, такие как Cloud Control API для AWS, попытались создать стандартизированный интерфейс для запросов к множеству различных типов ресурсов AWS. К сожалению, использование Cloud Control API сильно ограничено, и пользователям всё равно нужно знать, как правильно запрашивать свои данные. Это означает больше времени на чтение документации и понимание того, как работают сервисы и как они связаны друг с другом.
Хотя модульность API CSP — отличная логическая система организации и имеет смысл, она является бременем для конечных пользователей с точки зрения когнитивной нагрузки и кривой обучения. Необходимость помнить, как работают сотни постоянно меняющихся сервисов и как они связаны, приводит к кофеиновой зависимости и потере времени на поиски.
