Архітектура на AWS. Яких помилок ми припустились

Я Руслан Кусов, Senior Solutions Architect у SoftServe і лідер AWS-кластеру. Недавно мій колега писав статтю про топ архітектурних помилок з власного досвіду, і я вирішив теж поділитися кейсами моєї команди. Адже робота над помилками допомагає сформулювати висновки та уникнути схожого в майбутньому. Сподіваюся, наш досвід допоможе ще комусь.

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

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

Ілюстрація Марії Рибак

Випадок № 1. Неузгоджений план гірше, ніж його відсутність

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

Стейкхолдери (спонсори міграції) на боці клієнта добре розуміли принципи AWS landing zone, вони погодилися з усіма нашими пропозиціями, зауваживши лише те, що у них теоретично може бути VPN з дата-центром і є SD-WAN, який бажано буде налаштувати у майбутньому, але зараз це непринципово, крім того, цим будемо займатися не ми, а їхня інженерна команда. Загалом умови були привабливими: свобода вибору, «правильні» стейкхолдери й обіцяна підтримка інженерів з боку клієнта.

Ми зрозуміли, що оптимально буде використати AWS CloudFormation для розгортання ресурсів, бо він простіший, зокрема і для централізованого менеджменту AWS хмари. Усе мало бути добре, однак...

Що пішло не за планом

Проблеми з’явилися вже на першому тижні роботи. Ми побудували landing zone і були готові переходити до фінального етапу, коли виявилося, що нам все-таки треба налаштувати SD-WAN і зробити так, щоб через неї можна було збирати дані з віддалених центрів. І що це взагалі головний критерій успіху проєкту. Це стало першим тривожним дзвіночком.

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

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

Зрештою, ми таки налаштували SD-WAN, створили концепт централізованого мережевого акаунту та VPC під кожного SD-WAN вендора й навіть отримали дані з віддалених дата-центрів. І тут клієнт повідомив про появу чергових нових стейкхолдерів.

З’ясувалося, що отримання даних — критерій лише операційної команди, а у неї є ще внутрішні клієнти, які на базі її продуктів розробляють свої рішення. І ці стейкхолдери не можуть користуватися AWS-інфраструктурою і всією організацію в нинішньому вигляді, бо, по-перше, структура акаунтів не відповідає їхній моделі, а по-друге, вони користуються Terraform, а не AWS CloudFormation, і хочуть передавати його операційній команді на підтримку. Це означало, що для нас проєкт значно ускладнюється, бо з’являється ще один інструмент, під який треба повністю підлаштувати продукт. Зрештою нам довелося створити дизайн AWS landing zone 2.0 — несумісний із попередньою версією — із численними кардинальними змінами та додатковими ризиками, пов’язаними з міграцією на цю версію 2.0.

Чого ми навчились

Ось які висновки я зробив із цього непростого досвіду:

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

Випадок № 2. Everybody lies

На перший погляд цей клієнт здавався справжнім експертом: стверджував, що добре обізнаний з технологіями, які ми впроваджували, що має сертифікованих AWS-cloud архітекторів та AWS-девелоперів і використовує best practices від Amazon Web Services, а також переконував, що у нього все на 100% правильно налаштовано. Все за AWS Well-Architected Framework.

Клієнт звернувся до нас, коли підрахував, що забагато платить за використання інфраструктури AWS (це було в травні 2020-го, коли більшість компаній були в режимі жорсткої економії та почали прискіпливіше контролювати витрати).

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

На той момент ми для них виконували роботу, пов’язану лише з одним з їхніх застосунків, до AWS інфраструктури доступу в нас не було і все, що лишалось — повірити їм на слово.

Загалом є два шляхи вирішення такої проблеми:

  • Cost cut — урізання витрат шляхом відмови від певних сервісів, що впливає на характеристики якості системи (безпека, масштабування, відмовостійкість тощо).
  • Cost optimization — оптимізація наявних ресурсів, щоб зберегти всі бажані характеристики якості системи.

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

