Cloud native strategie en inrichting

Van 17 tot 19 maart 2026 was Amsterdam even de ‘Europese hoofdstad’ van VMware-gebruikers, IT-professionals en executives. Op die dagen vond namelijk VMUG Connect plaats. Dit is de opvolger van de bekende VMware UserCons, waar ik een van de mede-organisatoren van ben. Ik mocht dit jaar ook weer een inhoudelijke sessie verzorgen: Cloud native strategie – welke platformkeuzes kan je maken en hoe richt je dat in? Tijd voor een terugblik!

Over VMUG Connect

De inhoudelijke tracks van VMUG Connect focussen op technologieën die relevant zijn voor grote organisaties die op schaal werken. Hoe gaan die grote organisaties om met de kenmerkende enterprise complexity? En welke strategische en tactische keuzes kunnen zij maken om complexiteit te reduceren en flexibiliteit en performance te vergroten? In mijn sessie ben ik dieper ingegaan op de opties en keuzes rond een succesvolle cloud native-strategie.

 

Waarom cloud native?

De grote voordelen van cloud native zijn de vrijwel onbeperkte schaalbaarheid, hoge beschikbaarheid en flexibiliteit. Lifecycle management van cloud native applicaties is veel eenvoudiger (en dus efficiënter) dan in een klassiek applicatielandschap. Om cloud native te kunnen gaan werken, moet je een application modernization platform boven op je bestaande infrastructuur bouwen. In mijn sessie heb ik daarvoor twee platformen uitgelicht: Kubernetes en Cloud Foundry.

 

Begin met de strategie

Voordat je begint te bouwen moet je eerst bepalen waarop je bepaalde apps cloud native wilt gaan draaien. Gaat het om licentiekosten, kortere time-to-market, doorvoeren van snelle changes of wil je risico’s reduceren? Daarnaast inventariseer je je applicatielandschap om te kunnen bepalen welke apps je cloud native wilt en kunt uitvoeren. Pas daarna bepaal je wanneer en hoe je apps gaat verplaatsen naar jouw cloud native platform.

 

Inventariseer je applicatielandschap

Om de cloud (on-)mogelijkheden van jouw applicaties in kaart brengen classificeren wij de apps met het 5 R-model: Retain, Retire, Replatform, Rehost en Refactor.

1. Retain = je houdt je applicatie-architectuur zoals die is en laat hem draaien waar die nu ook staat.
2. Retire = je kan de functionaliteit in de applicatie vervangen door een SaaS-gebaseerde variant.
3. Replatform = Je zet de applicatie één op één om naar een container-variant die rechtstreeks op een Kubernetes-cluster wordt geïmplementeerd. Hier moet je wat mij betreft mee uitkijken. Als jouw applicatie namelijk niet voldoet aan de cloud native-principes dan crasht hij op een Kubernetes-platform.
4. Rehost = ‘lift and shift’: je verplaatst jouw workload naar een public of private cloud.
5. Refactor = Je herstructureert de applicatie-architectuur tot een collectie microservices zodat het een volledige cloud native applicatie wordt. Hiermee kan de applicatie op iedere cloud draaien.

 

De voordelen van refactoring

Bij refactoring is de investering in tijd en dus ook kosten aanzienlijk. Tegelijkertijd is de waarde curve daarin ook veel hoger. Het kost eenvoudigweg veel tijd en geld om een traditionele app naar cloud native om te bouwen. Maar als hij eenmaal op zo’n platform draait is hij veel stabieler omdat elke functie als een microservice wordt aangeroepen. Vergelijk het met de app van jouw bank. Als in die app een onderdeel een storing heeft, dan draait de rest van de applicatie gewoon door. Als dat in een traditionele app gebeurt, dan ligt de hele applicatie plat. Daarnaast kunnen cloud native apps eenvoudiger opschalen en kan je snellere software releases doen.

 

Architectuurkeuzes: Kubernetes versus Cloud Foundry

