Microsoft ilmoitti äskettäin avoimen lähdekoodin projektin luominen, joka on OAM laajennus, un uusi standardi Kubernetes-sovellusten kehittämiseen ja käyttämiseen ja muilla alustoilla. Tämä uusi projekti käynnistettiin, koska Kubernetesista on tullut johtava konttiorkesteriympäristö.
Sen menestys on johtanut palvelujen huomattavaan kasvuun kaikissa julkisissa pilvissä. Kuitenkin lydin Kubernetes-resurssit, palveluina ja toteutuksina, rNe edustavat globaalin sovelluksen eri osia. Ne eivät edusta itse sovellusta. Vastaavasti objektit, kuten Helm-kaaviot, edustavat mahdollisesti käyttöönotettavaa sovellusta, mutta kun se on otettu käyttöön, ei ole mallia, joka olisi keskittynyt nykyiseen sovellukseen.
Siksi Microsoft ja Alibaba Cloud loivat Open Application Model -projektin (OAM) alla Open Web Foundation.
OAM laajennus on eritelmä kuvaamaan sovelluksia siten, että sovelluksen kuvaus erotetaan sovelluksen yksityiskohdista miten infrastruktuuri toteuttaa ja hallinnoi sovellusta. Tämä huolenaiheiden erottaminen on hyödyllistä useista syistä.
Todellisessa maailmassa jokainen Kubernetes-klusteri on erilainen pääsystä Container Network Interface (CNI) -palvelupisteeseen.
Erottamalla määritelmä klusterin operatiivisten yksityiskohtien toteuttamisesta, sovelluskehittäjät voivat keskittyä keskeisiin elementteihin pikemminkin kuin sovelluksesi operatiiviset yksityiskohdat.
Lisäksi huolenaiheiden erottaminen antaa alusta-arkkitehdeille mahdollisuuden kehittää uudelleenkäytettäviä komponentteja ja sovelluskehittäjät keskittymään näiden komponenttien integroimiseen koodiinsa luotettavien sovellusten rakentamiseksi nopeasti ja helposti.
Kaikessa tässä avoimen sovellusmallin tavoitteena on tehdä yksinkertaisista sovelluksista helppoja ja että monimutkaiset sovellukset ovat hallittavissa.
OAM: ssa sovellus koostuu useista käsitteistä. Ensimmäiset ovat komponentit, jotka muodostavat sovelluksen. Nämä komponentit voivat olla palveluja, kuten MySQL-tietokanta tai replikoitu PHP-palvelin, jolla on vastaava kuormituksen tasapainotin.
Kehittäjät voivat luoda koodin, jonka ne paketoivat komponentiksi, sitten kirjoittaja ilmoittaa kuvaavansa kyseisen komponentin ja muiden mikropalveluiden välistä suhdetta. Komponenttien avulla alustaarkkitehdit ja muut voivat luoda uudelleenkäytettäviä moduuleja, joiden tiedetään sisällyttävän tietoturvan ja skaalautuvan käyttöönoton parhaat käytännöt.
Niiden avulla voit myös erottaa komponentin toteutuksen kuvauksesta kuinka nämä komponentit yhdistetään a
Muuntaakseen nämä komponentit konkreettisiksi sovelluksiksi sovellusoperaattorit muodostavat näiden komponenttien kokoonpanon muodostamaan tietyn sovelluksen sovelluksen.
Konfigurointitoiminto antaa sovellusoperaattorille mahdollisuuden ajaa todellista sovellusta kehittäjien ja alustojen tarjoamista komponenteista.
Lopullinen konsepti on joukko ominaisuuksia, jotka kuvaavat sovellusympäristön ominaisuuksia, mukaan lukien sellaiset ominaisuudet kuin automaattinen skaalaus ja syöttö, jotka ovat tärkeitä sovellusten toiminnalle, mutta jotka voidaan toteuttaa eri tavoin eri ympäristöissä.
Yksinkertainen esimerkki tällaisista eroista voi olla hypertaajuuskuormituksen tasapainotin pilvi tarjotaan vs. paikallinen laitteiston kuormituksen tasaaja.
Sovelluskehittäjän näkökulmasta ne ovat täysin identtisiä, kun taas operaattorin kannalta ne ovat täysin erilaisia. Ominaisuudet mahdollistavat ongelmien erottelun toisistaan, jotta sovellus voi toimia siellä, missä vaaditut ominaisuudet on otettu käyttöön.
Infrastruktuurioperaattorit voivat sitten määrittää nämä ominaisuudet vastaamaan ympäristönsä ainutlaatuisia toimintavaatimuksia (kuten vaatimustenmukaisuus ja turvallisuus).
Toisin kuin perinteisempi PaaS-sovellusmalli, OAM: lla on ainutlaatuiset ominaisuudet. Vielä tärkeämpää on, että hän on alustan agnostikko. Microsoft huomauttaa, että vaikka sen alkuperäinen OAM, nimeltään Rudr, perustuu Kubernetesiin, OAM itsessään ei ole läheisessä yhteydessä Kubernetesiin.
On mahdollista kehittää toteutuksia moniin muihin ympäristöihin, jopa pienille laitteisiin liittyville muodoille, joissa Kubernetes ei välttämättä ole oikea valinta. Meidän on myös ajateltava palvelimettomia ympäristöjä, joissa käyttäjät eivät halua tai tarvitse Kubernetesin monimutkaisuutta.