AWS перебудувала Elastic Beanstalk як сервіс керування застосунками

Спонсорована стаття AWS, опублікована The New Stack 22 вересня, твердить, що для хмарних платформ складною проблемою є не складність, а відповідальність. Її автори — менеджер із продуктового маркетингу AWS Сабарі Савант і аналітик Джанакірам MSV — описують, як AWS перебудувала Elastic Beanstalk на сервіс керування застосунками, що бере на себе відповідальність за все під застосунком.

Тест третьої години ночі

Автори пояснюють проблему через так званий тест третьої години ночі: коли надходить сповіщення й сервіс деградує, чи мусить хтось не спати, щоб це виправити? Тест проходять ті сервіси, де рішення про те, що означає «здоровий» стан і що робити, коли він перестає бути таким, ухвалюють під час розгортання, а не під час інциденту.

Автори порівнюють дві моделі: повний контроль — інфраструктура як код, service mesh, власні пайплайни — і простоту однієї програми: надіслав код, отримав URL. Їхня ілюстративна компанія середнього розміру має сорок інженерів, вісім продакшн-застосунків, одного SRE, який насправді є старшим розробником у небажаному графіку чергувань, і аудит відповідності, до якого ніхто не почав готуватися.

Чотири моделі збоїв

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

Джанакірам MSV вважає розрив структурним: cloud native стандартизував інфраструктурний рівень навколо контейнерів і Kubernetes, але не стандартизував операційну межу між командою застосунку та інфраструктурою під нею. Дослідження CNCF разом із SlashData показало, що 28% організацій мають окрему команду platform engineering, 41% розподіляють ці функції між командами, а 3% не мають формального підходу — саме там, за словами статті, перебуває більшість інженерних організацій середнього розміру.

Режими Standard і Cluster

Elastic Beanstalk тепер працює у двох режимах, що є зміною порівняно з попередньою архітектурою з одним середовищем. Standard Mode дає повну операційну відповідальність за один застосунок, включно з робочими навантаженнями Windows і .NET Framework. Cluster Mode поширює цю модель на весь портфель зі спільною інфраструктурою та розгортанням від коду до продакшну, тож восьмий застосунок ділить накладні витрати з першими сімома.

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