1. Wat is het verschil tussen managed en unmanaged VPS?
Bij een unmanaged VPS krijg je een server met een besturingssysteem erop en verder niets. Alles daarboven is van jou: updates, firewall, back-ups, monitoring, en het oplossen van storingen. De aanbieder houdt de hardware en het netwerk in de lucht. Bij een managed VPS neemt de aanbieder het beheer van het besturingssysteem en de serverdiensten over, binnen een scope die per aanbieder verschilt.
Wat dat concreet betekent, staat hieronder.
Twee kanttekeningen bij die tabel, en ze zijn belangrijker dan de tabel zelf.
De eerste: managed is geen beschermde term. Elke aanbieder legt de grens ergens anders. Bij de één valt een database die niet meer opstart binnen de dienstverlening, bij de ander krijg je dan een verwijzing naar een uurtarief. Wat telt is niet het woord op de productpagina maar de omschrijving in de voorwaarden.
De tweede: managed dekt zelden je eigen software af. Een verouderde plugin, een lek in je eigen code, een thema dat na een PHP-update stukgaat: dat blijft van jou. Wie denkt dat managed alle verantwoordelijkheid overneemt, ontdekt op een ongelegen moment van niet.
2. Wanneer kies je unmanaged?
Unmanaged is de logische keuze als het beheer al ergens is belegd, of als er geen productieomgeving aan hangt.
Je hebt beheercapaciteit in huis
Niet iemand die het er wel bij doet, maar iemand voor wie serverbeheer onderdeel van de functie is. Met een vervanger tijdens vakantie en ziekte. Draai je al configuratiebeheer, een centrale monitoringomgeving en een vaste patchcyclus, dan voegt een beheerlaag van een derde weinig toe en zit hij je soms in de weg.
Test-, staging- en CI-omgevingen
Machines die je opbouwt en weer weggooit. Als een servertje een dag stilligt en niemand merkt het, is beheer erop organiseren duurder dan het probleem.
Hobbyprojecten en leeromgevingen
Gebruik je een VPS om Linux onder de knie te krijgen, dan is zelf beheren niet de prijs die je betaalt maar precies het punt.
Teams die de controle bewust willen houden
Bijvoorbeeld omdat je een afwijkende kernel of stack draait, omdat je deployment-pipeline geen wijzigingen van buitenaf verdraagt, of omdat je niet wilt dat een externe partij rootrechten heeft.
In al deze gevallen geldt één voorwaarde: de routine moet ook echt draaien. Staan security-updates binnen enkele dagen na publicatie, is er ooit een restore getest, reageert er iemand op alerts? Zo ja, prima. Zo nee, dan koop je geen controle maar uitgesteld onderhoud, en dat wordt later alsnog in rekening gebracht.
3. Wanneer kies je managed?
Er is geen beheercapaciteit
De kennis zit bij één persoon, of bij niemand. Linux-beheer valt te leren, maar dan is de vraag of je die uren wilt steken in wat er op je server draait of in de server zelf.
Je draait productieomgevingen voor klanten
Als bureau of softwareleverancier ben je aanspreekbaar op omgevingen die je niet de hele dag zelf bewaakt. Dan helpt het als updates en monitoring belegd zijn bij een partij die dat structureel doet, en als er een aanspreekpunt is wanneer er iets misgaat.
Uitval kost direct geld
Een webshop die 's nachts orders binnenkrijgt. Een platform waar klanten op inloggen. Een applicatie waar andere processen van afhangen. De vraag is niet of jij een storing kunt oplossen, maar of dat gebeurt op momenten dat je niet achter je scherm zit.
Onderhoud blijft in de praktijk liggen
Updates die al maanden wachten. Back-ups die nooit zijn teruggezet. Monitoring die is uitgezet omdat hij te vaak afging. Dat zijn signalen, en ze zijn eerlijker dan een inschatting vooraf.
Ook hier de grens: managed haalt het serverbeheer weg, niet het onderhoud aan je eigen applicatie. Die verantwoordelijkheid blijft, en die moet je apart beleggen.
4. Wat vraagt zelf beheren aan tijd?
Overweeg je unmanaged, dan is dit het werk dat erbij komt. Het is goed te doen, maar het komt terug en het kiest zijn eigen momenten.
Patchen. Advisories volgen voor je distributie en voor de pakketten die je draait, beoordelen wat urgent is, updates uitvoeren. Bij kernel- en libraryupdates hoort een herstart, en die moet je inplannen. Daarna controleren of alles nog draait. Automatische updates nemen een deel van dit werk over, maar niet het beoordelen en niet de herstart.
Distributie-upgrades. Een Ubuntu LTS krijgt vijf jaar standaard onderhoud. Voor die datum moet je over, en zo'n upgrade raakt meestal ook je PHP-versie, je database en dus je applicatie. Dit is geen klusje maar een project, en het staat met vaste regelmaat op de agenda.
Monitoren. Bewaking op schijfruimte, geheugen, load, certificaten en de services die moeten draaien. Alerts naar een kanaal waar iemand ze werkelijk ziet. En daarna drempels bijstellen, want een monitor die te vaak afgaat wordt weggeklikt en is dan erger dan geen monitor.
Back-ups verifiëren. Een schema instellen is het kleinste deel. Het werk zit in periodiek een restore doen naar een testomgeving en kijken of de data compleet en bruikbaar is. Plus bewaken dat de bewaartermijn nog past bij wat je zou moeten kunnen herstellen, en dat de kopie ergens anders staat dan het origineel.
Beveiliging. Firewallregels, SSH-toegang, sleutels intrekken als iemand het team verlaat, services uitzetten die je niet gebruikt.
De kleine dingen die groot worden. Logrotatie die stilvalt en de schijf volloopt. Een certificaat dat niet automatisch vernieuwt en na negentig dagen verloopt. Een cronjob die al weken faalt zonder dat iemand het merkt.
Incidenten oplossen. Logs uitlezen, oorzaak vinden, herstellen. Dit is het deel dat zich niet laat plannen: het valt in het weekend, tijdens een vakantie, of op je drukste dag.
Documenteren. Vastleggen hoe de omgeving in elkaar zit, zodat een collega het kan overnemen als degene die het gebouwd heeft er niet is.
Hoeveel tijd dit bij elkaar kost, hangt zo sterk af van je stack, je aantal servers en je risicobereidheid dat elk getal hier misleidend zou zijn. De belasting is bovendien ongelijk verdeeld. Weken waarin je niets doet, en dan opeens een kritieke kwetsbaarheid of een distributie die afloopt. Wil je het voor jezelf inschatten: houd een kwartaal bij hoe vaak je hebt moeten ingrijpen, hoe lang het duurde en op welk moment van de dag het viel. Dat zegt meer over jouw situatie dan welk gemiddelde ook.
5. Waar let je op bij het vergelijken van aanbieders?
Instapprijzen zijn onderling niet vergelijkbaar. Sommige aanbieders rekenen 24/7 support en een SLA standaard mee in het maandbedrag, andere bieden dat als losse optie naast een lager basistarief. Twee bedragen naast elkaar leggen zegt daardoor weinig. Vergelijk op de configuratie die je nodig hebt: dezelfde resources, hetzelfde supportniveau, dezelfde back-upretentie, dezelfde licenties. Wat er bij Netbela standaard inbegrepen is en wat een aparte keuze is, staat op /tarieven.
Kijk ook naar wat eronder draait. Managed en unmanaged zijn vaak niet dezelfde machine met een ander servicecontract. Ze verschillen ook in resources: gedeeld of dedicated, het type opslag, wel of geen overprovisioning. Leg dus niet alleen de voorwaarden naast elkaar maar ook de specificaties.
Vraag de scope op papier. Welke taken vallen eronder en welke niet? Wat gebeurt er als het probleem in je applicatie zit in plaats van in het OS: wordt dat afgewezen, of tegen een uurtarief opgepakt?
Back-ups. Hoe vaak, waar opgeslagen, hoe lang bewaard, en wie zet terug: jij via een portaal of de aanbieder op verzoek? Vraag ook of restores periodiek getest worden en hoe je dat terugziet.
Monitoring. Wat wordt er precies bewaakt? Alleen of de server reageert, of ook services, schijfruimte en certificaten? Wie krijgt de melding, en binnen welk venster wordt er iets mee gedaan?
Support. Via welk kanaal, binnen welke tijden, en wat is de route buiten die tijden? Spreek je iemand die op de server kan, of een eerste lijn die doorzet?
Rootaccess bij managed. Mag je zelf software installeren en configuratie aanpassen? En blijft het beheer daarna gelden voor wat je hebt gewijzigd? Aanbieders gaan hier verschillend mee om, en het is precies het soort verschil dat je pas merkt als je het nodig hebt.
Patchbeleid. Automatisch of handmatig, worden herstarts aangekondigd, kun je een onderhoudsvenster opgeven?
Licenties. Zitten een controlepaneel, het besturingssysteem en eventuele commerciële software erbij, of komen die er los bij? Dit verklaart een groot deel van het verschil tussen twee aanbiedingen die op papier op elkaar lijken.
Migratie en vertrek. Wordt er geholpen bij de overstap, en kun je er later weer weg? Vraag of je een image of een volledige dump kunt meenemen, en wat de opzegtermijn is.
Veelgestelde vragen
Is een managed VPS veiliger dan een unmanaged VPS? Niet automatisch. Een managed VPS wordt doorgaans structureel gepatcht en gemonitord, en dat scheelt, maar de beveiliging van je eigen applicatie blijft in beide gevallen jouw werk. Een goed onderhouden unmanaged server is veiliger dan een managed server met een verouderd CMS erop.
Krijg je bij een managed VPS ook rootaccess? Dat verschilt per aanbieder. Sommige geven volledige rootrechten, andere beperken de toegang om de omgeving beheersbaar te houden. Vraag ook wat er met de dienstverlening gebeurt als je zelf iets wijzigt.
Kun je later overstappen van unmanaged naar managed? Meestal wel, maar het is zelden een knop die je omzet. Vaak gaat het om een migratie naar een andere omgeving, omdat de aanbieder een eigen inrichting hanteert. Vraag vooraf hoe dat traject eruitziet en of er downtime bij komt kijken.
Wat is het verschil met semi-managed of self-managed? Dat zijn tussenvormen zonder vaste definitie. Self-managed betekent bij de meeste aanbieders hetzelfde als unmanaged. Semi- of core-managed ligt ertussenin, bijvoorbeeld wel OS-updates maar geen monitoring. Ga niet af op de naam, lees wat er onder valt.
Heb je bij unmanaged nog support? Ja, maar op een andere laag. Support gaat dan over de hardware, het netwerk en de beschikbaarheid van de virtuele machine. Een dienst die niet meer start of een configuratie die stuk is, valt buiten die scope.
Beide keuzes zijn verdedigbaar. De vraag is niet welke variant beter is, maar of het werk uit sectie 4 in jouw situatie structureel gebeurt, en door wie. Bekijk daarna wat past: zelf beheren of uitbesteden.
