Als je het infrastructuurgesprek nog steeds framet als één architecturale keuze - on-premise of cloud, kies er één en houd je daaraan - dan beantwoord je een vraag die je vakgenoten rond 2023 al niet meer stelden. De verschillen die de oude vergelijkingstabellen opsommen (kapitaaluitgaven vs. operationele kosten, wie de data beheert, hoe snel je kunt schalen, wie de onderhoudslast draagt) zijn allemaal nog steeds reëel. Wat is veranderd, is de beslissing waar ze in uitmonden. Voor elke serieuze engineeringorganisatie in 2026 is dit niet langer een locatiekeuze die je één keer op platformniveau maakt. Het is een plaatsingsbeslissing per workload, die je individueel onderbouwt op kosten, datagevoeligheid, performance en operationele fit, en die je herziet zodra die variabelen verschuiven. Dit artikel loopt de vier klassieke verschillen langs vanuit dat nieuwe perspectief, en onderbouwt elk verschil met wat de huidige data daadwerkelijk laat zien in plaats van de marketingversie ervan.
Kosten: het pay-as-you-go-verhaal is niet goed verouderd
De gangbare verkooppitch is dat on-premise zware investeringen vooraf vereist, terwijl het consumptiemodel van de cloud inherent goedkoper en efficiënter is. De eerste helft klopt. De tweede helft is het deel dat stilletjes is uitgegroeid tot de grootste operationele hoofdpijn in de sector. Flexera's 2025 State of the Cloud Report, gebaseerd op meer dan 750 technische professionals en bestuurders, constateerde dat 84% van de organisaties het beheersen van clouduitgaven als hun grootste clouduitdaging noemt, dat organisaties hun cloudbudget gemiddeld met 17% overschrijden, en dat ongeveer 27% van de clouduitgaven wordt verspild. Cloud is niet betrouwbaar goedkoper. Het is betrouwbaar makkelijker om er te veel aan uit te geven, want dezelfde elasticiteit waarmee je om 3 uur 's nachts kunt opschalen, zorgt er ook voor dat ongebruikte resources, te grote instances en vergeten omgevingen kosten blijven opbouwen zonder dat iemand in de goedkeuringsketen zit.
De strategische correctie is niet "ga terug naar on-premise". Het is om kosten te behandelen als iets wat je engineert en bestuurt, niet als iets wat het facturatiemodel je in de schoot werpt. Hetzelfde rapport laat zien dat 87% van de organisaties kostenefficiëntie en besparingen nu als belangrijkste metric bestempelt, en dat een meerderheid leunt op FinOps-praktijken en managed service providers om weer grip te krijgen. Voor een engineering director is de praktische implicatie concreet: cloudplaatsing is alleen verdedigbaar als die gepaard gaat met forecastingdiscipline, tagging en showback, rightsizing, en iemand die verantwoordelijk is voor de run-rate. On-premise wint nog steeds op unit economics voor stabiele, voorspelbare workloads met een hoge benuttingsgraad - precies die waarbij je een cloudpremie betaalt voor elasticiteit die je in de praktijk nooit gebruikt. Veelzeggend genoeg wordt, ondanks al deze aandacht, de groei van de clouduitgaven nog altijd geraamd op 28% jaar-op-jaar, wat aangeeft dat het antwoord governance is, geen terugtocht.
Security en datacontrole: hier valt over plaatsing het minst te onderhandelen
De oude vergelijking behandelt security als een gelijkspel - on-premise geeft je directe controle en volledige verantwoordelijkheid, terwijl cloudproviders meer in security-infrastructuur investeren dan jij ooit zou kunnen. Beide blijven kloppen, en voor de meeste workloads tillen de grote hyperscalers je baseline daadwerkelijk omhoog. Maar security is zelden nog de doorslaggevende variabele. Datacontrole en soevereiniteit zijn dat wel. De vraag die de plaatsing daadwerkelijk stuurt, is niet "is de cloud veilig", maar "waar mag deze specifieke dataset juridisch en contractueel staan, wie kan worden gedwongen om die af te geven, en kan ik tegenover een auditor aantonen waar de data zich bevindt". Voor gereguleerde data - betaalgegevens, gezondheidsdata, alles wat onder soevereiniteits- of sectorspecifieke residency-eisen valt - kunnen die antwoorden een workload naar on-premise of naar een specifieke jurisdictie dwingen, hoe goed de encryptie van de provider ook is.
Precies daarom faalt een binaire, platformbrede keuze: één en dezelfde organisatie zal terecht stateless, klantgerichte services in de public cloud draaien terwijl ze een gereguleerd system of record on-premise of in een soevereine regio houdt. De onderscheidende factor op workloadniveau is datagevoeligheid en de kosten van het aantonen van controle, niet een algemeen oordeel over de vraag of "de cloud" veilig is.
Schaalbaarheid: de waarde zit in het operating model, niet in de migratie
Het schaalbaarheidsvoordeel van de cloud is reëel en grotendeels onbetwist - je kunt capaciteit binnen minuten toevoegen en weghalen in plaats van via inkoopcycli. De valkuil is de aanname dat het voordeel arriveert zodra je workload in een cloudaccount belandt. Dat is niet zo. DORA's 2024 Accelerate State of DevOps Report is daar onverbloemd over: het benutten van flexibele cloudinfrastructuur verhoogt direct de organisatieprestaties, maar simpelweg naar de cloud migreren zonder de inherente flexibiliteit te omarmen "kan schadelijker zijn dan blijven in een traditioneel datacenter."
Die zin zou moeten veranderen hoe je een migratie onderbouwt. Lift-and-shift - een statisch geprovisioneerde, verticaal geschaalde, handmatig beheerde applicatie nemen en exact hetzelfde draaien op gehuurde hardware - behoudt elke beperking van on-premise en plaatst er een rekening met verbruiksmeter bovenop. Je krijgt het kostenprofiel van de cloud met de starheid van een datacenter. Het schaalbaarheidsverschil wordt pas een voordeel wanneer de workload opnieuw wordt gearchitecteerd om het te benutten: horizontale autoscaling, infrastructure as code, ontkoppelde state, en elastische capaciteit die ook echt krimpt als de vraag daalt. Als een workload dat operating model niet kan of niet wil omarmen - omdat het een legacy-monoliet is, een licentiegebonden database, of een stabiele batchjob - dan is "cloud is schaalbaarder" abstract waar en in de praktijk irrelevant voor die workload. Dat is een sterk signaal om hem on-premise te laten.
Onderhoud: de last verschuift, hij verdwijnt niet
On-premise betekent dat je de volledige stack bezit: hardware, patching, capaciteit, het hele zwikje. Cloud verschuift het infrastructuuronderhoud naar de provider, wat teams daadwerkelijk bevrijdt van een categorie ongedifferentieerd werk. Maar het frame dat de cloud je laat "focussen op kerncompetenties" verkoopt het te mooi. De onderhoudslast verandert van vorm in plaats van te verdwijnen. Je ruilt hardware-lifecycle en fysieke capaciteitsplanning in voor het beheren van IAM-wildgroei, networking, service limits, version deprecations op managed services, en - zoals het kostengedeelte duidelijk maakte - continue spend governance. Teams die migreren in de verwachting dat het onderhoud afneemt en hun bezetting daarop afstemmen, ontdekken doorgaans dat het cloud operating model minstens evenveel engineeringdiscipline vergt als het datacenter, alleen gericht op andere problemen.
Het eerlijke antwoord: bewust hybride, per workload onderbouwd
De markt is hier al naartoe geconvergeerd. Uit IDC-onderzoek van medio 2024 bleek dat ongeveer 80% van de organisaties binnen 12 maanden enige repatriëring van compute en storage verwachtte, terwijl minder dan 10% volledige workloads had teruggehaald naar on-premise. Goed gelezen is dat geen clouduittocht - het is selectieve correctie. Foundry/CIO formuleert het precies: dit is een verfijning van de cloudstrategie richting hybride als ideaal, geen afwijzing van de cloud. Flexera's data komt op hetzelfde uit, met momenteel ongeveer 55% van de workloads in de public cloud en zo'n 21% gerepatrieerd. De cijfers beschrijven een sector die workloads aan de marge heen en weer beweegt om waarde te optimaliseren, niet een sector die een winnaar uitroept.
De vier verschillen houden dus nog steeds stand - maar het zijn inputs voor een plaatsingsbeslissing, geen argumenten voor één kant. De verdedigbare positie voor een team met grote schaal of strenge regelgeving is een bewust hybride model waarin de thuisbasis van elke workload op vier assen wordt onderbouwd:
- Kosten en benutting. Stabiele workloads met een hoge benuttingsgraad pakken vaak goedkoper uit op on-premise; bij piekerige of onvoorspelbare vraag verdient cloud-elasticiteit haar premie - mits je de FinOps-discipline hebt om de 27% verspilling te stoppen.
- Datagevoeligheid en soevereiniteit. Residency-, regelgevings- en contractuele beperkingen kunnen een workload vastpinnen, ongeacht elke andere factor. Bepaal dit als eerste, want het is de minst flexibele input.
- Performance en architecturale fit. Latency-gevoelige of hardware-gebonden workloads, en alles wat geen cloud-native elasticiteit kan omarmen, winnen weinig bij migratie en kunnen er zelfs op achteruitgaan.
- Operating model. Volgens DORA zijn de workloads die profiteren juist die waarvan de teams de cloudflexibiliteit daadwerkelijk gaan benutten. Als je niet opnieuw gaat architecteren, krijg je het voordeel niet.
De teams die dit goed doen, zijn niet degenen die "naar de cloud zijn gegaan" of "on-prem zijn gebleven". Het zijn degenen die ophielden het als één beslissing te behandelen, de kostengovernance en architecturale discipline opbouwden om elke plaatsing verdedigbaar te maken, en accepteerden dat het juiste antwoord voor een gegeven workload kan veranderen naarmate kosten, regelgeving en vraag verschuiven. De verschillen zijn nog steeds de moeite waard om in detail te begrijpen. Stop alleen met ze te gebruiken om een winnaar aan te wijzen.
Bronnen
- New Flexera Report Finds that 84% of Organizations Struggle to Manage Cloud Spend - 2025 State of the Cloud Report (Flexera)
- The great repatriation? IT leaders reset cloud strategies to optimize value (CIO / Foundry)
- Assessing the Scale of Workload Repatriation: Insights from IDC's Server and Storage Workloads Surveys, 1H23 and 2H23 (IDC)
- Accelerate State of DevOps Report 2024 (DORA / Google Cloud)
