De kans is groot is dat it-operators op korte termijn naadloze, functionele en effectieve netwerkmonitoring in hun diensten moeten integreren. Aangezien it-technologie blijft innoveren en snel vooruitgang boekt, moet de industrie openstaan voor verandering.
Sinds het begin van deze eeuw zijn er drie grote verschuivingen geweest op het gebied van it-operations.
De eerste was virtualisatie, waarbij we van een bare metal-server met een paar applicaties, naar een enkele server met gevirtualiseerde ‘servers’ gingen. Die servers werden onttrokken door de onderliggende hardware van de server te virtualiseren, en beheerders toe te staan om veel servers op een enkele bare metal-server te laten draaien. Doordat je onder andere minder fysieke servers nodig hebt, betekent dit minder investeringen vooraf.
De tweede verschuiving was de adoptie van containers. Containers werken op dezelfde manier als virtualisatie, maar brengen de abstractie naar een hoger niveau. In plaats van alleen de hardware te virtualiseren en op elke virtuele-machine (vm)-volwaardige besturingssystemen uit te voeren, draaien containers bovenop het besturingssysteem van een host of node. Dit betekent dat je veel workloads op één besturingssysteem uitvoert.
Deze nodes of hosts hoeven niet op bare metal te staan; het kunnen ook vm’s zijn, maar het idee is dat je één ‘server’ hebt waarop veel containers kunnen draaien. Loadbalancing wordt daarmee efficiënter, omdat je alleen maar nieuwe exemplaren van de toepassing verplaatst of creëert.
De laatste, meest recente verschuiving is die naar serverless. Containers laten nog een niveau van abstractie toe: functions-as-a-service (faas), soms ook wel serverless genoemd, omdat het de noodzaak voor iemand binnen de organisatie om een server te onderhouden, overbodig maakt. Dit betekent niet dat er ergens een server is die uw functie uitvoert; iemand anders zorgt er gewoon voor dat het werkt.
Faas staat softwareontwikkelaars toe om hun business logic te schrijven en het dan te uploaden naar een faas, ofwel met een cloudprovider als AWS or Azure, ofwel met iets als Kubeless of Openfaas. Ze kunnen een event driven architectuur opzetten om hun business logic op te laten draaien en klaar is Kees. De operatie van de servers voor de containers en de operatie van de container-orkestratie is helemaal ontkoppeld, waardoor je je kunt focussen op applicatieontwikkeling en je niet druk hoeft te maken over hoe je het laat draaien.
Tijdelijke aard
Over een paar jaar interesseert infrastructuur ons niet meer, doordat we ons van hardware af bewegen en door de tijdelijke aard van applicaties. Hoe meer we ons en onze applicaties van bare metal laten weg bewegen, hoe minder we ons ermee bezig hoeven te houden.
Denk erover na. Als een operator een complete serverless applicatie in een publieke cloud zet, hoeft hij zich geen zorgen te maken over de infrastructuur erachter, maar kan hij het ook niet monitoren. Er is geen manier om toegang te krijgen tot de metrics of de servers achter de containers die de code draaien.
In het geval van containers zouden devops-teams – die applicaties draaien in containers op een goedgebouwd Kubernetes-cluster of een managed cluster in de cloud – niet hoeven na te denken over de hardware waarop het draait.
Steeds vaker zal het beheer van K8-clusters of iets vergelijkbaars verplaatsen naar de cloud. En de hardware onder die clusters of de clusters zelf zullen dan echt geen zorg zijn van het bedrijf dat de applicaties draait.
De reden dat het logisch is om dit werk uit te besteden, is dat de abstractie van computing, hardware en het laten draaien ervan steeds meer een standaardproduct wordt.
Toekomst
De vraag die rijst is: hoe ziet de toekomst van monitoring eruit? Om deze vraag te beantwoorden, moeten we ons richten op de applicatie zelf in plaats van op de workloads die op de infrastructuur draaien.
Inzicht verkrijgen is een goede manier om hierover na te denken. Het omvat metrics, logs en traces die direct in of uit onze workload of applicatie komen. Met deze data kunnen we de huidige staat van een systeem afleiden, plus de context om die staat te interpreteren.
Hoge importantie in onze monitoringdata was altijd patroonloos en iets wat iedereen probeerde te vermijden. Maar om een applicatie inzichtelijk te maken, moet je relevante data opslaan om in een probleem te kunnen duiken wanneer het zich voordoet.
Wanneer een operator een probleem in een applicatie heeft geïdentificeerd, zal hij naar de dataflow-logs willen kijken om duidelijk te krijgen of het netwerk worstelt met het schrijven van een specifieke node en daardoor bijvoorbeeld schrijf-time-outs veroorzaakt.
Uiteindelijk zal de manier waarop operators hun netwerken monitoren steeds meer wegschuiven van bare metal. En omdat we steeds minder leunen op hardware, is het logisch dat de it-industrie mee moet veranderen.
Het verhaal van ‘serverless’ is onzin omdat door virtualisatie de galvanische afhankelijkheid niet kleiner is geworden, aan de andere kant van de lijn zitten geen 30 chinezen met een telraam om de berekeningen te doen.
Prima artikel waar ik helemaal achter sta!
Ewout, “galvanische afhankelijkheid”: What does that even mean?
Het verhaal van serverless vind ik helemaal geen onzin. Maar soms moet je dingen gebruiken om te snappen wat het doet en wat de betekenis is en niet door er eendimensionaal naar te kijken.
En als je dan zo van abstracties houdt, lees dan een wat meer over Wardley maps, het zal je aanspreken. Laat Simon Wardley nu ook eens groot fan zijn van serverless.
Volgens dit artikel moet ik van alles, waarom?
En Henri “galvanische afhankelijkheid” is wat je merkt zodra memory/cpu/disk(ssd) gewoon kapot gaan.
Dan doet je programma het ook niet meer.
Weet je, 1 EMP kan je hele dag verpesten.
30 horizontaal geschaalde resources zorgen wel er wel degelijk dat je dag niet verpest wordt door een EMP.
Henri,
Ik stelde dat aan de andere kant van de lijn nog gewoon de gebruikelijke ijzerwaar staat. Dat het knuffelen van die ijzerwaar uitbesteed is aan een andere partij betekent nog niet een serverless architectuur. En zoals Jan al zegt is het feest gauw afgelopen als door een stroomstoring de onderliggende servers het niet meer doen. En de cache mechanismen om genoemde schrijf time-outs in de keten te voorkomen zijn vaak dus niet tegen stroomstoring beschermt.
Wardley mapping lijkt me de zoveelste vorm van abstracte kunst, visualisaties hebben weinig waarde als er geen metrics (KPI) onder zitten. En opmerkelijk veel organisaties hebben dan ook moeite met het contractmanagement doordat die stippen op papier allemaal weer andere juridische aspecten hebben. Gezien de krantenberichten maken een heleboel mensen zich momenteel daarom juist zorgen over de strategische core infrastructuur.
Mijn driedimensionale kijk op de IT architectuur maakt dus onderscheid tussen de verschillende lagen hierin die allemaal een verschillende snelheid van verandering hebben. Ik wens je dus veel succes om de bedrijfskritische processen – met strikte SLA’s (KPI) – in serverless architecturen te laten verdampen.
Serverless betekend gebruikmaken van venor/cloudspecifieke api’s en webdiensten
Serverless/Faas betekend gewoon een vendor lockin
Je Serverless applicatie gemaakt op Azure kan je nooit op Google Cloud of Amazon gaan draaien (je zal de “serverless/faas” applicatie daar helemaal opnieuw moeten maken) Na de vendorlockin komen de prijsverhogingen automatisch.
Geef mij dan maar een cloud onafhankelijke container waar de applicatie in draait, dan kan je ten minste kiezen waar hij moet gaan draaien (on premise, Azure, Google Cloud, AWS is dan allemaal mogelijk) en heb je iets te onderhandelen.