Як пандемія змінює стратегію для клаудів і DevOps

Роль клаудів усе зростає, а в нових реаліях пандемії та закриття цілих країн на карантин стає критично важливою для багатьох бізнесів. Тому сьогодні компанії готові (а інколи й змушені) пройти extra mile, щоб швидко втілити ті зміни, на які довго не зважувалися. Адже це дає можливість не лише вистояти в турбулентні часи, а й отримати додаткові конкурентні переваги.

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

Які зміни спричинила пандемія

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

Зараз клієнтів можна розділити на три умовні категорії:

  • Неочікувано стрімко зростають — кількість клієнтів збільшилася в сотні разів за лічені дні. ІТ-інфраструктури компаній до цього не були готові, відповідно не можуть витримати такого навантаження. Сюди насамперед належать ритейлери із сильною онлайн-складовою, онлайн-сервіси та e-learning платформи.
  • Неочікувано стрімко падають — попит знизився майже до нуля, доходи падають. Найважливіше для цих компаній — скоротити операційні витрати до мінімуму, зекономити кожен долар, аби вберегти бізнес і втратити якомога менше людей. Зменшення витрат на підтримку ІТ-інфраструктури відіграє важливу роль. Саме в цьому компанії потребують нашої допомоги. У категорію потрапляють, зокрема, туристична галузь та офлайн-ритейл.
  • Поки що стабільні — теперішня ситуація мінімально вплинула на основний бізнес цих компаній. Але вони не знають, що їх чекає далі.

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

  1. Навіть ті компанії, які наразі у виграші, не готові до значних трансформацій та інвестицій в ІТ-інфраструктуру. Такі дорогі та складні послуги, як зміна архітектури чи модернізація програм, у найближчому майбутньому будуть актуальними лише для невеликої кількості компаній, які потребуватимуть діджитал-трансформації. Основна частина намагається не ризикувати та вкладати лише в те, що принесе миттєву користь.
  2. Фокус зміщується з довгострокових стратегій, які приносять більшу вигоду в далекій перспективі (від 1-2 років), на короткострокові, результат яких є слабшим, однак відчутним уже за кілька місяців чи навіть тижнів.
  3. Пріоритетом стає масштабованість (scalability) та ефективність як інфраструктури, так і бізнесу загалом. Адже нинішній, сильно збільшений/зменшений попит потенційно повернеться до попереднього рівня, щойно ситуація стабілізується. Але може статися і черговий різкий стрибок. Компанії розуміють, що їхня інфраструктура повинна швидко адаптуватися, щоб бізнес міг функціонувати в різних умовах. Це має відбуватися оперативно і без значних інвестицій (наприклад, без побудови датацентру, закупівлі серверів).

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

Тож виділю кілька ключових думок щодо того, куди рухається ринок DevOps і клауд-сервісів.

Оптимізація вартості інфраструктури

За даними State of the Cloud Report, у 2020 році 82% ентерпрайз-компаній вважають оптимізацію витрат на інфраструктуру в клауді основним пріоритетом. А для понад третини з них це великий виклик. З традиційними датацентрами ситуація ще гірша — більшість компаній стверджує, що не є оптимізованими і це призводить до перевитрати близько 30% ресурсів.

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

Коротко про те, який вигляд має оптимізація

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

Що отримує клієнт? Як засвідчує практика, реалізація короткострокового плану може скоротити бюджет на 15-30%, довгострокового — на 20-50%. Навіть для бізнесів, які пішли на спад, оптимізація витрат — це не тільки питання зекономлених коштів, а й інвестиція в те, наскільки швидко та ефективно вони зможуть відновити процеси, коли ситуація внормується і потрібно буде повертатися до активної роботи.

Один з наших останніх кейсів — клієнт витрачав понад 300 тис. доларів на місяць на підтримку клауд-інфраструктури в Azure, при тому вона була досить непогано оптимізована і використовувала більшість best practises. Компанія прийшла до нас у кінці лютого із запитом скоротити цю суму щонайменше на 35%, щоб мати змогу зберегти команду. Станом на кінець березня нам вдалося зменшити її до 243 тис. доларів, до кінця квітня — до 157 тисяч. Серед основних кроків, які допомогли цього досягти, виділю такі:

  • Об’єднали регіональні Dev/QA/UAT в один глобальний розшарений Kubernetes-кластер.
  • Залишили на виділеному пулі серверів лише ворклоади, які погано переживають перезапуск. Більшість ресурсів у кластері живе на спот-інстансах.
  • За допомогою автоматизації перевели більшість QA/UAT на on-demand модель, де середовище стартує лише тоді, коли воно потрібне, і автоматично зупиняється за деякий час.
  • Внесли багато змін до профілю ресурсів для зменшення їхнього performance. Це вплинуло на такі метрики, як Build Time/Test Time. Але оскільки під час кризи процес розробки перейшов у режим «лише пріоритетні продукти», загальна кількість комітів, білдів зменшилась, завантаженість всієї системи теж знизилася, відповідно Time To Production (Market) майже не змінився.

