Навигация по затратам на облако: как добиться финансовой прозрачности с помощью облачной архитектуры
15 апреля 2023 г.В том, что становится очень экономичным миром использования облака по множеству причин; глобальное экономическое давление, безудержные затраты на облачные технологии, неудачные программы миграции и так далее. Является ли то, что у каждой организации все еще есть возможность, независимо от существующей или новой структуры посадочной зоны (организационной структуры управления), добиться необходимой прозрачности затрат, чтобы обеспечить внедрение практики облачных финансовых операций («FinOps») таким образом, чтобы обеспечить наилучшее беспрецедентные результаты в данном сценарии.
Содержание
- Волшебное облако
- Что это значит?
- Почему это важно?
- Архитектура учетной записи для отслеживания затрат
- Общие принципы управления
- Компания А – Окружающая среда
- Компания Б — бизнес-подразделения
- Компания C – рабочие нагрузки и ресурсы среды
- Заключение
Волшебное облако
Облачные вычисления, когда-то продававшиеся как волшебный компьютер, спрятанный в небе , готовый решить самые сложные проблемы вашей организации, за последние несколько лет резко изменились настроения, поскольку организации быстро и на собственном горьком опыте поняли, что это не так просто.
Из-за неудачных миграций, когда болтливые раздутые локальные монолиты были подняты и перемещены в спешке для продвижения «основных облачных принципов» без каких-либо вспомогательных навыков для рефакторинга. Вплоть до плохо спланированного и налаженного управления для обеспечения соблюдения основных мер безопасности для защиты организаций от событий, связанных с безопасностью, и того, о чем эта статья, разработки архитектуры, позволяющей избежать шока при выставлении счетов за счет обеспечения прозрачности расходов вашей организации на облачные технологии.
<цитата>Как Питер Друкер, "что измеряется, то улучшается"
Реальность такова, что облачный мир никоим образом не похож на локальные рабочие нагрузки с миллионами SKU, представляющими все виды услуг, вычислений, памяти, хранилища и многого другого одним нажатием кнопки. Инженеры могут в одиночку проделать дыру в ИТ-бюджете организации. Как пишет Данн Берг в своей статье здесь "петля денежной обратной связи" значительно дольше (если вообще существует) по сравнению с неудачным техническим изменением, внесенным инженером.
Что это значит?
Это означает, что к тому времени, когда организации осознают, что инженер A развернул целую группу инстансов AWS EC2 u-12tb1.112xlarge с колоссальными 448 виртуальными ЦП, 12 ТБ памяти для Proof of Concept Web App и начал в праздничные дни у них есть счет как минимум на 80 тысяч долларов США от EOM.
Теперь это маловероятный сценарий, поскольку стажеру пришлось развертывать рабочий процесс без утверждения, но факт в том, что это может произойти, и это происходит каждый день недели по всему миру. Так как такая жестяная банка недоступна в помещении, чтобы ее можно было раскрутить, не прыгая через обручи, и уж точно не так быстро, как позволяет волшебное облако.
Почему это важно?
Это важно, потому что использование облака не показывает признаков замедления. Gartner прогнозирует рост расходов на публичное облако на 20,4 % в 2022 году, а к 2023 году во всем мире будет потрачено 600 млрд долларов. Хотя согласно Flexera из этих значительных мировых расходов, Ожидается, что в 2022 году 32% будут потрачены впустую (158,3 млрд долларов). Ой.
Одни только эти цифры бросаются в глаза, но по сравнению с глобальной экономикой, которая имеет тенденцию к более трудным временам, 83% основной облачной проблемой организаций является управление своими облачными расходами (Flexera). Неизбежно, что руководители уже спрашивают или собираются спросить, где я могу сэкономить деньги?
<цитата>Хотя для экономии денег, оптимизации и эффективной работы мы должны сначала знать, на что расходуется организация
Итак, давайте рассмотрим это.
Архитектура учетной записи для отслеживания затрат
В зависимости от того, была ли ваша организация одной из первых облачных служб или ваша организация изучает передовые методы внедрения новых облачных возможностей в вашей организации. Ответ на видимость облаков — это не просто #тегирование. В нескольких статьях о тегах говорится так, как будто это панацея от всех проблем с размещением и видимостью в организации.
Тем не менее, как облачный архитектор и руководитель FinOps, работающий в сфере профессиональных услуг, где я участвую во всех концах спектра различных облачных путешествий организаций, я считаю, что «тегирование» — это один из многих рычагов. Но, как указано во многих статьях, они не дают полной картины, поэтому я и пишу эту статью.
Все начинается с того, как ваша организация использовала свои предложения CSP для предварительной разработки необходимого управления. Видите ли, тегирование происходит после создания необходимой организационной структуры, политик контроля, ограждений и т. д. для того, как ваша организация может захотеть лучше организовать себя. Это могут быть бизнес-подразделения, среды, рабочие нагрузки и т. д.
Исходя из этого, существует больше, чем просто соображения стоимости, и в зависимости от отрасли вашей организации вы можете обнаружить, что конструкции управления сильно различаются. Ниже будет представлен ряд общих конструкций, которые я вижу, и их плюсы и минусы, которые помогут вам принять правильное решение для вашей организации.
<цитата>Намерение здесь состоит в том, чтобы «сдвинуть влево» способность FinOs не полагаться на один фактор, который обычно просто «прикрепляется», то есть на теги, а «встраивать» его в структуру вашей структуры управления в рамках вашего CSP или CSP. если вы используете несколько облаков.
Чтобы обсудить это, мы сначала должны прояснить некоторую общую номенклатуру, чтобы мы все были на одной странице. В разных CSP терминология, используемая для представления одной и той же логической конструкции, различается, хотя при развертывании мы можем достичь одного и того же результата. Ниже представлено сравнение Amazon Web Services (AWS) и Microsoft Azure (Azure) и то, как их терминология иерархии управления отличается, но обеспечивает одинаковые результаты.
Примечание. Во всех приведенных ниже примерах я буду использовать терминологию AWS, но, если я потеряю вас, вернитесь к приведенному ниже для сравнения терминов!
Общие конструкции управления
Как кратко обсуждалось выше, структура управления, которую развертывает или уже развернула ваша организация, может основываться на том, что было доступно в то время (первое внедрение), или на хорошо продуманных передовых методах, которые существуют сейчас. В любом случае, понимание того, как различные отрасли могут создавать свои посадочные зоны и структуры управления, позволяет вам принимать более эффективные решения для улучшения прозрачности затрат в вашей организации уже сейчас, двигаться вперед и находить правильные компромиссы.
Примечание. В приведенных ниже примерах «учетная запись управления» используется как совокупность потенциальных «других» учетных записей, которые используются для общего управления и обеспечения соблюдения политик, безопасности и т. д. И не относятся к терминологии AWS, где « учетная запись управления» — это центральная учетная запись, используемая для управления иерархией организации AWS (ранее известная как основная учетная запись). Они могут включать, но не ограничиваться:
* Учетная запись личности; централизованное управление Active Directory, RBAC и т. д. * Учетная запись подключения; централизованное управление и настройка сетевых ресурсов, таких как AWS Direct Access * Управленческий учет; централизованное управление мониторингом, ведением журналов и аналитикой, которые могут подключаться к локальным инструментам SIEM, таким как Splunk
Поэтому, пожалуйста, не зацикливайтесь на этих управляющих аккаунтах.
Кроме того, приведенные ниже примеры ни в коем случае не являются исчерпывающими, но представляют собой попытку предоставить вам достаточную информацию, чтобы начать рассмотрение ваших требований к организационному управлению. Таким образом, может потребоваться, чтобы вы организовали свои организационные подразделения и их соответствующие учетные записи таким образом, чтобы поддерживать масштаб, политики, структуру сети или границы управления, которые наилучшим образом соответствуют операционным потребностям организации.
<цитата>Поскольку один размер не подходит всем.
Компания А – Окружающая среда
Эта организационная структура использует организационные подразделения AWS (OU) и разбивает учетные записи по средам со всеми бизнес-подразделениями и их соответствующими рабочими нагрузками, смешанными в каждом «DEV», «TEST» и «PROD» в этом примере.
Преимущество этой структуры заключается в минимизации затрат, поскольку общие ресурсы могут быть общими, и логически учетная запись создает границу для изоляции, которая разделяет задачи. Таким образом, даже без тегов мы можем отнести рабочие нагрузки к их среде.
Однако из-за структуры по «среде» легко увидеть, что маркировка здесь имеет решающее значение, если предполагается метод распределения затрат «возврата» или даже «показ назад» для каждого бизнес-подразделения и их рабочих нагрузок. Хотя безопасность здесь вызывает беспокойство, поскольку учетная запись «PROD» представляет собой медовый горшок производственных рабочих нагрузок, ожидающих использования, если они не управляются должным образом.
Компания Б – бизнес-подразделения
Эта организационная структура использует подразделения для представления бизнес-подразделений со всеми рабочими нагрузками этого бизнес-подразделения и их соответствующими «средами», управляемыми внутри каждого.
Преимущество этой структуры заключается в минимизации затрат, поскольку общие ресурсы могут быть общими, а логически учетная запись создает границу для изоляции, которая разделяет задачи, подобные компании А. Таким образом, даже без тегов мы можем приписывать рабочие нагрузки логическим бизнес-подразделениям.
В организации, где для распределения затрат используется возврат или возвратный платеж, этого может быть достаточно, чтобы иметь определенные границы затрат, определенные структурой счета. Тем не менее, чтобы лучше понять, какая рабочая нагрузка использовала конкретный ресурс, и для дальнейшего разделения затрат, требуется пометка.
Здесь важно отметить, что эта организационная структура действительно представляет риск для безопасности, аналогичный компании А, поскольку среды смешанные, поэтому инженеры могут по небрежности непреднамеренно внести изменения, предназначенные для среды «DEV», но вместо этого повлиять на рабочую нагрузку «PROD». . Здесь важны надежные методы разработки, конвейеры CI/CD, проверки кода и так далее. Включая использование политик AWS Service Control Policies (SCP), AWS Control Tower и AWS Organizations для управления и обеспечения соблюдения политик.
Компания В – Рабочая нагрузка и объем работы Окружающая среда
Эта организационная структура не характерна для многих организаций, но она распространена в организациях с высоким уровнем безопасности, где важно ограничить радиус взрыва, например, для моих клиентов в Defense & Сектор национальной безопасности. Можно использовать организационные подразделения, но в этом случае следует внедрить политики контроля, поскольку детализация затрат достигается самой природой структуры аккаунта.
Учетные записи разбиваются как по рабочим нагрузкам, так и по среде. Таким образом, каждая рабочая нагрузка будет иметь как минимум две учетные записи со всеми «непроизводственными» рабочими нагрузками в одной учетной записи и «производственной» — в другой. Количество учетных записей может увеличиться, если непроизводственные среды более высокого уровня, такие как «Предварительная версия», имеют интеграцию со сторонними организациями для тестирования сквозной конфигурации, а также необходимо поддерживать интеграцию и разделение задач.
Эта структура, несомненно, является самым дорогим способом операционализации организационной структуры внутри CSP, поскольку ресурсы не используются совместно. Учитывая рабочие нагрузки, которые могут взаимодействовать друг с другом как часть сквозной системы, необходимо принять дополнительные меры для включения пиринга и т. д. Кроме того, затраты организации дублируются, поскольку используемые основные ресурсы, такие как AWS WAF, требуются в каждой учетной записи, и взимается соответствующая плата.
Учитывая эту структуру, рабочие нагрузки имеют очевидные операционные границы и применение политик. В свою очередь, затраты могут быть напрямую связаны с конкретной рабочей нагрузкой и соответствующей средой. В этом сценарии маркировка становится менее важной, поскольку затраты детализированы до цента, и нет общих затрат, которые можно было бы распределить обратно. Таким образом, этой структуры может быть достаточно для некоторых организаций, чтобы быть уверенными в том, что они просто «оплачивают счета» и доверяют командам принимать меры с помощью облачных инструментов Advisor.
Однако когда вы начинаете учитывать, какие ресурсы используются, например кластеры Kubernetes, и выходите на новый уровень видимости в больших рабочих нагрузках с потенциально сотнями ВМ, тегирование становится критически важным.
Как обсуждалось выше, все сводится к императиву вашей организации. Я разговаривал с некоторыми организациями, занимающимися обменом криптовалют, которые совершенно не заботятся о своих расходах и, следовательно, не заботятся о прозрачности в контексте финансов (хотя могут с точки зрения SRE. В то время как другие, такие как правительство, тратят государственные средства). средства и иметь более строгий контроль над тем, как эти деньги должны быть потрачены.
Заключение
Понимание организационной структуры управления — это первый шаг к лучшему распределению затрат и прозрачности. Хотя тегирование играет в этом невероятно важную роль, это всего лишь рычаг, и понимание цели того, почему вещи устроены именно так, как они есть, позволяет вам более эффективно использовать этот рычаг. Снижение нагрузки на ваши инженерные команды и увеличение добавленной стоимости определенных тегов. Поскольку слишком много тегов без конкретной цели просто создают накладные расходы. Не будь такой командой!
Так что будьте ближе и поймите почему, и я обещаю, что вы добьетесь лучших результатов для вашей команды finops и, в свою очередь, для вашей организации.
Эта статья представляет только мое личное мнение, а не мнение моего работодателя.
Также опубликовано здесь
Оригинал