Як обрати найкращі DevOps-технології для проєкту

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

Привіт, спільното DOU. Мене звати Роман Бурдюжа, я — Cloud Architect & CTO у компанії Gart Solutions.

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

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

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

Шість «простих» кроків, які допоможуть обрати кращий toolset під задачу

Покроковий процес може виглядати приблизно так:

• пропишіть бізнес-драйвери;
• встановіть обмеження бізнес-рішення;
• визначте функціональні та нефункціональні вимоги;
• створіть high level дизайн майбутнього рішення;
• підберіть відповідні DevOps-технології;
• підтвердження концепції (PoC).

Бізнес-драйвери

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

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

Важливо не просто робити щось, але робити те, що приносить користь. Раджу задокументувати керівні принципи та цілі.

Обмеження бізнес-рішення

Будь-яке бізнес-рішення має певні обмеження (незалежно від того, наскільки добре воно розроблене). Ось деякі загальні обмеження, з якими ви можете зіткнутися:

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

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

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

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

Функціональні та нефункціональні вимоги

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

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

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

• аутентифікація користувачів (за допомогою логіна та пароля, біометричних даних тощо);
• авторизація доступу (різні рівні доступу до інформації);
• управління рахунками для користувачів (перегляд балансу, перекази і платежі);
• історія та виписки.

З іншого боку, NFR (нефункціональні вимоги), які часто називають атрибутами якості, є більш складними і мають важливе значення.

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

Нефункціональними вимогами до банківського ПЗ можуть бути:

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

Джерело

Робота з атрибутами якості може бути доволі складною. На NFRs часто не зважають, оскільки основна увага приділяється функціональності програми.

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

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

Щоб забезпечити ефективне врахування NFRs в процесі розробки, важливо чітко визначити, що ми маємо на увазі під безпекою, доступністю та іншими quality attributes.

Дизайн майбутнього рішення

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

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

Наприклад:

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

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

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

Крім того, на цьому етапі ми також обираємо reference architecture — так званий шаблон майбутнього рішення, на який ми можемо орієнтуватися надалі. Тобто ми не збираємо архітектуру з 0, а шукаємо референси — успішні кейси і приклади реалізації. Для натхнення можна зазирнути в Azure Architecture Center.

Інструменти та Trade-offs

Після завершення високорівневого проєктування ми переходимо до впровадження відповідних інструментів. Для вибору необхідних інструментів DevOps я використовую CNCF Cloud Native Interactive Landscape. Цей ресурс допомагає спростити процес вибору, надаючи всебічний огляд доступних інструментів та їхніх категорій.

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

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

Наприклад, ми вирішили, що наш застосунок повинен використовувати ШІ для розпізнавання фото і обрали модель OpenAI. Однак інтеграція цієї моделі в архітектуру накладає певні обмеження, бо модель OpenAI доступна лише в Azure, а у нас (наприклад) була основна бізнес-вимога — створити cloud-agnostic застосунок без прив’язки до провайдера.

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

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

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

Перевірка концепції (PoC)

Після завершення високорівневого проєктування та оцінки компромісів настав час перейти до перевірки концепції (PoC) запропонованого рішення.

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

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

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

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

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