Migreren naar de cloud begint zelden met een grootse hertekening van het applicatielandschap. De meeste organisaties starten voorzichtig, vaak met een lift-and-shift, omdat tijd dringt, licenties aflopen en datacentercontracten opzegbaar worden. Een jaar later volgt de ontnuchtering: kosten lopen sterker op dan begroot, teams missen zicht op prestaties, en de belofte van wendbaarheid blijft uit. Het echte werk begint dan pas, wanneer de vraag verschuift van verhuizen naar vernieuwen.
Ik heb die boog in uiteenlopende sectoren gezien, van verzekeraars die mainframe-achtige patronen probeerden te reproduceren in Kubernetes tot scale-ups die te snel met microservices begonnen. In bijna alle gevallen is het pad naar cloud-native geen sprong maar een serie bewuste stappen. De kunst is om per stap bedrijfswaarde te leveren, technische schuld te beperken en talent op te bouwen. Dat vereist een mix van Software Development, DevOps & Cloud Services, productmanagement, en soms gerichte IT Recruitment of Nearshore AI Development om schaarse expertise aan te vullen.
Waarom lift-and-shift vaak noodzakelijk is, maar nooit voldoende
Lift-and-shift is het snelste antwoord op een harde deadline. Je virtualiseert workloads, migreert ze naar IaaS, en minimaliseert codewijzigingen. De winst is tastbaar: datacenterkosten da dalen, provisioning versnelt, en je schakelt fysieke hardware uit. Alleen, de rekenmodellen die op on-prem hardware goedkopere piekcapaciteit veronderstellen, voelen in de cloud onverbiddelijk, omdat je continu afrekent op werkelijk gebruik. Een applicatie die 24x7 op tachtig procent CPU draait, blijft duur, ongeacht hoe modern de hypervisor is.
In een verzekeringsorganisatie die ik begeleidde, bleef 60 procent van de rekeningen afkomstig van een handvol monolieten die nooit naar auto-scaling zijn omgebouwd. Ze draaiden op te grote VM-profielen, met vaste reservecapaciteit, uit angst voor performanceverlies tijdens batchverwerking. De factuur verdubbelde tegenover het datacenterbudget. Pas toen we jobs splitsen, observability toevoegden en de batchvensters herontwierpen, kantelde het beeld. Niet door magische optimalisatie, wel door aanpassing van het werkproces aan cloudmechanismen.
Lift-and-shift legt kortom bloot waar de knelpunten zitten, het lost ze niet op. Het is een noodzakelijke tussenstap, geen bestemming.
Een pragmatisch volwassenheidsmodel voor de stap naar cloud-native
Er bestaan veel raamwerken, van 6R tot CNCF-landschappen. In de praktijk werk ik met een eenvoudig, empirisch model met vijf niveaus. Niet als scorekaart, maar als routekaart die helpt prioriteiten te stellen.
Niveau 1: Lift-and-shift, met zicht op het landschap
Doel is verhuizen zonder breken. Je brengt workloads over naar IaaS, zet basisbeveiliging op, en regelt identity-federatie. Teams leren de cloud kennen, maar bouwen nog niet significant om.
Resultaat in de praktijk: kortere provisioningtijd, maar beperkte daling in kosten. Lead time for change blijft vaak gelijk, omdat deployment- en testprocessen niet veranderd zijn. Zonder aanvullingen als IaC en central logging bots je aan tegen zichtbaarheid en herhaalbaarheid.
Wat wel werkt op dit niveau is vroeg starten met observability. Zelfs een eenvoudige combinatie van metrics en distributed tracing geeft inzicht in hotspots Php Dev en idle capaciteit. Het is de brandstof voor latere keuzes.
Niveau 2: Replatforming, gericht op snelle winsten
Hier vervang je infrastructuurcomponenten door beheerde diensten. Denk aan managed databases, objectopslag, eventbussen, secrets-management en containerplatforms. Je past code minimaal aan, maar verwijdert DIY-infra die onderhoud en storingen veroorzaakt.
In een e-commercecase zagen we 20 tot 35 procent lagere totale kosten voor databasebeheer door over te stappen op een managed variant. Niet omdat de ruwe compute goedkoper was, wel omdat patching, failover, back-ups en tuning stabieler en voorspelbaarder werden. Tegelijkertijd kenden we een valkuil: een zware query die op een eigen database incidenteel piekte, werd in de cloud structureel duur door pay-per-IO. Pas toen we query’s herstructureerden en caching toevoegden, kwamen de kosten en performance in balans.
Op dit niveau introduceren teams meestal Infrastructure as Code en geautomatiseerde deploymentpaden. CI/CD gaat van optioneel naar noodzakelijk, want zonder herhaalbaarheid verzanden replatformingtrajecten in tickets en handwerk.
Niveau 3: Refactoren voor schaal en betrouwbaarheid
De echte verschuiving begint wanneer je applicaties aanpast aan cloudmechanieken. Patterns als circuit breakers, idempotente verwerking, bulkheads en retries worden standaard. Monolieten worden niet per se opgesplitst in tientallen microservices, maar ontvlechten kritieke paden en scheiden lees- en schrijflasten. State wordt waar mogelijk naar managed diensten verplaatst.
Het belangrijkste inzicht hier: je hoeft niet alles te herschrijven. In een logistieke planningsapplicatie hebben we slechts het planningsalgoritme uit de monoliet gelicht en asynchroon gemaakt. Eén verandering, maar de wachttijd per batch daalde van 22 naar 5 minuten en de compute kon s nachts opschalen naar spot-capaciteit, met 40 tot 60 procent lagere rekencosts tijdens pieken. De rest van de monoliet bleef intact tot later.
Refactoren brengt discipline in Software Development. Feature-werk en modernisering concurreren om dezelfde capaciteit. Zonder productmatige sturing strandt dit niveau vaak. De meest succesvolle teams hanteren roadmaps met expliciete capaciteitsverdeling, bijvoorbeeld 60 procent op features, 30 procent op tech-debt en 10 procent op experimenten. Het exacte getal is minder belangrijk dan het feit dat het afgesproken en transparant is.
Niveau 4: Cloud-native bouwen en exploiteren
Op dit punt gedraagt de organisatie zich als een cloudproductbedrijf. Teams ontwerpen met failure in het achterhoofd, omarmen managed services als bouwstenen, en werken met duidelijke SLO’s en error budgets. Deploymentfrequentie stijgt van per sprint naar dagelijks of vaker, change failure rate daalt doorgaans onder 15 procent en mean time to recover gaat naar minuten of uren in plaats van dagen.
Technisch zie je containers of serverless als default, event-driven architecturen, immutable builds en security by design. Organisatorisch zie je een platformteam dat opinionated golden paths aanbiedt en guardrails afdwingt voor netwerk, identiteit en data. FinOps is geen losse exercitie meer, maar ingebouwd in de developer workflow, met kostenfeedback in pull requests en dashboards op servicelaag.
Niet elk domein vraagt om microservices. Transacties die hoge consistentie en lage latency vereisen, profiteren soms meer van modulair monolith design met duidelijke grenzen en een gedeelde database. Andersom gedijen integraties, ETL en batchverwerking vaak op serverless en queue-gebaseerde patronen. Cloud-native is een set keuzes, geen dogma.
Niveau 5: Continu optimaliseren, met platform als product
Op het hoogste niveau is het platform zelf een product met een backlog, SLA’s en klanttevredenheidsmetingen bij de gebruikers, namelijk de ontwikkelteams. Het platformteam levert self-service provisioning, compliant by default, en duidelijke standaardcomponenten. Team topologieën volgen Stream-aligned en Platform volgens Team Topologies, met gericht support via enablement.
Hier zie je ook volwassen omgang met data en AI. Feature stores, data contracts, privacy-by-design en lifecycle management zijn geïntegreerd. Experimentele workloads zoals machine learning draaien naast transactionele systemen, maar via gescheiden paden met heldere kosten- en risicokaders. Organisaties met schaarse specialisten vullen hiaten soms op met Nearshore AI Development partners die in dezelfde tijdzone werken en op het platform kunnen aanhaken zonder eigen schaduwstack op te tuigen.
Een snelle zelftest: waar sta je nu
- Je deployments verlopen nog grotendeels handmatig, of via scripts die niet door CI worden aangestuurd. Kosten worden per account of abonnement bekeken, niet per product of service. Je gebruikt managed diensten, maar zonder duidelijke standaard en herbruikbare modules. Observability is reactief, vooral logging, met beperkte tracing en weinig SLO’s. Security en compliance zijn reviews aan het eind, niet ingebouwd in pipelines en templates.
Als je meerdere van deze punten herkent, zit je meestal tussen niveau 1 en 2, soms op de drempel van 3. Dat is geen verwijt, het is een startpunt voor gerichte verbetering.
Technologie is het halve werk: teamontwerp en talent
Het verschil tussen een succesvolle en een moeizame cloudreis zit zelden in de toolkeuze. Terraform of Pulumi, Kubernetes of een PaaS, dat zijn secundaire beslissingen. Het gaat om teamtopologie, vaardigheden en autonomie met de juiste guardrails.
Productteams die end-to-end eigenaar zijn van hun service presteren beter. Ze hebben zicht op kosten, prestaties en security, en voelen verantwoordelijkheid voor de hele levenscyclus. Een platformteam helpt ze vooruit door de lastige gedeelde problemen op te lossen, zoals netwerksegmentatie, secrets-rotatie, image hardening en basisobservability. Dat platformteam moet een productmindset hebben. Als hun golden path sneller en veiliger is, kiezen teams het vanzelf.
Aan de talentkant is de markt krap. IT Recruitment van cloud-ingenieurs, SRE’s en securityspecialisten kost tijd en aandacht. Bedrijven die wachten tot het perfecte profiel langskomt, vertragen hun transformatie. Ik zie betere resultaten bij organisaties die gericht opleiden, pairing inzetten en tijdelijke gaten vullen met nearshore of gespecialiseerde partners. Nearshore AI Development is zo’n voorbeeld: je plaatst een klein, ervaren team naast je productteams, in dezelfde werkritmes en met dezelfde toolchain. Je koopt geen Python developer inhuren remote model- of notebookmagie, je koopt deliverycapaciteit die in je platform past.
FinOps zonder spreadsheets: kosten als ontwikkelparameter
Kostenbeheersing die losstaat van softwareontwikkeling eindigt in frictie. Je hebt ontwikkelteams nodig die kostenbegrip ontwikkelen en kosten kunnen sturen. Dat lukt niet met maandelijkse PDF’s. Het lukt wanneer kosten zichtbaar zijn per service, in de metrics waar een team dagelijks naar kijkt. Tagging en cost allocation per product zijn randvoorwaarden. Geef een team liefst een budget met contouren, niet met micromanagement.
In een retailomgeving plaatsten we kosten per 1.000 requests direct in de service dashboards. Het effect was bijna direct. Engineers zagen dat een onschuldig lijkende feature de kosten per bestelling met 8 cent verhoogde. Een kleine wijziging in de cache TTL bracht dit terug naar 2 cent, zonder kwaliteitsverlies. Dit is FinOps in de praktijk: feedbacklussen die technische en financiële uitkomsten verbinden.
Spot-instanties en auto-scaling zijn krachtig, maar alleen als workloads fault-tolerant zijn. Zonder retries en idempotentie worden goedkope resources duur, omdat je extra storingen oplost met mensenuren. Dat is de reden waarom refactoren eerder komt dan agressieve kostenoptimalisatie.
Security en compliance als versneller, niet als rem
Cloud-native beveiliging begint bij identiteitsgrenzen en het principe van least privilege. In de praktijk verdwijnt het meeste risico niet in exotische zero-days, maar in brede permissies, verouderde images en secrets in code. Het werkzame recept bestaat uit statische en dynamische scans in de pipeline, image signing, secrets management en periodieke rotatie, en policy-as-code die infrastructuurconfiguraties blokkeert voordat ze landen.
Compliance wordt behapbaar als je controle-bewijs automatisch verzamelt. Denk aan drift-detectie met pull requests als audittrail, standaardnetwerkpaden die verkeer afdwingen via inspectiepunten, en data-classificatie die bepaalt waar PII mag landen. Een verzekeraar met streng toezicht wist de auditdoorlooptijd van negen naar twee weken te brengen door 80 procent van de controles te automatiseren en evidence uit de CI/CD-logs te trekken. Het was geen extra laag tooling, het was de integratie van controls in bestaande ontwikkelpatronen.
Observability: meten om sneller te worden
Zonder meetgegevens wordt moderniseren gokken. Teams hebben minstens drie soorten signalen nodig: metrics voor trends, logs voor context, en traces voor oorzakelijkheid. SLO’s zetten die signalen om in doelbewust sturen. Als jouw checkout-service 99,9 procent beschikbaar moet zijn, definieer je samen wat een fout is, hoe je meet en hoeveel speling je hebt om te deployen. Error budgets zijn geen stok, maar een stuurmiddel: als het budget opraakt, investeer je in stabiliteit; als er ruimte is, versnel je leveringen.
Twee valkuilen komen vaak voor. Ten eerste te veel metrics, waardoor alert-moeheid ontstaat. Kies liever een handvol service-level indicators die de klantervaring representeren. Ten tweede observability die losstaat van de ontwikkelcyclus. Als dashboards alleen door operations worden bekeken, mis je het leereffect bij developers. Integreer dashboards in PR’s en retrospectives, en koppel incident reviews aan codeveranderingen, niet aan schuldigen.
Data en AI in een cloud-native wereld
Data is zelden netjes. Historische schemadeviaties, batchstromen, en ad-hoc exports zijn normaal. Cloud-native data-oplossingen bieden schaal, maar afdwingen van kwaliteit blijft mensenwerk. Data contracts tussen producer en consumer, plus schema-evolutie die via CI/CD loopt, beperken verrassingen. Feature stores en modelregistraties helpen om AI-artefacten als eersteklas assets te behandelen, inclusief versiebeheer en herhaalbaarheid.
Bij een mobiliteitsbedrijf bouwden we een verdunde eventstream naast transactionele systemen. Machine learning voor voorspellingen draaide op de eventstream, niet op het OLTP-systeem. Training vond plaats op serverless jobs buiten piekuren, met kostenplafonds per experiment. De model-API draaide in dezelfde mesh als de productservices, met duidelijke SLO’s. Nearshore AI Development speelde hier een rol om snel MLOps-patronen op te zetten, waarna interne teams het beheer overnamen.
Vendor lock-in en de mythe van volledige portabiliteit
Elke cloud heeft unieke diensten. Volledige portabiliteit klinkt aantrekkelijk, maar leidt vaak tot de laagste gemene deler. Een universale abstractielaag kan zinvol zijn voor deploy en observability, maar abstraheren van kern-diensten zoals storage, IAM of eventing kost veel flexibiliteit en performance.
Een werkbare strategie is kiezen voor portable interfaces waar het moet, en vendor-specifieke optimalisatie waar het loont. Container images, OpenTelemetry, OpenID Connect en SQL-standaarden geven je bewegingsvrijheid. Voor zaken als serverless runtimes of geavanceerde AI-accelerators Objective-C accepteer je soms lock-in in ruil voor snelheid en kostenvoordeel, zolang je exit-scenario’s kent en code niet onnodig verstrengelt.
KPI’s die iets zeggen
Bestuurders vragen om cijfers. De kunst is om cijfers te kiezen die gedrag stimuleren dat je wilt zien.
- Doorlooptijd van idee naar productie per product, niet per team, zodat afhankelijkheden zichtbaar worden. Veranderfrequentie per service, idealiter ten minste meerdere keren per week bij actieve domeinen. Change failure rate met oorzakelijke analyse, om te investeren in testdekking of rollback-strategieën. Mean time to recover inclusief detectie, zodat observability mee-ontwikkelt. Kosten per transactie of per 1.000 requests, gecorrigeerd voor seizoensinvloeden.
Je hoeft niet perfect te meten. Start met een grove meting en verfijn. Het belangrijkste is een vaste cadans waarin teams met deze cijfers werken en verbeteringen zichtbaar maken.
De eerste 90 dagen, zonder het wiel opnieuw uit te vinden
- Stel een klein, gemandateerd kernteam samen met mensen uit development, operations, security en finance. Geef ze de opdracht om een golden path te definiëren voor één type workload. Breng servicegrenzen in kaart voor de top 5 applicaties op kosten en risico, en plaats kosten- en performance-telemetrie direct naast functionele dashboards. Zet een minimale, maar strikte CI/CD-pijplijn neer met IaC, image scanning en basis-SLO’s, en migreer minstens één dienst via dit pad om geloofwaardigheid te bouwen. Kies twee tot drie managed diensten die de grootste operationele last wegnemen, bijvoorbeeld database, secrets en eventing, en standaardiseer modules en templates. Regel talent: definieer kritieke skills, start met interne training en pairing, en vul gaten gericht met IT Recruitment of een nearshore-partner die op het gekozen platform kan landen.
Deze stappen zijn saai en concreet, en dat is precies de bedoeling. Ze voorkomen dat je strategie blijft hangen in adviespresentaties zonder tastbare verandering.
Valstrikken die je beter vermijdt
Te vroeg microservices. Een monoliet die slecht is ontworpen in microservices knippen levert geen schaal of veerkracht op, alleen meer netwerkverkeer en complexiteit. Begin met modulair ontwerp, niet met het aantal services.
Tooling boven processen. Een nieuwe pipeline lost geen gebrekkige testcultuur op. Eerst definieer je wat kwaliteit betekent, dan automatiseer je het.
Bezuinigen op platform. Zonder sterk platform vervallen teams in lokale optimalisaties en security-excepties. Een platformteam dat niet bemenst is, levert geen golden path maar een bottleneck.
Kostenbesparing zonder architectuur. Rightsizing, reserved instances en spot helpen pas echt als de applicatie af kan schalen en falen verdraagt. Anders verschuif je kosten van compute naar mensen.
Big bang refactors. Parallelle oude en nieuwe systemen die te lang naast elkaar bestaan slopen focus en budget. Werk in dunne plakken, lever per iteratie echte waarde, en sluit iets ouds af voor je nieuw terrein verovert.
Een kort werkvoorbeeld: van migratie naar versnellen
Een B2B SaaS-bedrijf met 120 engineers migreerde in 9 maanden zijn monoliet en 18 ondersteunende services naar de cloud. De rekening steeg 25 procent, ondanks een daling van hardwarekosten. Vertragingen zaten in incidenten, uitval tijdens pieken en handwerk bij deployment.
We hebben in twaalf weken drie ontwerpbeslissingen gemaakt: checkout en facturatie losgetrokken met een eventbus, de database gemigreerd naar een managed variant met read replicas, en een platformpad neergezet met IaC, policy-as-code en service templates met standaard logging en tracing. Daarna volgden twee featureteams het golden path, zonder uitzonderingen.
Het effect na zes maanden: deploymentfrequentie van wekelijks naar meerdere keren per dag, change failure rate van ongeveer 28 naar 12 procent, MTTR van uren naar gemiddeld 25 minuten, en compute-kosten min 18 procent door slimmer schalen. Belangrijker nog, de backlog van compliance-issues daalde met 70 procent doordat evidence automatisch verzameld werd. Geen wondermiddel, wel consistent vakwerk op de juiste plekken.
Wat er nodig is om vol te houden
Cloud-native is geen project, maar een manier van werken. De energie ebt weg als eigenaarschap vervaagt en successen onzichtbaar blijven. Hou daarom het volgende vast in de routine:
- Een platform-roadmap met kwartaaldoelen die aansluiten op productdoelen, inclusief meetbare verbeteringen in ontwikkelaarservaring. Periodieke service reviews met SLO’s, kosten en security als vaste rubrieken, geleid door het productteam, niet door een commissie. Doorlopende scholing en mobiliteit. Laat engineers roteren tussen product- en platformteams zodat kennis stroomt en silo’s afbrokkelen. Bewuste keuze voor waar je wilt excelleren en waar je pragmatisch standaard volgt. Niet alles hoeft bijzonder te zijn. Heldere grenzen voor experimenten, zeker bij AI. Beperk data-exfiltratie, definieer kostenplafonds, en dwing reproducibility af in de toolchain.
Met deze discipline groeit cloud volwassenheid niet als een sprong, maar als een compounding effect. Kleine verbeteringen, consequent uitgevoerd, bouwen op elkaar. Het resultaat is niet alleen snellere software, maar een organisatie die verandervermogen in haar weefsel heeft. Dat is de kern van Digital Transformation: niet verhuizen, maar leren om sneller en zekerder te bewegen, met technologie, mensen en processen die elkaar versterken.