Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Роздуті хмарні рахунки — проблема, з якою не можуть впоратися 6 років. Говоримо про рішення для хмарних витрат

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт, я Антон Грішко, головний клауд архітектор у Profisea Labs. Як архітектор DevOps з більш ніж 10-річним досвідом у створенні складної інфраструктури та автоматизації процесів розробки, я наразі керую професійними технічними експертами для створення економічно ефективних і високопродуктивних хмарних рішень, на основі найкращих DevOps/CloudOps практик.

За останні кілька років ІТ-організації енергійно перенесли свою інфраструктуру в хмару, і правильно зробили, враховуючи, наскільки хмари ефективні для бізнесу. Але, як завжди буває, не обійшлося без «trouble in paradise» — вже шість років поспіль витрати на хмарні сервіси постійно зростають. Отож, я впевнений, що ця стаття, де ми поговоримо про потужне рішення проблеми хмарних витрат, буде вельми корисною як представникам IT-лідерства — бізнес овнерам, менеджерам, CTO, CFO, так і інженерам (девопсам, девелоперам і іншим), в обов’язки яких таки входить контроль за витратами на клауді.

«Чому інженери?» — спитаєте ви. Від компанії до компанії вимоги до технічних спеціалістів різні — і на сьогодні існує зрозумілий тренд залучати команду технарів до фінансових справ проєкту. Комусь це подобається, комусь — ні, але це наша реальність, до якої декому прийдеться пристосуватись.

Прохолодно і хмарно — це добре, хоча пустити трохи сонячного світла для ясності не завадило б

За даними Flexera State of the Cloud Report (одне з багатьох хмарних опитувань), 36% керівників ІТ-бізнесу (із 750 респондентів) заявили, що їхні щорічні витрати на хмару перевищили 12 мільйонів доларів США, а 83% сказали, що їхні витрати на хмару досягли 1,2 мільйона доларів на рік. Згідно зі звітом, оптимізація хмарних відходів є найголовнішою проблемою в хмарі вже шостий рік поспіль, що випереджає переміщення більшої кількості робочих навантажень у хмару та покращення фінансової звітності про витрати на хмару.

Хмарні витрати зростають? Дурниці! Саме існування хмар має за мету знизити витрати бізнесу, чи не так? Так це правда, але за іронією долі, згідно з новими даними, фахівці називають гігантські $45 мільярдів витрат на хмару щорічно, розкриваючи «...маленький секрет про хмари, що рахунок ніколи не зменшується», — стверджує FinOps Foundation. Дане опитування продемонструвало значне збільшення витрат на хмару й відчайдушну боротьбу за їх контроль та оптимізацію.

Source: Data.finops.org

До того ж, якщо обмірковуєте перехід в епоху штучного інтелекту (ШІ) — від чого, звісно, не буду відмовляти, адже згідно з дослідженням ARK, загальна вартість компаній зі штучним інтелектом досягне $87 трлн, тут є над чим поміркувати. Опанування моделями ШІ — задоволення не з дешевих. Наприклад, у 2021 році знадобилося $2,5 мільярда, а у 2030 році це коштуватиме вже $600 000. А тепер уявімо, що компанія зі складною інфраструктурою на хмарі планує розвивати штучний інтелект — витрати такої компанії важко спрогнозувати, враховуючи, що компанії, які вже давно працюють з рішеннями AI, витрачають 25% своїх доходів на хмарні ресурси.

Темний ліс: чому витрати на хмарні сервіси щорічно зростають

До появи хмар у нас була локальна інфраструктура, і процес отримання нового обладнання був досить простим, хоч і займав багато часу. Якщо вам потрібно було додати більше послуг у ваш центр обробки даних, ви фактично зверталися до фінансового відділу вашої організації, і вони робили закупівлю за вас. Звичайно, ця модель не була ідеальною, і компанії «гралися» з приміщенням та їх обслуговуванням, однак фінансова частина була під контролем, і команди знали, яка команда або персона керує процесом.

