Cobytes

Stel je voor: je stuurt maandagochtend een nieuwsbrief naar 40.000 mensen. Binnen tien minuten klikt een derde daarvan door naar de webshop. Topresultaat, precies waar je op gehoopt had! Maar je hostingomgeving is minder enthousiast. De plotselinge verkeerspiek is groter dan de server aankan. Pagina’s laden traag, het bestelproces hapert en bezoekers haken af. De campagne die omzet moest opleveren, kost je nu klanten. Dit zien we helaas vaker dan je zou denken. En meestal komt dit omdat bedrijven een hostingpakket hebben dat niet is berekend op dergelijke pieken. Het is prima ingericht voor een gemiddelde dag, met een gemiddeld aantal bezoekers. Er is alleen niet nagedacht over de gevolgen van succesvolle piekmomenten. Bij managed hosting kijken we daarom niet alleen naar "staat de site online", maar ook naar of de omgeving flexibel meebeweegt als het drukker wordt. Zo zorgen we bijvoorbeeld dat de capaciteit ingesteld is op automatisch op- en afschalen als dat nodig is. Zodat een goede nieuwsbrief gewoon een goede nieuwsbrief blijft, en geen vervelend incident wordt dat schade oplevert in plaats van omzet.

De komkommertijd staat weer voor de deur. Maar dat geldt niet voor jouw website of applicatie. Want vakantie of niet, jouw online omgeving moet gewoon probleemloos blijven werken. Ook als jij en je collega's genieten van een welverdiende vakantie. Stel je voor: je ligt met je voeten in het zwembad, of je bent net een weekje weg. Dan gaat je telefoon. Er komt ineens een enorme hoeveelheid verkeer op een klantomgeving af die daar niet hoort te zijn. Als er niet snel wordt ingegrepen, ligt de omgeving straks plat! Los van de stress is het vanaf een Franse camping in the middle of nowhere met een brakke internetverbinding niet bepaald ideaal om op afstand een incident op te lossen. Bij ons hoeft dat gelukkig ook niet. Onze monitoring signaleert afwijkingen vaak al voordat een klant er iets van merkt. Ons team staat altijd klaar om direct in te grijpen en problemen op te lossen voordat ze impact hebben. Geen paniek, geen haastwerk en geen onderbroken vakantie. Dát is het verschil tussen reactief en proactief beheer. Het zien aankomen voordat het een probleem wordt. Want het internet neemt geen zomerstop. Bots, scans en DDoS-aanvallen gaan gewoon door. Daarom hoort je hosting ook 24/7 beschermd en gemonitord te worden. Hoe regelen jullie dat tijdens de vakantieperiode? Wie houdt bij jullie de wacht?

1775 dagen uptime. Klinkt indrukwekkend toch? Totdat je inlogt... Vandaag moest ik een unmanaged VPS in ons netwerk verplaatsen naar ons nieuwe platform. Normaal gesproken doen we niets met unmanaged servers, maar hiervoor moest ik er toch echt even op inloggen... Dit trof ik aan: ⏱️ 1775 dagen uptime 🐧 Een sterk verouderde kernel 💀 CentOS 7 (2 jaar End of Life) 🐘 PHP 5.4 (al ruim 10 jaar End of Life) 🌍 Publiek bereikbaar via het internet! Veel mensen zien een hoge uptime als iets positiefs. Maar in de praktijk betekent dit vaak dat een server al jaren geen reboot, kernel-update of groot onderhoud heeft gehad. Dat brengt serieuze risico’s met zich mee: - Beveiligingslekken waarvoor geen patches meer beschikbaar zijn. Met de huidige stroom aan nieuwe CVE’s is dat vragen om problemen. - Verouderde software stack die niet meer wordt ondersteund. - Grotere kans op uitval wanneer een update uiteindelijk wél noodzakelijk wordt. - Compatibiliteitsproblemen met moderne software. - En uiteindelijk een migratie die veel complexer wordt dan nodig. Dit is precies waarom managed hosting meer is dan alleen “iemand die updates installeert”. Goed beheer betekent: ✅ Regelmatig beveiligingsupdates installeren. ✅ Direct reageren op kritieke kwetsbaarheden (CVE’s) met spoedupdates wanneer dat nodig is. ✅ Het besturingssysteem, de kernel en alle software up-to-date houden. ✅ Proactief monitoren en onderhoud plannen. ✅ Problemen voorkomen in plaats van achteraf oplossen. Een VPS is geen apparaat dat je één keer neerzet en vervolgens jarenlang kunt vergeten. Net als iedere andere IT-omgeving heeft ook een server onderhoud nodig om veilig, stabiel en toekomstbestendig te blijven. Een hoge uptime is voor mij geen prestatie. Voor mij is het een red flag! 🚩 #ManagedHosting #ManagedServices #ManagedVPS #Hosting #Linux #Cybersecurity #ServerBeheer

