"Draait het in de cloud?" "Ja." "Is het dan cloud native?" "Euh."
Cloud native is zo'n term waar je meestal mee om de oren wordt geslagen door iemand die je iets wil verkopen, meestal Kubernetes, soms een veel duur migratietraject. Het idee erachter is eenvoudig. En het is niet onbelangrijk, zeker als je maatwerk laat bouwen dat de komende jaren mee moet kunnen.
Cloud-hosted is iets anders
Je bestaande applicatie op een cloud server zetten is niet echt cloud native. De software merkt niet eens dat ze in de cloud staat. Ze verwacht nog altijd één machine, één schijf, één plek waar alles staat. Dat werkt prima, tot die machine uitvalt, tot je ineens twee keer zoveel gebruikers krijgt, of tot je naar een andere provider wil.
Cloud native software houdt er van bij het begin al rekening mee dat de machine waarop ze draait elk moment kan verdwijnen, en dat er net zo goed vijf kopieën tegelijk kunnen draaien. Voor een systeembeheerder lijkt dat een detail. In de praktijk is het precies de beslissing die bepaalt hoe duur je software de komende jaren wordt.
De applicatie schrijft niets naar schijf
Dit is de kern. Al de rest volgt eruit.
Als een draaiend programma niets vasthoudt wat je nodig hebt, kun je het zonder gevolgen afsluiten, vervangen of tien keer tegelijk starten. Nieuwe versie uitrollen? Je start een nieuwe container, stuurt het verkeer erheen en sluit de oude af. Crash? Herstarten. Piek in het gebruik? Zet er twee bij.
Houdt datzelfde programma wel iets vast (een geüpload bestand, een sessie in het geheugen, een logbestand), dan werkt geen van die trucs nog, en wordt elke ingreep een klusje met risico.
Containers, in de praktijk Docker, maken dit mogelijk. Ze verpakken je applicatie samen met alles wat ze nodig heeft, zodat ze overal identiek draait. Maar een container is pas nuttig als er niets in zit dat je niet mag verliezen.
Waar je gegevens dan wel staan
Niets naar schijf schrijven wil niet zeggen dat je gegevens nergens staan. Ze verhuizen naar een klein aantal plekken die daar wel voor gemaakt zijn.
- Een databank, bij ons meestal Postgres, voor je gegevens en sessies. Hoe je die gegevens modelleert is een verhaal apart. Daarover schreven we in wat is event sourcing en wanneer loont het voor een KMO.
- Object storage voor bestanden: contracten, foto's, geüploade PDF's. Precies wat je nodig hebt als je bijvoorbeeld documenten laat verwerken met AI.
- Telemetrie voor logs, metrics en traces. Wij sturen die met OpenTelemetry naar buiten in plaats van naar een logbestand op de server.
Zo blijft de applicatie vervangbaar en is er nog maar één plek die je echt moet beschermen.
Wat een KMO daaraan heeft
Je merkt het verschil op vier momenten.
Bij elke update. Nieuwe versies gaan live zonder dat er iemand offline moet. Geen onderhoudsvenster op zondagavond meer.
Als er iets stukgaat. Je herstelt door opnieuw te starten, niet door te repareren. Een storing duurt seconden in plaats van een halve dag.
Als je groeit. Meer capaciteit betekent gewoon een tweede kopie opstarten. Je software groeit mee met je bedrijf, in plaats van er een rem op te zetten.
Bij je back-up. Omdat alle waardevolle data op één plek staat, is je back-upstrategie eenvoudig genoeg om ook écht getest te worden. Meteen een stuk van je NIS2-huiswerk gedaan.
Je hebt hier geen hyperscaler voor nodig
Cloud native wordt vaak gelezen als "bij Amazon, Microsoft of Google". Dat klopt niet, en soms gaat het er zelfs tegenin.
Een applicatie die volledig op de eigen diensten van één provider leunt, is misschien modern, maar je krijgt ze nergens anders naartoe. Dat is net de vendor lock-in die je met containers wou vermijden. Een gecontaineriseerde applicatie met een gewone Postgres en S3-compatibele opslag verhuis je in een dag. Wij draaien ze op Europese servers; de redenering daarachter staat in hoe Europese cloud jouw bedrijf kan helpen.
Hetzelfde geldt voor Kubernetes. Prachtig gereedschap als je honderd services beheert. Voor de meeste KMO-projecten is het een tweede probleem bovenop het eerste. Containers achter een reverse proxy doen hetzelfde werk, met een fractie van het onderhoud. Die afweging werkten we uit in heb je als KMO echt Kubernetes nodig. Maar iets dat cloud native is opgezet kan je heel simpel verzetten van een simpele docker compose naar Kubernetes of omgekeerd.
Hoe wij dit bij Tandem Studio aanpakken
Onze standaardopstelling voor maatwerk is bewust saai. Een applicatie in Go, verpakt als container, met Postgres voor de gegevens en object storage voor de bestanden. Docker Compose achter Traefik, telemetrie via OpenTelemetry, alles op Europese servers bij Scaleway.
Niets in de applicatie raakt de schijf. Daardoor kunnen we drie jaar later nog probleemloos updates uitrollen, zonder jou 's avonds te bellen.
De databank schrijft natuurlijk wél naar schijf. Dat is het ene volume dat ertoe doet, en het enige waarvan de back-up écht jouw beschikbaarheid bepaalt. Wie Postgres in een container zet zonder volume, leert dat op de moeilijke manier.
Veelgestelde vragen
Is cloud native hetzelfde als Kubernetes?
Nee. Kubernetes is één manier om cloud native software te draaien, en voor de meeste KMO's een zware. Het principe zit in hoe je applicatie gebouwd is, niet in welk platform ze draait.
Moet ik naar AWS of Azure om cloud native te zijn?
Nee, en soms werkt dat zelfs tegen je. Hoe dieper je in de eigen diensten van één provider zit, hoe moeilijker je er weg raakt. Een container met een gewone Postgres en S3-compatibele opslag draait evengoed op Europese infrastructuur.
Kan ik bestaande software cloud native laten maken?
Vaak wel, en meestal is dat beperkter werk dan een herbouw. De vraag is telkens: wat schrijft de applicatie vandaag naar schijf, en waar kan dat naartoe? Uploads naar object storage, sessies naar de databank, logs naar telemetrie.
Betekent dit dat er nergens meer iets op schijf staat?
Nee. De databank schrijft wél naar schijf, en dat is precies de bedoeling. Het punt is dat alles wat je niet mag verliezen op één beheerde plek staat, in plaats van verspreid over elke draaiende container.
Hoe je software met data omgaat bepaalt wat ze je de komende jaren gaat kosten, of je nu een bestaande applicatie hebt die aan haar limiet zit of van nul begint.
Vertel ons wat je in gedachten hebt, dan bekijken we samen wat er in jouw geval zinvol is.
