Проектирайте софтуер за cloud native среда

Определете необходимото поведение

Cloud native практиките подпомагат повторяема разработка и експлоатация в публични, частни или хибридни среди. CNCF набляга на системи, които остават управляеми, наблюдаеми и устойчиви при промяна. Контейнери и оркестрация могат да подкрепят този подход. Те не установяват всички тези свойства сами по себе си.

Започнете с измислена услуга за отчети. AI инструмент създава endpoint, worker и контейнерен образ. Демонстрация произвежда правилния PDF. Преди продукционна употреба екипът трябва да отговори на друг въпрос: какво става, когато платформата замени worker-а по време на задача?

Това е въпрос за проекта на приложението, както и за инфраструктурата. Рестарт може да възстанови процес, като загуби незавършената му работа.

Разграничете процеса от устойчивото състояние

Прототипът пази чакащите задачи и завършените отчети на диска на контейнера. Замяната на контейнера може да премахне и двете. Добавянето на още worker-и може също да даде различни отговори според това кой получава заявката.

Преработеният проект използва устойчиво хранилище за задачи и одобрено обектно хранилище. Заявка записва идентичност на задача. Worker поема задачата, създава резултата и записва местоположението му. Проверките за достъп все още се прилагат, когато потребител изтегля отчета.

Пазете тайните стойности извън образа. Предоставяйте ги чрез одобрената система за тайни стойности. Запишете кои промени в конфигурацията изискват ново пускане или рестарт на процес.

Проектирайте повторните опити, преди да добавяте worker-и

Да предположим, че worker-ът запазва PDF и после спира, преди да потвърди задачата. Опашката доставя задачата отново. Втори опит не трябва да създава второ таксуване на клиента или да изпраща противоречиви съобщения за завършване.

Използвайте идемпотентна операция, когато е подходящо. Повторението на една и съща логическа заявка трябва да запазва предвидения ефект. Определете стабилна идентичност на заявката, запишете резултата устойчиво и проверете какво става при всяка точка на неуспех. AWS описва тази техника в ръководството за безопасни повторни опити.

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

Направете желаното състояние достъпно за преглед

Декларативна конфигурация посочва предвиденото внедряване. Контролер работи, за да поддържа това състояние. Например Kubernetes Deployment управлява реплики на приложение и контролирани обновявания. Приложението все още трябва да обработва замяната правилно.

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

Изберете платформа, която екипът може да експлоатира

Cloud native не изисква всяко приложение да се превръща в микросървиси. Модулно приложение върху управлявана среда за изпълнение може да покрива изискванията си. Повече услуги добавят повече интерфейси, решения за внедряване и работа по експлоатацията.

Дайте на агента за разработка действителния договор с платформата: поддържана среда за изпълнение, метод за идентичност, услуги за данни, правила за внедряване и необходими доказателства. Тествайте поведението при прекъсване и замяна заедно с успешните заявки. Продължете с наличност и граници на отказите.