Een developer zet iets live. En dan begint het echte gedoe… ‘’Waar heb jij het nou weer over, Kevin?” Nee, het is niet de hitte die naar mijn hoofd is gestegen 😉 Ik zie nog te vaak dat development en hosting als twee compleet gescheiden werelden opereren. Ze werken allebei aan hetzelfde eindresultaat, maar praten tijdens het ontwikkelproces nauwelijks met elkaar. Neem bijvoorbeeld een applicatie die lokaal perfect draait, maar in productie onder belasting meteen de mist in gaat. Ik heb inmiddels van alles voorbij zien komen: - Applicaties die tegen geheugenlimieten aanlopen. - Scripts die vastlopen door execution time-outs. - Cronjobs die elkaar blijven overlappen en zo een server volledig overbelasten. - Een verkeerde PHP-versie of een ontbrekende extensie. - Een cachinglaag die in productie nét anders werkt dan tijdens development. - Trage SQL-queries door ontbrekende indexen. - Logbestanden die ongemerkt de volledige schijfruimte opslokken. - Order e-mails komen niet meer aan door een missend SPF-record. Op zichzelf zijn dit vaak geen ingewikkelde problemen. Maar als je ze pas ontdekt tijdens of na een livegang, kosten ze onnodig veel tijd, frustratie en soms zelfs omzet. Gevalletje: “It works on my machine.” Volgens de developer moet het gewoon probleemloos werken. En volgens de hostingpartij is er niets veranderd aan de serverconfiguratie. En weet je? Ze hebben allebei gelijk. Precies dát is het probleem. Development en hosting zijn twee verschillende disciplines die uiteindelijk naadloos moeten samenwerken. Alleen gebeurt die samenwerking in de praktijk vaak pas vlak voor de livegang. En dan ontstaat de uitdaging bij de overdracht. Vaak onder hoge tijdsdruk, omdat de livegang al een paar keer is uitgesteld. De developer bouwt in een lokale omgeving die nét anders is ingericht dan productie. De hostingpartij krijgt vervolgens een applicatie aangeleverd zonder de volledige context over wat nodig is om die stabiel te laten draaien. Of het oorspronkelijke plan is tijdens het ontwikkelproces flink veranderd, zonder dat de impact op de hostingomgeving is meegenomen. En dan hopen we maar dat het goed gaat… Soms gaat het goed, maar vaak niet.

"Hoe zit die omgeving eigenlijk in elkaar?" "Geen idee, dat heeft Mark ooit ingericht. En Mark werkt hier niet meer." Dit gesprek wordt dagelijks gevoerd bij bedrijven van elke grootte. Cruciale kennis over een IT-omgeving zit vaak in één hoofd. En als dat hoofd vertrekt, vertrekt die kennis mee. Vooral bij servers zie je dat regelmatig. Een keer ingericht, daarna liever niet meer aankomen. "Werkt het? Dan vooral afblijven." Totdat er iets moet veranderen of geüpdatet moet worden. Dan blijkt ineens niemand meer precies te weten hoe alles ooit is opgebouwd en vallen er dingen om. Daarom werken wij met Infrastructure as Code (IaC). Simpel gezegd: de volledige inrichting van een omgeving ligt vast in code. Geen losse commando’s, handmatige aanpassingen of verborgen kennis in iemands hoofd, maar één bron van waarheid die exact beschrijft hoe de infrastructuur eruit moet zien. Die code bouwt de omgeving op én dient tegelijkertijd als documentatie. Dat levert veel op: → Een omgeving opnieuw opbouwen? Dat is geen archeologie meer, maar een kwestie van de configuratie opnieuw uitrollen. → Iets aanpassen? Elke wijziging staat vastgelegd in Git. Je ziet wat er veranderd is, wanneer, waarom en door wie. “Configuration drift” wordt hiermee voorkomen. → Opschalen bij een verkeerspiek? De blauwdruk ligt er al; een extra server inrichten kost geen middag handwerk meer. Maar is gepiept in enkele minuten. → En misschien wel het belangrijkste: de kennis zit niet meer in iemands hoofd, maar in het systeem zelf. Misschien is dat laatste wel de grootste winst. Want infrastructuur moet niet afhankelijk zijn van personen. Het moet reproduceerbaar, inzichtelijk en beheersbaar zijn. Eigenlijk is dat dezelfde reden waarom ik zo’n voorstander ben van open source: je kunt zien hoe iets gebouwd is. Geen black box, maar transparantie. En juist nu we steeds meer automatiseren met AI en andere tooling, wordt dat alleen maar belangrijker. Je infrastructuur beheren is één ding. Begrijpen hoe die is opgebouwd, dát geeft controle.

Een AI bouwt vandaag in een middag een werkende website. Tien jaar geleden was ik daar weken mee bezig. Geweldig toch? Zeker! We bouwen sneller dan ooit. En bijna iedereen kan tegenwoordig een website, applicatie of workflow maken zonder diepgaande technische kennis. Maar er zit ook een risico aan. Vroeger wist je precies hoe iets werkte. Welke functies erin zaten, hoe systemen met elkaar communiceerden en waar mogelijke problemen konden ontstaan. Je had het zelf gebouwd, dus je kende de techniek van binnen en van buiten. Nu geef je een opdracht "bouw dit voor mij" en het wordt gebouwd. Maar wat er onder de motorkap gebeurt, blijft vaak een mysterie. Een beveiligingslek kun je tijdelijk afschermen met allerlei maatregelen en quick-fixes. Maar uiteindelijk moet het probleem in de code worden opgelost. En als je niet begrijpt hoe het systeem in elkaar zit, wordt dat toch best lastig. Mijn punt is dus eigenlijk ook niet: gebruik geen AI. Want het heeft enorm veel voordelen en geeft veel efficiëntie, maar we moeten wel grip houden op wat we bouwen en in productie zetten. Je hoeft echt niet elk detail te begrijpen. Wel de grote lijnen. Stel duidelijke kaders. Test wat eruit komt. Kijk af en toe onder de motorkap. En vooral: Blijf verbonden met de techniek. Want snelheid is mooi. Maar grip op je eigen techniek? Dat zorgt voor controle en eigenaarschap. En dat is wat je uiteindelijk overeind houdt als het een keer misgaat.