Cloud-native waar het past: zes bewuste keuzes voor digitale overheidsoplossingen

Al jaren ervaren we tijdens projecten en in gesprekken met klanten zowel de voordelen als de beperkingen van cloud-native denken. Zeker binnen een strikt gereglementeerde sector als de overheid vraagt elke digitale oplossing om een doordachte afweging. Welke gegevens worden verwerkt? Waar mogen die worden opgeslagen? Hoe belangrijk zijn maatwerk, integraties en voorspelbare prestaties? En hoeveel regie wil een organisatie zelf behouden?

Informatieveiligheid, datasoevereiniteit en technologische onafhankelijkheid zijn vandaag geen bijkomstigheden, maar essentiële voorwaarden. Daarom kiezen we niet automatisch voor of tegen cloud-native. We bekijken per project en oplossing welke architectuur het beste aansluit bij de processen, risico’s en infrastructuur van de organisatie.

We zetten zes redenen op een rij waarom het soms een bewuste keuze is om net niet cloud-native te werken.

In een niet-cloud-native omgeving, vaak on-premise, behoudt de organisatie de volledige fysieke en logische controle over haar data.

Dataresidentie

Voor overheidsinstanties en organisaties die met zeer gevoelige gegevens werken, bijvoorbeeld dataclassificatie 4 binnen de Vlaamse Overheid, kan het noodzakelijk zijn dat data op specifieke fysieke locaties wordt opgeslagen. Zo wordt vermeden dat gevoelige gegevens zonder duidelijke waarborgen onder buitenlandse wetgeving (zoals de US Cloud Act) vallen.

De softwareoplossingen van Bridg kunnen gehost worden in een private cloud of een andere beveiligde omgeving, zoals het VO-MDC voor organisaties binnen de Vlaamse Overheid.

Gescheiden infrastructuur

In tegenstelling tot multi-tenant cloud-native oplossingen, is er bij een traditionele architectuur geen risico dat data en toepassingen van verschillende klanten op hetzelfde platform met elkaar in aanraking komen of gelekt worden.

Cloud-native architecturen worden vaak geprezen vanwege hun flexibele pay-per-usemodel. Die flexibiliteit kan echter ook leiden tot moeilijk voorspelbare kosten, bijvoorbeeld bij gebruikspieken of een sterke toename van dataverkeer.

CapEx versus OpEx

Voor organisaties met vaste budgetten (zoals in de publieke sector) kan een vooraf bepaalde investering in infrastructuur en licenties (CapEx) gemakkelijker te beheren zijn dan variabele maandelijkse verbruikskosten (OpEx).

Geen onverwachte egress fees

Er zijn geen kosten voor het verplaatsen van grote hoeveelheden data uit de cloud. Voor data-intensieve toepassingen kan dat een belangrijk financieel voordeel zijn.

Cloud-native applicaties maken vaak gebruik van specifieke technologieën of diensten van één cloudprovider, zoals AWS Lambda, Google BigQuery of bepaalde Azure-componenten. Dat kan het moeilijker en duurder maken om later naar een andere omgeving over te stappen.

Portabiliteit

Een traditionele architectuur, bijvoorbeeld gebaseerd op standaard Java/JEE en SQL-databases zoals DB2 of PostgreSQL, kan gemakkelijker worden verplaatst tussen verschillende hostingpartners of eigen datacenters.

Onafhankelijkheid

Organisaties zijn zo minder afhankelijk van de roadmap, prijswijzigingen (lees: verhogingen) of het stopzetten van specifieke diensten door één cloudprovider. Ze behouden meer vrijheid om hun infrastructuurstrategie later bij te sturen.

In een cloud-native multi-tenantomgeving kan intensief gebruik door één klant in bepaalde situaties invloed hebben op de beschikbare capaciteit voor andere klanten. Dit wordt ook wel het noisy-neighbor-effect genoemd.

Gereserveerde capaciteit

Binnen een niet-cloud-native opzet, zoals multi-instance, beschikt iedere klant over eigen gereserveerde rekenkracht en geheugen. Daardoor kunnen de prestaties beter worden afgestemd op de verwachte belasting en blijven snelheid en beschikbaarheid voorspelbaar.

Gestandaardiseerde cloud-native SaaS-oplossingen zijn vaak ingericht volgens één gemeenschappelijk model. Dat maakt snelle implementatie mogelijk, maar biedt niet altijd voldoende ruimte voor organisaties met complexe of sterk gespecialiseerde processen.

Diepgaande configuratie en maatwerk

Case management systemen en oplossingen met complexe bedrijfsprocessen vragen waar nodig diepgaandere aanpassingen op applicatie-, database- of serverniveau. Dat is in een gestandaardiseerde cloud-omgeving niet mogelijk.

Integratie met bestaande systemen

Veel organisaties werken nog met mainframes, lokale databases en andere toepassingen die on-premise draaien. Een oplossing die binnen dezelfde traditionele infrastructuur kan worden ingezet, kan eenvoudiger met deze systemen integreren en de vertraging in het dataverkeer beperken.

Voor de huidige geopolitieke onzekerheid was ‘ontzorging’ vaak het uitgangspunt. Bij cloud-native oplossingen ligt de gespecialiseerde kennis van onder meer Kubernetes, Terraform en specifieke cloud-securityprotocollen doorgaans volledig bij de leverancier. Organisaties hoeven die expertise niet zelf op te bouwen, maar geven daarmee ook een deel van de technische regie uit handen.

Controle over de technische omgeving

Voor IT-teams met expertise in traditionele serverstacks kan een vertrouwde architectuur vandaag net een voordeel zijn. Ze behouden zelf de kennis, controle en verantwoordelijkheid over de technische omgeving en zijn minder afhankelijk van externe leveranciers.

Zo wordt het behoud van een bekende architectuur geen beperking, maar een bewuste keuze om de regie in eigen handen te houden.