Miksi Kubernetes on nykyaikainen COBOL, sanoo teknologia-asiantuntija.

Kommentti: Mutta on olemassa tapoja rakentaa, joilla vältetään sudenkuopat.

Kubernetes logo concept

Kuva: Lisa Hornung, iStock

Nykyään meillä on COBOL-ongelma: paljon (ja paljon) vanhaa koodia roikkuu ympäriinsä, ja yhä harvempi (ja harvempi) ihminen osaa käsitellä sitä. COBOL oli aikoinaan ”in” -infrastruktuuri, joka pyöritti monien rahoituslaitosten ja hallitusten taustajärjestelmiä. Nyt olemme siirtyneet eteenpäin.

Samoin Mike Loukides, O’Reilly Median sisältöstrategiasta vastaava varajohtaja, on ehdottanut, että alamme seuraava ”COBOL-hetki” liittyy todennäköisesti Kubernetesiin. Hän totesi, että ajan myötä Kubernetes korvataan väistämättä jollakin yksinkertaisemmalla, jolloin meidän on vastattava kysymykseen: ”Kuka ylläpitää infrastruktuuria, joka jo nyt perustuu siihen?”

KATSO: Alusta loppuun: Miten sovellus otetaan käyttöön Kubernetesin avulla? (TechRepublic Premium)

Infrastruktuuri koodina

Tämä koodin ”COBOLisoituminen” ei ole ominaista kaikille ohjelmistoille. Loukides käyttää esimerkiksi Fortrania erottaakseen toisistaan koodin, joka aiheuttaa pitkän aikavälin ylläpito-ongelmia, ja koodin, joka ei aiheuta:

Fortrania ja COBOLia käytetään pohjimmiltaan eri tavoin. Vaikka Fortrania käytettiin infrastruktuurin luomiseen, Fortranilla kirjoitetut ohjelmistot eivät ole itse infrastruktuuria….Ketään ei enää kiinnosta 60-, 70- ja 80-luvuilla kirjoitettu Fortran-koodi, jolla suunniteltiin uusia siltoja ja autoja. Fortrania käytetään yhä paljon insinöörityössä, mutta vanha koodi on jäänyt eläkkeelle. Vanhoja työkaluja on muokattu ja korvattu….[Jos kaikki maailman Fortran-ohjelmoijat katoaisivat taikaiskusta, nämä kirjastot ja sovellukset voitaisiin rakentaa melko nopeasti uudelleen nykyaikaisilla kielillä, joista monilla on jo erinomaiset kirjastot lineaarialgebraa ja koneoppimista varten.

Infrastruktuurikoodi on erilaista. 1960-luvulla kirjoitettu COBOL-koodi saattaa olla yhä käytössä – se on infrastruktuuria, jonka varaan rakennamme. Fortran-koodia, kuten Loukides totesi, ei kohdella samalla tavalla.

Mikä on siis nykypäivän COBOL? Loukidesille vastaus on selvä. Se on Kubernetes:

Yritykset siirtävät sovelluksia pilvipalveluihin joukoittain. Yksinkertaisen nostamisen ja siirtämisen lisäksi ne muokkaavat monoliittisia sovelluksia mikropalvelujärjestelmiksi, joita usein orkestroi Kubernetes…..

On varmaa, että monet näistä järjestelmistä toimivat vielä 20 tai 30 vuoden kuluttua; ne ovat seuraavan sukupolven ”legacy-sovelluksia”. …Kubernetesin konfigurointi on monimutkaista, ja se on oma erikoisalansa. Jos Kubernetes korvataan jollain yksinkertaisemmalla (mikä on mielestäni väistämätöntä), kuka ylläpitää infrastruktuuria, joka jo nyt perustuu siihen? Mitä tapahtuu, kun Kubernetesin oppiminen ei olekaan lippu seuraavaan työpaikkaan tai ylennykseen? Kubernetesia konfiguroivat YAML-tiedostot eivät ole Pythonin kaltainen Turingin täydellinen ohjelmointikieli, mutta ne ovat koodia. Niiden ihmisten määrä, jotka ymmärtävät, miten tuon koodin kanssa työskennellään, vähenee väistämättä, ja heistä voi lopulta tulla ”kuoleva rotu”. Kun näin tapahtuu, kuka ylläpitää infrastruktuuria?

Tämä ei ole hälyttävää. Useimmat organisaatiot keskittyvät nykyisten järjestelmiensä nykyaikaistamiseen sen sijaan, että kurkistaisivat 10-20 vuoden päähän tulevaisuuteen ja murehtisivat osaajapulaa, joka saattaa lopulta saavuttaa niiden päätökset. Ja kiistatta yritykset tekevät fiksun päätöksen, kun ne rakentavat Kubernetesin kaltaisen alan standardin avulla. Kyllä, Kubernetes tulee jonain päivänä olemaan perintönä, kaikkine sen mukanaan tuomine lahjakkuuspulmineen. Mutta nykyään organisaatiot ovat enemmän huolissaan Kubernetes-osaajien nykyisestä puutteesta, kun ne pyrkivät ottamaan käyttöön kontteja tukevia, mikropalveluvetoisia arkkitehtuureja.

Ehkäpä tästä kannattaa ottaa opiksi: rakenna nykyiseen infrastruktuuriin mahdollisimman paljon ketteryyttä ja anna tulevaisuuden huolehtia itsestään. Expedian teknologiajohtaja Subbu Allamaraju ilmaisi asian näin puhuessaan samankaltaisesta mentaliteetista, joka tarttuu niihin, jotka haluavat säilyttää mahdollisimman suuren infrastruktuurivapauden suojaamalla pilvipalveluja datakeskusinvestoinneilla: ”Jotta hybridirakenteessa voidaan menestyä mittakaavassa ja maksimoida asiakasarvo, kustannustehokkuus ja ketteryys, on tehtävä suuri määrä teknisiä, henkilöstö- ja prosessipäätöksiä jo vuosia ennen tarvetta. Vaikka sinulla olisi varaa tähän, on [epätodennäköistä], että saat nämä päätökset tehtyä oikein.”

KATSO: Kubernetes: (ilmainen PDF) (TechRepublic)

Tai ota huomioon Duckbill-analyytikko Corey Quinnin neuvot samasta aiheesta: ”Rakentamalla teoreettista poistumista varten maksat valinnaisuudesta ominaisuuksien nopeudella ja vähennät mahdollisuuksiasi päästä tilanteeseen, jossa pilvikustannuksilla on edes merkitystä yrityksesi kokonaismenestyksen kannalta.”

Yhteenvetona voidaan todeta, että kyllä, tämän päivän kuuma Kubernetes-klusteri on todennäköisesti huomisen COBOL-henkinen legacy-infrastruktuuri. Mutta Raamatun sanoja lainatakseni: ”Älkää siis miettikö huomista, sillä huominen miettii itseään. Riittää sen päivän legacy-infrastruktuuri.”

Ilmoitus: työskentelen AWS:lle, mutta tässä esitetyt näkemykset ovat minun.

Katso myös