Потім з’явилися хмари, і я, як DevOps, із задоволенням вітав хмари через усі їх переваги. У той самий час з’явилася досить велика проблема — процес закупівлі був порушений, адже будь-який інженер DevOps міг по суті запросити ресурс, і споживання ресурсів виходило з-під контролю. У більшості випадків компанії не можуть стежити за тим, скільки грошей вони витрачають. В результаті виникла потреба в організації залучення фінансової грамотності до процесу управління хмарами. Саме тут FinOps приходить на допомогу, оскільки основна ідея FinOps полягає в тому, щоб надати найкращі фінансові методи для оптимізації витрат на хмару.

Інженер FinOps або команда FinOps є обов’язковою умовою для ІТ-організацій. Як показано на цьому графіку, експерт FinOps наразі дуже популярна професія, і їхня кількість продовжує зростати.

Source: itjobswatch.co.uk

Ви, напевно, також думаєте, що вартість хмари завжди пов’язана з автоматизацією. Ми можемо просто автоматизувати все для оптимізації нашої хмарної інфраструктури. Автоматизація таки допомагає оптимізувати процеси та підвищити продуктивність, але це не єдине рішення для всіх. Цей графік показує, що майже половина компаній (доволі успішних) взагалі не мають автоматизації.

Source: globaldots.com

Тож автоматизація — чудова річ, але компаніям знадобиться багато часу, щоб автоматизувати хмарні процеси, в той момент, як вони вже витрачають купу грошей на свої хмари. Отож, що можна зробити?

Потужне рішення для зменшення хмарних витрат або що таке FinOps

Gartner стверджує, що витрати кінцевих користувачів на загальнодоступні хмарні послуги, як очікується, сягнуть $482 мільярдів у 2022 році. Крім того, оскільки постачальники публічних хмарних послуг зараз повсюдно поширені і ринок перевантажений послугами, розповсюдження хмарних сервісів зараз спричиняє повну дезорієнтацію для неспеціалістів з хмари. Саме тому, керівникам IT-бізнесу, менеджерам IT-проєктів та і просто відповідальним інженерам IT-команд FinOps необхідний як повітря. Що ж це за звір такий FinOps?

За словами FinOps Foundation,

«FinOps, як операційна модель для хмар — це система поєднання, найкращих практик та культури для підвищення спроможності організації розуміти витрати на хмари та оптимізувати їх».

Більше про ключові функції FinOps, такі як принципи, фази, домени та особи, можете почитати тут.

На мою думку, кожній компанії необхідно мати інженера, роль якого полягала б у тому, щоб тримати ресурси компанії під контролем. Цей інженер повинен відповідати за: планування бюджету ресурсів, закупівлю ресурсів, використання ресурсів, відстеження ресурсів, звітування про ситуацію зі споживанням ресурсів, прогнозування ресурсів тощо, головне — за розробку стратегії оптимізації ресурсів. Цей спеціаліст і є FinOps. За наявності великої кількості визначень самого поняття, для мене FinOps — це дуже особлива методологія, яка в основному означає, що організації кооперуються зі спеціалістом, який відповідатиме за стратегію оптимізації витрат на хмару.

На додачу скажу, що існує поширена помилка, що FinOps — це про економію грошей. Насправді FinOps — це набагато більше про заробляння грошей. Витрати на хмару, за умовою, що гроші витрачені правильно — збільшують дохід і допомагають бізнесу розвиватися. Однак, кожна компанія повинна бути впевнена, що певний набір хмарних ресурсів насправді є цінним. З цієї точки зору фахівець FinOps має зосередитися на прийнятті рішень в режимі реального часу щодо використання хмари, розподілу витрат на хмару, а також виявлення аномалій споживання хмари та забезпечення ефективних витрат. Все це вимагає гідних навичок управління проєктами та гнучкості: фахівець FinOps повинен вміти оптимізувати витрати на хмару, щоб не знижувати швидкість інновацій — надмірне і, що більш важливо, невиправдане зниження витрат на хмару матиме свої негативні наслідки.

Як ми організували FinOps — історія з власного досвіду