Ви можете спитати, чому до цієї оптимізації дійшли лише тепер? Адже все можна було зробити і в спокійні часи. І ви маєте слушність, цю інфраструктуру і процеси варто було оптимізувати вже давно. Частина з цих імпрувментів була навіть закладена в цьогорічному плані. На жаль, тільки криза допомогла бізнесу зрозуміти важливість ефективності їхньої ІТ-інфраструктури та процесів. Лише загроза втратити цей бізнес підштовхнула нарешті пріоритезувати час девелоперів на потрібні зміни в коді, сфокусувати автотести і DevOps-команди на розробку нового підходу для тестування продуктів та інфраструктури. Вже зараз менеджмент активно планує розгортання цього нового підходу на Production, що допоможе зекономити ще приблизно 30-40 тис. доларів на місяць.

Як результат компанія буде мати вдвічі більше cost-efficient інфраструктуру, ніж до цього.

Розширення інфраструктури завдяки використанню публічних клаудів

Ведення основної діяльності у власних датацентрах має значні недоліки, серед яких високий TCO (total cost of ownership) при низькому ROI (return of investments) і складність масштабування потужностей. Тому все більше компаній почали переходити на гібридні клауди. За даними IDG, кількість організацій, які хоча б одну програму чи частину інфраструктури ведуть у публічному клауді, зросла з 51% у 2011 році до 73% у 2018 році, а на сьогодні вже перевищила 90%. Близько 44% організацій вже використовують одночасно приватний і публічний клауди, щоб надавати один зі своїх сервісів.

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

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

Близько 2/3 компаній, які почали переходити на гібридну модель, в клаудах розміщували лише нові проєкти, але не були готові вкладати ресурси в перенесення туди основного бізнесу, що приносить найбільше доходів і на який значно посилилось навантаження зараз. В таких випадках гібридний клауд виглядає так: весь основний бізнес ведуть у датацентрі, нові проєкти запускають у клауді, але все одно зв’язуються з датацентром, щоб використовувати ті дані, які в ньому зберігаються. Відповідно те, що ці компанії мають ресурси в клауді, не допомагає у ситуації, коли потрібно швидко масштабувати основний бізнес.

Про мультиклауд

Ще одна актуальна проблема — те, що не лише компанії переживають зростання навантаження на сервер, а й клауд-провайдери. Наприклад, навантаження на Azure за березень збільшилося на понад 700%. Це впливає на його користувачів — деякі з них дуже залежать від доступних ресурсів для short-time bursts. Оптимальне рішення в такій ситуації — розширитися на інший публічний клауд.

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

Що ці зміни означають для DevOps-інженерів

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

Із ключового: експертиза в роботі з клаудами та контейнерними платформами — must have, без цього важко знайти проєкт. Не дуже віддалена перспектива — рішення для гібридних/мультиклаудів і Workload Mobility: Google Anthos, OpenShift і VMware Taznu.

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

LinkedIn

23 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

У нас в епаме кстати hybrid. Где требуется гибкость, быстрая разработка, инновации, тех везем в Azure, в кубер. Где проекты на саппорте или имеют sensitive information, те на on-premesis. Кстати, зря вы не упомянули такую действенную технику оптмизиации костов, как overcommitment. У меня в кластере overcommitment по CPU например почти 100%, то есть совокупные лимиты выше чем реальный cpacity. И в случае превышения — автоскейлить кластер и поды, что происходит довольно редко.

Це вплинуло на такі метрики, як Build Time/Test Time.

А какие у вас еще метрики?

Ведення основної діяльності у власних датацентрах має значні недоліки, серед яких високий TCO (total cost of ownership) при низькому ROI (return of investments)

html.scirp.org/file/7-2121263×6.png

шукав давно таку картинку :)’

але по ROI — ви не праві, ROI залежить від моделі, витрати лише складова ROI. Цілком можна мати високий ROI при високих витратах

Інша річ — як цей ROI визначається — зазвичай в паверпойнт людьми які ці клауди продають :)

Станом на кінець березня нам вдалося зменшити її до 243 тис. доларів, до кінця квітня — до 157 тисяч

Эх, а сколько можно было сэкономить слив все кроме прода на on-prem) Думаю с учетом своего железа окупилось бы за второй месяц)

окупилось бы за второй месяц)

за четвертый
видел где-то расчеты, что оплата полноценной VM в public cloud за три месяца — уже равна стоимости приобретения аналогичного железа

