Uit de gesprekken die wij voeren binnen de industrie leren we dat veel bedrijven het applicatielandschap willen moderniseren om de digitale experience voor klanten en gebruikers te verbeteren. Deze modernisering gaat hand in hand met ‘containerization’ van applicaties. Daarom zien we dat de vraag voor een schaalbaar container platform blijft stijgen sinds de introductie van Docker zo’n 5 jaar geleden. Daarnaast zien we dat de meeste organisaties springen op de adoptie van Kubernetes.
Zoals met bijna alle innovaties hebben Nederlanders niet gewacht met het aanpakken van deze open source technologie. Voor ontwikkelaars betekent dit dat organisaties verwachten dat ze zo snel en zo vaak mogelijk releasen. Dit draagt bij aan de ontwikkeling van een meer agile organisatie. Op deze manier kunnen ze zich sneller aanpassen aan de vraag van klanten en gebruikers en daarmee competitiever zijn. Uit ons onderzoek blijkt dat 53% van de ondervraagden ziet dat het gebruik van Kubernetes tot kortere software cycli leidt. Toch gaat dit niet vanzelf. Om ontwikkelaars efficiënter te laten werken is immers wat denkwerk en een strategische planning nodig, voordat er gestart kan worden met het direct lanceren van een Kubernetes programma. Er zijn twee struikelblokken waar ik organisaties mee zie worstelen.
Te snel en gretig handelen kan leiden tot problemen
Als ik spreek met organisaties hoor ik steeds dat ze met de beste bedoelingen zijn begonnen en al een jaar of soms langer werken aan het zelfstandig opzetten van een Kubernetes platform, maar dat ze nog geen applicatie naar productie hebben kunnen brengen. De problemen bij doe-het-zelf Kubernetes initiatieven liggen echter niet bij het initieel installeren van Kubernetes zelf, maar aan alle andere activiteiten die erbij komen kijken. Denk hierbij aan de integratie met netwerken en storage en het implementeren en handhaven van security en compliance policies. Daarnaast moet er ook nog rekening worden gehouden met het opzetten van container registries, het bouwen van een service mesh en het managen en monitoren van het platform. En dan, als je dat allemaal voor elkaar hebt moet Kubernetes iedere drie maanden geüpgraded worden naar de volgende major release, zodat je over de nieuwste bug fixes en features beschikt. Het trainen en behouden van personeel voor het beheer, is overigens ook een veelvoorkomend probleem. Hierdoor hebben organisaties vaak het idee dat ze de softwareleverancier van zichzelf zijn geworden. Vervolgens moet op een gegeven moment het project worden geanalyseerd en kan de conclusie zijn dat het succes uitblijft.
Developers voelen zich niet betrokken
Een andere uitdaging is ervoor zorgen dat developers de Kubernetes clusters ook echt een verbetering vinden en het willen gebruiken. Gebruiksgemak is hierbij het belangrijkste selectiecriterium blijkt uit ons onderzoek. Te vaak heb ik programma’s gezien waarbij developers te laat in het proces werden betrokken om belangrijke beslissingen te valideren. Dit zorgt er mogelijk voor dat developers niet aan de slag gaan met Kubernetes als het beschikbaar wordt gesteld. Het is daarom belangrijk dat developers de nieuwe Kubernetes richtlijnen volgen. Kubernetes schrijft bijvoorbeeld een goed gedefinieerde infrastructuur architectuur voor, en er zijn duidelijke richtlijnen voor de applicatie architectuur. Het is hierdoor anders dan de klassieke, applicatie architectuur die de meeste enterprise applicaties volgen.
Bepaal eerst wat je nodig hebt
Kortom, een Kubernetes programma moet ontwikkelaars informeren en helpen om de nieuwe architectuur te begrijpen, zodat zij de applicaties op de juiste manier kunnen moderniseren. Het is daarom belangrijk developers al vroeg bij de ontwikkeling van het Kubernetes programma te betrekken, zodat ze vroegtijdig kunnen testen en feedback kunnen geven. Ontwikkelaars pas naderhand betrekken vormt een risico, door ze juist deelgenoot te maken van het Kubernetes programma zorg je ervoor dat ze zich mede-eigenaar voelen en daarmee verantwoordelijk zijn voor het succes.
We bewegen tenslotte toch naar een agile wereld dus waarom zouden we niet een applicatie platform bouwen en de gebruiker vragen hoe de experience moet zijn? Mijn aanbeveling is dan ook om eerst goed te bepalen wat er in totaliteit nodig is voordat je begint met Kubernetes en of je de mensen (vrij) hebt om de ontwikkeling te realiseren. Mijn collega Coté noemt het ‘The Blinking Cursor Problem’. Het eindresultaat van Kubernetes is slechts een knipperende cursor, klaar om applicaties te ‘runnen’. Wij zien het meeste succes bij organisaties die de inspanningen vanaf het begin richten op hoe deze applicaties in productie worden genomen. Veel IT-organisaties richten zich op wat ze jarenlang succesvol hebben gedaan, namelijk het neerzetten van de infrastructuur. Het verhogen van developer productiviteit vereist meer dan het neerzetten van Kubernetes alleen.
Dit is een ingezonden bijdrage van Rouven Besters, Regional Director Benelux & Nordics bij VMware Tanzu. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.
8 uur geleden
