Кодифицируйте свои приложения SaaS: ответ на неуправляемые джунгли SaaS

Дрейф инфраструктуры, неуправляемые ресурсы, активы-призраки — все это хорошо известные «тихие убийцы» в наших облаках. Будь то AWS, GCP, Kubernetes, Azure или что-то еще, при развертывании наших сервисов в нескольких облаках мы знаем, что унифицированная инвентаризация и управление нашими облачными ресурсами сложны, и существует множество отличных инструментов, которые помогут решить эту проблему. возрастающая сложность.

Одна вещь, которую часто упускают из виду, — это то, где в микс вступают наши инструменты SaaS. Когда мы внедряем инструменты SaaS, мы склонны рассматривать их как инструменты, а не то, чем они в конечном итоге являются: дополнительные разрозненные, неуправляемые облака с собственным набором сервисов, объектов и ресурсов.

Явление, с которым мы часто сталкивались, помогая компаниям преодолевать дрейф, — это обычное пренебрежение инструментами облачной инфраструктуры, такими как CloudFlare, Okta, Mongo Atlas, Datadog, Git и многими другими популярными платформами и инструментами SaaS, которые являются частью нашей основной деятельности. Как мы можем сделать эти облака SaaS неизменяемыми, версионными, масштабируемыми и контролируемыми, если эти расширения не кодифицированы? Дрейф состояний в Okta вызывает меньше беспокойства, чем, например, дрейф в ваших ролях IAM? Как мы можем гарантировать надлежащий мониторинг, если наши информационные панели Datadog позволяют любому вызвать дрейф?

Это лишь некоторые из вопросов, которые приходят на ум, когда мы видим этот повторяющийся антишаблон в облачных операциях сегодня. Но вы можете спросить, почему это важно?

Если инженеры DevOps начинают понимать, что систематизировать облачные ресурсы гораздо безопаснее и менее подвержено ошибкам, включая неотъемлемые преимущества управления этими ресурсами, как и всем другим кодом — будь то история git, экспертные оценки, автоматизация PR и соблюдение политик похоже, сервис SaaS еще не претерпел подобной эволюции и прозрения. Если клики для облачной конфигурации в основном были заменены практиками IaC, инструменты SaaS в основном по-прежнему настраиваются вручную через пользовательский интерфейс с минимальным кодированием. Неудивительно, что это приводит ко многим подобным проблемам, которые вы обнаружите в своих облачных операциях.

Включение Git в GitOps

Когда дело доходит до Kubernetes и облачных систем, которые так часто ассоциируются с практиками GitOps, которые считаются лучшими практиками и современным способом управления сложными операциями Kubernetes, — часть git gitops практически игнорируется, когда дело доходит до управления этими операциями. системы. Я объясню.

Если мы посмотрим на самых загруженных провайдеров Terraform для приложений SaaS, которые не являются облаками, список и данные будут чрезвычайно убедительными:

• DataDog/датадог 32,4 млн+

• интеграций/github 16,9 млн+

• облачная вспышка/облачная вспышка 16,8 млн+

• ньюрелик/ньюрелик 12.5M+

• hashicorp/consul 9.7M+

• PagerDuty/пейджердьюти 8.6M+

• графана/графана 5,4 млн+

• gitlabhq/gitlab 4.8M+

• монгодб/монгодбатлас 4.2M+

• окта/окта 4M+

• эластичный/EC 3.2M+

Хотя наблюдается растущая тенденция к кодификации этих ресурсов через поставщиков Terraform, если мы возьмем количество загрузок поставщика AWS Terraform или следующего по популярности облачного Azure, то это 750+ и 127+ миллионов соответственно, что ставит следующего по популярности необлачного провайдера. при примерно 5% принятии (и, в конечном итоге, кодификации).

Это связано с тем, что такую ​​кодификацию необходимо будет выполнять не только для каждого инструмента SaaS в отдельности, но и после того, как эти инструменты будут настроены с помощью кликов, простое преобразование этого в IaC является чрезвычайно сложной задачей (особенно в крупных организациях с несколькими информационными панелями, облаками, сервисами и прочим). зависимости и ресурсы).

Если мы вернемся к размышлениям о том, как преобразовать наши операции git в нативные GitOps, нам, вероятно, придется следовать сообщению, подобному этому, которое проведет вас через процесс управления вашей организацией Github с помощью Terraform. И это всего лишь один из многих инструментов в огромном наборе инструментов SaaS, которые должны быть подвергнуты аналогичному преобразованию. /hackernoon/managing-datadog-with-terraform-89abe0eb62f5). И список продолжается. Теперь представьте, что в крупных организациях есть десятки инструментов — несколько команд и облаков. Задача сложна даже для размышления. До настоящего времени.

Кодификация вашего SaaS

Размышляя о критических аспектах кодификации вашего SaaS, есть несколько аспектов, на которых Firefly было важно сосредоточиться, чтобы сделать этот переход действительно ценным для всех команд DevOps. Первый уровень ценности заключается в едином реестре как облачных ресурсов, так и ресурсов SaaS в одном месте. Уже одно это позволяет командам DevOps искать, понимать и классифицировать ресурсы во всех облаках — операционных или инструментальных. Что-то, что раньше было невозможно с помощью одной панели инструментов или инструмента.

Следующий аспект — управление всеми этими инструментами и активами как кодом. Если это стало облачным стандартом, непонятно, почему этого не произошло и с приложениями SaaS. Мы говорили о преимуществах управления всем как кодом, но, в конце концов, когда управление осуществляется как код с применением соответствующих руководств и внутренних инженерных практик, их можно автоматизировать как часть процессов CI/CD, а также применять соответствующие ограничения и барьеры. .

Выполнение этого вручную потребовало бы от инженеров перевода всех своих ручных конфигураций (которые не всегда можно найти в одном месте в пользовательском интерфейсе, на многих уровнях их приложения) в соответствующие конфигурации кода, и, как правило, много раз, если их несколько. приложения, информационные панели или инструменты. Теперь это возможно одним нажатием кнопки для всех инструментов SaaS в одном месте.

Если мы посмотрим на типичную панель мониторинга Firefly, то увидим, что типичные инструменты SaaS имеют всего 20% кодифицированных ресурсов по сравнению с 50% у поставщиков облачных услуг.

Компании, которые изменили это число и кодифицировали эти ресурсы, смогли воспользоваться преимуществами IaC, заключающимися в более быстрых циклах развертывания и резервных шаблонах конфигурации для сценариев аварийного восстановления.

Мы надеемся, что вы нашли это полезным — не стесняйтесь оставлять любые вопросы, которые у вас могут возникнуть, в комментариях.