Ось перелік проблем, які ми виявили:

  • технічний борг, який виник при переході в AWS-хмару з дата-центру за принципом lift&shift без жодної адаптації інфраструктури;
  • відсутність хмарної моделі витрат;
  • відсутність контролю за витратами у хмарі та нормального планування;
  • відсутність контролю за ресурсами та сервісами, що використовуються;
  • не впроваджені best practices та базові конфігурації безпеки й обмежень — дослідивши звіти з використання reserved instances, ми з’ясували, що на початку вони обрали та придбали попереднє покоління EC2 віртуальних машин (C4), але в якийсь момент команда розробників вирішила, що краще підходить C5 покоління віртуальних машин (тобто вони двічі платили за одне й те саме);
  • погана внутрішня комунікація;
  • погана документація: банально не було задокументовано, які ресурси вони купили, а які використовують по факту.

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

Чого ми навчились

З цього кейсу я виніс три основні уроки:

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

Випадок № 3. Kubernetes як срібна куля

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

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

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

Зазвичай понад два варіанти краще не давати, оскільки клієнту буде складно визначитися. Тому ми провели й аргументовано запропонували обрати між Kubernetes і Amazon ECS. Нам з самого початку кращим здавався другий варіант, оскільки він дозволив би за короткий час досягти конкретного результату (клієнт зміг би продавати свій продукт кінцевим користувачам). Kubernetes є повноцінною «екосистемою» з низкою додаткових особливостей та можливостей. Все це додає функціоналу, але цьому клієнту він був не потрібен. До того ж на той момент в AWS не був повноцінно доступним Kubernetes як managed service (Amazon EKS працював лише в кількох регіонах і з обмеженим функціоналом). Це ускладнювало процес менеджменту та підтримки цього рішення. Однак клієнт побоявся, що Amazon ECS сильно підв’яже їх під AWS-хмару (vendor lock), і зупинився на Kubernetes.

Що пішло не так

Коротко кажучи, ми просто послухали клієнта, а також зовнішніх експертів, які стверджували, що ECS не перспективна технологія, розвивати яку AWS не буде, і почали робити проєкт на Kubernetes.

Серед перших труднощів, з якими зіткнулися, були:

  • Рішення повинно було відповідати PCI DSS (Payment Card Industry Data Security Standard). Це обмежувало використання певних managed-сервісів. Так, наприклад, EKS тоді був доступний лише у двох регіонах і не мав цієї сертифікації. ECS, на відміну від нього, підходив.
  • Managed-сервіси піднімати не могли, але могли використовувати Vanilla Kubernetes. Операційна команда на боці клієнта виявилася не настільки кваліфікованою, щоб його повноцінно підтримувати.
  • До кластерів були особливі вимоги, оскільки треба було робити безпечну інтеграцію сервісів основної платформи, яка не обробляє платіжні дані, з сервісами, які їх обробляють. З ECS це було б набагато простіше.

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

Результат:

  • Додаткова складність проєкту.
  • Затягнуті строки.
  • Проблема з гнучкістю рішення в розрізі його життєвого циклу, тобто в процесі того, як він розвивався б далі.

Зрештою, коли managed Amazon EKS сервіс став відповідати PCI DSS у потрібних нам регіонах, ми перейшли на нього. Але, звісно, це було не так просто, враховуючи, що треба було переписувати під нього всі конфігураційні скрипти.

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

Чого навчились

Головний урок — важливо об’єктивно оцінювати доречність технологій. Не до всього треба і можна застосувати Kubernetes (є достатньо альтернатив, наприклад, Amazon ECS і HashiCorp Nomad). Хоч у платформи й багато можливостей, але вони далеко не всім доречні, особливо коли йдеться про невеликі проєкти, які потребують швидких і максимально ефективних рішень. Не для всього треба ракети — для дечого досить і повітряних кульок.

Випадок № 4. «Нові фічі — наша мета»

Цьому клієнту була потрібна мікросервісна архітектура з нуля, процес CI/CD, і він погоджувався з використанням IaC для розгортання менеджменту та інфраструктури. Однак у клієнта був обмежений час на ухвалення рішення та реалізацію пілоту (MVP) — йому спершу варто було показати рішення MVP-інтеграції і вже потім рухатись далі. Отримавши широке поле роботи, ми нав’язали клієнту ідею all-in-one-platform з великою кількістю фіч (уявіть незалежні компоненти з можливістю перевикористання, розгортання різних компонентів хмарної інфраструктури, використання різних типів збирання застосунків, використання Golden Image тощо).

Що пішло не так

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

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

Чого навчились