Де ж набратися тих FinOps спеціалістів, адже роль FinOps з’явилася лише кілька років тому на ринку. Першими компаніями, які запровадили його на початку 2010-х років, були такі перспективні підприємства, як програмний гігант Adobe та Intuit, багаторічний лідер у сфері фінансових інноваційних технологій. Термін FinOps навмисно нагадує DevOps, щоб підкреслити його приналежність до світу ІТ.

FinOps — саме такий спеціаліст, який поєднує в собі найкраще з обох світів — технічне та фінансове. Загалом, фахівці FinOps дуже потрібні тим компаніям, які залежать від хмарних сервісів (а це 94% усіх IT-організацій) і водночас прагнуть зробити витрати на хмарні сервіси свідомими, оптимальними та максимально прозорими. Щоб це реалізувати, фахівець FinOps повинен відповідати за прискорення оптимізації витрат на хмару, досягнення повної прозорості витрат на хмару та створення спільної міжфункціональної команди інженерів.

Що зробили ми в Profisea Labs? Ми прийняли в команду фінансового аналітика з величезним досвідом і за декілька місяців навчили його основ DevOps, достатніх для того, щоб розуміти як працює дана методологія. Тепер цей готовий FinOps — розвиває FinOps команду, співпрацює із DevOps командою і ефективно працює із витратами на хмарі клієнтських інфраструктур.

Далі буде!

Як і свого часу DevOps, так сьогодні FinOps — тренд, який швидко набирає оберти. Ця професія поступово визнається у всьому світ: у LinkedIn популярні списки вакансій для менеджерів FinOps у великих хмарних організаціях та провідні світові ІТ-підприємства набирають цілі команди FinOps, які розробляють автоматизовані системи обліку витрат і пошуку оптимізації витрат при використанні хмарних сервісів. Причина? У сучасних ІТ-компаніях, які покладаються на хмарні сервіси, важко підтримувати прибуток без оптимізації витрат на ІТ-інфраструктуру, а отже важко обійтися без грамотного спеціаліста FinOps.

Дана стаття — це тільки початок серії статей, присвячених методології FinOps. Очікуйте у наступних роботах більш детальні розбори найкращих FinOps практик, методів, тактик, помилок та інструментів. Також ми поговоримо про FinOps спеціалістів, розберемо їх обов’язки, навички, roadmap, зарплати, наведемо приклади гарно оформлених FinOps резюме та надамо поради щодо FinOps інтерв’ю.

Сподіваюсь, ця інформація була корисна. До нових зустрічей.

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мені ще років із п’ять тому наш СТО, на питання «чому ми не в клауді» відповів: щоб ми з тобою заробляли гроші собі, а не власникам клауду :)

А, якщо ваш CTO так сказав — то клауд фігня, так ))

Де я написав, що клауд фігня? Я про те, що він може стати дуже коштовним, як і написано в статті. А навіщо ділитися доходами з власниками клауду?

для маленьких компаній частіше саме так. Скейл це те, для чого потрібен клауд в першу чергу.
Все питання в масштабі/розмірі.
Це як з сортуванням масиву, якщо в тебе тільки 10 елементів в масиві, то простіше посортувати бульбашковим алгоритмом, квиксорт кодити не має сенсу.

Переклад: виявилось, що «здоровий глузд» та «фінансова дисципліна» переходом до хмари (чи навпаки) не замінюються. Голова людині дана не тільки щоб в неї їсти, а й щоб і думати. )

архітектор DevOps з більш ніж 10-річним досвідом у створенні складної інфраструктури

Це ж ваш брат останні 10 років запевняв весь світ що нема життя поза хмарами,
що будь-який хеловорлд має бути клауд-нейтів,
що перш ніж написати хоч строчку коду потрібно розгорнути дженкіс, кубернетіс, тераформ, а всьо то обмазати АВСом,
то ж ви пропихували скрізь мікросервіси, які жеруть х10 ресурсів просто так,
то ж ви малювали архітектурні схеми, де будь-яка мілка срань має бути обов’язково прибита до АВС, бо інакше не феншуйно

