Хмарні оборонні застосунки: мікросервіси, service mesh і шаблони

Оборонні платформи командування й управління історично були монолітними — єдиним розгортуваним блоком, що містить керування треками, ретрансляцію зв'язку, координацію вогневого ураження та інтеграцію розвідувальних даних за спільною базою даних. Моноліт не був випадковістю: він спрощував акредитацію, мінімізував поверхню мережевих атак і відповідав кадровій моделі невеликої команди, що супроводжує єдиний артефакт. Проте крихкість, яку він створює, дедалі менш прийнятна. Оновлення одного компонента вимагає вікна обслуговування всієї платформи. Сплеск обсягу треків ISR погіршує роботу інтерфейсу вогневого ураження. Зміна схеми бази даних на тижні заморожує не пов'язані з нею напрями розробки.

Хмарно-нативна архітектура усуває ці режими відмов, розкладаючи платформу на сервіси, що розгортаються незалежно, кожен зі своїм рівнем збереження даних, керовані Kubernetes і наскрізно захищені сервісною сіткою (service mesh). Це насамперед не історія про вартість чи гнучкість — це історія про стійкість та операційний суверенітет. Коли в хмарно-нативній платформі C2 відмовляє сервіс злиття треків, він відмовляє ізольовано. Інтерфейс координації вогневого ураження залишається доступним, ретрансляція зв'язку далі маршрутизує повідомлення, а оператори бачать деградовану — але не відсутню — спільну оперативну картину (COP), поки збійний сервіс самовідновлюється. Еквівалентної ізоляції в моноліті неможливо досягти без навмисного внутрішньопроцесного розмежування ресурсів (bulkheading), яке вносить по суті таку саму складність.

У цій статті розглянуто повний набір хмарно-нативних патернів для оборонних навантажень C2 та ISR: декомпозицію домену на обмежені контексти, розгортання сервісної сітки для взаємного TLS і спостережуваності, патерни операторів Kubernetes для компонентів зі станом, подієве злиття даних сенсорів із CQRS та event sourcing, практики SRE для критично важливих сервісів і плавну деградацію в умовах протидії противника в мережі.

Чому хмарно-нативний підхід для оборонних застосунків C2/ISR

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

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

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

Горизонтальне масштабування під час сплесків навантаження. Операції ISR генерують дуже змінні обсяги даних. Навчання на рівні театру воєнних дій може створити в десять разів більше треків, ніж зазвичай. Моноліт масштабується як єдине ціле — щоб витримати пікове навантаження, усі компоненти потрібно забезпечити ресурсами на піковий рівень, марнуючи їх у звичайному режимі роботи. У хмарно-нативній платформі сервіс злиття треків масштабується горизонтально під навантаженням, тоді як інтерфейс вогневого ураження та ретрансляція зв'язку зберігають звичайну кількість реплік. Kubernetes виконує масштабування автоматично залежно від процесора, пам'яті або власних метрик, похідних від глибини черги в конвеєрі приймання даних сенсорів.

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

Декомпозиція на мікросервіси для застосунків C2

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

Проєктування обмежених контекстів для доменів C2. Предметно-орієнтоване проєктування (domain-driven design) надає для цього каркас: визначте окремі домени в межах платформи C2 і проведіть навколо них межі на основі володіння даними, кола споживачів та семантики оновлення. Платформа C2 зазвичай містить щонайменше п'ять окремих доменів, які чітко відповідають обмеженим контекстам:

• Керування треками — володіє еталонним сховищем треків, виконує злиття звітів сенсорів, веде історію треків і обслуговує спільну оперативну картину. Частота оновлення висока (звіти сенсорів надходять безперервно); споживачами є практично всі інші сервіси.
• Ретрансляція зв'язку — керує маршрутизацією повідомлень, топологією радіомережі та розподілом каналів. Відокремлена від керування треками: зв'язок працює незалежно від того, чи справне злиття треків.
• Координація вогневого ураження — керує вогневими завданнями, деконфлікцією та відстеженням ураження цілей. Споживає дані треків, але володіє власним станом; інтерфейс вогневого ураження має залишатися доступним, навіть якщо злиття треків тимчасово деградоване.
• Інтеграція розвідувальних даних — приймає розвідувальну продукцію, корелює її з треками та публікує оцінки. Тривалі аналітичні завдання з іншими вимогами до затримки, ніж у злиття треків у реальному часі.
• Стан логістики — відстежує рівні забезпечення підрозділів, наявність техніки та запити на матеріально-технічне забезпечення. Інший ритм оновлення та інша база споживачів, ніж у оперативних функцій C2.

