Cloud native. De term voelt soms een beetje aan als een ouderwetse reclame voor een wasmiddel. ‘Je was wordt nog witter’ of ‘verbeterde formule’. Maar werkt het echt, of is het gewoon marketing? Mijn was werd toch al wit. De vraag is dus of cloud native echt werkt. Ik zit toch al in de cloud? Als we er goed naar kijken, heeft het begrip cloud native misschien wel minder met de cloud te maken dan je denkt.
Wat wordt er eigenlijk bedoeld met cloud native? Dat is niet heel eenduidig. Er zijn verschillende definities in omloop en men zegt ook wel dat je het niet moet definiëren omdat je het dan teveel vastlegt en het zich niet meer kan ontwikkelen. Hoewel hier iets voor te zeggen valt, zijn we toch gebaat bij enige houvast. Dus toch een poging.
De Cloud Native Foundation heeft zich het volgende doel gesteld: Als onderdeel van de Linux Foundation, geven wij support, inzicht en sturing aan snel groeiende cloud native-projecten, waarbij ook Kubernetes, Envoy, en Prometheus worden ingezet. Dit zijn allen populaire tools die gebruikt worden voor het beheer en de monitoring van (cloud) softwareoplossingen.
In dit kader hebben ze ook een definitie gegeven voor cloud native:
Cloud native-technologieën stellen organisaties in staat om schaalbare applicaties te ontwikkelen en te draaien in moderne en dynamische it-omgevingen zoals public, private, en hybrid clouds. Containers, service meshes, microservices, immutable infrastructuur en declaratieve api’s illustreren deze benadering. Deze technieken maken de weg vrij voor flexibel gekoppelde systemen die veerkrachtig, eenvoudig in beheer en goed te monitoren zijn. In combinatie met robuuste automatisering kunnen engineers frequente en voorspelbare aanpassingen doen, die een grote impact hebben zonder al te veel inspanningen.
Efficiency en beschikbaarheid
Deze beschrijving is wel heel technisch. Het gaat erg in op de techniek: de schaalbaarheid van applicaties in een dynamische omgeving, cloud- en containertechnologieën, et cetera. Amazon gaat in aanvulling hierop in op de vraag wanneer je cloud native zou willen toepassen. Ze benoemen drie punten:
- Hogere efficiency, waarmee ze vooral doelen op hogere productiviteit van ontwikkelaars.
- Lagere kosten, daarbij denken ze vooral aan het goed gebruiken van cloud waardoor je kunt besparen.
- Hogere beschikbaarheid, door de gedecentraliseerde architectuur van cloud native-applicaties kun je beschikbaarheid verhogen.
Als we cloud native toch van de technische kant benaderen, is het van belang te weten hoe het werkt. En waar de meningen over een definitie uiteenlopen, zijn de experts het op dit vlak met elkaar eens.
Het gebruik van containers staat buiten kijf als het om cloud native gaat. Dat komt omdat er altijd gedacht wordt vanuit een microservice-architectuur. En dat is een belangrijk element. Deze architectuur geeft het voordeel van flexibiliteit en schaalbaarheid. En containers passen heel goed op deze architectuur.
Overigens is het ook goed om op te merken dat deze voordelen een prijs hebben. Je voegt wel complexiteit aan je architectuur toe. Een goede afweging van voordelen tegen complexiteit is nodig voordat je de stap maakt.
Er is hulp bij die complexiteit, met name op het infrastructurele deel van je landschap. Door te standaardiseren op Kubernetes, maak je gebruik van een gemeenschappelijke taal voor al je microservices. Je beschikt over een abstractielaag op je infrastructuur die het beheer van je services eenvoudiger maakt.
Werken met een zogenaamde immutable infrastrucutre helpt daar ook bij. Eigenlijk wil dat zeggen dat alle infrastructuur door code wordt opgebouwd en daarna niet meer aanpasbaar is. Aanpassingen doe je door de onderliggende code aan te passen en opnieuw uit te voeren. Dat zorgt voor een heel stabiele en voorspelbare infrastructuur door de hele softwareontwikkelstraat heen.
Snelheid en innovatiekracht
In de beschrijving van cloud native komt de term cloud zelf weinig voor. Dit komt doordat het niet afhankelijk is van elkaar. De opkomst van cloud heeft zeker gezorgd voor een andere manier van kijken naar applicatieontwikkeling. Door de onderliggende infrastructuur meer te standaardiseren en als api beschikbaar te maken, werd het makkelijker om microservice-architecturen te realiseren. De snelheid en innovatiekracht van de grote cloudaanbieders maakten het mogelijk om dit voortvarend te doen. Iets wat in onze eigen datacenters lange projecten zouden zijn waarvan succes niet altijd verzekerd is.
Dus de opkomst van cloud heeft er zeker voor gezorgd dat cloud native ontwikkelen sneller is omarmd en breed wordt toegepast. En dat is een goede ontwikkeling, want het levert inderdaad de voordelen op die Amazon beschrijft. Maar besef wel dat het niet hard is gekoppeld aan een cloudaanbieder. Veel bedrijven hebben meer dan één cloudaanbieder en over het algemeen ook nog een eigen datacenter. Ook dan is het heel goed mogelijk om cloud native te ontwikkelen.
Gert Jan, veel partijen verwijzen naar de definitie van Cloud Native Foundation (“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. …….”). Maar daarna geven die andere partijen er hun eigen draai aan in een poging om duidelijkheid naar de praktijk te scheppen, en hun visie te verkopen. Het “such as” wordt bijvoorbeeld niet altijd meegenomen.
Probleem is dat bij het definiëren van Cloud Native, het volgende door elkaar gaat lopen: het abstracte concept (sommigen noemen het een filosofie) van Cloud Native, de verwijzingen naar architectuur, de doelen en of voorwaarden, het model (de gegeneraliseerde praktijk of de huidige praktijk van een bepaald bedrijf), de tools / technieken (niet alleen qua software, maar ook hardware), de resultaten en soms zelfs de grote beloften.
Dit levert een wirwar van gedachten op. Dit bemoeilijkt niet de communicatie over Cloud Native, maar ook de verdere ontwikkeling en aanpassing van de definitie van Cloud Native gedurende de verdere ontwikkeling.
De Cloud Native Foundation zou eigenlijk terug naar de tekentafel, om die aspecten onder elkaar te zetten, in plaats van naast elkaar en door elkaar. Maar ik ken de sfeer van die club niet; wellicht is dit niet mogelijk. Gert Jan, toch een mooie poging om ons na te laten denken over één van de belangrijke ontwikkelingen in de ICT.
‘Cloud’ is natuurlijk zelf al zo’n containerbegrip, sorry voor het verwarrende woordgebruik, waarmee iedereen net iets anders wil benadrukken, afhankelijk van de boodschap. Het kan geen kwaad de aspecten van een ‘buzz begrip’ een keer op een rijtje te zien in Computable, zoals in dit artikel, plus wat uitleg over welke softwarematige technieken worden toegepast.
Alleen aan het eind mis ik het het begrip “private cloudomgeving”, want dat is toch wat het oplevert als je cloud native in een eigen datacenter toepast? Het idee dat ‘de cloud’ alleen door publieke cloud aanbieders wordt geleverd, lijkt me nu juist door een ontwikkeling als cloud native achterhaald. De kop van het artikel is blijkbaar alleen bedoeld om aandacht te trekken…
Beste Fred, ik heb met opzet de term “private cloud” niet gebruikt. Dat is naar mijn mening bijna een artikel op zich. Omdat een echte private cloud heel lastig is om te realiseren en die projecten mislukken vaak.
Blijft wel dat je in je eigen data center prima cloud native kan werken. De publiek cloud providers helpen daarbij door bijvoorbeeld op Kubernetes gebasseerde platformen cross cloud en eigen datacenter beschikbaar te maken. Ik denk dat die optie vaak realistischer is dan een private cloud bouwen.
Maar opnieuw, dat kan je best als definitie kwestie beschouwen
Beste Jaap, je hebt helemaal gelijk. En ik wilde proberen dat aan te kaarten door terug te gaan naar wat het volgens mij is. En vandaaruit verder te kunnen denken over hoe we het kunnen gebruiken.