Избегайте того, чтобы отдельные команды сами выбирали поставщика облачных услуг (CSP). Если оставить за agile-подразделениями право самостоятельно решать, какие сервисы использовать, это в конечном итоге приведет к фрагментации, сложности и отсутствию сотрудничества в организации. Навыки, во многих случаях, не будут переноситься между CSP. Аналогичным образом, команда по архитектуре предприятия должна рассмотреть вопрос о том, какие службы должны быть стандартизированы, чтобы избежать сложностей и технического долга (например, какие службы баз данных или технологии обмена сообщениями должны быть приняты предприятием в качестве стандарта). Каждый CSP предлагает сотни собственных услуг и рыночных площадок, обеспечивающих доступ к экосистеме услуг сторонних производителей.
Создайте облачную основу
Многие облачные решения не удается масштабировать, потому что компании не вкладывают средства в создание прочного облачного фундамента. Для создания этих фундаментальных элементов вам понадобится несколько высококвалифицированных облачных архитекторов:
Базовые возможности облака. Эти возможности включают сетевые подключения и маршрутизацию, централизованные межсетевые экраны и прокси-серверы, стандартизацию идентификационных данных, корпоративную регистрацию, мониторинг и аналитику (ELMA), общие корпоративные службы, конвейеры "золотого образа" (или "первичного образа"), а также обеспечение соответствия и безопасности. Компании могут создать базовые возможности один раз и повторно использовать их во всех зонах изоляции.
Зоны изоляции. Зоны изоляции (иногда называемые посадочными зонами) - это облачные среды, в которых живут приложения. Каждая зона содержит службы CSP, управление идентификацией и доступом (IAM), изоляцию сети, управление мощностями, общие службы, специфичные для данной зоны изоляции, и контроль изменений, в которых выполняются одно или несколько связанных приложений. Зоны изоляции обеспечивают избыточность в случае сбоя одной из зон. Поэтому необходимо иметь более одной зоны изоляции для создания избыточности, но не так много, чтобы не создавать сложности.
Согласование количества зон изоляции - критически важное решение. При наличии одной зоны изоляции изменения конфигурации для поддержки одного приложения могут непреднамеренно повлиять на другие. Впадение в другую крайность - одна зона изоляции для каждого приложения - препятствует эффективному развертыванию изменений конфигурации, требуя выполнения одной и той же работы во многих зонах изоляции.
Шаблоны приложений. Это артефакты кода, автоматизирующие безопасную, совместимую и стандартизированную конфигурацию и развертывание приложений со схожими функциональными и нефункциональными требованиями. Шаблоны приложений могут отвечать за конфигурирование общих ресурсов, стандартизацию конвейеров развертывания, а также за обеспечение качества и соответствия требованиям безопасности. Примерами шаблонов приложений являются шаблоны обработки данных, такие как SQL DB, NoSQL DB, data mart/warehouse; веб-приложения, такие как статический веб-сайт или трехуровневое веб-приложение; API и т. д. Количество шаблонов, необходимых для поддержки перечня приложений, должно быть небольшим, что позволяет добиться максимальной рентабельности инвестиций. Например, один крупный банк успешно использовал всего 10 шаблонов приложений, чтобы удовлетворить 95 % необходимых сценариев использования.
Эти основополагающие элементы позволяют в восемь раз ускорить темпы миграции и внедрения облачных технологий и на 50 % сократить расходы на миграцию в долгосрочной перспективе.3
Наращивайте потенциал FinOps
Наиболее эффективная экономика облачных вычислений заключается в том, чтобы платить за мощности только тогда, когда они вам нужны, а не платить за мощности, которые вы не используете. Этого можно достичь, выбирая облачные сервисы, которые наилучшим образом соответствуют текущие требования к рабочим нагрузкам. Это может привести к экономии расходов на облачные вычисления до 20 %.
Наиболее успешные предприятия развивают эту способность, объединяя технических, финансовых специалистов и специалистов по поиску поставщиков в команды FinOps для управления расходами на облачные вычисления. Эта команда должна определить потребности предприятия в вычислительных и сетевых ресурсах, часто используя передовую аналитику для прогнозирования спроса, а затем преобразовать эти потребности в оптимальные облачные предложения и ценовые схемы. Они используют облачные инструменты для создания автоматизированных информационных панелей, чтобы отслеживать использование облака и перераспределять ресурсы для оптимизации расходов. Команда FinOps также отслеживает расходы на облачные технологии в масштабах всего предприятия, чтобы обеспечить финансовую дисциплину.