Цей проєкт навчив мене важливих речей про доцільність і необхідність певних сервісів і функціоналу:

  • украй важливо зрозуміти, що саме потрібно клієнту, і працювати згідно з цими потребами, а не з власними уявленнями про проєкт і цікавими для нас варіантами його втілення — наша думка тут далеко не на першому місці;
  • варто керуватися технічними можливостями клієнта та рівнем розвитку його команди при регулюванні складності проєкту — якими б крутими не були фічі, які ми створюємо, в них не буде жодного сенсу, якщо вони не виконуватимуть свого призначення і не будуть ефективно наближувати клієнта до його мети;
  • Proofs of Concept потрібно робити тільки тоді, коли вони доводять value, бо інакше це даремна трата часу і зусиль.

Замість висновків

Ну і насамкінець кілька загальних принципів, які я для себе сформулював:

  1. Будівля починається з архітектури та фундаменту, так само добре прописана архітектура — ключовий компонент для успішного технологічного проєкту.
  2. Увага до деталей важлива: за потреби можна змінити рішення, але вже на самому початку роботи треба правильно визначити, скільки часу потрібно для реалізації, наскільки продуктивна робота і чи скоординовані окремі команди, які працюють над проєктом.
  3. Атрибути якості залежать від архітектурних рішень: кожен дизайн потребує компромісів (якщо літак пасажирський — акцент на комфорт, якщо військовий — на швидкість і безпеку), тому зрозумійте, що саме потрібно вашому клієнтові та якомога швидше обговоріть пріоритети.
  4. AWS landing zone дуже корисна під час міграції — не ігноруйте її переваги.
  5. У стейкхолдерів ключова роль у тому, щоб проєкт був успішний, і кожен з них відповідає за окремі сфери, тому для того, щоб зрозуміти всю систему, треба порозумітися з ними усіма. Ставте правильним стейкхолдерам правильні питання та обмежуйте кожне обговорення невеликою кількістю тем, щоб максимально ефективно опрацьовувати інформацію.
  6. За все треба платити — сервіси і платформи не безплатні, кожне рішення вимагає йти на певні компроміси (часто пов’язані з ціною), і якщо клієнт до цього не готовий, то важливо вміти пояснити йому можливі наслідки.
👍НравитсяПонравилось23
В избранноеВ избранном16
Подписаться на тему «архитектура»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


12 комментариев

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

Руслан, спасибо за интересную статью!

Давно так не вчитувався в статтю
Дякую, було дуже цікаво

Якщо перебільшити трохи з висновком, то можна сказати наступну річ: «задавайте багато питань клієнту та не вірте відповідям, все одно все піде не за планом» 🤣

Цікаво, а чому ви спочатку вибрали AWS CloudFormation, а не Terraform?

Как в анекдоте

— Ответ: кубернетес. А в чем был вопрос?

Чудова стаття, дякую автору. Чи не думали написати статтю з порівнянням рішень на готових мікросерфісних платформах (aws, gcp і тп) та контейнерною архітектурою на залізному хостингу? З точки зору економіки, гнучкості, життєвого циклу. Було б дуже цікаво.

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

Не дуже зрозумів, чому в історії № 3 щось «пішло не так». Замовник хотів відв’язатися від вендор-локу AWS, був в курсі існування альтернатив і вибрав саме цей шлях — складніше рішення заради свободи потенційної міграції. Що хотів — те і отримав.

очевидно, что у заказчика не было экспертизы разгребания авгиевых конюшен с K8S — k8s.af
у исполнителя, видимо — тоже (о чем скромно умолчали), но так как делали они не для себя, то им было — все равно
во всяком случае, выглядит именно так :-)