Контракти інтерфейсів сервісів. Кожен обмежений контекст публікує контракт інтерфейсу — специфікацію OpenAPI для синхронних інтерфейсів REST або gRPC, схему Avro чи Protobuf для асинхронних подієвих інтерфейсів. Контракти — основний механізм зв'язування між сервісами; їх слід версіонувати й ставитися до них як до чутливих до змін, що порушують сумісність. Сервіс, який змінює схему своїх подій без реєстрації нової версії в реєстрі схем, може непомітно порушити коректність роботи споживачів — цей режим відмови невидимий, доки споживач не обробить пошкоджену подію й не видасть некоректний результат.

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

Щоб докладніше дізнатися, як ці сервіси захищаються на рівні інфраструктури, див. посилення безпеки Kubernetes для оборонних систем: безпека подів, мережеві політики та конфігурація admission control, що доповнюють декомпозицію сервісів.

Сервісна сітка: mTLS і спостережуваність

Сервісна сітка додає sidecar-проксі (Envoy в Istio; легкий проксі на Rust у Linkerd) до кожного пода, перехоплюючи весь вхідний і вихідний мережевий трафік. Застосунок взаємодіє з localhost; sidecar відповідає за шифрування, автентифікацію, повторні спроби, спрацювання запобіжників (circuit breaking) і збір телеметрії. З погляду застосунку мережа абстрагована; з погляду оператора кожен виклик у сітці видимий і керований політиками.

Взаємний TLS для трафіку east-west у мережах C2 із нульовою довірою. Архітектура нульової довіри (zero trust) вимагає, щоб жоден мережевий виклик не вважався довіреним лише через розташування в мережі — сервіс усередині меж кластера має автентифікуватися так само суворо, як і сервіс поза ними. У сервісній сітці, налаштованій на суворий mTLS, кожен виклик east-west (від сервісу до сервісу в межах кластера) автентифікується сертифікатами робочих навантажень, виданими центром сертифікації сітки. Сервіс, який не може пред'явити чинний сертифікат — чи то через неавторизоване робоче навантаження, чи неправильно налаштоване розгортання, чи скомпрометований контейнер, — відхиляється на sidecar-проксі ще до того, як запит досягне застосунку.

У засекречених середовищах центр сертифікації сітки має інтегруватися з внутрішньою PKI анклава, а не з центром сертифікації, доступним з інтернету. Istio підтримує підключувані бекенди CA — центр сертифікації Istio можна замінити власним, що видає сертифікати з ланцюга довіри, коренем якого є акредитована PKI-інфраструктура програми. Ротація сертифікатів має бути автоматизована: ручне керування сертифікатами операційно крихке й призводило до відмов у засекречених системах, коли сертифікати спливали під час навчань.

Istio чи Linkerd у засекречених середовищах. Istio пропонує багатший набір можливостей — AuthorizationPolicy на рівні методу HTTP і шляху, дзеркалювання трафіку для канарного аналізу, точки розширення на Lua — але ціною вищої складності й більшого ресурсного відбитку площини керування. Linkerd має значно меншу поверхню атаки й простішу операційну модель, що робить його привабливим для програм, у яких пріоритетом є мінімізація довіреної обчислювальної бази. Вибір залежить від вимог до функціональності конкретної програми: якщо потрібні авторизація за шляхами й дзеркалювання трафіку, складність Istio виправдана; якщо основні вимоги — mTLS і базова спостережуваність, краще обрати простоту Linkerd.

Розподілене трасування для аналізу затримок. У платформі C2 із сімома й більше сервісами в ланцюгу викликів діагностувати проблеми із затримкою без розподіленого трасування майже неможливо. Запит, що виконується 800 мс від початку до кінця, може витратити 600 мс на очікування запиту до бази даних у сервісі керування треками й лише 200 мс на передавання та обробку в решті шести сервісів. Без трасування єдиний доступний сигнал — загальна затримка, а внесок окремих сервісів невидимий. З трасуванням у Jaeger або Tempo видно каскадну діаграму (waterfall): кожен спан сервісу, його тривалість і зв'язок із загальним запитом одразу очевидні.