А тепер ой, будем рішать чому наш бізнес платить амазону більше, ніж платить податків.

Багато мілкої срані в клауді можна хостити взагалі безкоштовно. Значно цікавіше питання: як без клауду можна швидко зреагувати на різкий (10-100x) зріст навантаження, а потім його повернення до нормального стану?
ІМХО, Hybrid Cloud — єдине на даний момент рішення, що дає хоч якусь впевненість у завтрашньому дні.
А питання overprovisioning і тупо забутих десь у хостера серверів швидко виникає і в будь-якій on-premises інфраструктурі і я не бачу суттєвої різниці в порівняння з хмарним оточенням. Disclaimer: я маю на увазі людські оточення з budget limits & alerts.

як без клауду можна швидко зреагувати на різкий (10-100x) зріст навантаження

Почнемо із того, що якщо ваш софт написаний правильно, а не студентом на піхтоні, то він апріорі не має якось особливо реагувати на х10.

х100 — то вже залежить від того, що ви робите, але загалом теж чогось особливого не має буть. Ну добре, задеплоїли ще кілька серваків у кластер, і що?

От якщо х1000-10.000 то тоді вже да, треба щось думати

А тепер подумаємо над сенсом вашого питання — а багато є шансів що деякий бізнес РАПТОМ отримає х100-10.000 зростання запитів/користувачів, а потім так само раптово втратить?
Це справді той сценарій, до якого потрібно готуватись, закладаючи аxyєнно дорогий вендор-лок (а авс це і є вендор-лок) із самого початку проекту?
Я вважаю — ні.

Але ж ефективні менеджери продали всьому світу ідею, що якщо ти не мікросервіси в клауді то ти лох.

я не бачу суттєвої різниці в порівняння з хмарним оточенням

Особисто я — не прораховував. Але маю багатьох знайомих, які рулять розробкою у реальних бізнесах із реальними продакшенами, хостяться на землі, і кажуть шо рахували — всі як один кажуть що хмара то просто космічна перевитрата коштів по зрівнянню із їх затратами на землю.

От якщо х1000-10.000 то тоді вже да, треба щось думати

про, зазвичай <20% усієї системи, які є bottleneck’ом.

всю інформаційну систему пхати у хрестоматійний клауд — раціонального сенсу навряд чи буде

зазвичай <20% усієї системи, які є bottleneck’ом.

Я більше скажу, ботлнеком є в 99% випадків треди у фіксед сайз пулах, які чекають на довгих синхронних операціях. Ну а на фізичному рівні скільки тредів може реальнг витягувати проц. Потужні проци, грамотна робота з багатопоточністю, менеджмент тред пулів, асинхронність де потрібна, і не буде ніяких ботлнеків. Але із моєї практики майже ніхто не вміє в треди навіть на простому рівні.

А я співпрацював з великою кількістю замовників, які, після всіх розрахунків, прийшли до висновку, що hybrid cloud модель для них є оптимальною, дозволяючи використовувати дешевші власні сервери для BAU і швидко масштабуватися в клауд при нагальній потребі. Також для динамічних dev/qa оточень, де певний інстанс взагалі може бути спотом і жити собі півгодини, я важко уявляю собі рішення на залізі. Мабуть, єдине, що приходить в голову — це свої гіпервізори з overprovisioning на такі випадки.

Знову ж таки, в іншому треді я вже підіймав питання DR оточень для яких будь-яка схема, окрім backup/restore та multisite виглядає економічною катастрофою в порівнянні з клаудами.

Прошу мене зрозуміти правильно: я не кажу, що baremetal не потрібен і поганий. Я кажу, що існують ситуації, в яких клауд виходить фінансово дешевше, не кажучи вже про його flexibility та elasticity.

багато є шансів що деякий бізнес РАПТОМ отримає х100-10.000 зростання запитів/користувачів, а потім так само раптово втратить?

ДДОС?

Серьозний аргумент.

