4 mythes over OpenShift
Er zijn 1001 redenen om OpenShift in te gaan zetten in je organisatie. Als je een OpenShift platform daadwerkelijk gaat implementeren of verder doorontwikkeld is het belangrijk om de te behalen doelen – en daarmee dus de voordelen – helder te hebben. Er is voldoende te vertellen over deze voordelen. Niet alleen welke er potentieel allemaal zijn, maar ook waarom ze zo belangrijk zijn. Helaas leven er ook veel mythes, wat averechts werkt om realistische verwachtingen te hebben. Welke mythes over OpenShift komen wij zoal tegen?
Mythe 1: OpenShift is een totaaloplossing
Als je ziet welke voordelen er zo nu en dan worden toebedeeld aan OpenShift, dan moet het wel een soort van Haarlemmerolie zijn, een panacee voor al je IT-kwalen. Eerlijk gezegd zit er echt wel een kern van waarheid in ieder genoemd voorbeeld. Het is alleen niet het hele verhaal. Je moet meer doen dan alleen met OpenShift gaan werken om het voordeel te behalen. Het draait dus om de realiteitszin. Je maakt met de komst van OpenShift een grote stap vooruit, maar je moet ook nog wel wat meer doen dan alleen OpenShift invoeren. Wij zeggen niet voor niets: Let’s get real!
Praktijkvoorbeeld
“Developers hoeven niet meer te wachten op producten die ter beschikking gesteld moeten worden door een ander onderdeel van de organisatie. Ze kunnen zelf een product opstarten door deze te kiezen uit één van de ‘stores’ of door een base-image te gebruiken.”
Nu de realiteit. Welke organisatie heeft dan geen last meer van wildgroei, licenties en security vraagstukken? We gaan naar de hybrid multi-cloud of het niets is. Workload verplaatsen we van het ene brok infrastructuur naar het andere. Natuurlijk kan je container-images opstarten op ieder platform, technisch geen enkel probleem. Alleen veel applicaties vereisen dat het ecosysteem, waar zij onderdeel vanuit maken, redelijk dichtbij is. Neem nu de data, daar moet vanuit al die plekken waar de applicatie opstart beschikbaar zijn en ook nog met een goede performance. Als laatste voorbeeld zien we dat we gaan A/B-testen alsof het een lieve lust is en we leveren, zonder downtime, over diverse versies onze functionaliteiten. Vergis je niet wat dit verlangt van de opzet van je applicatie en de gebruikte middleware!
Mythe 2: Applicaties moeten ‘container / cloud ready of native’ zijn
Veelvuldig krijgen wij bij implementaties te horen dat als uitgangspunt gekozen is om alleen applicaties op het platform toe te laten als deze voldoen aan de criteria van container / cloud ready of native. Je boekt anders toch geen voordelen? Natuurlijk boek je de meeste voordelen als de applicaties voldoen aan deze criteria. Applicaties die bestaan uit kleine autonome functionele componenten als microservices, stateless zijn, schaalbaar zijn, enzovoort, maken inderdaad optimaal gebruik van de mogelijkheden van het platform. Laten we eens eerlijk zijn. Hoeveel procent van je applicatielandschap voldoet al aan die criteria? En vergeet niet, het platform rendeert als er workload op komt. Ook als applicaties niet nog niet voldoen aan de criteria boeken we al belangrijke voordelen als ze hun ‘build-ship-run’ op het platform kan plaatsvinden. Wij noemen dat container-ignorant applicaties. Die hebben we in een container ‘weten te hijsen’ en voorzien van een aantal specifieke elementen voor een container applicaties. Zowel voor die applicatie als voor het rendement van het platform interessant genoeg om deze applicaties op te nemen.
Mythe 3: Doe je niet aan DevOps, dan is OpenShift niets voor jou
We zullen echt niet ontkennen, dat het helpt als je organisatie DevOps heeft omarmd en ingevoerd. Maar het is zeker geen must. Eerlijk gezegd zien we bij veel organisaties ook dat het andersom werkt. Het implementeren van OpenShift werkt als een katalysator voor het invoeren van DevOps. Organisaties die het ontwikkelen, onderhouden en beheren van een applicatie bij één team hebben ondergebracht plukken met de komst van OpenShift de vruchten op het gebied van de delivery pipeline (CI/CD) en het Technisch Applicatie Beheer. Bij organisatie die dit nog niet gedaan hebben vindt er gaandeweg het doorlopen van de delivery pipeline nog een overdracht plaats. Dat kan effecten hebben op de opzet van deze pipelines en eventueel daar minder voordelen opleveren. Echter de voordelen op andere gebieden worden zeker wel volop gescoord.
Mythe 4: De voordelen liggen (alleen) op het technologische vlak
Aangezien het containerplatform als een infrastructureel component gezien kan worden, is deze gedachtegang heel begrijpelijk. En zekers, er zijn voordelen te behalen op technologisch vlak, maar daar blijft het niet bij. Sterker nog, de voordelen met over het algemeen de meeste impact, hebben meer te maken met de organisatie. Denk hierbij aan modernisering van de werkwijze. Of wat dacht je van het effect van een moderne omgeving op de aantrekkelijkheid van je organisatie als werkgever? Zelfs de werving spint er dus garen bij.