Microsoft наскоро обяви създаването на проект с отворен код, който е ОАМЗаn нов стандарт за разработване и стартиране на приложения на Kubernetes и други платформи. Този нов проект стартира, защото Kubernetes се превърна в водещата среда за оркестрация на контейнери.
Успехът му доведе до забележителен ръст в услугите във всички обществени облаци. Въпреки това, lосновните ресурси на Kubernetes, като Услуги и изпълнение, rТе представляват различни елементи на глобално приложение. Те не представляват самото приложение. По подобен начин обекти като Helm диаграми представляват потенциално разгръщаемо приложение, но след като бъдат внедрени, няма модел, който да се фокусира върху текущото приложение.
Ето защо Microsoft и Alibaba Cloud създадоха проекта Open Application Model (OAM) под Open Web Foundation.
ОАМ е спецификация за описание на приложения така че описанието на заявлението да бъде отделено от подробностите на как инфраструктурата изпълнява и управлява приложението. Това разделяне на опасенията е полезно по няколко причини.
В реалния свят всеки клъстер на Kubernetes е различен, от влизането в интерфейса на контейнерната мрежа (CNI) до мрежата от услуги.
Чрез отделяне на определението на изпълнението на оперативните детайли на клъстера, разработчиците на приложения могат да се съсредоточат върху ключовите елементи на вашето приложение, а не на оперативните подробности за вашето изпълнение.
Освен това разделянето на проблемите също така позволява на архитектите на платформи да разработват компоненти за многократна употреба, а разработчиците на приложения да се съсредоточат върху интегрирането на тези компоненти в своя код за бързо и лесно изграждане на надеждни приложения.
Във всичко това, целта на отворения модел на приложение е да улесни прости приложения и че сложните приложения са управляеми.
В OAM приложението се състои от няколко концепции. Първите са компонентите, които съставляват приложение. Тези компоненти могат да бъдат услуги като MySQL база данни или репликиран PHP сървър със съответния балансиращ товар.
Разработчиците могат да създадат код, който опаковат като компонент, след това авторът заявява, че описва връзката между този компонент и други микроуслуги. Компонентите позволяват на архитекти на платформи и други да създават модули за многократна употреба, за които е известно, че капсулират най-добрите практики в сигурността и мащабируемото внедряване.
Те също така ви позволяват да отделите изпълнението на компонента от описанието на това как тези компоненти се комбинират в a
За да преобразуват тези компоненти в конкретно приложение, операторите на приложения използват конфигурация на тези компоненти, за да формират конкретен екземпляр на приложение за разполагане.
Съоръжението за конфигуриране позволява на оператора на приложения да изпълнява реално приложение от компоненти, предоставени от разработчици и платформи.
Крайната концепция е набор от функции, които описват характеристиките на средата на приложението, включително функции като автоматично мащабиране и въвеждане, които са важни за работата на приложенията, но които могат да бъдат приложени по различни начини в различни среди.
Един прост пример за такива разлики може да бъде хипермащабен балансиращ товар предоставен облак срещу локален хардуер за балансиране на натоварването.
От гледна точка на разработчика на приложения, те са напълно идентични, докато от гледна точка на оператора, те са напълно различни. Функциите позволяват това разделяне на проблемите, така че приложението да може да работи там, където са разположени необходимите му функции.
След това инфраструктурните оператори могат да конфигурират тези функции, за да отговорят на уникалните оперативни изисквания на тяхната среда (като съответствие и сигурност).
За разлика от по-традиционния модел на приложение на PaaS, OAM има уникални характеристики. По-важното е, че той е агностик на платформа. Microsoft отбелязва, че въпреки че първоначалният OAM, наречен Rudr, се основава на Kubernetes, самият OAM не е тясно свързан с Kubernetes.
Възможно е да се разработят внедрения за много други среди, дори за малки формати, свързани с устройства, където Kubernetes може да не е правилният избор. Също така трябва да помислим за безсървърни среди, където потребителите не искат или се нуждаят от сложността на Kubernetes.