1) при сучасних можливостях розгорнути ддос атаку, я не думаю, що клауди сильно допоможуть. Припустимо, що ви вижили, коли на вас направили 100500кк запитів/сек. Скільки ви потім заплатите за це хмарі? 100500$? А чи варте воно того було?

2) ви що, російський мід чи мінвторгнення щоб вас ддосити?

3) якщо ваш бізнес вже настільки великий щоб вас бог десь наказував вас за щосьддосили, то у вас мають бути кошти і на резервний сервак.

Серьозний аргумент.

Ні, я зовсім не хотів аргументувати. Тільки поцікавився можливими випадками такого різкого стрибка «популярності». То ж виходить — це єдиний кейс? На все інше можна приготувати заходи?

Лень читать. Шо там, серверлесс безпонтовый пытаются впарить?

Давайте по сути — 20к/мес будет или нет?

Бухгалтер со знанием terracost? Мб и 30к/мес. Грн.

В Україні поки бачив лише одну вакансію на FinOps інженера і поки не зрозуміла вилка ЗП. А ось в США якщо вірити сайту indeed.com то — $106K — $134K a year is Indeed’s estimated salary for this role in Remote

Если избавиться от облачных сервисов — вполне можно не нанимать и FinOps-инженеров.
Двойной профит!

Ця історія ж не про треба чи не треба клауд, комусь треба, комусь ні. Але тим кому треба — потрібно слідкувати за костами, бо забувають/забивають

Доречі щодо заліза звичайного — враховуйте витрати на оренду приміщення, оплату комунальних, заробітню плату інженерів, та на заміну того самого заліза, а також на неможливість швидко заскейлитись чи дескейлитись

А ще враховуйте ситуації, коли сервери не під 95% навантаженням, я деякі з них тупо забули, не зробивши decommissioning після EOL якогось з сервісів :)

У нас подумали, подумали і вийшло що дешевше купити серваки, ніж використовувати аналогічні потужності амазон.
Також використання слова «сім’я» по відношенню до компанії, то червоний прапорець.

Многие просто ляпают не думая)
Пусть попробуют пойти у директора долгануть на первый взнос на ипотеку — сразу семейный флер развеется)))
«Ну а шо, мы ж семья. А вы мне как отец родной)»

Не просто дешевше, а ще й надійніше. Бо у власний сервак ви ніколи не поставите компоненти класу «супер-дешево». А досвід Parler довів, що Амазон так само танцює під Дермократів USA. Ви можете втратити все лише тому що вас вважають мешканцем окупованих територій.

А будувати DR по схемі «Cold Standby», чи «Pilot Light» Ви як пропонуєте без клаудів? Я розумію, що без вимог до RTO/RPO можна і колегу зі стрічковими накопичувачами можна в ДЦ пішки відправити, а якщо вимоги є? Чи буде дешевше тримати копію продакшена вимкненою в іншому регіоні в порівнянні з клаудом, враховуючи, що все обладнання треба буде купити, поставити в стойки, заплатити хостеру за розміщення, порти, електроенергію і інші опексні речі?

Ніхто ж не каже, що клауди не потрібні. Просто клауди, як і усе новомодне, мають давно вже припинити бутми релігією і стати тривіальним інструментом. Для чогось вони підходять, для чогось не дуже, а для задач з підвищеними вимогами до надійності критичних даних — просто непомірно ризиковані.

Задачі масштабування — це майже 100% хмарний ринок. Особливо якщо масштабування є венчурною задачею, і може стати непотрібним досить скоро.

чувак кінчай всюди писати свою дурість про ненадійність зберігання критичних даних у клауді. географічна розподіленість дата центрів, копій даних, до рівня коли втрата багатьох копій високо гарантовано (девять девяток) НЕ призведе до втрати даних. ти й десяту частину надійності НЕ ЗМОЖЕШЬ забезпечити самотужки.
клауд дорого — буває, є певні ситуація коли важлива low latency і клауд не підходить. але про надійність зберігання даних... це очевидна дурість рівня «земля пласка»

Підписатись на коментарі