Я такі теж бачив, а потім допомагав з кліенту з RFP для екстеншену і ось
результат реальної квоти(найдешевша з 7 вендорів) від дуже відомого постачальника заліза в США на наступний реквест:
1000+ CPU Cores (Xeon-based 2Ghz/core), 15TB RAM minimum, 150TB Storage 500k IOPS Minimum)
DC Option:
+ $3.2M Hardware Only
— $1.5M Discount (з коммітментом на те що через 3 роки ми будем реньювати залізо на таку ж, або дорожчу конфігурацію)
+ $0.6M Installation & Setup Services
+ $0.8M 3Y Fixed DC Operations and service costs
Fixed TCO 3 YEAR: $3,1M

І альтернативна опція з використанням VMware Cloud on AWS:
VMC Option
+ $1.6M VMC Fixed 3 Year Commitment
+ $0.3M Integration Services. Fixed Price
— $0.3M PS Funds over 3 Year
Fixed TCO 3 YEAR: $1.6M
І основний бонус, це час. Бо з хардварною опцією, ми б побачили готову до роботи інфраструктуру через 6 місяців. З VMC ми вже через 6 тижнів мали 40 кліентських енвів в проді на цій системі.

Щось мені не віриться що сторедж в 150tb на aws та трафік за 3 роки в тому тсо порахований

І перформанс в 500к iops у клауд сторедж? Ага

очевидно, что в hardware конфигурации был недешевый SAN storage, а в варианте с VMware Cloud on AWS — только локальная хостовая дисковая, со всеми вытекающими

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

$3.2M Hardware Only

сколько в этом всем стоил SAN storage?

1000+ CPU Cores (Xeon-based 2Ghz/core), 15TB RAM minimum, 150TB Storage 500k IOPS Minimum
VMware Cloud on AWS

cloud.vmware.com/vmc-aws/pricing
i3.metal
36core/512GB/NVMe (3.6 TiB cache plus 10.7 TiB raw capacity tier)
$109,366.25 / 3 years — $173,616.68 / 3 years (в зависимости от локации)
$109,366.25×30 = 3,280,987.5$ (30 таких хостов — это минимум, чтобы набрать озвученные изначально 15TB RAM)

3.2+M это никак не 1.6M
2х дискаунт? или ресурсов в предложении все же в разы меньше, чем в первоначальном реквесте?

далее
в этих i3.metal используются, мягко говоря, уже немолодые Intel Xeon Processor E5-2686 v4 четырехлетней давности
свежий конфиг на таких уже не посчитаешь, только б/у
но, в плане производительности, эти 60хXeon E5-2686 v4 (18-core) можно заменить 16хAMD EPYC 7742, да даже и 7702 (64-core)
сервер HPE Proliant 385 G10 plus 2xAMD 7702/2TB RAM/4×15TB NVMe ~180K USD (североамериканский прайс)
VMware vSphere (Enterprise Plus) на 3 года для такого сервера 21.5K USD
8×201.5=1612K USD, это без скидок
со скидками в эти же 1.6М войдет и стоимость колокейшена
наверняка можно прикинуть варианты дешевле, но мне лень
а если выкинуть из конфигурации хостов 32×15TB NVMe — то вместо них за те же 0.5М вполне можно взять внешний all-flash storage с искомыми «150TB 500k IOPS», при чем с NVMe over Fibre Channel

Я так і не помітив чіткого висновку куди, власне рухаєіться DevOps, але читати було цікаво.
Думаю, ідея була, що в сторону hybrid.

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

Прискорить впровадження hybrid та мульти-клауд hybrid моделей, і ось чому, Будь-який ресуерс в клауді перепродається кінцевому тенанту 2-3 рази. Гігабайт SSD за своє життя наприклад. Про оплату трафіку, коли клади купляють його оптом — це взагалі нонсенс для мене

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

Не згоден що ДЦ мають якийсь вроджений недолік масштабування. Це можливо відноситься до ДЦ 2000их, але тверезо, — чомусь ДЦ AWS чи Azure масштабуются на ура для Amazon та Microsoft. Компанії, що можуть собі дозволити такі ДЦ — дозволять їх собі. Так само як когорта великих ISP, які так само запустять контейнери, як і AWS. Хто сильно зав’язався на своїх клаудах — тим доведетья слізно й з кров’ю відв’язуватись.

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

Я думаю, ця криза тільки прискорить розуміння, що мати більше контролю і стабільності у витратах — а це і досягається розумним CAPEX у хороші часи, — все ж краще ніж опачувати поламані пайплайни на CI/CD, чи DEV/UAT енви втридорога у cloudах