Сервісна сітка автоматично генерує спани трасування для кожного виклику, що проходить через її проксі, без потреби в інструментуванні коду застосунку. Спани рівня застосунку (запити до бази даних, виклики зовнішніх API всередині сервісу) потребують явного інструментування за допомогою OpenTelemetry SDK, але міжсервісний каркас сітка надає безкоштовно. У засекречених середовищах бекенд трасування (Jaeger, Tempo або Zipkin) має працювати всередині акредитованого периметра — дані трасування містять імена сервісів, шляхи кінцевих точок і часову інформацію, що можуть бути чутливими для засекреченої системи C2.

Патерни операторів Kubernetes для оборонних навантажень зі станом

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

Custom resource definitions для стану C2. Оператор будується навколо Custom Resource Definition (CRD), що описує бажаний стан керованого компонента в термінах, зрозумілих предметній області застосунку. Для сховища треків C2 CRD може задавати кількість реплік, клас сховища, політику зберігання, коефіцієнт реплікації та мінімальну кількість синхронізованих реплік, потрібну, щоб оператор дозволив оновлення. Оператори надають інфраструктурним командам декларативний інтерфейс: команди декларують, чого хочуть, а оператор визначає, як цього досягти. Спосіб досягнення один раз закодовано в операторі, а не виводиться заново для кожного розгортання.

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

Поетапне оновлення без розриву у виконанні завдання. Оновлення C2-компонента зі станом у діючій системі без розриву у виконанні завдання вимагає певної послідовності: перевірити, що ціль оновлення справна, перш ніж починати; виводити з обслуговування по одній репліці; чекати, поки заміна досягне відомого справного стану, перш ніж виводити наступну; і перервати процес, якщо в будь-який момент перевірки справності не проходять. Оператор Kubernetes кодує цю послідовність як автомат станів у циклі узгодження. Оператор примусово підтримує мінімальну кількість справних реплік на кожному кроці — він не перейде до наступного кроку оновлення, якщо система опуститься нижче налаштованого мінімуму. Це ключова перевага над ручними оновленнями: обмеження забезпечує код, що працює зі швидкістю кластера, а не людина, яка виконує контрольний список під оперативним тиском.

Конвеєр CI/CD для ізольованих від мережі (air-gapped) оборонних середовищ, що збирає та підписує образи оператора, не менш важливий, ніж сам оператор, — оператор, розгорнутий із непідписаного, неперевіреного образу, є ризиком для ланцюга постачання в засекреченому середовищі.

Подієва архітектура для злиття даних сенсорів

Злиття даних сенсорів — об'єднання звітів від різних типів сенсорів у цілісну картину оперативної обстановки — одне з найвибагливіших навантажень у платформі C2. Воно за своєю природою подієве: звіти сенсорів надходять асинхронно, зі змінною інтенсивністю, одночасно з багатьох джерел. Синхронна архітектура «запит — відповідь» структурно не відповідає такому навантаженню. Правильним вибором є подієва архітектура з надійним журналом як основою.

Потоки подій на основі Kafka для даних сенсорів. Apache Kafka (або Apache Pulsar завдяки його можливостям мультиорендності та багаторівневого сховища) надає надійний партиціонований журнал, на якому тримається конвеєр злиття даних сенсорів. Кожен тип сенсора публікує в окремий топік — звіти радарів в один, радіоелектронна розвідка (ELINT) в інший, підказки на основі зображень у третій. Сервіс злиття треків підписується на всі потрібні топіки й обробляє звіти в міру надходження. Механізм груп споживачів Kafka дає змогу масштабувати сервіс злиття горизонтально: кожна репліка бере по партиції, тож пропускна здатність зростає разом із кількістю реплік. Надійний журнал Kafka означає, що якщо сервіс злиття тимчасово недоступний — під час оновлення чи відмови вузла, — звіти накопичуються в журналі й обробляються по порядку після відновлення сервісу, без втрат.

Патерн CQRS для керування станом треків. Патерн Command Query Responsibility Segregation (розділення відповідальності команд і запитів) відокремлює шлях запису (команди, що змінюють стан) від шляху читання (запити, що повертають стан). У сервісі керування треками шлях запису обробляє вхідні звіти сенсорів і команди операторів, оновлюючи еталонне сховище треків і додаючи події до журналу подій. Шлях читання обслуговує спільну оперативну картину та інтерфейси аналітиків із проєкції, оптимізованої для читання, — матеріалізованого подання стану треків, оптимізованого під шаблони доступу споживачів COP, які відрізняються від шаблонів запису під час злиття даних сенсорів.

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

