De cloudomgeving draait. Applicaties zijn bereikbaar, gebruikers kunnen werken en back-ups lopen. Voor veel klanten voelt dat als succes. Toch groeit bij msp’s het ongemak. Kosten lopen op zonder duidelijke verklaring. Performance blijft wisselend. Beheer voelt omslachtig, terwijl de belofte van flexibiliteit nou juist eenvoud was.
Dat spanningsveld komt vaak voort uit een lift-and-shift-migratie die technisch correct is uitgevoerd, maar architectonisch nooit is afgemaakt. De workload staat in de cloud, maar gedraagt zich nog hetzelfde als on-prem. Lift-and-shift heeft een slechte reputatie gekregen, maar dat is niet altijd terecht. Voor veel organisaties is het een logische eerste stap. Je verplaatst workloads met minimale aanpassing, beperkt risico en houdt de business draaiende. Zeker bij tijdsdruk of compliance-eisen is dat een verstandige keuze.
Het probleem ontstaat wanneer lift-and-shift het eindpunt wordt, in plaats van tussenfase. Virtuele machines blijven vervolgens permanent actief, sizing wordt niet herzien en architectuurkeuzes blijven gebaseerd op oude aannames. De cloud is dan feitelijk niet meer dan een externe hypervisor met een maandelijkse factuur. Als msp betekent dit dat je na de migratie steeds vaker vragen krijgt waar je geen eenvoudig antwoord op hebt. Waarom stijgen de kosten? Waarom voelt de applicatie trager dan verwacht? Waarom kost beheer meer tijd dan vroeger?
Technische schuld verschuift
On-prem technische schuld verdwijnt niet vanzelf door een migratie. Ze verandert van vorm. In de cloud uit zich dat onder andere in:
- permanent draaiende resources die nooit worden uitgeschakeld,
- overgedimensioneerde VM’s ‘voor de zekerheid’,
- monolithische applicaties die slecht schalen,
- netwerkontwerpen die latency introduceren,
- back-up- en snapshotstrategieën die elkaar overlappen.
Zolang alles werkt, blijft die schuld onzichtbaar. Pas bij groei, piekbelasting of kostenanalyse komt ze naar boven. Dan blijkt dat de cloudomgeving weliswaar technisch stabiel is, maar structureel niet erg efficiënt.
Wanneer is optimalisatie zinvol
Niet elke omgeving vraagt om herontwerp. Cloudoptimalisatie loont vooral wanneer meerdere signalen samenkomen. Een van die signalen is resourcegedrag. VM’s met lage gemiddelde CPU-belasting, maar hoge pieken, duiden vaak op verkeerd gekozen instance types. Constante belasting met voorspelbare patronen wijst juist op mogelijkheden voor reserved instances of schaalstrategieën.
Een tweede signaal is netwerkafhankelijkheid. Applicaties die intensief chatten tussen componenten, maar verspreid zijn over regio’s of subnetten, betalen latencybelasting. In on-prem omgevingen viel dat nauwelijks op. In cloudarchitecturen wordt dat direct voelbaar.
Ook operationele complexiteit speelt mee. Als beheer steeds meer scripts, uitzonderingen en handmatige checks vereist, is dat vaak een indicatie dat de architectuur niet meer past bij het gebruik.
Optimaliseren is geen refactorfeest
Een veelgemaakte denkfout is dat cloudoptimalisatie automatisch betekent: alles herbouwen. Dat schrikt klanten af en zet je als msp onnodig klem. In de praktijk zit de winst vaak in gerichte ingrepen.
Voorbeelden die je waarschijnlijk herkent:
- het opsplitsen van één grote VM in meerdere kleinere rollen,
- het verplaatsen van stateless componenten naar managed services,
- het loskoppelen van opslag en compute,
- het aanpassen van autoscaling-grenzen op basis van echte load.
Dit soort stappen vraagt technische analyse, maar geen complete herontwikkeling. Ze leveren vaak direct meetbaar resultaat op in kosten, performance en beheerbaarheid.
Cloud-native als principe
Cloud-native denken wordt vaak verward met specifieke technologieën. Containers, orchestratie en service meshes krijgen dan alle aandacht. Voor veel mkb-omgevingen is dat overkill. Het draait in de kern om een andere manier van kijken naar infrastructuur en applicaties. Resources worden niet gezien als vaste bouwstenen die je jarenlang in stand houdt, maar als tijdelijke onderdelen die je kunt vervangen zonder dat de omgeving instort. Componenten mogen verdwijnen, zolang de functionaliteit overeind blijft.
Schaalgedrag volgt daarbij het werkelijke gebruik. Capaciteit groeit of krimpt op basis van wat applicaties op dat moment nodig hebben, niet op basis van aannames vooraf. Dat betekent dat je minder vooruit reserveert en meer vertrouwt op meetgegevens en automatische aanpassing.
In zo’n architectuur worden fouten als normaal beschouwd. Systemen gaan stuk, verbindingen vallen weg en processen lopen vast. Ontwerpkeuzes zijn erop gericht om die situaties op te vangen, niet om ze koste wat kost te voorkomen. Herstelbaarheid, isolatie en automatische herstart krijgen daarmee een belangrijkere rol dan foutloosheid.
Beheer verschuift van handmatig ingrijpen naar beleid. In plaats van individuele resources aan te passen, leg je vast hoe de omgeving zich moet gedragen. Regels bepalen wie toegang heeft, hoelang resources blijven bestaan en onder welke voorwaarden wordt opgeschaald of afgebouwd. Dat maakt beheer consistenter en beter schaalbaar, zeker in omgevingen die blijven groeien of veranderen. Je kunt die principes toepassen zonder een volledig platform uit te rollen. Managed databases, object storage en serverless functies zijn vaak effectiever dan zelfbeheer op VM-niveau.
Kosten zijn symptoom
Veel optimalisatietrajecten beginnen bij kostenrapportages. Dat lijkt voor de hand te liggen, maar dat is niet optimaal. Kosten zijn het gevolg van architectuur, niet de oorzaak. Als je uitsluitend stuurt op besparen, loop je het risico performance of stabiliteit aan te tasten. Betere optimalisatie begint bij inzicht in gedrag. Monitoring, logging en tracing laten zien hoe applicaties zich werkelijk gedragen. Pas daarna volgt kostenoptimalisatie. Voor de msp verschuift het gesprek dan van ‘het is duur’ naar ‘dit is hoe de applicatie zich gedraagt’. Dat maakt keuzes uitlegbaar en verdedigbaar.
Cloudoptimalisatie zonder governance houdt geen stand. Zodra meerdere teams of klanten resources kunnen aanmaken zonder kader, ontstaat weer die verfoeide wildgroei. Naming conventions, tagging, lifecycle-regels en toegangsbeleid vormen daarom een technische randvoorwaarde. Goede governance maakt optimalisatie bovendien schaalbaar. Het voorkomt dat elke verbetering handmatig bewaakt moet worden. Cloudbeheer lijkt daardoor steeds meer op productontwikkeling. Je definieert standaarden, meet afwijkingen en stuurt bij.
Niets doen is ook beleid
Soms is niets doen de beste keuze. Sommige workloads draaien stabiel, voorspelbaar en tegen acceptabele kosten. Optimalisatie levert daar weinig op en je loopt kans risico’s te introduceren. De kunst zit in herkennen wanneer ‘goed genoeg’ ook echt goed genoeg is. Cloudoptimalisatie plaatst de msp nadrukkelijk in de rol van technisch adviseur. Je taak wordt voor zulke klanten minder uitvoerend, meer analyserend. Minder reageren op incidenten, meer sturen op ontwerp en gedrag.
Lift-and-shift blijft dus een valide startpunt. Maar optimalisatie bepaalt of de cloudomgeving ook op de lange termijn goed blijft functioneren tegen acceptabele kosten.
