Злого умысла в рекламе больших, а тем более зажравшихся, ЦОДов точно не было :) Прямых рук как всегда не хватает всем. Несомненно, когда ложится большой или не очень Провайдер — это громко и заметно. А насколько и как часто ложатся корпоративные инфраструктуры — надо постараться, чтобы собрать такие данные. А сколько денег и усилий надо, чтобы реально выдерживать обозначенный sla для крупной компании — страшно представить, чтобы и экономика не поехала (не будем брать во внимание небольшую инфраструктуру на 20 ВМ).
Рекомендуемые нами показатели обоснованы эмпирическими наблюдениями за пиковыми нагрузками на нескольких "дружественных" инфраструктурах.
Мы не различаем какой вид ПО работает на ВМ - для наших наблюдений важно, что ВМ работает и есть колебания нагрузки.
Рекомендации не являются рецептом или правилом для автоматизации. А именно рекомендациями для того, чтобы обратить внимание на те или иные параметры работы ВМ, а дальше коллегиально с архитекторами, разработкой и эксплуатацией провести обсуждение и принять решение. ФинОпс - это про совместную деятельность, а не автоматизацию.
Наверняка есть сценарии, как минимизировать этот кейс. Но глобально — да, в этом случае платить) И если это выходит сильно дорого — значит в этом случае не использовать облака. Благо всегда есть выбор (ну или хотя бы иллюзия его наличия).
Сам по себе FinOps, конечно же не панацея. Как минимум отправится нотификация об аномалии в стоимости (вдруг кто-то не заметит, что была ДДОС и сработало масштабирование) — т.е. не переплатят сильно больше, чем если бы заметили в конце отчетного периода из биллинга от провайдера. А так, это скорей участие "финопс-инженеров" в архитектурном комитете. Вдруг они предложат задать лимиты на автоскейл
Внедрение FinOps как раз помогает в прогнозировании и бюджетировании. По крайней мере, "дает" набор метрик и инструментов для контроля. Но это тоже требует средств, и актуально когда оптимизационный потенциал выше затрат))
Смотря как считать) Если сравнивать только стоимость железа и итого за облака за некий период — там разница в "Иксах". Если добавить все косвенные расходы, амортизацию и прочее, помноженное на скорость/гибкость/возможности облаков — то эта разница уже будет не такой значительной.
Это как с аутстаффом разработчиков) Это всегда дороже, чем взять в штат. Но есть сценарии при которых это будет явно выгодней. Как минимум, редко можно "уволить/заменить" позицию день-в-день
Всё чаще вижу подход, при котором своя инфра стремится к 90+% утилизации. Что-то новое запускается в облаках, и , при необходимости, в нужной конфигурации перетаскивается внутрь.
И опять же, доступ к "неограниченным" и "легким" сервисам команды немного развращает. "Ну а чо, в любой момент срежем лишнее или вообще выключим)" Такой прыти при работе со своей инфрой не наблюдается.
Согласен про чих, каждый CPU и в своей инфре стоит условных "попугаев". Только финансистам такое спокойней, посколько новый инстанс не потребует денег сверх оплаченного.
Под "раньше" подразумевается работа с собственной инфрой. И берется за основу концепция, что за железо уже уплочено) А при работе с публичными облаками каждый чих тарифицируется сверху
Злого умысла в рекламе больших, а тем более зажравшихся, ЦОДов точно не было :)
Прямых рук как всегда не хватает всем. Несомненно, когда ложится большой или не очень Провайдер — это громко и заметно. А насколько и как часто ложатся корпоративные инфраструктуры — надо постараться, чтобы собрать такие данные.
А сколько денег и усилий надо, чтобы реально выдерживать обозначенный sla для крупной компании — страшно представить, чтобы и экономика не поехала (не будем брать во внимание небольшую инфраструктуру на 20 ВМ).
Рекомендуемые нами показатели обоснованы эмпирическими наблюдениями за пиковыми нагрузками на нескольких "дружественных" инфраструктурах.
Мы не различаем какой вид ПО работает на ВМ - для наших наблюдений важно, что ВМ работает и есть колебания нагрузки.
Рекомендации не являются рецептом или правилом для автоматизации. А именно рекомендациями для того, чтобы обратить внимание на те или иные параметры работы ВМ, а дальше коллегиально с архитекторами, разработкой и эксплуатацией провести обсуждение и принять решение. ФинОпс - это про совместную деятельность, а не автоматизацию.
Причем "быстрые победы" чаще всего не заставляют себя долго ждать
Наверняка есть сценарии, как минимизировать этот кейс. Но глобально — да, в этом случае платить) И если это выходит сильно дорого — значит в этом случае не использовать облака.
Благо всегда есть выбор (ну или хотя бы иллюзия его наличия).
Интересно, что думают об этом компании, которые были изначально cloud-native и продолжают "витать в облаках".
Сам по себе FinOps, конечно же не панацея.
Как минимум отправится нотификация об аномалии в стоимости (вдруг кто-то не заметит, что была ДДОС и сработало масштабирование) — т.е. не переплатят сильно больше, чем если бы заметили в конце отчетного периода из биллинга от провайдера.
А так, это скорей участие "финопс-инженеров" в архитектурном комитете. Вдруг они предложат задать лимиты на автоскейл
Внедрение FinOps как раз помогает в прогнозировании и бюджетировании. По крайней мере, "дает" набор метрик и инструментов для контроля. Но это тоже требует средств, и актуально когда оптимизационный потенциал выше затрат))
Есть компании клауд-нейтив, которые по своим причинам все продукты запускают в публичных облаках.
Есть сектора экономики, в которых паблик банально запрещен по требованиям ИБ.
А вы на своей инфраструктуре применяете FinOps?
Смотря как считать) Если сравнивать только стоимость железа и итого за облака за некий период — там разница в "Иксах". Если добавить все косвенные расходы, амортизацию и прочее, помноженное на скорость/гибкость/возможности облаков — то эта разница уже будет не такой значительной.
Это как с аутстаффом разработчиков) Это всегда дороже, чем взять в штат. Но есть сценарии при которых это будет явно выгодней. Как минимум, редко можно "уволить/заменить" позицию день-в-день
Про интим в точку)
Всё чаще вижу подход, при котором своя инфра стремится к 90+% утилизации. Что-то новое запускается в облаках, и , при необходимости, в нужной конфигурации перетаскивается внутрь.
И опять же, доступ к "неограниченным" и "легким" сервисам команды немного развращает. "Ну а чо, в любой момент срежем лишнее или вообще выключим)" Такой прыти при работе со своей инфрой не наблюдается.
Согласен про чих, каждый CPU и в своей инфре стоит условных "попугаев". Только финансистам такое спокойней, посколько новый инстанс не потребует денег сверх оплаченного.
FinOps не только и не столько про экономию. Но тем не менее, эффект экономии > трат (если прогнозируется меньше, то может оно вам и не надо).
А что касается провайдеров — они и "без экономии" это делают :)
Под "раньше" подразумевается работа с собственной инфрой. И берется за основу концепция, что за железо уже уплочено)
А при работе с публичными облаками каждый чих тарифицируется сверху