Door Mark van der Kruit en Tomas Hochstenbach

De grote serververhuizing - Dag True, hallo Exonet! - Tweakers-vlog #20

29-03-2026 • 06:00

51

Als het goed is heb je er niets van gemerkt … Maar de afgelopen weken hebben we misschien wel de grootste operatie ooit uitgevoerd bij Tweakers: de verhuizing van onze servers van True in Amsterdam naar Exonet in Ede. In deze video zie je hoe dat eraan toeging.

00:00 - De grote serververhuizing - Dag True, hallo Exonet!
00:22 - Datacenter euNetworks
01:06 - De laatste restanten van het Tweakers-rack
05:12 - Van de stad naar het platteland
06:17 - Onze nieuwe hostingprovider: Exonet
08:12 - Ons nieuwe datacenter Bit

Reacties (51)

Sorteer op:

Weergave:

Ik snap wel dat Tweakers niet zomaar naar de cloud gaat. De hoeveelheid performance en storage die nodig is maakt dat gewoon erg duur. De flexibiliteit van de cloud is helemaal niet nodig. En ik schat in dat Tweakers misschien wel helemaal niet cloud-native is. Ik schat zo in dat Tweakers draait op een database cluster (MariaDB?), webserver cluster (Nginx of Apache?) en een storage cluster. Het komt er dan op neer dat je in feite allemaal dikke compute nodes huurt. Dat is doorgaans 3x duurder dan zelf hosten. Waar doe je het dan voor?

Als ik het zelf zou moeten beheren zou ik denk ik ergens wat dedicated servers huren. Je hoeft dan een stuk minder na te denken over de hardware, netwerk en firewall. Ook die kosten zijn natuurlijk wat hoger, maar geeft je ook wel de flexibiliteit om een paar maanden wat extra hardware er bij te zetten, of juist af te schalen.
Ik snap wel dat Tweakers niet zomaar naar de cloud gaat.
Ze hebben feitelijk al de “Private Cloud”. Zoals @Kees namelijk al zegt: “Ons eigen stukje internet”. Dat zegt simpelweg dat ze een of meerdere eigen IP blokken hebben, waarop ze hun private cloud kunnen distribueren.
De hoeveelheid performance en storage die nodig is maakt dat gewoon erg duur.
Helemaal mee eens. In de cloud betaal je gewoon een flink voor het feit dat je geen fysiek werk wilt hoeven te verzetten. Daar komt echter voor terug dat je een Azure of AWS guru moet zijn om met de terminologie om te kunnen gaan, om vervolgens hetzelfde te kunnen doen als op je private cloud. En daarbij komt dat je vaak een baklading aan extra features erbij krijgt die je helemaal niet gebruikt maar wel voor betaalt. Om nog maar niet te spreken over jezelf vastzetten in het ecosysteem van een dergelijke partij.
De flexibiliteit van de cloud is helemaal niet nodig. En ik schat in dat Tweakers misschien wel helemaal niet cloud-native is. Ik schat zo in dat Tweakers draait op een database cluster (MariaDB?), webserver cluster (Nginx of Apache?) en een storage cluster. Het komt er dan op neer dat je in feite allemaal dikke compute nodes huurt. Dat is doorgaans 3x duurder dan zelf hosten. Waar doe je het dan voor?
Servers huren is ook altijd duurder dan servers zelf inkopen (hoewel geheugencapaciteit momenteel wel echt een grote domper op de prijs is). Voor tijdelijke projecten is een server huren een erg goed plan. Wanneer je over de langere termijn echter gaat werken, dan heb je wat meer aan een eigen server. Daargelaten dat een server van jezelf in eigen beheer staat en een server van iemand anders, vanzelf sprekend niet. Dat stukje manager hosting betaal je ook voor.

Wat ik als Ops/DevOps -persoon juist vaak zie, is dat Nginx veel gebruikt wordt voor load balancing en proxy-en. Daar is die heel sterk in. Ik durf zo niet te zeggen waar de applicaties (want dat zullen er meerdere zijn) op draaien (puma, php, etc), maar dat wordt dan simpelweg vanuit meerdere servers naar de nginx proxy gestuurd, zodat die kan bepalen vanaf welke server, met welke load, Tweakers.net op je scherm wordt getoverd.

