Even kort over VMUG Connect
De tracks van VMUG Connect focussen zich 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 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 écht bij het begin, dus met de strategie
Voordat je begint te bouwen bepaal je eerst waarom en waarop je bepaalde apps cloud native wilt gaan draaien.
Wat is je doel?
Gaat het om licentiekosten, kortere time-to-market, doorvoeren van snelle changes of wil je risico’s reduceren? Dit is de basis voor de inventarisatie van je applicatielandschap. Daarin bepaal je welke apps je cloud native wilt en kúnt uitvoeren. Pas daarná 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 te brengen, classificeren wij de apps op basis van het 5 R-model:
Retain = je houdt je applicatie-architectuur zoals die is en laat hem draaien waar die nu ook staat.
Retire = je kan de functionaliteit in de applicatie vervangen door een SaaS-gebaseerde variant.
Replatform = Je zet de applicatie één op één om naar een container-variant die rechtstreeks op een Kubernetes-cluster wordt geïmplementeerd. Een persoonlijke noot, hier moet je wel oppassen. Als jouw applicatie niet voldoet aan de cloud native-principes, dan crasht hij op een Kubernetes-platform.
Rehost = ‘lift and shift’: je verplaatst jouw workload naar een public of private cloud.
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
Kies je voor Refactoring, dan is de investering in tijd en daarmee ook kosten aanzienlijk. Tegelijkertijd is de waardecurve 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 het meest stabiel. Elke functie wordt als een microservice aangeroepen. Vergelijk het met de app van jouw bank. Als in jouw bankapp 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 kun je snellere software releases doen.
Architectuurkeuzes: Kubernetes versus Cloud Foundry
Na bovenstaande uitleg ben ik in de sessie met de aanwezigen de architectuur ingedoken: Wat zijn de bouwblokjes van Kubernetes en Cloud Foundry, en hoe werken die platforms? Wanneer je ze gebruikt vanuit een open source-perspectief dan is het best complex. Gelukkig is het mogelijk om het gebruik en beheer eenvoudiger te maken met een enkele tools van vendoren. Vervolgens ben ik met een demo van beide platformen dieper ingegaan op de requirements. Deze bepalen of je beter voor Kubernetes of Cloud Foundry kunt kiezen voor jouw organisatie.
Wat is de beste keuze voor jouw organisatie?
Het antwoord hierop is zoals zo vaak: 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 omheen nodig, om alles goed te kunnen laten draaien. Denk aan het beheren van certificaten.
Waarom kiezen veel organisaties dan toch voor Kubernetes? De realiteit is dat die externe partijen zich vrijwel allemaal op Kubernetes hebben gericht. Daardoor ben je dus beperkt in je keuze.
Wil je meer informatie over het ontwikkelen, implementeren en beheren van een cloud native infrastructuur voor jouw organisatie? Neem dan contact met ons op.
