image_pdfimage_print

In deze vierde en laatste aflevering over hoe een organisatie datagedreven kan worden, kijken we naar de nieuwste trends in applicatieontwikkeling en hoe deze zich verhouden tot storage. Gartner voorspelt dat in 2022 meer dan 75% van de wereldwijde organisaties gecontaineriseerde applicaties in productie zal nemen, terwijl dat nu nog minder dan 30% is. Deze applicaties hebben aanzienlijke potentiële voordelen ten opzichte van traditionele, monolithische applicatieontwerpen, zoals schaalbaarheid, elasticiteit en wendbaarheid. Tijdens de recente Kubecon 2021-conferentie werd duidelijk dat gecontaineriseerde applicaties mainstream aan het worden zijn. Volgens CNCF wordt containerisatie steeds meer omarmd door organisaties in Europa, ook in Nederland zien we dit gebeuren. De termen cloud-native, containers en microservices komen ongetwijfeld bekend voor, maar laten we kijken wat ze betekenen. 

Cloud-native applicaties zijn specifiek ontworpen om vanaf dag één op een cloud-achtige manier te werken, of dat nu in de publieke cloud is of on-prem. Ze kunnen sneller worden geïmplementeerd en gerepareerd en kunnen gemakkelijk worden verplaatst tussen verschillende omgevingen. Cloud-native applicaties bestaan meestal uit microservices en worden verpakt in containers. Deze nieuwe cloud-native stack omvat een reeks applicaties, zoals apps die streaming data in realtime analyseren, apps die enorme hoeveelheden data indexeren voor zoekopdrachten en apps die machine learning-algoritmes trainen op steeds grotere datasets.  Deze cloud-native revolutie wordt aangedreven door een combinatie van containers en Kubernetes

Een container is een standaard software-eenheid waarin code en al zijn afhankelijkheden zijn verpakt. Daardoor kan een container snel en betrouwbaar van de ene computeromgeving naar de andere worden overgezet. Containers maken het eenvoudiger om cloudgebaseerde applicaties in te zetten, omdat ze alle informatie bevatten die nodig is om ze in beheersbare pakketten uit te voeren. Containers maken het efficiënt om op schaal in fragmenten opgesplitste applicaties te draaien met minimale overhead en met de nodige flexibiliteit. Kubernetes biedt de orkestratie van al deze toepassingsfragmenten en kan deze fragmenten samenvoegen tot een applicatie op het moment dat het nodig is. 

Waar we vandaan komen – monolithische applicaties

Een monolithische applicatie is een app waarbij alle code-elementen (gebruikersinterface, bedrijfslogica en toegang tot data) zijn gecombineerd tot een sterk geïntegreerd systeem. Soms zit alles in één enkel programma. Maar het kan ook een verzameling zijn van onderling sterk verbonden diensten met veel onderlinge afhankelijkheden, bijvoorbeeld een Oracle-database. Omdat de hele applicatie één programma is, of sterk geïntegreerd is, moet voor het bijwerken van zelfs maar een regel code de hele applicatie opnieuw worden geïmplementeerd. Dat maakt updates complex en tijdrovend. Deze updates zijn relatief zeldzaam – vaak driemaandelijks of jaarlijks – vanwege de verstoring die zo’n update veroorzaakt. Nieuwe functies moeten dan ook wachten tot een volgende release. Daarom worden monolithische applicaties vaak gezien als te traag om adequaat te reageren op gebruikers- en bedrijfsbehoeften.

En dan zijn er de microservices

Wanneer gaf bijvoorbeeld Netflix voor het laatst een onderhoudsmelding? Precies. Er is nooit een goed moment om dit soort services te updaten omdat er altijd wel iemand naar een nieuwe film of serie kijkt. Maar als er nooit een goed moment komt om een update uit te voeren, is het eigenlijk ‘altijd’ het beste moment om een update door te voeren. Dat klinkt contra-intuïtief. Maar om het updateprobleem op te lossen, gaat het principe van microservices er van uit dat je een applicatie moet opdelen in kleinere stukken die onderling communiceren via API’s. Daardoor kan elk deel onafhankelijk van andere delen een update krijgen. Als Netflix bijvoorbeeld zijn wachtwoord-reset-functionaliteit moet updaten, kunnen miljoenen kijkers gewoon blijven kijken als dit een microservice is die onafhankelijk van de rest van het streamingplatform een update kan krijgen

Microservices en containers – een perfecte match

Dankzij microservices kunnen IT-teams eenvoudiger de applicaties die hun gebruikers willen, bouwen en draaien. Veel van de grootste consumenten- en bedrijfsapplicaties draaien tegenwoordig als microservices. Het is niet alleen een relevante trend voor kleinere organisaties, maar ook voor de grootste en meest complexe. In wat voor omgeving moeten ze draaien? Containers zijn de perfecte bouwsteen voor microservices. Ze bieden een consistente lichtgewicht omgeving die de applicatie kan volgen vanaf de desktop van de ontwikkelaar, via testsystemen, tot de uiteindelijke uitrol op het productiesysteem. Bovendien kunnen containers draaien op zowel fysieke als virtual machines, en ze starten op in seconden of zelfs milliseconden, sneller dan het opstarten van een volledige virtual machine.

Toepassingen samen met hun afhankelijkheden verpakken