Daarna ben ik met de aanwezigen de architectuur ingedoken. Wat zijn de bouwblokjes van Kubernetes en Cloud Foundry, en hoe werken die platforms? Als je ze gaat gebruiken vanuit een open source-perspectief dan is het best wel complex. Gelukkig kan je het gebruik en beheer eenvoudiger maken met een aantal tools van vendoren.

Daarna heb ik een demo van beide platformen gegeven, en ben wat dieper ingegaan op de requirements die bepalen of je beter voor Kubernetes of Cloud Foundry kan kiezen voor jouw organisatie.

 

Wat is de beste keuze voor jouw organisatie?

Het antwoord hierop is zoals zo vaak in de ICT: dat ligt eraan. Heb jij als organisatie veel Java- of .NET-ontwikkelaars in dienst? Dan zoek je een platform waar ze de geschreven code op kunnen zetten en dan kom je al snel bij Cloud Foundry uit. Gebruik je dat platform, dan heb je aan het eind van de rit een draaiende applicatie.

Werk je veel met externe partijen voor softwareontwikkeling, dan is Kubernetes vaak een logische keuze. En dat terwijl Kubernetes heel complex is. Je hebt er veel al dan niet commerciële tools en software omheen voor nodig om het goed te kunnen laten draaien, bijvoorbeeld voor het beheren van certificaten. Waarom kiezen veel organisaties hier dan toch voor? De realiteit is dat die externe partijen zich vrijwel allemaal op Kubernetes hebben gericht. Daarmee ben je dus beperkt in je keuze.

 

Paneldiscussie Security

Ik kreeg ook de mogelijkheid om deel te nemen aan een paneldiscussie over security. Met een host en vijf mensen in het panel, waaronder een aantal product managers van VMware, hebben we met de aanwezigen bijna twee uur over security gepraat over de assen people, processess & technology. De aanwezigen waren gespecialiseerd in vDefend, Container Security, Avi Loadbalancer en NSX. Het was een super interessante sessie met veel vragen uit het publiek.

 

Topics die aan bod zijn gekomen:

• Wat is de visie van de panelleden rondom security?
• Hoe verhouden people, process en technology zich in dit verhaal?
• Hoe kan het MITRE ATT&CK-framework hierbij helpen?
• Hoe zorg ik voor een volledige zero-trust architectuur?
• Welke hulpmiddelen kan ik gebruiken voor microsegmentatie in mijn volledige VMware omgeving?
• Security-capabilities in Avi Loadbalancer, zoals de WAF (Web Application Firewall) en DDoS Protection.
• Hoe kan ik Security Intelligence inzetten om inzicht te krijgen binnen mijn infrastructuurlandschap?
• Hoe kun je de NSX Distributed Firewall (DFW) zo goed mogelijk inzetten, ook in combinatie met de Gateway Firewall (GFW) op de T0 en T1?
• De manier waarop de NSX Advanced Threat Prevention (ATP)-producten zowel known uknown vulnarabilities detecteren.
• Hoe de NSX Network Detection and Response (NDR)-oplossing alle data correleert vanuit de overige ATP-oplossingen zoals IDS/IPS, NTA en de Malware Prevention service.
• Containersecurity binnen NSX en hoe dit zich verhoudt tot de volledige CI/CD pipeline.
• Aan het einde gaf ieder panellid nog wat takeways en tips rondom security.

 

Specifieke vragen vanuit het publiek waren:

• Hoe sluit ik security van containers aan op het vDefend-product van VMware?
• Hoe kan ik op een correcte manier MFA doorvoeren op de VCF-producten?
• Hoe krijg ik mijn netwerk volledig end-to-end inzichtelijk?
• Hoe ga ik om met de hoeveelheid netwerkconfiguraties en VLANs die er in mijn netwerk zijn?

 

Wil je een keer praten over een van deze onderwerpen?

Wil je meer informatie over het ontwikkelen, implementeren en beheren van een cloud native infrastructuur voor jouw organisatie? Neem dan contact met ons op.