Проєктуйте програмне забезпечення для середовища cloud native

Визначте потрібну поведінку

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

Почніть із вигаданого сервісу звітів. Інструмент ШІ створює endpoint, процес-обробник (worker) і образ контейнера. Демонстрація створює правильний PDF. Перед продуктивним використанням команда має відповісти на інше питання: що станеться, коли платформа замінить процес-обробник під час виконання задачі?

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

Відокремте процес від стійкого збереження стану

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

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

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

Спроєктуйте повторні спроби, перш ніж додавати процеси-обробники

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

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

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

Зробіть бажаний стан придатним для перегляду

Декларативна конфігурація визначає заплановане розгортання. Контролер працює над підтриманням цього стану. Наприклад, Kubernetes Deployment керує репліками застосунку та контрольованими оновленнями. Застосунок усе ще має правильно обробляти заміну.

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

Виберіть платформу, яку команда може експлуатувати

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

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