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

5 дієвих методів, з яких складається FinOps стратегія

Привіт, я Антон Грішко, клауд архітектор у Profisea Labs. Ми говоримо про FinOps, а саме про операційну модель для хмар, яка поєднує найкращі практики та культури для підвищення спроможності організації розуміння витрат на хмару та їх максимальну оптимізацію.

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

Отож, ця стаття буде корисною IT-менеджерам (CTO, CFO, CIO) і інженерам (девопсам, девелоперам та іншим), які постійно перебувають у пошуку дієвих способів розв’язання проблеми зростальних витрат на хмарі.

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

FinOps має значення

Популярність хмари продовжує зростати, як і проблема збільшення витрат на неї. Хмарна оптимізація є головною проблемою шостий рік поспіль. Звіт Flexera показав, що організації викидають на вітер 32% грошових ресурсів, запланованих на хмарні сервіси. Цей результат виріс з 30% у 2021 році, підкреслюючи тенденцію до зростання проблеми хмарних відходів. Чому?

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

Source: Info.flexera.com

FinOps — чи не наймодніше слово у хмарному світі. Це поєднання двох важливих відділів — фінансового та операційного, яке можна описати так: відділ управління витратами на хмарну інфраструктуру.

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

Source: Finops.org

Пряме поєднання фінансового та інженерного відділів типу «Тепер ви працюєте разом» — не варіант. І зараз я поясню, чому.

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

Більшість постачальників хмарних послуг пропонують модель оплати хмарних сервісів на вимогу, і це означає, що сервіси дуже легко і майже нескінченно масштабуються разом зі збільшенням робочого навантаження. На додачу, дуже важко прослідкувати розподіл ресурсів складних контейнерних інфраструктур, типу Kubernetes, де багато з них можуть бути прихованими для неозброєного ока.

В результаті, фінансова команда не може зрозуміти, як витрачаються гроші в хмарі. Інженери та продуктові команди не знають, як їх діяльність впливає на витрати на хмарну інфраструктуру.

Ось чому FinOps має значення. При правильному використанні FinOps практик команди долають бар’єр нерозуміння витрат на хмарі і максимально використовують кожен долар, який витрачається на хмарні ресурси.

5 дієвих FinOps методів, з яких складається FinOps стратегія

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

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

Попередні приготування

Готовність команд. Перш ніж інвестувати в розробку і впровадження FinOps стратегії, яка складається з конкретних методів, важливо переконатися, що ваша команда готова їх імплементувати. Можливо я озвучую прописні істини, проте, багато хто забуває підготувати спеціалістів до впровадження фінопсу і звідси починаються основні проблеми.

Команди мають розуміти методологію FinOps, визначати ключових гравців FinOps і гарантувати, що групи із закупівель, фінансів та інженерії існують не тільки на красивій картинці командної структури, а несуть реальну, рівнозначну відповідальність за змінні витрати у хмарі.

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

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

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

Welcome, інженери! Інженери розуміють, хто використовує хмарні ресурси та як їх потрібно використовувати. Тут не потрібно багато говорити, абсолютно зрозуміло, що ніхто так добре не розуміється в хмарних ресурсах, їх типах, розмірах і тому, для чого вони потрібні, як клауд експерти.

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

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

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

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

1. Забезпечити (або покращити, якщо вже є) візуалізацію хмарної інфраструктури і керування cloud waste

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

Source: Profisealabs.com

2. Підібрати правильний розмір для ваших інстансів

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

Це рішення має бути орієнтованим на конкретного користувача та спрямоване на коригування типу/розміру відповідного інстанса. Іншими словами, без експертної роботи тут не обійтись.

Source: Profisealabs.com

3. Організувати оптимальний графік роботи машин

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

Втрати можна легко побачити в простій формулі: наприклад, робочий тиждень складається з 5 робочих днів по 10 годин кожен: 10 * 5 = 50 годин, і це означає, що наші інстанси працюють лише 30% часу від загальної кількості годин у тижні (168 годин). Якщо ми не будемо зупиняти інстанси у неробочий час протягом тижня, то наші втрати будуть складати 70%, що і буде значним cloud waste.

Таким чином, було б цілком розумним рішенням зупинити ваші машини під час періоду простою і, за логікою, автоматизувати цей процес. Заплануйте автоматичний режим глибокого сну для ваших on-demand/spot інстансів, databases, autoscaling groups та Kubernetes кластерів, щоб оптимізувати використання віртуальних ресурсів і заощадити щонайменше 50% витрат на хмарні сервіси.

Source: Profisealabs.com

4. Застосовувати ефективну стратегію управління спотами

Споти, як правило, є найпродуктивнішим способом економії на клауді, пропонуючи знижки до 90%. Попри це, більшість компаній не повністю використовують цю можливість заощадити.

Постачальники хмарних послуг використовують спотові інстанси для продажу вільних ресурсів. Однак є одне маленьке «але,» яке полягає в тому, що споти можна від’єднати та повернути назад за найкоротший час, від 2 хвилин до всього 30 секунд.

Як правило, спотовий режим можна використовувати лише для процесів, які є можливість зупинити та перезапустити. Щоб сміливо конвертувати навіть важливі для бізнесу машини у споти потрібна ідеально розроблена стратегія керування спотовими інстансами.

Source: Profisealabs.com

5. Бронювати машини або/ також вміло користуватися сейвінг планами

Ефективно сплановані й керовані бронювання можуть допомогти вам отримати значні знижки.

Важливо проаналізувати поточне використання хмарних ресурсів, щоб із самого початку вибрати правильні атрибути резервування та розробити довгострокову стратегію моніторингу та керування вашими зарезервованими машинами й, згідно зі статистикою від AWS, зекономити до 72% витрат на хмарній інфраструктурі.