Voor een applicatie als Tweakers.net verwacht ik dat er meerdere PostgreSQL databases gebruikt worden. Dat is een stuk flexibeler dan MariaDB en past ook een stuk beter in de geest van Tweakers.net. Maar ook iets als ElasticSearch voor zoekmachine en Redis voor snelle queries.
Als ik het zelf zou moeten beheren zou ik denk ik ergens wat dedicated servers huren. Je hoeft dan een stuk minder na te denken over de hardware, netwerk en firewall. Ook die kosten zijn natuurlijk wat hoger, maar geeft je ook wel de flexibiliteit om een paar maanden wat extra hardware er bij te zetten, of juist af te schalen.
Voor een nieuw of kort project is dat wel de juiste manier inderdaad. Als je echter weet dat je project alleen maar steady blijft of juist zou moeten groeien de aankomende paar jaren, dan is huren totaal niet interessant (wanneer je de mankracht hebt om private cloud te hosten). Die flexibiliteit wordt belangrijk wanneer de winstmarges fundamenteel relatief laag liggen en de uitgaven dus ook laag moeten blijven. Seizoensgebonden applicaties zullen daar ook veel baat bij kunnen hebben.

@Tomas Hochstenbach @Kees @TradeMarkNL vette video! Dank daarvoor. :)

[Reactie gewijzigd door InjecTioN op 29 maart 2026 10:25]

We draaien (sinds 1999) al op MySQL (varianten). Postgres hebben we heel erg lang links laten liggen omdat het qua replicatie niet al te best was, en mysql daar veel beter in was.

En nu we zo'n uitgebreide database hebben is het erg lastig om naar postgresql over te stappen. We gebruiken nog te vaak mysql specifieke functionaliteiten en niet alles is abstract in een data-laag in de applicatie.

We gebruiken overigens Ivanti Virtual Traffic Manager als loadbalancer, maar ik wil in de toekomst toch eens naar HA-proxy kijken als vervanging.

Het cluster bestaat verder inderdaad uit twee database servers, 6 kubernetes nodes waar ook de apache servers in draaien (met php). En dan 6 ceph storage nodes. En nog wat servers er omheen, zoals 3 vm servers om vm's te draaien (die bijvoorbeeld een kubernetes cluster draaien voor de test omgevingen).

Het voordeel van de cloud is dat je "stukjes" server kan huren al dan niet tijdelijk. Het nadeel van de cloud is dat als je al die stukjes continue moet huren, het vrij duur is.

Er zijn ook nog wel wat andere voordelen zoals de services die zo'n cloud heeft gebruiken, maar dan krijg je weer vendor-lockin, en als het te gemakkelijk is om verschillende services te gebruiken kun je een hele complexe applicatie maken die niemand meer snapt (waarbij het 'per applicatie' nog wel mee zal vallen, maar ik heb oplossingen gezien waarbij het ene team java en postgres gebruikte, het volgende team python en mariadb en weer een team go en sqllite)
waarbij het 'per applicatie' nog wel mee zal vallen, maar ik heb oplossingen gezien waarbij het ene team java en postgres gebruikte, het volgende team python en mariadb en weer een team go en sqllite
Ik ook en dat werkt eigenlijk wel best als het bedrijf er ook geschikt voor is. Ligt ook aan de problematiek waar het team mee worstelt. Sommige dingen gaan nou eenmaal veel beter en sneller in Go.


En wat betreft cloud, voor tweakers denk ik niet dat het zin heeft gezien de lokale load als je ‘s nachts niet dynamisch kunt afschalen (ook in read replica’s).

Lekker on-prem blijven. Ook gezien de PHP serving de betere keuze.

Ik zou zelf nooit de cloud in gaan als er PHP wordt gebruikt, aangezien je de meeste compute zelf hebt als load. Dat is idd iets heel anders dan statisch JS uitserveren via een CDN.
Ik ook en dat werkt eigenlijk wel best als het bedrijf er ook geschikt voor is. Ligt ook aan de problematiek waar het team mee worstelt. Sommige dingen gaan nou eenmaal veel beter en sneller in Go.
Het hangt inderdaad van de teams af, maar ik bekijk het zelf van de operationele kant. Ik ben lui en doe het liefst zo min mogelijk. En dus hou ik het liever bij 1 database type, 1 webserver en 1 taal. Dat maakt backups, monitoring en observability een stuk eenvoudiger

