Deploy en beheer jij je resources nog steeds handmatig via het Azure portaal? Het beestje heeft een naam: “ClickOps”.
In dit artikel leggen we uit wat ClickOps is, waarom het niet de beste manier is om je Azure resources te beheren en wat je in plaats daarvan beter kunt doen.
Leestijd 5 minuten Gepubliceerd: 22 augustus 2025
Zoals omschreven door het Microsoft Cloud Adoption Framework, is ClickOps het proces van provisioneren, configureren en beheren van resources door te klikken in portals, beheerconsoles en wizards.
Elke keer dat je de Azure Portal gebruikt om resources in te zetten, gebruik je “ClickOps”.
We zeggen wel eens gekscherend: “Vrienden laten vrienden niet klikken in de Azure Portal”, maar waarom is dat?
Hebben we een afkeer tegen grafische User Interfaces of is het omdat het cooler is om command-line interfaces te gebruiken? Niet zozeer...
Om deze vraag te beantwoorden, moeten we ons eerst afvragen waarom we de Azure Portal gebruiken.
De reden is eenvoudig: Het is je eerste ervaring met Azure. Je klikt rond, maakt kennis met de functies en raakt meer vertrouwd met het platform. Naarmate je meer ervaring opdoet, zul je het zelfs gebruiken om snel problemen op te lossen.
Niet alleen dat, maar de meeste gebruikers waarderen een visuele ervaring en directe feedback op hun acties. Dat is precies wat een goede User Interface zoals de Azure Portal biedt.
Als je de portal ooit hebt gebruikt, weet je waarschijnlijk dat het gemakkelijk te gebruiken is. Deze voordelen zijn echter ook de keerzijde voor je infrastructuur.
ClickOps lijkt misschien een gemakkelijke manier om resources in te zetten in Azure. Het zijn tenslotte maar een paar klikken in de portal, toch?
Het probleem ontstaat wanneer je vertrouwt op het klikken in de Azure Portal om je infrastructuur in te zetten en te beheren.
Laten we eens kijken waarom dit een probleem kan zijn met paar voorbeelden.
Stel je voor dat je 20 Virtual Machines (VM's) moet deployen via de Azure Portal. Elke VM moet identiek geconfigureerd worden om consistentie in je omgeving te garanderen. Wanneer je echter handmatig door de portal (ClickOps) klikt om elke VM te configureren, neemt het risico op menselijke fouten aanzienlijk toe.
Een kleine afwijking in de configuratie, misschien een over het hoofd geziene instelling of een verkeerde klik, kan leiden tot tegenstrijdigheden. Dit betekent dat, hoewel 20 VM's technisch gezien zijn geïmplementeerd, ze mogelijk niet identiek zijn qua configuratie. Deze inconsistentie kan leiden tot onvoorziene problemen, die het oplossen van problemen en het onderhoud bemoeilijken.
Een ander groot probleem met ClickOps is het ontbreken van één enkele bron van waarheid; “single source of truth”.
Wanneer infrastructuur handmatig wordt uitgerold via het portaal, is er geen gecentraliseerd record of script dat de exacte configuratie documenteert. Deze afwezigheid maakt het een uitdaging om omgevingen te repliceren of de huidige staat van de infrastructuur te begrijpen.
Als er meerdere beheerders bij betrokken zijn, wordt het probleem nog groter omdat ieder zijn eigen aanpak kan hebben, wat leidt tot nog meer inconsistenties.
Documentatie wordt ook problematisch in ClickOps. Het handmatig vastleggen van elke stap die wordt genomen om infrastructuur te implementeren en te configureren is niet alleen vervelend, maar kan ook tot onnauwkeurigheden leiden. Zonder nauwkeurige documentatie wordt het moeilijk om wijzigingen te controleren, configuraties te volgen of nieuwe teamleden effectief in te werken.
Infrastructure drift treedt op wanneer de werkelijke staat van je infrastructuur afwijkt van de beoogde staat. Dit komt meestal door handmatige wijzigingen in het portaal, zoals iemand die instellingen aanpast, een resource toevoegt of een configuratie bijwerkt zonder dit in code bij te houden. Dit leidt tot onvoorspelbaar gedrag, beveiligingsrisico's en verminderde prestaties.
“Vertrouwen op de Azure Portal om infrastructuur handmatig in te zetten en te beheren brengt risico's met zich mee.”
Zoals uit de voorbeelden hierboven blijkt, is ClickOps, hoewel snel en gemakkelijk, niet de beste oplossing.
Het gebruik van Infrastructure as Code (laC) biedt daarentegen een betrouwbaardere en efficiëntere manier om je infrastructuur te beheren.
"Infrastructure as Code (laC) is een moderne benadering voor het beheren en aanbieden van computing infrastructuur door middel van machine-leesbare definitiebestanden in plaats van handmatige configuraties of interactieve tools."
Lees onze nieuwste whitepaper over IaC in Azure, beheers Azure Bicep, Azure Verified Modules (AVM) en meer!
Download de IaC whitepaper nu gratis!Dit geautomatiseerde proces stelt developers en systeembeheerders in staat om resources efficiënt te beheren en biedt vele voordelen, waaronder schaalbaarheid, consistentie en betrouwbaarheid:
In dit artikel hebben we laten zien dat Infrastructure as Code (IaC) versus ClickOps niet helemaal zwart-wit is. Je moet de voor- en nadelen van beide begrijpen, zodat je de beste beslissing voor jouw organisatie kunt nemen.
Over het algemeen is er nog steeds ruimte voor ClickOps, met name voor taken als probleemoplossing, onderzoek, leren en verkennen. Als je bijvoorbeeld snel een diagnose moet stellen en problemen moet oplossen in je IaC-implementaties, kan ClickOps een waardevolle aanpak zijn.
Voor productiescenario's die schaalbaarheid, consistentie en de mogelijkheid van broncontrole vereisen, is IaC echter onmisbaar.
Het lost de nadelen van ClicOps op door een herhaalbare, betrouwbare en geautomatiseerde aanpak van infrastructuurbeheer te bieden.
Er zijn veel populaire IaC-tools (zoals Azure Bicep) die je kunnen helpen om je bestaande omgeving om te zetten in code.
Infrastructure as Code (IaC) tools: ARM, Bicep & Terraform