Containere og kubernetes er på få år blevet en afgørende faktor for virksomheder og organisationer, der vil optimere IT-infrastrukturen og fremskynde digitale transformationsprocesser. Primært fordi det giver gode muligheder for at udvikle, distribuere og drifte applikationer og microservices konsistent og skalerbart på tværs af vidt forskellige miljøer og partnere – og bygge bro mellem on-premise, hybride setups, private- og public clouds.
”Containerteknologi markerer et paradigmeskifte, fordi du kan indkapsle services og drifte dem i præcis den sammenhæng, der giver bedst mening,” konstaterer Rune Stenbæk, dansk country manager for RedHat.
”Men selv om teknologien er blevet moden, så vil jeg helt klart opfordre til at overveje, hvordan man bygger sin infrastruktur, hvor stor en risiko man løber og hvor mange ressourcer, man bruger,” tilføjer han.
Risiko for at bygge sig ind i problemer
Ganske vist har en række virksomheder som f.eks. Amazon, Microsoft og Google – foruden RedHat selv – etableret sig som betydelige aktører indenfor inden for udviklingen af færdigpakkede kubernetesplatforme. Her udvikles hele tiden på f.eks. integrationer, adminmoduler og muligheden for at udrulle hurtigt og standardiseret. Ligesom løsningerne også supporteres og patches fuldkommen som al anden software til virksomhedsbrug.
Alligevel er der stadig en vidt udbredt kultur omkring containerteknologien, hvor mange foretrækker at sammenstykke deres egne platforme på grundlag af frit tilgængelige open source-elementer.
”Det var af gode grunde mere udbredt, da containere og Kubernetes var nye teknologier, som man eksperimenterede med i begrænsede setups. Men det kan stadig være en fin fremgangsmåde, hvis din organisation har så specifikke krav, at man bedst når i mål ved selv at sidde bag rattet på hele rejsen,” siger Rune Stenbæk.
”I dag taler vi imidlertid stadig oftere med store organisationer i både den private og offentlige sektor, hvis egenudviklede containerløsninger har nået en størrelse, der gør dem meget ressourcekrævende at overskue, drifte og administrere,” tilføjer han.
Rune Stenbæk fortæller, at han for nylig var i kontakt med en stor dansk koncern, som i forbindelse med gennemgang af infrastrukturen opdagede, at her var et tocifret antal applikationer i drift på en containerplatform, som de selv havde bygget – og som kun et meget lille antal personer kendte til.
”Nogle af applikationerne var en endda relativt kritiske for deres drift. Så de var utroligt sårbare og havde travlt med at komme over på en supporteret platform,” bemærker han.
Kompatible versioner var alligevel ikke kompatible
I andre tilfælde beslutter virksomheder at migrere til en supporteret standardplatform, fordi det med tiden er blevet for tidskrævende at vedligeholde og opdatere den hjemmebyggede containerplatform. Eller fordi elementer af infrastrukturen alligevel ikke er direkte kompatible, fordi man har mistet overblikket over sammenhænge og integrationer – eller der opstår kritiske fejl.
”I en anden virksomhed, jeg talte med, trak de metrics på driften i en hjemmebygget containerplatform. Her var der grønne lys over hele linjen og alt så fint ud. Først senere opdagede de, at en del af deres containere ganske vist meldte grønt, men reelt slet ikke var koblet på overvågningen, fordi de kørte en marginalt anderledes version af Linux end resten af infrastrukturen. Det var de en smule rystede over,” siger Rune Stenbæk.
"Samtidig hører jeg relativt ofte, at man i forretningen har en klar forventning om, at der er mulighed for at søge support fra en ekstern partner. Og det kan jo i sagens natur være svært, hvis man selv har bygget platformen fra bunden,” bemærker han.
Husk at spørge ind til fordele og ulemper
Rune Stenbæk understreger, at målet med beretningerne isoleret set ikke er at trække kunder over på RedHats platform, for ”selv om vi har en god teknologi og ligger i top på samtlige Gartners og Forresters parametre, så er andre professionelle containerløsninger måske i nogle sammenhænge bedre for den enkelte kunde. Ja, i nogle tilfælde kan en selvudviklet platform som sagt også være det helt rette valg.”
”Men hvis man selv udvikler og implementerer en containerplatform, bør man gå ind i opgaven med 100% åbne øjne. Derfor bør ledelsen også stille spørgsmål til strategien og sikre sig, at den valgte fremgangsmåde tjener virksomheden bedst med hensyn til risiko, ressourceforbrug og skalerbarhed,” siger han.
Det indebærer bl.a. at man minutiøst kortlægger ansvar, sårbarheder, life-cycle management osv. Hvilket alt andet lige er lettere i en mindre organisation med et begrænset antal containere end i en koncern. Dertil kommer, at det helt generelt er afgørende at reflektere over, hvordan den valgte metodik og platform passer ind i organisationens langsigtede IT-strategi.
”I sidste ende bør man foretage en nøje afvejning af, om den valgte platform er den, der tjener virksomheden bedst. Eller om man risikerer at komme til at bruge uforholdsmæssigt mange ressourcer på at løfte en opgave, der måske ikke ligger indenfor virksomhedens kerneforretning,” tilføjer han.