Dat is niet helemaal gelukt, want we draaien alsnog een rits aan database en talen (PHP en Java voor het grootste deel, en daarnaast nog wat python, ruby, go en c - en dan tel ik alleen de programma's mee waar ik in de source code zaken heb aangepast of plugins voor heb geschreven)
Ja begrijpelijk hoor. Vanuit enterprise zie ik ook meer standaardisatie op 1 taal + tooling rondom een select aantal van die andere talen zoals Python en Go voor het scriptwerk.

in het geval van tweakers zit er ook al weer 25 jaar aan development achter dus kan me ook nog wel wat legacy en dergelijke voorstellen. Je noemde de data complexiteit al. Als je dan wat kleiner bent en idd niet 80 teams en 500 devs hebt, dan wil je er idd zo weinig mogelijk zien.

Hoewel ik jouw lijstje nog behoorlijk vind hoor.
Ben trouwens wel benieuwd hoe de cloud business case zou uitpakken als je vanaf scratch moet beginnen. Als je alle hard- en software al hebt, en je hebt een redelijke stabiele load (en de grote, zware dingen als video’s zet je al wel in de cloud), dan is het een no-brainer. Maar als je nu een cluster moet bouwen met nieuwe servers en networking (en software!), kan het zomaar een ander plaatje worden.
37signals (Basecamp) van David Heinemeier Hansson is teruggegaan naar eigen (nieuwe) servers en zegt dat het ze alsnog veel geld bespaart.

YouTube: How hard is it to run your own servers? | DHH and Lex Fridman
Ik zou zelf waarschijnlijk nieuwe projecten in de cloud starten. Maar wel in het achterhoofd houden dat je op termijn, als het project een success is je weer uit die cloud weg wil. Of op zijn minst dat je naar een andere cloud provider wil verhuizen.

En dan kun je ook een tijd lang hybride draaien waarbij je rustig je eigen infra laat opzetten (want er zijn ook genoeg bedrijven die dat voor je kunnen overnemen; een argument dat ik vaak hoor is dat je "alles zelf" moet doen als je niet in de cloud zit; dat is niet correct, net als met de cloud zijn er ook gradaties in hoeveel je zelf doet als je je eigen servers host).
Beetje jammer om te horen dat buiten de A10 het platteland begint. Als Google in de Eemshaven staat, hoe zouden jullie dat wel niet noemen...
Dat is toch de periferie?

Nee grapje; ik woon zelf op het platteland buiten de bebouwde kom, en kom van origine uit noord groningen. Dit was gewoon een grapje om aan te geven dat we niet in de randstad blijven waar je uiteindelijk toch de meeste datacenters zal vinden.
Ook het platteland? Ede is gewoon fors kleiner en ligt niet in de randstad. Is het een belediging?
Platteland heeft volgens het CBS minder dan 500 adressen per vierkante kilometer, daarboven heb je te maken met stedelijk gebied. Ede (stad, waar Bit gesitueerd is) heeft 1000 tot 1500 adressen per vierkante kilometer en is daarmee "matig stedelijk". De gemeente Ede daarentegen is met 32000 hectare gigantisch voor Nederlandse begrippen, waardoor het aantal adressen per km2 erg laag is. Dit is volgens mij de definitie van platteland/stedelijk gebied in de volksmond.

Echter: het gaat om de dichtheid van adressen in een cirkel rondom een adres, de omgevingsadressendichtheid. Puur afgaande op de letterlijke definitie die het CBS geeft, neem ik aan dat Bit ligt op het platteland (gezien de adressendichtheid van het industrieterrein), alhoewel het in kern Ede stad ligt.
Het is niet zwart-wit. Ede heeft 100k+ inwoners, staat in de top 25. Dus als alles onder top 25 platteland is heb je gelijk…
Het gebied waar Ede ligt is erg platteland. Kijk eens hoever het toch ligt vanaf Utrecht. Je moet echt het land in. Zelf is Ede een uit de kluiten gewassen dorp (hele grote woonwijk) waar veel mensen vanuit Utrecht en Arnhem/Nijmegen zijn gaan wonen. Het heeft zeker geen stads karakter.

Iets als Hoofddorp, Zoetermeer of Heerhugowaard of noem nog een paar, zijn van die typische dorpen die uit de kluiten gegroeid zijn door er maar bevolking te "planten".
Het is zeker geen echt Amsterdam meer. :P
Leuk! Kan iemand de link delen naar de vorige server post waar ze het over hebben in de video?
wat is de reden dat True ermee stopt als sponsor?
.plan: Serververhuizing, DB-versimpeling en feedbackfixes - Development-iteratie #332
Verhuizing van de servers

In een video van ongeveer een jaar geleden hebben wij jullie laten zien hoe we Tweakers hosten. Deze video begint buiten een datacenter en neemt jullie mee naar onze servers in dat datacenter.

Helaas kregen wij in de herfst te horen dat dit datacenter op relatief korte termijn gaat sluiten. Omdat het hele gebouw leeg moet, hebben wij geen andere keuze dan ook onze servers daar weg te halen en ergens anders onder te brengen.

Hier komt nog bij dat onze hoster, die ons de afgelopen 24 jaar heeft gesponsord, in de loop der tijd zijn focus heeft verlegd en dat nu de tijd is gekomen om deze sponsorovereenkomst op te zeggen. Onze dank gaat uit naar TrueFullStaq voor de afgelopen 24 jaar, maar helaas gaan onze wegen scheiden. Wat we met onze hosting gaan doen, zullen we binnenkort in een ander artikel vertellen.
Ook bij FOK! stoppen ze als sponsor. Blijkbaar heeft True het niet meer nodig, of juist wel maar dan tegen keiharde euro's ;)
Uit het gesprek dat ik met ze had kwam inderdaad naar voren dat de klanten die wij aantrekken niet perse meer de klanten zijn waar zij zich op focussen.

Ze verhuizen zelf ook van een gehuurde ruimte met racks naar een datacenter waar ze individuele racks huren. In het oude datacenter zaten de kosten voor de sponsoring dus voornamelijk in de stroomkosten, in het nieuwe datacenter komen daar de kosten voor de ruimte bij (en een commitment op stroom). Dus hoe minder racks ze afnemen, hoe lager hun kosten zijn.

En dan is het ineens duidelijk wat de kosten zijn voor de sponsoorovereenkomsten die 25 jaar geleden door hele andere mensen gemaakt zijn en hebben ze besloten om die op te zeggen.
Leuke video! Ik mis alleen een wat diepgaandere vergelijking tussen de oude en de nieuwe hosting, bijvoorbeeld op het gebied van snelheid of andere voordelen. Ik ben benieuwd wat de maximale snelheid van de aansluiting voor Tweakers is en hoe de capaciteit van de nieuwe hoster zich verhoudt tot de oude.
De snelheid van de internet verbinding is niet heel erg van invloed op hoe snel de website is. We hebben nu 2x10Gbit op de ene locatie en 1x1Gbit op de backup locatie, maar we gebruiken in een normale situatie dat bij lang na niet.

En alle hosters en datacenters hebben meerdere 100Gbit verbindingen waar het verkeer verder over heen gaat.

De capaciteit van de nieuwe vs de oude hoster zal niet merkbaar verschil maken tegenwoordig. Vroeger was dat wel anders toen hosters nog met 100mbit verbindingen werkten, maar tegenwoordig is dat niet meer merkbaar.
Creatief bedacht een 1U rail voor kabelmanagement.
Ik heb die "oplossing" al vervangen door een D-ring.

En andere mensen hebben schroefjes over na een verhuizing, ik had ineens een set sliders te veel. Geen idee waar de server is gebleven, maar het kwam achteraf wel handig uit om een extra set sliders te hebben.
Ik zou als serverbeheerder niet ál te hard roepen dat je na een verhuizing niet weet waar een server gebleven is… ;)
Het is meer een oproep; Is er iets wat niet meer werkt omdat de server erachter uit staat? Mischien dat ik er op die manier achter kan komen van welke server die sliders waren :+

