DevOps, containers en serverless vragen om ander infra-beheer

Om als organisatie snel te kunnen innoveren heb je nieuwe manieren van software-ontwikkeling geadopteerd. Door DevOps, containerization en serverless functions toe te passen bouw je sneller nieuwe functionaliteiten. Maar het handmatig configureren van servers, storage en connectiviteit blijft een grote hindernis. Het maakt het moeilijk om te voldoen aan security- en compliance-eisen en het is een terugkerende frustratie voor developers én voor beheerders.

Snel en agile ontwikkelen en uitrollen van nieuwe software is één ding. Zorgen dat dat ook iedere keer voorspelbaar, veilig en compliant gebeurt is vers twee. Applicaties die goed werken in een testomgeving kunnen in de acceptatie-omgeving of in productie ineens onverwacht gedrag vertonen.

Developers noemen dat het ‘works on my machine-effect’. Vele uren zoekwerk later is het verschil in configuratie gevonden. Zo verspil je kostbare tijd aan het debuggen van software die al getest en geaccepteerd is. Of, nog erger, je introduceert fouten en veiligheidslekken zonder dat je dat doorhebt.

Minder onvoorspelbaar

Containerization is daarvoor de oplossing. Door applicaties, of delen van applicaties, met standaardscripts in containers te verpakken zijn ze niet afhankelijk van serverconfiguraties. Het werken met containers heeft ook grote voordelen bij het testen, updaten en op- en afschalen van applicaties. Veel onvoorspelbaarheid verdwijnt door containers uit het development- en deploymentproces en je krijgt veel meer controle over capaciteit en kosten.

Nieuwe infra nodig

In de nabije toekomst migreren vrijwel alle organisaties ook bestaande software naar containers, terwijl er ook continu nieuwe functionaliteit wordt gebouwd. Ondertussen verschijnt ook serverless development aan de horizon, waarbij developers zich alleen nog maar bezighouden met het maken van functionaliteit. Om dit te kunnen faciliteren zijn grote aanpassingen aan die infrastructuur nodig om de veiligheid, continuïteit en overzicht te bewaren.

DevOps en self-service

Containers maken een totaal andere manier van met software omgaan mogelijk. De meeste IT-teams zitten dan ook midden in de transitie naar DevOps, het combineren van development en operations in hetzelfde team. In een goedlopend DevOps-proces hoeven developers nooit te wachten tot beheer een omgeving in orde heeft gemaakt of een update heeft geïnstalleerd. Die verantwoordelijkheid kunnen ze zelf nemen. In een intelligente, AI-gedreven infrastructuur geeft Operations vooraf aan welke toepassingen, databases en frameworks er beschikbaar zijn. Een developer lanceert via een self-service portal met één klik zo’n standaardomgeving. Geen toestemming nodig, altijd de juiste versies, altijd veilig en conform de geldende normen.

Beheerders in de development teams

Maar niet alles aan een nieuwe applicatie zal op die manier in te regelen zijn. Er is in de teams dus iemand van Operations nodig die zorgt dat de architectuur gedocumenteerd is, de scripts gemaakt zijn en alles bij iedere opgeleverde feature of sprint getest is. Het live zetten van een app is dan niet anders dan het opleveren van een nieuwe versie van een container naar een testomgeving. Er zijn geen risico’s door onbekende serverconfiguraties, geen verschillen tussen de servers van een OTAP-straat. In principe kan een container dan geautomatiseerd naar productie gezet worden. Zo werkt innovatie!

Maar dan moeten ze wel tijd hebben…

Maar dan moeten er wel beheerders vrij zijn om mee te werken in de teams. Dat kan niet als die druk zijn met handmatig beheerwerk. Met automation en orchestration haal je handmatig beheerwerk weg bij het beheerteam en maak je specialisten vrij om mee te werken in development. Automation en orchestration zorgen dus niet alleen voor abstractie en voorspelbaarheid, ze maken ook dat Operations het development- en innovatieproces veel beter kan faciliteren.