Тому оптимізація тут, я згоден, неминуча і буде масовою в наступні 3-5 років, і спрямується вона в мульті-клауди й hybrid, коли при бажанні все швидко зможе перетекти в ДЦ, а коли вийде сонечко і зросте турновер — можна буде швидко витекти в клауд. І критерієм розміру ДЦ завжди буде profitable worst-case scenario.

Дякую за статтю

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

похивлинної й швидкої скалабіліті

тут теж згоден. Якщо у компаннії зараз дирка в дні, то те що вони можуть зараз «гребти» швидше не спасе їх бізнес в цілому. Якщо за рахунок зєкономлених коштів просто намагатися продовжити собі життя і перечекати кризу, то в кращому випадку компанія втратить стої позиції на ринку, а в гіршому — піде на дно, але трішки пізніше.
В цілому, криза стала «wake-up call» для багатьох компаній, що їх IT це не просто неминуча ціна яку вони плятять за свій бізнес, а невідємна частина їх бізнесу.

А яка ваша думка про Tanzu? Я помітив, що ви згадали, цікaвить чи має воно з вашої точки зору майбутнє як hybrid-cloud. Цікаво з саме конкурентних переваг, звісно певна частина онсайт просто купить ліцензії на апгрейд аби просто не вкладатись в нові рішеняя.

Я був дуже оптимістичний про Tanzu, але попробувавши, мені очевидно що вхід у k8s на vmware-платформі дуже високий як з точки зору technology skill gap, так і з точки зору ціни

Набагато простіше й дешевше піднімати k8s на vm-ках на мій погляд, ніж зав’язуватись на vendora, переплачувати за аддони, й тримати в штаті лобастих NSX архітекторів, без який цю танцу ні запустити ні підтримувати

І ще більш дешево переїхати на якісь опенстеки

В паверпонті Tanzu виглядає круто, буквально тиждень назад отримали доступ в Tanzu Mission Control і нові збірку TKG. Перевіримо тепер на практиці.
Але наскільки технологічно крутий солюшен, мало впливатиме на вібір бізнесу. Інша справа, що у VMware приблизно 70% on-prem ринку зараз. Основна «фіча» Tanzu зараз це те, як VMware це продає своїм же кліентам майже за безкоштовно разом с VMC (VMware Cloud on AWS, Google наздоганяє з VMware Engine). При тому, відиляючи на 2020-2021 сотні мільйонів під Professional Services на інтеграцію.
Серед мультиклауд солюшенів для Enterprise, це зараз дуже сильний гравець. IBM з OpenShift теж не пасе задніх і вливає мільйони в PoC для своїх кліентів.
Моя персональна трійка зараз: Tanzu, OpenShift, Anthos.

А розкрийте ще про майже безкоштовно? Я сам кастомер і у нас 6.7, апгрейд плюс аддон коштуватиме добряче вже, а засетапити NSX-T уже ще та задачка, а з WM так взагалі, я не уявляю SMB який подолає цей шлях і не розіб’є пару джойстиків

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

Я зараз теж не покладаю багато надій на те що це прод-солюшен, але вже маємо кастомерів з підписаними комітментами на Танзу. По «майже безкоштовно» давайте в ДМ.
А для тих кому цікаво «якщо ваш кліент або компанія в топ 20% у VMware, або у лого яке у всіх на слуху», то у вас тут багато можливостей конвертнути свої ліценції, отримати знижки и жирний PSF бюджет)

Маю ще один результат оптимізації бізнесу і R&D для девопс інженерів — очікування автоматичних\лоад тестів, секюріті аудитів, архітектурних змін, кост оптимізацій, датаопсу та ETL pipelines, py\lambda\custom API\golang\serverless використання, датабейс\даталейк девелопера скілів, скрам консультантом і всі інші приховані очікування за сучасних t-shirt skills era

Крутая статья! как раз работаю в компании, которая помогает экономить на AWS и Azure. Пишите в личку кому интересно

навантаження на Azure за березень збільшилося на понад 700%

Це дуже погано перекладене речення, якщо воно і було звідкись перекладене. Збільшилась кількість користувачів хмарних сервісів Azure, більше чим на 700%, проте навантаження не збільшилось на 700%.

Все вірно. Після 4 раундів правок, контекст змінився, а очі вже бачили, що хотіли.
По контексту, кількість користувачів виросла на 775%, але на цю цифру треба дивитися з долею скептицизму. Бо це лиш нові зареєстровані акаунти, а процент з них буде реально використовувати Azure після тріального періоду, IMHO, буде дуже далекий від цього.
Що ж до реальної проблеми, то під час пікових періодів, один з наших великих онлайн-ритейл кліентів мав великі проблеми з запуском додаткових інстансів для AKS, та пропускною здантістю деяких Azure сервісів в Європі.

кількість користувачів виросла на 775%

в основном, наверно триальные учётки после серии их вебинаров

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