Event sourcing для журналу аудиту. Event sourcing поширює подієвий патерн на збереження даних: замість того щоб зберігати поточний стан запису треку й перезаписувати його при кожному оновленні, система зберігає послідовність подій, що призвели до поточного стану. Еталонний запис треку виводиться шляхом відтворення журналу подій. Такий підхід дає кілька властивостей, цінних для акредитації оборонних систем: повна історія кожного переходу стану зберігається й незмінна; стан системи в будь-який момент минулого можна відновити, відтворивши події до цього моменту; а журнал аудиту, якого вимагають стандарти акредитації, є прямим результатом архітектури, а не окремо підтримуваним журналом.

SRE для критично важливих оборонних сервісів

Практики Site Reliability Engineering — SLO, бюджети помилок, структуроване керування інцидентами — застосовні до оборонних платформ C2, але їх реалізацію потрібно адаптувати до засекреченого середовища експлуатації, обмежень оперативного темпу та моделі наслідків відповідних застосунків.

Визначення SLO та SLI для сервісів C2. Комерційні SLO зазвичай формулюються як метрики користувацького досвіду. SLO для C2 мають формулюватися як метрики оперативного ефекту, визначені спільно з операторами та планувальниками місій, які розуміють, яка поведінка системи реально впливає на результати виконання завдань. Показові SLO для платформи C2:

• Затримка оновлення треків: вік треків на COP на 95-му перцентилі не повинен перевищувати 15 секунд. Вимірюється як різниця між часовою позначкою звіту сенсора та моментом, коли оновлення треку стає видимим на COP.
• Показник доставки повідомлень: командні повідомлення мають доставлятися з втратами менш ніж 1 % у будь-якому 30-хвилинному вікні. Вимірюється як відношення підтверджених доставок до надісланих повідомлень на межі сервісу ретрансляції.
• Доступність інтерфейсу вогневого ураження: інтерфейс координації вогневого ураження має бути доступним протягом 99,9 % зважених за часом вікон в оголошені оперативні періоди. Вимірюється синтетичними пробами, а не пасивним показником успішності запитів.
• Затримка приймання даних сенсорів: звіти сенсорів мають бути прийняті та зафіксовані в журналі подій протягом 5 секунд після отримання на 99-му перцентилі. Вимірюється від часової позначки мережевого отримання на шлюзі приймання до часової позначки фіксації зміщення (offset) у Kafka.

Вимірювання SLI слід, де це можливо, будувати на телеметрії сервісної сітки — метрики рівня сітки не залежать від коду застосунку, і їх не можуть завищити помилки на рівні застосунку, через які збої недораховуються. Там, де метрик сітки недостатньо (наприклад, для вимірювання застарілості потрібні часові позначки рівня застосунку, недоступні на рівні проксі), інструментуйте застосунок через OpenTelemetry і експортуйте дані до Prometheus-сумісного бекенда в межах анклава.

Політика бюджету помилок. Бюджет помилок — доповнення до SLO: якщо SLO актуальності треків становить 99,5 % відповідності за 30 днів, то бюджет помилок — 0,5 %, тобто приблизно 2 години 10 хвилин невідповідних вікон на місяць. Коли бюджет у нормі, інженерні команди можуть розгортати зміни й приймати розрахований ризик. Коли бюджет наближається до вичерпання, політика зміщується до стабільності: жодних неаварійних розгортань, інженерні ресурси спрямовуються на підвищення надійності, а після вичерпання бюджету проводиться обов'язковий розбір. Оборонні програми мають накладати оперативні вікна на політику бюджету помилок: деякі періоди оголошуються оперативними, і витрата бюджету в ці періоди має підвищену вартість незалежно від накопиченого балансу.

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

Плавна деградація в умовах протидії противника

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

Запобіжники (circuit breaker) для деградованого зв'язку. Запобіжники не дають повільній або збійній залежності каскадно поширити відмову ланцюгом викликів. У сітці Istio запобіжники налаштовуються через ресурс OutlierDetection у DestinationRule: задайте поріг послідовних помилок, що розмикає контур, інтервал виведення та базовий час виведення. Коли частота помилок сервісу перевищує поріг, сітка припиняє маршрутизувати до нього виклики й одразу повертає помилки, замість того щоб ставити в чергу виклики, які завершаться тайм-аутом. Це захищає бюджет затримки викликача — сервіс вогневого ураження не чекає 30 секунд, поки запит треку завершиться тайм-аутом, а одразу отримує помилку й переходить на кешований стан.

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

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

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

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

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