Traditioneel bevatten softwarepakketten alle code die nodig is om de applicatie uit te voeren op een bepaald besturingssysteem, zoals Windows of Linux. Er is echter meer nodig dan alleen applicatiecode om een applicatie te draaien, er zijn ook andere applicaties nodig. Bijvoorbeeld: een applicatie voor het opzoeken van aandelenkoersen zou een bibliotheek kunnen gebruiken om bedrijfsnamen om te zetten in ticker-symbolen en vice versa. Dit is generieke functionaliteit zonder toegevoegde waarde. Maar het is natuurlijk nog steeds belangrijk dat een gebruiker ‘Apple’ kan invoeren en dan het aandeel ‘AAPL’ krijgt. Deze bibliotheek is een voorbeeld van een afhankelijkheid. Zonder dat IT zich dat realiseert, kan een applicatie honderden van dit soort afhankelijkheden hebben.

Een van de belangrijkste redenen waarom containers zo populair zijn geworden, is dat ze een mechanisme en formaat bieden om applicatiecode – inclusief afhankelijkheden – te verpakken op een manier die het makkelijk maakt om een applicatie in verschillende omgevingen te draaien. Het lost een groot probleem op voor ontwikkelaars die constant te maken hebben met omgevingscompatibiliteitsproblemen tussen hun ontwikkellaptops, testomgevingen en productieomgevingen. Door containers te gebruiken om hun applicaties te verpakken, is ‘code once and run anywhere’ mogelijk, wat de oplevering van applicaties drastisch versnelt. 

Beheer van meerdere containers is complex

Omdat moderne applicaties uit meerdere microservices bestaan, bestaan ze vaak ook uit meerdere containers. Hierdoor kunnen complete applicaties gemakkelijk in meerdere omgevingen draaien. Dit roept de vraag op hoe je al die containers bijhoudt en beheert. Softwarebouwers en de bedrijven waarvoor ze werken, hebben geprobeerd met deze containers geld te verdienen. Per slot van rekening hebben ontwikkelaars meestal geen grote budgetten om mee te werken. Het beheren – of orkestreren – van al deze containers werd daarom al in een vroeg stadium gezien als een noodzakelijke en lucratieve uitbreiding van de containerrevolutie. In juni 2014 bracht Google Kubernetes uit als een open-sourceproject dat als een van de eerste de beheeruitdagingen van containers aanpakte.

 

Waarom een moderne data-ervaring nodig is

Wat de uitdagingen betreft, was de eerste generatie cloud-native applicaties ontworpen om stateless te zijn – met behulp van containers die applicatiewerk deden, maar geen persistente data hoefden op te slaan in bijbehorende volumes. Naarmate het gebruik van containers evolueert, bouwen ontwikkelaars steeds vaker stateful apps in containers – apps die data moeten opslaan in een volume dat in stand gehouden en bewaard moet worden. 

Dit is waar storage een uitdaging wordt en een moderne data-ervaring nodig is, omdat de flexibiliteit en openheid van containers verandert in barrières en knelpunten in de storage-laag. Eenvoudige storagemogelijkheden die we al jaren als vanzelfsprekend beschouwen in de traditionele applicatiestack (hoge beschikbaarheid, disaster recovery, back-up, encryptie) worden uitdagingen in de containerwereld. Erger nog, wat vaak gebeurt is dat voor elke applicatie zijn eigen opslagstrategie wordt bedacht, waardoor het onmogelijk wordt om standaarden en data-compliance binnen een organisatie door te voeren.

Provisioning on-demand 

Als best practice raden we aan een oplossing te kiezen die de Kubernetes-gebaseerde datadiensten levert die zowel cloudgebaseerde als traditionele apps nodig hebben (want die traditionele apps zullen niet snel verdwijnen). Dit betekent het leveren van block-, file- en object storagediensten, in meerdere performanceklassen, die on-demand worden geleverd zoals Kubernetes dat vereist. Het betekent het bieden van directe toegang tot data, bescherming tegen alle soorten storingen, de mogelijkheid om data te verplaatsen tussen clouds en zelfs van/naar de edge, en robuuste beveiliging – ongeacht waar een applicatie naartoe gaat. 

De toekomst van Kubernetes

Het zal duidelijk zijn waarom microservices de moderne architectuur bij uitstek zijn voor de ontwikkeling van applicaties, hoe containers de perfecte bouwsteen zijn voor microservices en waarom Kubernetes nodig is zodra het aantal containers explosief toeneemt. Maar hier eindigt het verhaal misschien niet. Kubernetes wordt steeds vaker gebruikt om applicaties te beheren die niet gecontaineriseerd zijn, maar alleen uit componenten bestaan. Zolang de applicatie maar te automatiseren is en de configuratie en storage gescheiden is van compute, kan Kubernetes helpen. Hoewel containerisatie hoogstwaarschijnlijk zal doorgaan, zullen we mogelijk zien dat dat bedrijven steeds vaker Kubernetes zonder containers gebruiken voor sommige applicaties.

Een echte data-driven organisatie

In de vier afleveringen van deze serie hebben we de belangrijkste criteria behandeld om een data-gedreven organisatie te worden. We hebben gekeken naar het gebruik van echte STaaS, het beschermen van data tegen ransomware en het herstel na een aanval, het gebruik van de cloud en het beheer van containers met Kubernetes. Als alle vier de elementen eenmaal op orde zijn, is de moderne data-ervaring bereikt. Een data-ervaring die de organisatie nu in de toekomst zal ondersteunen, zelfs als de technologie zich verder ontwikkeld.