Дякую за коментарі. Тут хотів би прокоментувати та дати більше деталей. Частково то є вірно, але все ж таки основна ідея в концепті «срібної кулі». Наш найбільший фейл був в тому, що не вдалося правильно позиціонувати всі ризики такого рішення та вірно їх продемонструвати у розрізі наслідків для бізнесу. І нашій команді як раз не вистачило саме цього досвіду.
Так, клієнт був під враженням гнучкості та можливостей k8s. Три роки тому як раз набирали популярності різноманітні тематичні групи та міжнародні конференції, тобто почався хайп: «А давайте в себе мігруємо на Кубернетіс і всі наші проблеми відпадуть».
Наші експерти хотіли підтримати клієнта в його прагненнях та зробити «шаблонний» k8s проект. Тим паче все ж робилося з нуля :-) З цим «дияволом на плечі» ігнорувалося багато додаткових, але не менш значущих факторів. Як то передача рішення на підтримку до клієнтської 24/7 команди, яка працювала до того виключно з класичними датацентрами та віртуальними машинами в них. Клієнт (точніше, його основні стейкхолдери) думав, що то все буде дуже просто зробити та навчити його інженерів працювати з k8s. Також три роки тому k8s вже був доволі розвинутим, але більшість сучасних додаткових сервісів (для розгортання кластера, розгортання та доставки сервісів/застосунків в кластер, масштабування кластеру та самих сервісів, роботи з секретами, моніторингу, сервіс мешу тощо) були або відсутні, або «незрілі». Та навіть сам EKS був дуже обмежений (в тому числі і по PCI DSS compliance) і доступності по регіонах. Тому багато компонентів (якщо вони потребувалися) треба було фактично робити з нуля під конкретні цілі. Часу на реалізацію було небагато, а однією з критичних вимог перед заведенням клієнтів до платформи був PCI DSS зовнішній аудит.
Команда то все грубо проігнорувала. І замість додаткових раундів аналізу та архітектурних воркшопів, що ми робимо зараз за замовчуванням (якщо цікаво, то зроблю окрему статтю або подкаст про формат, ідею та цілі), команда використала той принцип «срібної кулі». Частина того перегукується з відгуками та вивченими уроками з k8s.af, також ще раз підтвердився постулат про людей, які «просто роблять свою роботу» та їх жагу до навчання (без образ, клієнтська 24/7 командо :-))
На жаль, я все ще бачу команди/людей, що шукають або використовують свою «срібну кулю». І це не обов’язково Кубернетіс (хоча з ним більше всього таких історій). Роблять контейнери там де не треба, мігрують з хмари у хмару, бо то певно буде класно в новій хмарі, зберігають сікрети у конфігураційних файлах в Git репозиторіях, бо так простіше. І дуже погано, що більшість команд все ще користується принципами, як у Ваших коментарях — «Клієнт, що хотів — те і отримав, а нам все одно». Тому я би хотів, щоб цей вивчений урок був корисним не тільки для нас і змінив підхід роботи з клієнтами у послідовників концепту «срібної кулі».

(якщо цікаво, то зроблю окрему статтю або подкаст про формат, ідею та цілі)

Цікаво, звичайно.

І дуже погано, що більшість команд все ще користується принципами, як у Ваших коментарях — «Клієнт, що хотів — те і отримав, а нам все одно».

А ось ця палка — з двома кінцями. Іноді воно так, як Ви кажете і несе негативний контекст. Але іноді буває і навпаки — технічні спеціалісти бачать лише технічні аспекти проблеми і вперто доводять клієнту, що йому потрібно, а що йому не потрібно. А клієнт каже, ні, мені потрібно ось так. Техніки крутять пальцем біля скроні і продовжують доводити технічну неефективність рішення, а клієнт все-одно каже «мені треба ось так». І тут треба трохи приструнити своє «его» і згадати, що клієнт — це бізнес, у нього гроші, він їх якось заробив, він знає як їх заробляти, він у цій сфері давно і справді знає, як йому треба. Технічний аспект задачі — це лише один з аспектів, а він оперує й десятками інших. Тому, можливо, треба зробити «Клієнт, що хотів — те і отримав, а нам все одно» і це буде правильно. Взяти той же AWS — з одного боку, класне рішення, чому б на нього поглибше не зав’язатися? А з іншого боку, ми вже бачили випадки, коли AWS, наприклад, взяв і викинув Parler. Справедливо чи ні, то вже інше питання, але ж це сталося. Тому коли бізнес просить про «слабкий зв’язок» з хмарою — це можна на 100% зрозуміти, навіть якщо це вимагає більше роботи.

Я от прийшов до думки, що клієнту варто 1-2 рази пояснити негативні технічні сторони рішення, але якщо він каже «все одно робіть так», то ми беремо і робимо «так».

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

Дякую за статтю, реальні кейси завжди цікаві.

Правильна комунікація часто є на найскладнішою частиною.

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