(En het is natuurlijk een grapje; die sliders waren van een server die zelf al uit het rack was gehaald, maar die sliders zaten muurvast in het rack en kreeg ik niet los tot ik de server erboven ook uit het rack haalde. En toen had ik dus een extra set aan sliders over, en die kunnen best handig zijn als je bijvoobeeld switches wil ophangen en je geen tool als deze hebt)

[Reactie gewijzigd door Kees op 29 maart 2026 11:57]

Blijven mooie migraties. Zelf ook een tweetal keer zo'n migratie mogen doen, waarbij er vooral heel veel kleinere sites betrokken waren in plaats van 1 grote. Een intern netwerk wat op beide locaties actief is scheelt dan inderdaad een hoop.

Gezien de huidige kosten van stroom snap ik wel dat sponsoring steeds minder interessant wordt voor partijen.
Welkom in het Edese! Tja typisch Amsterdams om te zeggen dat je naar het platteland gaat. Vergeet niet je laarzen als je hier komt, allemaal zandwegen.

Herinner mij nog in het oude pand van BIT, begin ‘00 de LAN party’s. Toen al een leuke plek en al een supersnelle verbinding. Weet eigenlijk niet hoe het er nu is.

[Reactie gewijzigd door no_way_today op 29 maart 2026 09:23]

Ik had gehoopt dat ze wat specificaties hadden gegeven. Wel een leuke video.

Om te kunnen reageren moet je ingelogd zijn