Source: Profisealabs.com

Далі буде

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

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

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному3
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

Поради хороші.
Також рекомендую подивитися в сторону серверлес інфраструктури замість інстансів.

Можете детальніше? Які основні критерії вибору цієї форми для яких ворклоадів? Які головні інструменти для автоматизації процесів?

Схоже рішення є для усіх клаудів але я буду писати про AWS:
у нас на проекті 0 ec2 інстансів. Повністю все на Лямбдах і на інших Амазон сервісах де вони потрібні. Сервісів багато.

Статика: CloudFront і s3
більшість іншого: Custom Domain => API Gateway => AWS Lambda
Бази даних: DynamoDB + Psql
Також багато використовуються: SNS, SQS щоб Лямбда відправивши реквести не ’чекала’ на відповідь.

Деплоїться 99% всього через Serverless Framework який робить купу всього за тебе.
Ворклоуди у нас на різні сервіси — різні, але є доволі значні, по декілька тисяч реквестів на секунду. В Лямбді вже вшито скейлінг, потрібно просто правильно архітектуру зробити щоб не весь код в одній лямбді був. Деви мають вміти це також, це не лише робота ДевОпса.

Також юзається багато інших ’обслуговуючих’ амазон сервісів.
В результаті кошти які виділяються на цю архітектуру просто Мізерні порівняно до ’звичайних’, бо коли лоуду немає то і оплати немає, відповідно ваші дев/qc/uat навіть квоту ФріТіра не можуть використати.

Для CI/CD у нас:
GitHub Actions + Terraform + Serverless Framework + AWS CodeBuild

Если юзер послал запрос в вашу систему (нажал та кнопку, запросил страницу, обновил форму и тд) как быстро он получит ответ?

Менш ніж 0.5 секунди, Якщо це `свіжий’ реквест, якщо на якомусь кроці використається кеш то напорядок швидше. Для цього юзаємо:
CloudFront + Lambda Edge + serverless-provisioned-concurrency-autoscaling

Дякую, цікаво.
В вас повністю задоволені таким рішенням чи розглядаєти альтернативи через якісь моменти?
Serverless Framework я так розумію, ви задоволені? На чому пишите ваші сервіси? (цікаво наскільки серверлес підходить для Java)
Як влаштували процес розробки? Ремоут-розробка чи імітуєте середовище локально. Наскільки все рівно працює (деви задоволені)?
По архітектурі, щоб вас не нагружати, маєте якісь цікаві лінки? Вона виходить досить специфічна. В вас був в команді хтось з цим досвідом?
Ну і можливо розглядали контейнери на базі серверлес?

В вас повністю задоволені таким рішенням чи розглядаєти альтернативи через якісь моменти?

Так повністю задоволені, рішення на порядок краще куберів і іншого.

В цілому, Serverless Framework я так розумію, ви задоволені?

Так, все ок. Якби з нуля, можливо щеб на SAM від AWS глянули

На чому пишите ваші сервіси? (цікаво наскільки серверлес підходить для Java)

.net3.1 нові сервіси на .net6.0
Так, Java цілком підходить. Якщо сапортиться в графі «runtime» то і може нормально працювати.

Як влаштували процес розробки? Ремоут-розробка чи імітуєте середовище локально. Наскільки все рівно працює (деви задоволені)?

є докер який збирає сервіс для простого дев середовища. Але деви тим дуже рідко користуються. в 95% відсотках ремоут розробка бо багато взаємодії сервісу з іншими сервісами. СіСд добре працює тому у тому немає проблем.

По архітектурі, щоб вас не нагружати, маєте якісь цікаві лінки? Вона виходить досить специфічна.

Гугліть «Serverless Architecture» & «Serverless AWS Architecture»

В вас був в команді хтось з цим досвідом?

я + толкові техліди + адекватні менеджери які готові до нового як у нас так і на стороні клієнта. Але то не весь наший ’ентерпрайз’, це у нас ’новий’ відділ, і потихеньку решта тім апдейтиться на нове, але то роки займе.

Ну і можливо роглядали контейнери на базі серверлес?

це крок назад. AWS це ввів бо багато команд не готові відразу в серверлес стрибати, а хочуть на контейнери перейти.

п.с. Існуючу вже архітектуру і/або код дуже важко на Serverless переводити, яб рекомендував це впроваджувати для нового функціоналу

Зрозуміло, дякую за відповіді!

СіСд добре працює тому у тому немає проблем.

Тобто пишеться код, потім робиться коміт, який тригерить деплой у AWS і потім є інструменти дебагу? Але кожну зміну потрібно проганяти через процес деплою? Скільки цей фідбек луп займає часу?

контейнери на базі серверлес?
це крок назад.

Ну скоріше більше вперед :)
Для прикладу, але не дуже детально: www.youtube.com/watch?v=iV7WrsxExdY

Скільки цей фідбек луп займає часу?

Луп — 5 хвилин

Ну скоріше більше вперед :)

все питання завжди в ціні і перформансі, якщо у вашому випадку ціна буде дешевше і перформанс кращий то без питань, у нас не так

можу ставити собі новий тайтл: DevSecChatGitFinOps

Будь-яка сфера стає виглядати в х-раз краще, якщо до неї додати ops
Хочете щоб ваша сфера стала звучати солідніше? Ops вирішить вашу проблему)

Когда облака небыли так популярны наклепали кучу статей про то как в облаке будет хорошо и как бизнес сэкономит кучу денег. Сейчас же много статей как сократить затраты в облаке. Конечно всегда хочется платить меньше. Но остается какое-то чувство легкого н̶а̶е̶б̶а̶л̶о̶в̶а̶ обмана...

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