21 jaar geleden werd de site waar je nu dit artikel op leest opgericht. In dat tijdperk was er nog geen cloudhosting, Nederlandse domeinnamen waren alleen beschikbaar voor bedrijven en de meeste mensen hadden internet via een telefoonlijn. In dit artikel gaan we in op de hostinggeschiedenis van Tweakers. Omdat we dat ook al gedaan hebben bij het 10-jarig en 18-jarig bestaan van Tweakers beginnen we met een korte samenvatting van deze afgelopen 21 jaar en zullen dan op een aantal onderdelen dieper ingaan.
Van shared hosting naar dedicated servers
De allereerste pagina van Tweakers stond op een shared-hostingaccount van Femme bij Pair. Toen deze pagina aandacht kreeg op Slashdot werden de maandelijkse limieten van dat account in een dag geslecht. De eerste upgrade van het account gaf Femme echter ook de mogelijkheid om een forum te gaan draaien en daarmee te concurreren met Webwereld. In september 1998 zag daardoor 'World of Tweaking' het licht.
Dit forum liep vrij hard, en toen Femme daarnaast ook nog regelmatig nieuws ging schrijven op de voorpagina liepen de bezoekersaantallen rap op. Het shared-hostingaccount werd vrij snel opgezegd en we stapten over naar de Amerikaanse provider Rackspace. De dedicated server die wij daar huurden crashte echter met grote regelmaat waardoor Tweakers er soms dagenlang uit lag. Meer over deze periode kun je lezen in het artikel dat Femme schreef toen Tweakers 10 jaar werd.
Zelfbouwservers en crashes
In het begin van het jaar 2000 besloten wij om onze eerste twee zelfgebouwde servers te plaatsen in een gesponsord rack dat werd aangeboden door Vuurwerk Internet. De uptime van de website verbeterde daarmee behoorlijk, maar al heel snel bleek dat deze twee servers niet voldoende waren. In maart 2000 behaalden we net 3 miljoen pageviews, een jaar later was dat al 15 miljoen. In hoog tempo werden daarom de bestaande servers voorzien van upgrades en kochten we extra servers. De upgrades verliepen niet altijd vlekkeloos en dat ging soms gepaard met wat dataverlies.
Omdat wij alleen woensdagmiddag maximaal een uur bij de servers mochten komen bij Vuurwerk waren wij erg blij toen Trueserver ons benaderde met een hostingvoorstel. Wij konden een eigen rack krijgen, een uplink van maar liefst 1Gbit/s en belangrijker: 24/7 toegang tot de servers. Begin juni 2001 verhuisden we dan ook naar Telecity II, tegenwoordig Equinix AM7, en tot op de dag van vandaag wordt de colocatie door True gesponsord.
Professionele hardware en uitbreidingen
Nadat de zoveelste zelfbouwserver weer eens met kapotte hardware niets stond te doen werd besloten om vanaf toen alleen maar complete servers met garantie aan te schaffen. Sinds 2006 hebben we alleen nog maar servers aangeschaft van serverfabrikanten in plaats van zelf een systeem in elkaar te schroeven met daarin hardware waarvan we van tevoren niet zeker wisten of die goed met elkaar ging samenwerken.
Voor de nieuwe servers waren wij niet erg merktrouw. Omdat de hardware grotendeels vergelijkbaar was, bleef er eigenlijk maar een criterium over en dat was de prijs. Hierdoor hadden we op een gegeven moment servers van Dell, HP, IBM en Sun in ons rack hangen. De Sun-servers wonnen overigens met afstand de prijs voor uiterlijk en bouwkwaliteit.
Redundantie en High Availability
Nu de kwaliteit van de servers eindelijk op orde was, werd het vanaf 2012 tijd om meer redundantie in het serverpark in te bouwen. Hiervoor werd in samenwerking met Quanza Engineering een tweede locatie opgezet zodat de site zelfs zou blijven werken als een van de locaties van de aardbol zou verdwijnen. Deze twee locaties zijn vervolgens door een redundante darkfiberverbinding van 10Gbit/s met elkaar verbonden om zo alsnog één netwerk intern te hebben. Alle servers zijn bovendien op twee powerfeeds en twee netwerkswitches aangesloten.
Ook op applicatieniveau hebben we de redundantie verbeterd, zo draait MySQL in een master-master-opstelling, zitten de MongoDB-servers in een cluster, zijn de ActiveMQ-instanties onderdeel van een 'network of brokers', kunnen de loadbalancers eenvoudig ip's van de ander overnemen en slaat het Ceph-cluster zijn data op drie verschillende plekken op.
Databaseservers: performancemonsters
Bijna vanaf het eerste moment dat de site live ging was er een databaseserver nodig. In de 21 jaar die daarop volgden hebben we vele databaseservers versleten. Tegenwoordig draaien wij MySQL in een 'primary-secundary master-master'-opstelling, dat wil zeggen dat lees- en schrijfacties op beide servers gedaan kunnen worden, maar dat we die bij voorkeur op de 'primary'-server doen.
De zelfbouw- en bareboneservers
In het begin van deze site moest alles zo goedkoop mogelijk en het liefst gesponsord. De allereerste databaseserver droeg de naam Athena en was voorzien van een enkele AMD Athlon-singlecore op 800MHz met een mix van diverse soorten geheugen: 1x 128MB PC100 en 1x 256MB PC133, een 100Mbit/s-netwerk en een consumentenmoederbord van MSI. De data werd opgeslagen op maar liefst drie IBM-schijven van 9,1GB groot.
Athena heeft het uiteindelijk minder dan een jaar volgehouden voordat de load te hoog werd en ze werd vervangen door een grotendeels gesponsorde nieuwe server. Deze server was de eerste die de naam Artemis kreeg. Bovendien was dit de eerste dual-cpu-server ooit in ons serverpark. Zij kreeg de beschikking over twee Intel Pentium III-chips die hun werk op 733MHz deden. Verder kon zij de data wegschrijven naar 1GB geheugen en voor permanente opslag kreeg zij de beschikking over drie Seagate Cheetah X15-schijven van 35GB. Ook Artemis bleek niet snel genoeg te zijn en werd nog tijdens de diensttijd geüpgraded naar een configuratie met dubbele Pentium III op 1GHz en 4GB geheugen.
Ook deze eerste Artemis was geen lang leven beschoren. Na iets meer dan een jaar moest ze plaats maken voor een server met een tweetal AMD Athlon MP1600+-cpu's. Het AMD-tijdperk leefde voort in de opvolger, een barebone van Appro die wij van twee AMD Opteron 246-chips op 2GHz voorzagen. Korte tijd later werd deze server weer vervangen door de vrijgekomen server van het forum waardoor het geheugen verdubbelde naar 8GB en ze de beschikking kreeg over twee AMD Opteron 254-cpu's die nog op de plank lagen.
Het Intel-tijdperk
Vanaf 2006 was het gedaan met de AMD-hegemonie in onze databaseservers. De nieuwere server-cpu's van AMD werden wat performance betreft volledig voorbijgestreefd door Intels Xeon-processors en dan met name op singlethreaded prestaties. Wat nog wel bij het oude bleef was dat we ouderwets roterende schijven gebruikten om de data op te slaan. Omdat de performance van een enkele schijf, zelfs op 15.000 toeren, niet heel erg goed is, gebruikten wij in deze periode maar liefst vijftien van deze energieslurpers per databaseserver.
In 2009 kwam ook daar verandering in en kochten wij de eerste databaseserver met ssd's erin. Zoals gebruikelijk kwam daar ook weer genoeg kritiek op, de ssd's waren van het verkeerde merk, het verkeerde type, ze draaiden in de verkeerde raidmodus, we hadden ook gewoon roterende harde schijven kunnen kopen, we gebruikten de verkeerde raidcontroller en de site was al snel genoeg en hoefde niet sneller. Deze server heeft het als eerste databaseserver meer dan drie jaar vol gehouden.
De jaren daarna werd het redelijk stil op het gebied van de databaseserver, de performance nam minder dramatisch toe met de upgrades, de disks werden niet veel sneller en downtime door vervanging was niet meer nodig. Daarom bij deze een lijst met alle databaseservers die we hebben gehad tot en met de laatste server die wij deze maand hebben gekocht.
Met de laatste twee servers kunnen we weer even vooruit. Sterker nog, de ontwikkelingen op de servermarkt en de groei van de belasting zijn dusdanig gedaald dat we de servers nog maar elke 5 jaar vervangen in plaats van elke 3 jaar. Aangezien Artemis 9 nog geen jaar oud is, houdt dat in dat we pas weer een databaseserver vervangen nadat we ons 25 jarig jubileum vieren. Wie weet krijgen we dan weer AMD-cpu's en kunnen we het geheugen weer verdubbelen.
Opslag: oorzaak van de meeste downtime
Het zal de vaste Tweakers.net-bezoeker niet ontgaan zijn dat t.net als gevolg van een instabiele fileserver zo af en toe niet bereikbaar is.
Zo begon ik ruim 16 jaar geleden een .plan en om eerlijk te zijn: ook na die .plan waren de problemen nog lang niet over. De shared filestorage is eigenlijk altijd de achilleshiel geweest van het serverpark, en alhoewel de situatie nu veel beter is dan in het verleden, gaat het nog steeds af en toe verkeerd.
De eerste stapjes
Al vanaf het moment dat wij meerdere servers hadden was er behoefte om bepaalde files beschikbaar te maken voor meerdere webservers, bijvoorbeeld redactionele afbeeldingen en usericons. In het begin lieten we gewoon een webserver via nfs een share exporteren en zetten we daar alles op. In 2001 bleek dat dit niet altijd een goed idee was, problemen met de nfs-share zorgde meerdere keren voor downtime omdat ineens alle webservers op de nfs-share zaten te wachten.
Eind 2001 namen we daarom onze eerste dedicated fileserver met de naam 'Atlas' in gebruik, een Gigabyte-server met twee 1GHz Pentium III's, 1GB geheugen en een drietal scsi-schijven van 18GB in een raid5-opstelling. In eerste instantie wilden we daar het coda-filesystem op gaan draaien maar dit bleek niet zo eenvoudig aan de praat te krijgen zijn waardoor we dat idee lieten varen en weer met nfs aan de slag gingen. Deze server heeft het minder dan een jaar volgehouden voordat hij vervangen werd door 'Argus'.
Ook met Argus hadden wij regelmatig last van downtime omdat alle webservers uitvielen als er een probleem met nfs was, iets wat regelmatig voor kwam. Als oplossing kregen wij van Trueserver tijdelijk een NetApp te leen. Ondanks dat dit een professionele fileserver was wisten wij deze in korte tijd ook om zeep te helpen waardoor de site er weer uit lag.
De grote bakbeesten en slechte ideeen
Als vervanging van de NetApp hebben we een bakbeest van een fileserver in elkaar gezet. In deze server van maar liefst 7U hoog was plek voor twaalf 3,5"-schijven en we vulden hem dan ook met zo'n beetje elke schijf die we nog hadden liggen. Helaas bleek ook deze server enkele eigenaardigheden te vertonen. Zo had bijvoorbeeld een van de drive bays de eigenschap om elke schijf die wij daarin deden binnen een maand stuk te krijgen en konden we maar twee van de drie sata-schijven plaatsen omdat ze anders te warm werden.
Deze server is uiteindelijk vervangen door een Melrow-case vol te stoppen met acht Western Digital Raptor-schijven, dit was de eerste fileserver die niet elke maand voor problemen zorgde. Nadat deze server goed draaide hebben we de oude server met behulp van een honkbalknuppel een waardig afscheid gegeven.
Om eindelijk van nfs af te zijn stapten we over op een Dell MD3000i, een appliance van Dell die via iscsi zijn disks kon exporteren. Hierop draaiden wij een cluster-filesystem met de naam OCFS2. Dit was in theorie een prima oplossing, en het systeem heeft ook twee jaar in productie gedraaid, maar helaas bleek dit zo'n beetje de meest instabiele oplossing te zijn, helemaal omdat het cluster-filesystem de webservers 'afschoot' via stonith als hij dacht dat die webserver niet meer goed in sync was. Dit leidde regelmatig tot een situatie waarbij de webservers elkaar nonstop gingen rebooten totdat wij handmatig ingrepen.
Door de problemen die wij ondervonden in deze tijd zijn helaas ook veel oude foto's corrupt geraakt of gewoon helemaal verdwenen.
Sun, OpenSolaris en ZFS
Vanwege goede verhalen die wij hoorden over Sun en zfs besloten wij om de vervanger van de MD3000i te kopen bij Sun. We kochten een Sun Fire x4270 voorzien van OpenSolaris met tien 146GB-schijven die op 10k rpm roteerden. Daarnaast zaten er twee slc-ssd's in voor de zil en twee mlc-ssd's voor de l2arc.
Deze server beviel zo goed dat wij als opvolger twee Sun 7120 zfs-appliances kochten met daarin elf 3TB-schijven per appliance. Dit was de eerste keer dat we een redundante fileserver hadden. Maar omdat deze redundantie nog steeds op nfs was gebaseerd hebben we dat nooit in productie getest. De servers waren zo stabiel dat dit gelukkig ook nooit nodig is geweest.
Ceph-cluster
Het was door de beperkte redundantie van nfs tijd om daar vaarwel tegen te zeggen. Dat hebben we eind 2016 gedaan door een Ceph-cluster in gebruik te nemen. In plaats van twee 2U-servers neemt deze oplossing wel significant meer ruimte in. In totaal bestaat ons Ceph-cluster uit negen servers, drie daarvan hebben de 'monitor en management' rol gekregen en de overige zes zijn de storagenodes.
Voor elk van deze storagenodes hadden wij zes ssd's van 1,2TB op de planning. Dit stond ook zo in de offerte van de serverfabrikant. Helaas belde de fabrikant ons op om te vertellen dat deze ssd's niet leverbaar waren voordat ze hun kwartaal afsloten en of we het heel erg vervelend vonden als we de 1,6TB-uitvoering van deze ssd's voor dezelfde prijs kregen. Dat was natuurlijk niet wat we besteld hadden, maar ondanks dat gingen we daar schoorvoetend mee akkoord.
Dit Ceph-cluster draait nog steeds en exporteert via CephFS een posix-compliant filesystem aan onze servers en tegelijkertijd verzorgt hij via rbd vm-images aan onze vm-hosts. Helaas heeft heel af en toe een server moeite met het bereiken van het filesystem waardoor die ene server dan tijdelijk wegvalt. De loadbalancers zorgen er dan voor dat dit voor een gebruiker vrijwel niet merkbaar is.
Twee van de negen Ceph-servers - met ruimte voor uitbreiding
Zoals vanzelfsprekend is de verbinding naar de buitenwereld en de servers onderling van cruciaal belang. Je hebt weinig aan drie racks vol servers als je de site alleen kan bezoeken door naar het datacentrum te gaan en je laptop direct met de servers te verbinden. Ook is het wel handig als de servers elkaar kunnen bereiken; een webserver die niet met de databaseserver kan praten heeft niet zoveel te vertellen aan zijn bezoekers.
100Mbit/s
De allereerste switch in ons eigen netwerk was een 8-poorts 3Com OfficeConnect-switch. In die tijd van zelfbouwservers hadden de meeste moederborden geen netwerkpoorten en moesten wij losse netwerkkaarten in de servers installeren. De 3Com-kaarten die wij daarvoor gebruikten gingen met enige regelmaat stuk dus we zorgden voor een extra voorraad. De servers zelf waren voor internettoegang verbonden met een switch van Vuurwerk en die hadden weer een uplink van 644Mbit/s met internet.
Omdat het serverpark snel groeide waren de 8 poorten van de 3Com-switch al snel niet meer genoeg en stapten we over op drie 'nieuwe' switches, twee van Micronet en een LevelOne-switch. Ook deze switches waren nog 100Mbit/s omdat snellere switches te duur waren. De eerste gigabit-switch in ons netwerk was een cadeau van een sponsor, die samen met de switch ook een aantal netwerkkaarten verstrekte.
1000Mbit/s
Bij de verhuizing van Redbus naar EUNetworks hebben we van de gelegenheid gebruikgemaakt om het interne netwerk ook te vernieuwen. Hiervoor kochten wij twee HP Procurve 2824-switches met 24 poorten die we met twee kabels aan elkaar knoopten. Drie jaar later hebben we deze vervangen door de 2900-versie, die we door middel van twee 10Gbit/s CX4-poorten met elkaar konden verbinden.
In die tijd groeide het serverpark maar door en omdat elke server standaard met twee netwerkpoorten en een remote access-kaart kwam hebben we daar later nog eens twee switches met 48 poorten bij gekocht. Bovendien konden we daardoor alle servers in ieder rek op twee switches aansluiten.
10.000Mbit/s
In 2015 zijn we ook weer druk bezig geweest met het netwerk, eerst hebben we het hele stroomnetwerk vervangen. De oude 'zero-U'-stroomvoorziening zat het netwerkonderhoud in de weg en vervanging moest daarom gebeuren. Toen dit eenmaal achter de rug was hebben we twee 10Gbit/s-switches en firewalls opgehangen. Via onze hoster True zijn deze switches met behulp van twee 10Gbit/s-kabels verbonden met de rest van internet.
Al deze verhalen brengen ons uiteindelijk tot drie (half) gevulde serverracks, die zijn verspreid over twee locaties; EUnetworks en Telecity 3.
We hebben onze redundant opgestelde servers vooral over de twee locaties verspreid, zodat alle soorten voorzieningen blijven werken als een van de twee locaties uitvalt. Maar als we van een bepaald type server meer dan twee hebben, dan wordt het grootste deel bij EUnetworks geplaatst. En in dat geval worden ze over die twee racks verspreid, zodat we zo min mogelijk last hebben van de uitval van een switch of stroomvoorziening.
Het is al weer even geleden dat we foto's van de racks toonden. Dus bij deze hebben we ook nieuwe foto's gemaakt van de racks en de daarin gestalde servers.
Van links naar rechts: racks H23 en H24 bij EUnetworks en het rack bij Telecity
H23 EUNetworks
Dit rack is een van de twee racks die staan bij EUnetworks, het zijn zelfs nog de originele racks waar we ruim twaalf jaar geleden naar toe verhuisden. Tegenwoordig staat het daar een stuk voller dan op die foto's.
Helemaal bovenin is onze 10Gbit/s-netwerkswitch te zien, met daaronder de Fortinet Firewall die de heel erg vervelende users buiten moet houden. Aan de achterkant van het rack zijn nog vier pdu's, twee Cisco-switches en een managementrouter te vinden. Aan de voorkant zie we wat servers betreft:
Server
Taak
CPU
Geheugen
Disk
web3
webserver
2x Xeon 6132 (2,6GHz, 14C)
64GB
1x 200GB ssd
damia
devserver
2x Xeon E5-2630v3 (2,4GHz, 8C)
128GB
4x Samsung 350 Pro 1TB 4x Samsung 860 Pro 2TB
static1
webserver
1x Xeon E3-1270v6 (3,8GHz, 4C)
32GB
1x 200GB ssd
mon1
ceph-mon
1x Xeon E3-1240v5 (3,5GHz, 4C)
32GB
1x 200GB ssd
cronus
vm-host
2x Xeon E5-2630v4 (2,2GHz, 10C)
256GB
2x 1TB hdd
leda
loadbalancer
2x Xeon E5-2623v3 (3GHz, 4C)
64GB
2x 120G ssd 2x 1TB hdd
osd2
ceph-osd
1x Xeon E5-2640v4 (2,4GHz, 10C)
32GB
6x 1.6TB Intel S3510 ssd
osd1
ceph-osd
1x Xeon E5-2640v4 (2,4GHz, 10C)
32GB
6x 1.6TB Intel S3510 ssd
man1
management
1x Xeon E3-1240v5 (3,5GHz, 4C)
16GB
2x Intel S3510 120GB
nosql2
nosql-dbs
2x Xeon Gold 5122 (3,6GHz, 4C)
128GB
2x 400GB ssd
H24 EUnetworks
Dit is ons tweede rack bij EUnetworks. Ook hier vinden we bovenin een firewall en 10Gbit/s-switch. Even daaronder is de Altusen-rackmonitor te zien waarmee we de servers op een toetsenbord en monitor kunnen aansluiten.
Server
Taak
CPU
Geheugen
Disk
db1
dbserver
2x Xeon Gold 6128 (3,4GHz, 6C)
512GB
4x 960GB ssd 2x 240GB ssd
artemis
devserver
2x Xeon E5-2643v3 (3,4GHz, 6C)
256GB
6x 240GB ssd 2x 80GB ssd
web1
webserver
2x Xeon 6132 (2,6GHz, 14C)
64GB
1x 200GB ssd
web2
webserver
2x Xeon 6132 (2,6GHz, 14C)
64GB
1x 200GB ssd
leto
loadbalancer
2x Xeon E5-2623v3 (3GHz, 4C)
64GB
2x 120G ssd 2x 1TB hdd
nosql1
nosql-dbs
2x Xeon Gold 5122 (3,6GHz, 4C)
128GB
2x 400GB ssd
mon2
ceph-mon
1x Xeon E3-1240v5 (3,5GHz, 4C)
32GB
1x 200GB ssd
static3
webserver
1x Xeon E3-1270v6 (3,8GHz, 4C)
32GB
1x 200GB ssd
bacchus
backups
1x Xeon E5-2640v4 (2,4GHz, 10C)
64GB
8x 8TB hdd
osd4
ceph-osd
1x Xeon E5-2640v4 (2,4GHz, 10C)
32GB
6x 1.6TB Intel S3510 ssd
osd3
ceph-osd
1x Xeon E5-2640v4 (2,4GHz, 10C)
32GB
6x 1.6TB Intel S3510 ssd
crius
vm-host
2x Xeon E5-2630v4 (2,2GHz, 10C)
256GB
2x 1TB hdd
TC3 Equinix AMS8
Dit is het rack op onze backuplocatie. Mochten de twee racks hierboven uitvallen dan heeft dit rack in theorie alles om ons snel weer online te krijgen. Deze servers hebben verder gewoon actieve taken in ons netwerk, waardoor we ook zeker weten dat ze goed hun werk kunnen doen.
Hoger in het rack (niet op de foto) hangt een firewall en wat netwerkonderdelen van Quanza Engineering. Omdat het niet altijd heel makkelijk is om servers weer uit een rack te halen, hebben we dat hier al een tijdje niet uitgebreid opgeruimd. Vandaar dat je bij sommige servers de taak 'uit' ziet staan.
Server
Taak
CPU
Geheugen
Disk
mon3
ceph-mon
1x Xeon E3-1240v5 (3,5GHz, 4C)
32GB
1x 200GB ssd
web4
webserver
2x Xeon 6132 (2,6GHz, 14C)
64GB
1x 200GB ssd
narwhal
uit
2x Xeon E5-2623v3 (3GHz, 4C)
64GB
2x Intel S3700 120G
nosql3
nosql-dbs
2x Xeon Gold 5122 (3,6GHz, 4C)
128GB
2x 400GB ssd
stork
uit
1x Xeon E3-1271 v3 (3,6GHz, 4C)
32GB
1x 250G hdd
apollo
dbserver
2x Xeon E5-2643v4 (3,4GHz, 6C)
256GB
6x Intel S3510 800G 2x 1TB sata
lion
loadbalancer
2x Xeon E5-2623v3 (3GHz, 4C)
64GB
2x 120G ssd 2x 1TB hdd
camel
uit
2x Xeon E5-2630v2 (2,6GHz, 6C)
64GB
2x 1TB hdd
camel
vm-host
2x Xeon E5-2630v4 (2,2GHz, 10C)
256GB
2x 1TB hdd
mole 02
uit
1x Xeon E5-2420v2 (2,2GHz, 6C)
32GB
1x 1TB hdd
edge3
webserver
1x Xeon E3-1270v6 (3,8GHz, 4C)
32GB
1x 200GB ssd
mole3
management
1x Xeon E3-1240v5 (3,5GHz, 4C)
16GB
2x Intel S3510 120GB
Dat Tweakers alweer 21 jaar oud is, vieren we graag op zaterdag 5 oktober met jullie: onze trouwe communityleden en bezoekers. Als je een kaartje koopt krijg je toegang tot het feestje in UndercurrentAmsterdam én kun je (bijna) onbeperkt eten en drinken met alle bekenden van Gathering of Tweakers en heel veel bekende en minder bekende gezichten van Tweakers HQ. Het belooft een mooi feest te worden met tal van activiteiten, van bordspellen en videogames tot aan workshops en de beste foodtrucks.
Wat een heerlijk herkenbaar verhaal. Erg leuk om het zo uit een te zetten en te zien hoe jullie en de hardware omgeving groeien.
Draai zelf ook al wat jaartjes mee en ben ook begonnen met de schroevendraaier in de hand.
W.b.t. de cloud ben ik nog weinig tegen gekomen dat het goedkoper is, eigenlijk helemaal niet. Het is vooral gemak maar zoals al eerder aangegeven blijft behalve het hardware onderhoud toch je applicatie beheer bestaan, daar win je weinig mee.
Cloud is inderdaad duurder wanneer je de cloud inzet als een klassiek datacenter. Wanneer je de cloud inzet zoals deze bedoeld is, gebruikmakend van zoveel mogelijk "cloud native" diensten, zijn de kosten flink minder dan on-prem/zelf hosten.
Ik heb nu heel wat migraties naar de cloud gedaan, en dit heeft altijd een kostenbesparing opgeleverd, variërend van ~25% tot zelfs 50% of meer.
Het grote nadeel van zelf hosten is dat je ten alle tijden capaciteit moet hebben voor je piekmomenten, daar je in de cloud gebruik kan maken van automatisch schalen, zodat je altijd precies genoeg resources hebt. In de cloud betaal je wat je gebruikt, schaal je 's nachts af? Dan zullen je kosten ook flink lager zijn.
Daarnaast neemt de cloud heel veel operationele overhead weg, zodat je je kan focussen op belangrijkere/leukere zaken. Niemand wordt blij van hardware failure en schijfjes swappen.
Als je meer wilt weten of wilt sparren over de mogelijkheden binnen de public cloud, stuur me maar een PM.
Dat linkje had ik gevonden idd, maar snap er niet zoveel van als niet serverbeheerder. Wat ik er wel van begrijp: kleine services, opgesplitste functionaliteit zodat als een van die services zwaar belast wordt (bijv. Serveren van een plaatje wat viral gaat) dat je dat dan enorm kan opschalen?
Dat wat je opnoemde klopt inderdaad wel, je begrijpt er dus meer van dan je jezelf eer aan doet
Als je bijvoorbeeld van een brownfield monolithic omgeving naar AWS toe gaat kan je alles 1 op 1 overzetten (lift en shift). Hierbij zul je eigenlijk alleen VMs gebruiken waar dit voorheen fysieke servers, of wellicht al VMs waren. Hierdoor zul je duurder uit gaan zijn aangezien als je compute (CPU en Memory) 1 op 1 van on-prem naar AWS omzet, het veel meer kost. Dit is dan ook niet cloud-native.
Je kan ook de monolith gaan ophakken in kleinere stukjes (microservices), en deze onder andere gaan dockerizen. Hierdoor wordt de "blast radius" kleiner, kan je ontwikkel proces sneller worden, kun je individuele delen van je applicatie afzonderlijk van elkaar schalen en nog veel meer voordelen. Dit is wel cloud-native. Daarnaast kan je gebruik van maken van diensten van AWS (of andere cloud providers) die bepaalde zaken voor jou uit handen nemen. Wanneer je deze diensten gebruikt krijg je praktisch altijd zaken als redundantie, authenticatie, backups etc... er bij in waardoor je deze niet meer zelf hoeft in te regelen. Uiteraard zijn dit soort zaken (vaak) niet gratis. Bij backups betaal je bijvoorbeeld voor de hoeveelheid data, of je betaalt voor het gebruik van de service. Echter als je vergelijkt wat het jou aan uurloon zou kosten aan het zelf bouwen en onderhouden van zulke setups, verdient het zichzelf snel terug.
Het is zeer zeker waar dat AWS (en andere cloud providers) heel snel heel duur kunnen worden. Wanneer je echter mensen met verstand van en expertise met de cloud provider aan de knoppen hebt zitten, is het bijna altijd goedkoper dan zelf alles doen. AWS geeft jou alle tools die je nodig hebt om zo efficiënt mogelijk je cloud omgeving te bouwen, maar je zult deze zelf op de juiste manier moeten toepassen. Zo heeft AWS een "Well Architected Framework" welke 5 pillars heeft: Operational Excellence, Security, Reliability, Performance Efficiency en Cost Optimization (https://aws.amazon.com/architecture/well-architected/). Deze 5 pillars toepassen met de AWS diensten die er zijn kost je minimale moeite versus het zelf on-prem doen/bouwen.
Leuke "sales" talk, maar in de praktijk gaat het niet zo makkelijk. Voor de cloud heb je ook mensen nodig, het beheer van de applicaties heb je ook mensen nodig en voor het ombouwen van de applicaties naar microservices heb je mensen nodig.
Bij ons op kantoor zijn ze al een jaar bezig met het overgaan op de cloud via een Microsoft Partner. Wij komen van een monoliet programma, en werken naar microservices toe. Omdat de oude code zo groot is (in 10 jaar opgebouwd), en er niets mag wijzigen in de functionaliteit is het vrij complex om hier wijzigingen in te maken. De kosten zijn inmiddels een keer zo veel als voordat wij in TWEE datacentra zaten met een met redundante servers. We zijn nog druk aan het timmeren om kosten te besparen op hosting, maar echt "snel" terugverdiend is dit niet. Daarbij zijn de prestaties niet perse beter.
Het is ook zeer zeker makkelijker gezegd dan gedaan. Natuurlijk zal je ten alle tijden mensen nodig blijven hebben, vandaar ook mijn baan als cloud consultant . Echter is het wel zo wanneer je gebruik gaat maken van IaaS en PaaS je veel meer tijd overhoudt om gave dingen te bouwen en het platform te verbeteren.
Wanneer je te maken hebt met een oude monoliet welke enorm veel technical debt met zich meebrengt is het inderdaad lastiger. Echter zal je op termijn toch echt over moeten naar modernere manieren van werken (zoals containers), of je nou naar de cloud gaat of on-prem blijft.
Het belangrijkste met een brownfield migratie is om niet teveel in 1 keer te willen doen. Neem kleine stapjes. Begin met simpele functionaliteit in dockers te stoppen en dat werkend te krijgen. Deze kleine stukjes kun je dan op AWS/Azure/Google/Alibaba gaan draaien. Dan werk je jezelf ook niet meteen enorm in de kosten. Het is natuurlijk erg fijn om alles in 1 grote knal over te kunnen zetten, maar dat is niet realistisch. Dat kost gewoon veel te veel tijd en geld (je zult lange tijd 2 complete omgevingen parallel hebben draaien).
Daarnaast moet je het ook niet zien als een kostenbesparing op korte termijn, maar als een langetermijninvestering. De grootste kosten zitten het in het moderniseren van je applicatie, iets dat sowieso gedaan moet worden. Wanneer dit gedaan is zal een migratie naar de cloud vele malen simpeler zijn (uitzonderingen daargelaten).
Voor een site als Tweakers dat je door de dag heen, en ook door het jaar heen, automatisch kan down en upscalen naar wat er nodig is op dat moment. En dus ook alleen maar betaald wat er afgenomen wordt. Losse databases via iets als https://aws.amazon.com/rds/. Als je het op die manier doet ipv een VPS ergens afnemen die het drukste moment in het jaar kan handlen dan wordt het wel een stuk goedkoper. Vooral als je meerdere servers/Kubernetes clusters etc. afneemt/gebruikt.
Om een heel simpel praktisch voorbeeld te geven, de uitleg hieronder is nogal high level.
Stel je hebt een bedrijfswebsite met statische content , traditioneel draait deze ergens op een server met vaak te veel hardwarevoorzieningen voor wat het moet doen. Bovendien staat die nog eens 24/7 te draaien.
Enter de cloud, met serverless computing kan je ervoor zorgen dat je website letterlijk on demand te zien is , er is geen constant draaiende infrastructuur. Op het moment dat iemand ergens op de wereld je site opent wordt die ad-hoc "gegenereerd".
Dit is natuurlijk veel goedkoper, en dat bedoelt men met de cloud gebruiken zoals het zou moeten, je dumpt niet je statische website op een VM in de cloud, je gaat gebruik maken van wat de cloud kan dat on premise niet '(of minder gemakkelijk) kan.
Er is een verschil tussen Cloud-Native Services and Cloud-Native Applicaties.
De link hierboven van Pivotal heeft het over Cloud-Native Applicaties.
Pivotal zelf is geen Cloud-Native Services, daarvoor moet je bij Azure en AWS zijn.
SaaS versus IaaS, bv. azure-sql versus een SQL server draaien in Azure en Azure-webservices versus een IIS server in Azure.
Maar om dat te doen moet wel je software er klaar voor zijn, en dat is in veel gevallen nog niet zo.
Dat ombouwen gaat bij websites als Tweakers denk ik sneller en makkelijker dan bv. een EPD
klopt, we zijn al 2 jaar bezig met het "clouden" van een medische webapplicatie, en dat begint nu pas een beetje op stoom te raken. Het is een technisch interessant proces, voor zowel coders als beheerders en security teams om de monoliet aan code te verdelen in microservices en die naar Azure te verplaatsen.
Ogenschijnlijk simpele design keuzes die een minder ervaren programmeur 10 jaar geleden heeft gemaakt, kosten nu zomaar maanden extra werk; we zijn vaak weken kwijt om één verborgen afhankelijkheid om te bouwen, voordat we kunnen verplaatsen wat we eigenlijk wilden verplaatsen.
Woest interessant werk, dat wel. Alles wat je aanraakt wordt beter, het is zelfs een flinke uitdaging om zo weinig mogelijk tegelijk te verbeteren
Heb zelf jaren cloud en grote infrastructuur gebouwd, nu ben ik 2 jaar bezig als cloud eindgebruiker in een container platform omgeving. De organisatie heeft op nooit iets anders dan cloud gedraaid maar is nu constant bezig alles van monolitische setups naar containers te verplaatsen. Nu komt serverless om de hoek kijken. Weer een nieuwe stack, sinds ik in 2012 Ben begonnen heb ik constant nieuwe oplossingen voorbij zien komen en geïmplementeerd.
(We hebben allemaal handjes nodig lijkt het, er worden nu zelfs video's naar mij gestuurd om toch vooral in gesprek te gaan)
W.b.t. de cloud ben ik nog weinig tegen gekomen dat het goedkoper is, eigenlijk helemaal niet. Het is vooral gemak maar zoals al eerder aangegeven blijft behalve het hardware onderhoud toch je applicatie beheer bestaan, daar win je weinig mee.
Ik denk dat cloud weinig nut heeft voor tweakers.net, omdat de belasting vrij goed voorspelbaar is, niet bijzonder hoog is en niet extreem varieert (ddos daargelaten - en daar zijn andere oplossingen voor).
[Reactie gewijzigd door BadRespawn op 22 juli 2024 14:57]
Elke cloud oplossing verhuist jouw data naar hun computers. Dus hun hardware. Dat jij er niet rechtstreeks meer mee kan/mag werken, betekent niet dat er geen sprake van hardware meer is.
Daarnaast is het een 3e partij die je in je keten brengt en deze wil gewoon geld zien voor hun geleverde dienstsen /en/of services. Of dat goedkoper voor jou als klant uitvalt, dat valt te bezien.
Ja, qua gemak en schaalbaarheid ziet een cloud oplossing er goed uit. Qua (onvoorziene) kosten en mate van controle, dan word het plaatje al gauw minder rooskleurig. En je bouwt een extra afhankelijkheid in je bedrijfsproces, waar je geen of weinig controle over kosten hebt (afrekenen per tijdseenheid en/of verbruikte resources kan onverwacht oplopen).
Zelf hosten van cloud-oplossingen in een on-premise en/of hybride omgeving klinkt mij dan nog altijd beter in de oren dan full-on cloud.
Maar ja, het blijft altijd een kosten/baten verhaal en iedereen heeft een verschillende mening in welke mate risico meetelt in dat verhaal. Is ook voor iedereen en hun specifieke situatie anders.
Vandaar dat de hosanna zingers voor de cloud net zo min gelijk hebben als de verstokte beheerder. Beter advies is om eerst te gaan rekenen voor jouw specifieke situatie, voordat je word afgerekend.
We (iig ik) zijn nog niet echt overtuigd dat eventuele voordelen opwegen tegen het feit dat het simpelweg een stuk duurder is.
En uiteraard kan je die kosten drukken door je applicatie helemaal anders in te gaan richten... maar ook dat brengt natuurlijk (iig eenmalige) kosten met zich mee.
Kortom, welke voordelen zouden we volgens jou hebben door een overstap naar bijvoorbeeld AWS?
Ik heb bij de vorige server updates van Tweakers al geroepen dat een move naar de public cloud (zoals AWS) absoluut interessant kan zijn en nu ben ik (gelukkig) inmiddels niet meer de enige.
Ik ben van mening dat de kosten die je nu maakt om al die hardware te onderhouden en te beheren niet meer opwegen tegen het gemak van de schaalbaarheid en flexibiliteit van AWS. Denk bijvoorbeeld dat je in de nachtelijke uren wanneer de load het laagst is maar op drie containers (want we ontwikkelen toch inmiddels wel minimaal met Docker in de stack??) kan draaien om de kosten laag te houden en wanneer de dag zich aanbreekt opschaalt tot wat nodig is. Sommige taken kunnen helemaal geoffload worden naar serverless (Lambda) zodat je je alleen nog maar druk hoeft te maken om de code en niet de infra die deze code draait. Databases draaien in Aurora zodat je je niet meer druk hoeft te maken of er nog wel genoeg storage beschikbaar is en binnen een paar jaar kan je die ook volledig migreren naar een Aurora serverless omgeving. Hoef je je ook niet meer druk te maken om het aantal CPU en mem die je database gebruikt want dan schaalt alles automatisch mee met de load. Backups kunnen overigens gemakkelijk multi region (en eventueel multi account) gerepliceerd worden zodat je je ook daar geen zorgen om hoeft te maken.
Uiteindelijk hoeft je je alleen nog maar druk te maken om je eigen code, de rest draait volledig redundant en schaalt automatisch wanneer nodig. Als je dit goed doet zullen de kosten echt niet zoveel duurder zijn er vanuit gaande dat je ook de kosten meeneemt voor alles wat je nu zelf moet beheren.
De kosten die wij maken om de hardware te onderhouden bestaan voor het grootste gedeelte uit mijn salaris, de servers zijn niet zo duur, helemaal niet omdat we er nu 5 jaar mee doen. En omdat ze niet zo duur zijn kunnen we makkelijk wat overcapaciteit kopen en daar onze flexibiliteit mee zijn.
Verder heb je met de cloud juist veel meer kosten, ja natuurlijk kunnen we tussen 01:00 en 07:00 wat servers afschalen, maar de load op tweakers is vrij constant, en dus heeft schalen niet heel erg veel zin. Laten we als voorbeel Aurora serverless nemen. Daar betaal je 0.07$ per ACU hour. Een ACU hour is '1 ACU has approximately 2 GB of memory with corresponding CPU and networking'. Laten we het krap nemen en zeggen dat we daar 25 van nodig hebben (huidge db heeft 512GB ram). Dan zit je op $1,75 per uur. Daarnaast betaal je 0.232$ per 1M write io. Dat halen we ongeveer in een halve dag op de huidge db server dus dat is te verwaarlozen. Dan moet je betalen voor backups, namelijk $0.022 per gb per maand. Alweer een mooi klein nummer, maar met 13TB aan backups zit je dan op $286 per maand. Dan nog de change records, die houden we nu 2 weken bij. Dat kan natuurlijk minder, maar dan zouden we achteruit gaan qua flexibiliteit. Daar betaal je $0.014 per 1 miljoen per uur voor. Dat komt voor ons uit op $1,26 per uur gezien het gemiddelde over de afgelopen 6 maand.
So far zien we alleen nog maar kleine getallen. Het probleem is dat we deze load 24/7 doen want ik reken met de gemiddeldes over de afgelopen 6 maand. Als we kijken naar de kosten per jaar komen we voor de db-instance uit op $15330, de IO komt op $170, de backups op $3432, en de change records op $11037. Totaal zit je dus voor dezelfde features als we nu hebben te kijken naar een rekening van ongeveer $30k per jaar. Als ik vervolgens ons budget erbij pak dan zie ik dat dit ongeveer $25k aan hardware vervangt en $10k aan hosting kosten (grof geschat, en gedeelt met alle andere servers/services) per jaar. Over 5 jaar gekeken kost onze huidige oplossing dus zo'n $75k en de cloud oplossing $150k.
En dat is imo vrij voorzichtig geschat mbt de cloud kosten, want db servers gaan langer dan 5 jaar mee en doen daarna nog andere leuke dingen zoals dev-, test- en bi-databases draaien, iets waar we anders (kortlopende) instancies voor zouden gebruiken.
En qua beheerskosten schiet je er ook nog niet zoveel mee op, in the end zul je nog steeds iemand nodig hebben die weet hou alles inelkaar zit, die de logs eruit kan halen en die ze snapt, die nieuwe dingen opzet (je hebt het zelf al over een dubbele migratie) en die bijhoud wat er allemaal speelt.
En er zijn ook problemen met de cloud, zoals de onmogelijkheid iemand direct te benaderen als er iets fout gaat. Ik heb hier collega's die wel in de cloud zitten wel eens paniekerig door het gebouw zien lopen omdat aws plat lag en ze niemand konden bereiken die iets meer wist.
De cloud heeft zeker ook voordelen, met als allergrootste voordeel de lage startup kosten. Maar die hebben wij allang gehad. Als we Tweakers nu zouden beginnen dan zou dat waarschijnlijk ook volledig in de cloud zijn. Alleen denk ik niet dat Tweakers zijn beginjaren had overleeft in de cloud, want sponsoring was in de beginjaren het middel om te overleven.
[Reactie gewijzigd door Kees op 22 juli 2024 14:57]
Amen dank voor deze uiteenzetting. Ik ben zelf 10 jaar consultant en ben het cloud verhaal zowat helemaal zat.
Het klopt dat een Exchange mailbox in de cloud heel even goedkoper is maar dat is dan ook maar enkel omdat de on-prem gewoon te duur geworden is.
Het rekenvoorbeeld van hierboven geeft je een ruime marge om iemand in dienst te nemen maar daar is management allergisch voor.
Blijft het ongekende gegeven dat je cloudprovider de kosten verhoogt terwijl je kennis al lang ergens anders gaan vissen is.
Ik ben ook gewoon achterdochtig wat data betreft, zit net iets te lang in het vak om eender wie met mijn data te vertrouwen.
Dan heb je de sales die zegt dat je geen lift en shift mag doen omdat je uiteraard zelf kan uitrekenen dat de cloud veel te duur is en je moet optimaliseren, Zit je bij gevolg 2 jaar met consultants van een dagtariefje van 1250 Excl. om je bestaande werkende shizzle om te zetten naar cloud cost optimized maar dat heeft je ook weer 2 huizen gekost.
Voor elke argument Cloud zijn er 5 argumenten tegen en vice versa. Het hele verhaal staat of valt bij de mensen die het implementeren, mijn ervaring is dat on prem mensen doorgaans meer betrokken zijn en bovendien meer kunnen dan die Hyper converged infrastructuur te patchen.
Bij de overheid had je ook on prem mensen die de boel gijzelden enkel Linux en Oracle en niemand die het zelfs wou begrijpen.
Cegeka CEO voorspelde de cloud chaos, komt eraan, iets in Amazon, wat bij MS nog iets on Prem. Bij een hosting provider en weinig kennis van het geheel..... daar valt wat mee te verdienen, het geheel snappen...
Ik begrijp de berekening maar denk dat er wel wat haken en ogen aan zitten. Aurora belooft bijvoorbeeld ook sneller te zijn met dezelfde hardware:
"Get 5X the throughput of standard MySQL and 3X the throughput of standard PostgreSQL. "
Nu zal dit verschil in real-life scenarios natuurlijk niet zo groot zijn maar het kan het wel waard zijn om eens te onderzoeken.
Aurora is eigenlijk sowieso niet te vergelijken met de huidige setup. Het zou interessanter zijn om eens een berekening te maken van de huidige setup tegenover RDS. Vergeet hierbij ook niet om Reserved instances mee te nemen.
Als je hiermee gelijk of lager uitkomt dan de huidige setup is het het zeker waard. Je wint het dan terug in de tijd die je moet steken in onderhoud en het gemiddelde datacenter in Nederland kan niet op tegen de uitvoering en de vormen van High Availability van een AWS region. Lees dit bijvoorbeeld eens: https://aws.amazon.com/ab...ns_az/#Availability_Zones
Dat soort vergelijkingen "3x sneller dan PostgreSQL" vertrouw ik voor geen meter. Dan is mijn eerste reactie "kunst, als je SSD's vergelijkt met HDD's".
Wij hebben zelf een vergelijkbare berekening gemaakt, en ook voor ons is de cloud significant duurder. Evengoed gaan we voor een kleine service mogelijk wel over. High Availability kan soms de meerprijs waard zijn. Maar voor de bulk van onze load is de cloud 2x-3x duurder.
Get 5X the throughput of standard MySQL and 3X the throughput of standard PostgreSQL.
Dit soort cijfers moet ik altijd om lachen. Doet denken aan reclames: nu 3x schoner. Vraag ik me altijd af: 3x ten opzichte van wat?
Hier zeggen ze: 5x ten opzichte van standaard MySQL en 3x ten opzichte van de standaard PostgreSQL. Leuk natuurlijk, maar bedrijven die al een enige tijd met MySQL of PostgreSQL werken draaien waarschijnlijk geen standaard meer, maar hebben die databases al lang afgestemd op hun eigen, specifieke situatie. Waarmee dus de vraag rijst hoe realistisch het is om veel verbetering te verwachten na een migratie naar AWS.
Als je naar de ruwe cijfers kijkt en het bereken hoe jij dat doet dan is AWS zeker niet goedkoper. Dat zal niemand, ik ook niet, onder banken of stoelen schuiven.
Ik had het er net met @ACM ook al over. Heb je echt een database draaien die 512GB aan RAM nodig heeft? Sta daar eens bij stil...dat moet toch stukken efficiënter kunnen!
Dus ja, als je Tweakers 1-op-1 naar AWS zou verhuizen zouden jullie nooit goedkoper uit zijn. Dat is een gegeven.
Totaal off-topic, maar je zegt het zelf al. De grootste kosten voor het onderhouden zit hem in jouw salaris.. ik hoop dat je je realiseert dat jongens zoals jij (en ik) die zelf de hardware beheren over een aantal jaar niet meer nodig zijn en dat omscholing/mee gaan met de wereld nodig is. Software is eating the world.
Daarom neem ik in het voorbeeld ook 1/10 van wat we nu hebben, want met een gelijk blijvend aantal pageviews zul je een gelijke datastroom blijven hebben. Ook neem ik niet mee dat we nu twee databaseservers hebben en dat een gedeelte op de tweede server word ge-offload terwijl ik die server wel in ons budget meeneem. Ik probeer dus juist zoveel mogelijk het gebruik 1-op-1 over te zetten want met een volledige rewrite naar amazon toe hoop ik niet dat ons dat pageviews kost
Daarnaast heb ik collegas hier rondlopen die wel op AWS zitten. Nu is dat (door een hele rits devops/consultant afwisselingen) niet heel erg goed opgezet, maar zelfs met maar 5% van onze pageviews hebben zij een hoger budget voor AWS per jaar dan ons budget voor hosting en hardware.
En dat software de wereld eet snap ik, ik probeer mij zeker up-to-date te houden en zo zijn we dus al over naar 'software defined storage', zijn de loadbalancers tegenwoordig software ipv hardwareappliances, ben ik druk bezig de hele ontwikkelomgeving te dockerizen en houd puppet alle configs mooi consistent.
[Reactie gewijzigd door Kees op 22 juli 2024 14:57]
Gaaf om te horen al die nieuwe ontwikkelingen! Wat voor software loadbalancers gebruiken jullie? HAproxy oid.? En merk je een groot verschil tussen de hardware appliances?
We gebruiken Pulse Secure vtm (voormalig Brocade VTM, voormalig riverbed, voormalig Zeus - bekend van ApacheBench).
Het grote verschil is dat je met hw appliances zo grof veel geld voor pruts hardware neerlegt dat het bijna crimineel is. Zo probeerde een vendor ons een bak te verkopen met een enkele Xeon die toen al 3 generaties oud was en met 8GB geheugen erin. En daar wilden ze zoveel voor hebben dat wij uiteindelijk goedkoper uitwaren door zelf 3 nieuwe dual-cpu xeon bakken met 64G geheugen te kopen. En met de ssl speedups van de nieuwere xeons was die ook nog eens sneller dan de dedicated ssl accelerator in die appliance.
Er zijn genoeg scenarios waar plekken als AWS gewoon MEGA veel duurder is, case en point, 'wij' (waar ik werk) zijn terug gegaan van een gedeelte dat we in de cloud hadden draaien naar eigen servers (racks hadden we al, en het was maar een gedeelte dat in AWS draaide) de kosten van AWS hebben we er in ongeveer een jaar uit door zelf hardware te kopen en de jaren daarna die we er mee kunnen doen is dus 'winst' (die aan onderhoud en misschien upgrades gespendeerd kan worden. Ook heeft AWS bijvoorbeeld nog leuke hidden burst credits op IO die onze performance spikes in de weg zaten, was wel op te lossen: meer geld er tegen aan gooien.. dus cloud.. lang niet altijd interessant voor veel bedrijven als je toch al de staff hebt lopen die onderhoud kan doen, en je toch al rackspace hebt.. en het voordeel van minder onderhoudsuren weegt toch vaak totaal niet op tegen de extra kosten die AWS met zich mee brengt, misschien dat dit op een bepaalde critical mass (misschien als je 10 racks ofzo hebt wel...?) aan servers wel het geval is, maar bij ons totaal niet.
Plus data opslag buiten nederland (afhankelijk waar je zit) is ook niet altijd wenselijk (afhankelijk van de afspraken die je hebt met klanten).
Precies dit dus. Wij zijn van twee racks naar de "cloud" gegaan, en zijn nu weer bezig om terug het DC in te gaan. Nu draaien we hybrid maar wellicht dat het weer volledig on-premise wordt. Onze data mag niet buiten NL staan i.v.m. afspraak met klanten. Daardoor zitten we vast aan Azure of Google.
Wij kwamen al snel tegen performance issues aan, en de enige oplossing op dat moment was geld er tegenaan te gooien. Een andere oplossing is er dan niet zo snel, omdat het meer tijd kost om data weer terug te plaatsen op on-premise servers, dan een VM omhoog te schalen. En dan praten we niet over een paar tientjes . Ik ben gaan walgen van de sales talks die de consultants uitkramen, niets is zoals het voorgeschoteld is, juist het tegenovergestelde.
En er zijn ook problemen met de cloud, zoals de onmogelijkheid iemand direct te benaderen als er iets fout gaat. Ik heb hier collega's die wel in de cloud zitten wel eens paniekerig door het gebouw zien lopen omdat aws plat lag en ze niemand konden bereiken die iets meer wist.
Het kán wel, met een Enterprise support plan. 24/7 een response time van 15 minuten door een senior engineer. Maarja dan hebben we t weer over >$15k/maand
Ik heb hier collega's die wel in de cloud zitten wel eens paniekerig door het gebouw zien lopen omdat aws plat lag en ze niemand konden bereiken die iets meer wist.
Wanneer lag er voor t laatste een complete region uit dan? Dat zal op 1 hand te tellen zijn. Als dingen niet op z'n minst redundant uitvoert over 2 of 3 availability zones doen ze t verkeerd. Daarnaast, als t business critical is dan kun je daar gewoon support voor bellen. Toen we laatst iets aan de hand hadden (diagnostics nodig van de internals van een NAT gateway) hadden we binnen 5min iemand aan de lijn.
De waarheid ligt dus in het midden wil ik ermee zeggen.
offtopic: Onze 2 hosting engineers beheren iets van 200+ omgevingen op AWS met z'n 2-en vrijwel alles lost zich vanzelf op (load balanced, auto-scaling, self healing).
[Reactie gewijzigd door Cartman! op 22 juli 2024 14:57]
De enige 'fout' die je hier maakt is rekenen in instance en 24/7 kosten.
Wanneer je gaat kijken na het statisch hosten van website & content en alles aan elkaar gaat knopen met hulp van dingen als lambda of sqs KAN het er heel anders uit zien.
Hier moet je applicatie wel geschikt voor zijn overigens.
In dat geval betaal je puur voor je opslag + trafic. En per 1M hits op je functie.
Als je daar handig mee om gaat kan het mogelijk een stuk goedkoper zijn.
Nogmaals, je architectuur moet hier wel op aansluiten.
Ook vergeet je voor het gemak ff de stroomkosten van je servers, welke ook niet $0 zijn..
Die zijn bij 2 van de 3 racks - voor ons - wel 0 euro En bij het 3e rack zit het in de standaard fee inbegrepen, dus we betalen niet meer of minder als we een beetje meer of minder stroom verbruiken. Als we fors over de limiet zouden gaan, dan wordt het natuurlijk een ander verhaal...
Dat geloof ik echt niet. Een deel van het onderhoud zou je kunnen schrappen (zeker het installatie en hardware gedeelte). Maar alsnog zul je iemand moeten hebben die zich met operations bezighoud. En ipv dat diegene aan hardware en een OS zit te sleutelen, zit diegene met een cloud console voor zijn neus aan andere knopjes te draaien.
Daarnaast wordt er 1 ding duidelijk niet meegerekend door velen hier: het ombouwen van het geheel naar een cloud omgeving. Om daadwerkelijk gebruik te maken (en kosten beperkt te houden) zul je een groot deel van de applicatie moeten aanpassen zodat deze meer geschikt is voor een cloud omgeving. En grote kans dat tweakers.net niet snel om te zetten is, gezien de applicatie toch wel geschreven is voor een situatie zoals het huidige serverpark. Overigens zie je in het serverpark ook een belangrijke trend: het basisidee is nog steeds hetzelfde als grofweg 10 jaar geleden. Loadbalancers, webservers, database servers en een fileserver. Als je daar al jaren mee werkt, is het toch flink omschakelen naar een cloud oplossing. Zowel qua development als qua operations.
Je haalt bij de cloud zowel de hardware als de host vm laag 'weg', deze valt niet meer onder je beheer. Bij verschillende organisaties betekend dat je een 1+ FTE kan schrappen. Daarnaast kan je, afhankelijk van de applicatie, ook in verschillende gevallen de OS laag schrappen. De database server kan je in iets kwijt als Azure of AWS. In veel gevallen kan je ook van de domain controller en de gateway server kwijt als aparte server, zo zijn er nog tig zaken waarvoor je geen server beheer meer nodig heb.
Natuurlijk doe je zoiets niet van vandaag op morgen, maar doordat de mensen die het beheren vaak er niet op zitten te wachten om hun job te verliezen of anders te gaan werken, gebeurd het helemaal niet. Zo een applicatie helemaal ombouwen is natuurlijk een enorme berg werk en er moet zeker gekeken worden of je niet teveel geld kwijt bent aan het herbouwen van je applicatie en dat het dus niet meer kost dan dat het uiteindelijk oplevert. Das het nadeel van zelf ontwikkelde software natuurlijk. Maar ik vermoed dat men op een gegeven moment (als dat niet al eens is gebeurd) de hele architectuur op de schop nemen. Is dit de meest efficiënte manier om voor de komende 5-10 jaar nog pagina's voor te schotelen...
Voor een organisatie ter grote van tweakers geloof ik niet dat dit een gehele FTE scheelt. Zeker gezien men elders aangeeft dat een enkel persoon het grootste deel van operations uitvoert. Naar een cloud solution overschakelen gaat voor tweakers nooit een volledige FTE schelen, gezien je ook voor het beheer van alle instances en andere cloud ongein tijd nodig gaat hebben.
Ook in cloud situaties is het niet zo dat magisch al je performance problemen opgelost worden. Ook daar moet je expertise voor in huis hebben of halen (of trainen). Vaak wordt gedaan alsof AWS een 'magic accelerator button' heeft om automagisch meer instances te starten waardoor alles sneller wordt. Echter, dit is juist weer een gecompliceerde set aan instellingen die ook beheerd moet worden. En foute instellingen hier kunnen ook downtime veroorzaken of heel dure grapjes worden.
Uiteindelijk verruil je de ene set werk (sleutelen aan servers en hardware) voor een andere set (sleutelen aan knopjes in een control panel). Het zijn niet exact dezelfde workloads, maar voor beiden heb je expertise nodig. En beiden kosten manuren.
Mijn eigen ervaring met cloud oplossingen is niet al te positief overigens. Bij een oud werkgever van mij hebben we een aantal experimenten gedaan om te kijken of cloud oplossingen een goed idee waren. Een idee hierin was om de opslag van geuploade data naar S3 te gooien, ipv dat zelf op onze eigen servers opslaan. Dit is een tijdje in productie doorgedraaid, totdat AWS hun prijzen veranderde waardoor alles een stuk duurder werd. Toen was het flink goedkoper om bij een VPS boer een VPS met veel storage te bestellen, en hier een cache voor onze S3 buckets van te maken, dan rechtstreeks S3 blijven gebruiken.
Daar bleek uit de urenadministratie dat operations ongeveer 0.5 FTE aan tijd was. De personeelskosten van operations waren ruim lager dan het switchen naar bijvoorbeeld AWS.
Ik denk dat veel mensen hier over het hoofd zien dat cloud een beetje is zoals andere zaken outsourcen. Als je schaal maar groot genoeg is dan wordt outsourcen duur ten opzichte van zelf regelen.
En ja, je kunt een deel van een FTE schrappen. Maar de cloud is niet gratis, daar betaal je niet alleen maar de afschrijving van de apparatuur.
Ik heb nog geen één keer meegemaakt dat moven naar de cloud voordeliger is.. Dus voor kosten hoeven ze het zeker niet te doen. Voor downtime inmiddels ook niet meer.. En komt op.. Het voelt erg hypocriet aan als de "Tweakers" van Tweakers geeneens hun eigen hardware beheren:').
Server kosten 1-op-1 zeker niet, klopt. Maar als je de kosten voor het beheren en vernieuwen mee gaat rekenen kom je een heel eind. Ja ook AWS moet je beheren en vernieuwen, maar de tijd dat je daar aan kwijt ben is denk een factor 10 of meerminder.
Eens. Een site als Tweakers zou, gezien zijn historie, zijn eigen hardware moeten beheren, maar het is in mijn ogen net zo onoverkomelijk als dat we over 50 jaar allemaal autonoom auto rijden. Er zijn/komen gewoon betere manieren.
[Reactie gewijzigd door Tristan op 22 juli 2024 14:57]
Ook ik ben niet bekend met een situatie waarin “de cloud” daadwerkelijk goedkoper was, dat is: een AWS, Google cloud etc. Wij werken doorgaans met een tussenoplossing: VPS afnemen en daar zelf op inrichten.
Het argument dat het beheer zoveel goedkoper is bij een cloud boer is vaak ook kul (zeker als het vergelijkt met een vps schuiver), het werk is niet weg en is nu ook niet veel.
Wij hebben zelf nog een project van een klant “ontcloud” omdat de kosten veel en veel te hoog werden. Oplossing? Een hele dikke VPS die voor een fractie van het geld sneller werkt.
De mooiste oplossing is niet altijd de beste, daarnaast ben ik geen fan van een vendor lock in op architectuur niveau of überhaupt nog een afhankelijk van iemand anders.
*ik weet dat een VPS ook als cloud kan worden gezien (someone else’s computer), hier wil ik echter onderscheid maken tussen een hippe autoscailer of simpele host.
Onoverkomelijk voor het gross: Eens... Maar net als dat je dan hobbyisten zal hebben die lekker (net als nu) aan "Oldtimers" aan t sleutelen zijn... Vind ik dat een site als tweakers dan ook hun eigen hardware zou moeten beheren over 50 jaar, want de oorsprong was toch ook lekker hobby-istenenenen... Maar is natuurlijk maar een bescheiden mening
[Reactie gewijzigd door Clarissa op 22 juli 2024 14:57]
We hebben het hier over tweakers. Daar werken mensen met verstand van zaken. Mensen zoals ik die een website hebben en eraan verdienen maar geen enkel verstand hebben van een inrichting onderhoud etc. Hebben dan wel voordeel aan cloud. Want deze wordt over het algemeen managed. Ja het is duurder maar betaald zich wel terug
Hoe vaak doe je dit soort trajecten dan, en waarom doe je het dan fout? Als je enkel VMs naar de public cloud aan het slepen bent, dan zul je inderdaad weinig voordeel trekken.
Het enige wat ik zie is alsmaar duurder wordende "services". Waar de service vooral meer eigen salaris is.
Steeds minder zelf doen en huren kan gewoon niet goedkoper zijn.
Persoonlijk vind ik het jammer dat een site als Tweakers niet zijn eigen servers bouwt. Ik snap het wel, maar het past natuurlijk wel gewoon bij de site (of paste).
De focus veranderd. In plaats van het zelf allemaal willen doen, laat je het doen door 1000 man (skilled) personeel van een ander bedrijf. En ja, daar betaal je voor. Maar dat zorgt ervoor dat jij je kan richten op de dingen die er echt toe doen. En in het geval van Tweakers is dat de content en de community onderhouden.
Noem het maar mijn ego, maar die 1000 man skilled personeel zijn allemaal niet zo goed als ik. Hoe vaak er wel niet 'experts' bij ons over de vloer komen die je binnen 10 minuten onder tafel praat is echt zorgwekkend. Dit zijn mensen die van partijen komen met gold/platinum/whatever certificeringen en zouden op zijn minst de basis moeten beheersen. Mogelijk krijg ik straks een -1, maar laat tot die tijd mijn boodschap zijn dat het niet zo is dat je zorgen in de Cloud over zijn. Het enige wat je hebt is een partij die naar SLA’s kijkt, met aapjes met truckjes aankomt en geen gevoel voor jouw bedrijf heeft.
**@Tristan dit is geen persoonlijke aanval op jou, maar ik zie dat je pro cloud ben en reageer daarom op je.
Geen probleem hoor @arnoudx6! Ja, die 1000 man zullen zeker niet allemaal even goed zijn. Maar mijn punt is dat jij in je eentje (lees jouw bedrijf) nooit het werk kan verzetten van wat AWS kan doen.
De was hosting is leuk voor iets als Ticketmaster waar het met enorme kleine doch forse golven qua belasting kan gaan, maar zoals al vaker gezegd heeft Tweakers hier amper last van gezien het enorm voorspelbaar is. Daarnaast, maak is een vergelijking van het serverpark van Tweakers en wat dat kost in de was hosting.... Een vps bij transip was voor mij al goedkoper dan een AWS 100% vooruitbetaalde..... Laat staan kleiner zijn en opschalen on demand wat nog eens een stuk duurder is voor de on demand naast je standaard 100%.
die 1000 man skilled personeel .... die zij er niet voor jouw.
Dus meestal is het ticket openen en heel lang wachten.
Cloud heeft zeker zijn plaats maar zelf hosten ook.Ik krijg het behoorlijk op mijn heupen van de hele meute “cloud-architects” die mensen met een andere visie afschilderen als IT-debielen.
IT-debiel niet, maar IT-mastodont wel. En we weten wat er met de mastodonten gebeurd is
Maar alles staat of valt met de omvang van je omgeving, aanwezige IT kennis en financiën. Ook de arbeidsmarkt speelt een rol: IT personeel is schaars, waardoor werving van nieuwe beheerders en bijbehorende salariskosten een factor is/wordt.
laat mij nou zo'n IT-mastodont zijn: hoewel ik af en toe met bewondering kijk naar wat er allemaal mogelijk is in de cloud, hou ik er toch van om fysiek zaken onder de vingers te hebben. I love the smell of burning CPUs in the morning
Jawel, want die 1000 man ontwikkelen services die mijn 20 of 50 man personeel nooit voor elkaar krijgt in dezelfde tijd. Daarnaast zijn de jongens die achter AWS support zitten ook de jongens die de service ontwikkelen dus in mijn ervaring is deze altijd erg goed.
Steeds minder zelf doen en huren kan gewoon niet goedkoper zijn.
Het is goedkoper je eigen brood te bakken. Waarom koop je dan lunch voor je software engineers en laat je ze niet brood bakken?
Een flauwe vergelijking misschien maar hier komt het wel op neer. Er is niets aan serverbeheer waarmee tweakers zich kan onderscheiden, de content en de community dat zijn de sterke kanten van tweakers.
Daarnaast kan het wel goedkoper zijn vanwege de enorme schaal van aws (of andere providers), zeker als je loonkosten gaat meerekenen.
Misschien simpel. Omdat dat de core van tweakers eigenlijk is. Ik snap dat ze daar allang vanaf zijn gestapt. Maar dat wil niet zeggen dat het niet een beetje jammer is.
Weet je. Ik vind het nog steeds jammer dat we (de meute) geen Winamp en ICQ meer gebruiken maar de wereld veranderd nou eenmaal sneller dan we soms willen.
Natuurlijk kan dat wel goedkoper zijn. Waarom? Omdat de schaal van een Cloudprovider enorm veel groter is. De automatisering erachter veel beter is. Tevens hoef je niet te schalen voor piek belasting.
Een rack huren, servers kopen en de uren die engineers investeren om het allemaal online te houden is ook niet goedkoop.
Aangezien er nog steeds "Hosted by true" hier boven staat heeft Tweakers wellicht wat andere voordelen waardoor zelf hosten goedkoper kan zijn ;-).
[Reactie gewijzigd door Jay-v op 22 juli 2024 14:57]
Het enige wat ik kan bedenken waarom Tweakers nog niet over is op AWS is omdat ze de hosting van het Rack etc gesponsord krijgen. En dan wegen de kosten die ze moeten maken om op AWS te draaien niet op tegen het zelf draaien van de hardware.
Grote cloud providers kunnen veel goedkoper inkopen, hebben veel betere tools om de servers te monitoren en al hun kosten worden over veel grotere aantallen uitgesmeerd.
Voorbeeld: Stel jij hebt nu 1 iemand in dienst om 10 servers te monitoren. Cloud provider heeft ook 1 iemand die er 100 in de gaten houdt. Wie is dan goedkoper?
Computerkracht gaat in de toekomst net zo als stroom/water/gas worden. Het komt gewoon uit een leiding/draad uit de muur.
Voorbeeld: Stel jij hebt nu 1 iemand in dienst om 10 servers te monitoren. Cloud provider heeft ook 1 iemand die er 100 in de gaten houdt. Wie is dan goedkoper? Wat is dit nou weer voor voorbeeld man
Daarnaast: Er zijn voldoende tools om dit goed te kunnen monitoren niet alleen een cloud provider heeft daar toegang toe.
Waarom zou je altijd afhankelijk willen zijn van andere bedrijven als je ook gekwalificeerd personeel in dienst kan hebben? Daarnaast praten de meeste vaak over dit en dat. Maar je wilt toch nooit afhankelijk zijn van een andere partij. En beter je eigen hardware hebben. Zo maak je in de toekomst het alleen makkelijker om afhankelijk te zijn van "de big boys" dan zelf de mensen in dienst te nemen en te trainen.
Cloud is leuk misschien voor een ZZP er die er de ballen verstand van heeft. Maar het echte werk zou gewoon in-house afgehandeld moeten worden ondanks de kosten. Denk je dat cloud gekomen ist door kosten te drukken? Echt niet hoor. Vage business Analisten denken zo.
[Reactie gewijzigd door theduke1989 op 22 juli 2024 14:57]
En aws dat zich iets te breed orie teert. Als true figuurlijk de stekker eruit trekt is Tweakers 1 dag offline en staan de servers ergens anders in een rack.
Als aws de stekker eruit trekt moet jij alles gaan overzetten naar een andere provider wat heel wat meer werk kost.... Daarnaast al vaker gezegd 'de cloud' is bij lange na niet altijd goedkoper, juist duurder en Tweakers heeft eigen skilled personeel die naast onderhoud ook gewoon op de redactie mee werken met hun vakkennis
daarvoor heb je ook oplossingen die niet duur hoeven te zijn. Daarnaast data centers doen al veel aan stroom ( energie zuinig ) etc waarbij de klant minder hoeft na te denken.
je wil alvast niet afhankelijk zijn van 1 provider, dus 2 datacenters die ieder met 2 verschillende paden verbonden zijn met 2 Verschillende internet providers, datacenters ver genoeg uit mekaar.
Classic setup !
[Reactie gewijzigd door klakkie.57th op 22 juli 2024 14:57]
2 breedbandinternet verbindingen, je eigen stroom voorzieningen het wordt steeds uitgebreider enig besef wat het allemaal kost en dat dit niet haalbaar is voor menig MKB bedrijf
Dat, dit aardig wat centen kosten ... absoluut maar we doen dit toch al tijden zo, lang voor iemand het woord cloud in de mond nam.
Dus het is niet zo dat dit uitzonderlijk is en een bedrijf als “de persgroep” kan dit best hebben.
Voor een eenvoudige backup van mijn video data heb ik de rekensom gemaakt en het is binnen een jaar goedkoper om zelf een server in een data center op te hangen dan dezelfde data bij AWS neer te zetten. Dan heb ik het alleen over storage en upload. Zodra de backup een keer nodig is zou ik een kapitaal kwijt zijn om de data te downloaden.
De cloud is makkelijk en prima om mee te starten. Zodra je serieuze hoeveelheden data gaat verschepen wordt het al snel goedkoper om zelf servers op te hangen. Als je een wereldwijd CDN nodig hebt kan het nog handig zijn maar daar is zijn ook managed oplossingen voor.
Waarschijnlijk heb je gelijk. Los van of je de goedkopere storage varianten mee berekend heb of niet. Ik heb niet de illusie dat AWS op pure kosten goedkoper gaat zijn. Echter weegt dat voor mij niet op tegen de enorme flexibiliteit en heavy lifting die het platform met zich mee brengt.
De goedkope varianten heb ik ook naar gekeken. TB's aan data opslaan kost veel geld en dan ook nog eens veel geld om die backup een keer te downloaden. AWS heeft S3 maar ook Glacier, lijkt goedkoop tot je 10TB gaat opslaan en een keer wil downloaden.
Backbase is per GB niet heel duur maar upload met 10Mbit/s. Dat schiet niet op en ook dan gaan de hoeveelheden weer meer tellen.
Al dat beheer moet je ook bij de cloudproviders doen dus daar ga je niet veel op besparen.
Bij een vorige baan gingen we naar Azure toe met een applicatie waar ik aan werkte. Toen Azure net nieuw was en we gebruikten applicatie hosting dus geen VPS. Na een maand kreeg ik de vraag waarom de rekening zo hoog was. Van de rekening van die maand hadden we ook een server kunnen kopen. Je hebt er natuurlijk meer nodig maar er zitten meer maanden in een jaar en een server gaat meerdere jaren mee.
En laten we wel wezen 10TB is nog wel te overzien , maar 2PB backupstorage loopt helemaal in de papieren en dan hebben we het nog niet over de dedicated unmetered 10Gbit link naar AWS of Azure, want je wil natuurlijk niet je backupstorage bij dezelfde cloudprovider hebben. .. 50K per maand
Een redundante 10Gbit layer 2 verbinding tussen 2 datacenters kost nog geen 10de
[Reactie gewijzigd door klakkie.57th op 22 juli 2024 14:57]
Wat betreft kosten is het veel makkelijker de juiste hoeveelheid cpu in te slaan, dat scheelt je dus ongebruikte capaciteit waar je nu voor betaalt en als je load te laag inschat downtime of trage service. Hoewel je normaal per minuut betaalt kan je ook compute voor 1 a 3 jaar reserveren tegen kortingen tot 70%. Het is maar de vraag of je wel duurder uit bent, als je een beetje bewust met je resources omgaat zou je weleens kunnen besparen.
Belangrijker echter is dat je ineens tijd vrijhebt om je met andere zaken bezig te houden want het beheren van je servers doe je danniet meer en het beheren van de cloud is echt een stuk minder werk. Daarnaast heb je beschikking over allerlei diensten die op dit moment waarschijnlijk teveel investeringen kosten. Denk bijvoorbeeld aan machine learning, big data etc.
EDIT: ook voor meer gebruikelijke services werkt de cloud drempelverlagend. Bijvoorbeeld een managed redis (elasticache) heb je zo deployed, er is een mysql die met load meeschaalt (aurora), cdn voor static files (cloudfront), load balancers sluit je zo af en mocht je zien dat je s nachts veel minder verkeer hebt dan kan je je vloot aan cpus dynamisch terugschalen. Kortom je bent zoveel meer flexibel, hier ga je je echte winst behalen.
Ik zou zeggen maak eens een accountje aan op aws, je krijgt het eerste jaar voldoende gratis resources in de free tier om development versies van tweakers te deployen en je hoeft echt niet alles gelijk naar serverless te refactoren om een feel te krijgen voor hoe het werkt.
[Reactie gewijzigd door Antipater op 22 juli 2024 14:57]
Een simpel voorbeeld voor die kosten is onze databaseservers. Als we die ongeveer namaken in AWS (en dan was ie destijds alsnog een stuk minder krachtig), dan kom je met een reserved instance voor een jaar ongeveer uit op de eenmalige aanschafprijs.
In onze inschatting is het dan ook alleen mogelijk om met vergelijkbare of lagere kosten uit te komen als we wel al die inspanning gaan verrichten om zo efficiënt mogelijk gebruik te maken van de diensten van AWS.
Jij en anderen lijken te denken dat we heel veel tijd kwijt zijn met het beheren van de servers.
In werkelijkheid gaan die het rack in (gemiddeld zo'n 4 a 5 per jaar), worden aangezet en dat is zo'n beetje al het hardware-onderhoud dat er is... soms gaat er iets stuk en moeten we wat moeite om bijvoorbeeld een disk of geheugenmodule te vervangen of om een engineer van Dell langs te laten komen.
Af en toe is een reboot nodig voor een os-upgrade, soms moet er wat aan de services worden geknoeid en dat is het wel. Het gros van het onderhoud dat onze ene 'devops'-persoon doet zit vooral in beheer van de loadbalancerconfiguratie, dns, inrichten van databases en services, etc. Waar misschien tijdswinst op dat vlak te behalen valt, is dat onze centrale storage relatief veel onderhoud vergt.
Maar het gros van die taken blijven bij AWS simpelweg bestaan of worden vervangen door equivalente taken; zoals het uitwerken en beheren van al die hippe features als auto-scaling
Ik zou zeggen maak eens een accountje aan op aws, je krijgt het eerste jaar voldoende gratis resources in de free tier om development versies van tweakers te deployen en je hoeft echt niet alles gelijk naar serverless te refactoren om een feel te krijgen voor hoe het werkt.
Ik geloof heus wel dat we onze huidige docker-containers in AWS werkend krijgen. Maar in dat voorstel werkt het ruwweg hetzelfde als onze huidige development-omgeving en zien we die voordelen dus effectief niet
Maar de truuk in AWS is dat je de resources niet 1-op-1 moet vergelijken. Heb je echt zoveel RAM en CPU nodig? Kijk eens kritisch naar je DB schema. Kan je bepaalde tabellen niet migreren naar een NoSQL zoals DynamoDB.
Daarnaast is het "beheren" van hippe features zoals auto-scaling in de regel niet meer dan het aanzetten.
[Reactie gewijzigd door Tristan op 22 juli 2024 14:57]
Nee dat kan vast allemaal anders, vandaar ook de tweede helft van mijn eerste alinea
Maar dat veranderen vergt natuurlijk wel een forse inspanning, tijdens welke we weinig anders kunnen doen. Want alle code die nu met die data werkt, moet dan aangepast worden.
Bovendien is DynamoDB ook niet gratis om te gebruiken.
Ik heb niet alleen positieve dingen over auto-scaling gehoord bij collega-sites die wel op AWS zitten. Veel meer dan dat kan ik niet zeggen, omdat ik ook niet veel meer dan dat gehoord heb. Maar er zijn o.a. wat issues rond dat je misschien wel helemaal niet wil dat het bij oneindig stijgende load ook oneindig blijft doorschalen en dus op een gegeven moment serieus duur kan worden.
Die maxima kan je vast instellen, maar moet je dus ook instellen en zo nu en dan tunen (en dus monitoren). Verder moet je natuurlijk wederom alle code die daarvoor relevant is aanpassen en blijven onderhouden.
Het allerbelangrijkste argument wordt hier natuurlijk vergeten... Het is gewoon tof om zo nu en dan je te vergapen over nieuwe dozen, beetje sporten om die net te zware unit boven je macht in het rack te prutsen. Bloed op de datavloer morsen. Dit gaat wel over tweakser.net !
Klopt helemaal. AWS werkt pas optimaal als je hele omgeving daarvoor getuned / aangepast is.
Vwb auto-scaling. Ja de sky (of eigenlijk je bankrekening) is de limit. Eens.
Ookal pas je alles aan en heb je minder resources nodig moet je niet alleen kijken naar de AWS omgeving maar ook in house, dan heb je dus in house ook minder resources nodig wat dus weer goedkoper is. Het werk daarentegen wat je moet investeren om dit mogelijk te maken is onbetaalbaar. Dit heb je niet in een paar maanden gedaan. Ik begrijp uit je reacties dat je fanboy ben van aws, maar het is simpelweg niet goedkoper dan in house.
Onbetaalbaar? Dat is wel héél duur.. en onrealistisch Ik heb ook niet gezegd dat de transitie naar AWS in een paar maanden gedaan moet zijn. Tweakers kan natuurlijk in kleine stapjes en beetje bij beetje migreren.
Eerst en vooral doe je een heleboel aannames zonder de werkelijk “case” te kennen.
Als uit hun metrics blijkt dat de databaseserver zo geschaald moet zijn. Daarenboven wat Is nou 512GB memory , kost haast niets meer.
Die verandering op zich, manuren, zul je ook moeten terugverdienen. Een beetje consultant (zoals je wel zult weten) 150e/u, dat loopt snel op.
Dus waarom iets veranderen dat gewoon werkt ?
[Reactie gewijzigd door klakkie.57th op 22 juli 2024 14:57]
Natuurlijk, ik heb geen idee hoe Tweakers het allemaal precies doet. En ja ik weet ook dat 512GB Ram geen drol meer kost, maar daar gaat het niet om. Mijn punt is dat als je efficiënt in de cloud wil opereren dan zijn grote monolithische setups verre van ideaal en dus ook een database met 512GB ram.
Fair enough. Natuurlijk is het zo dat een migratie zelf ook tijd kost, en je hebt nu eenmaal zowel de hardwarde als de skillset om op je eigen servers productief te zijn. Gecombineerd met een stabiele load en ik snap best dat je skeptisch bent.
Gewoon on-demand servers huren op AWS is immers ook een kostbare aanlegenheid met relatief weinig voordelen als je reeds goed bezig bent op je eigen metaal. Mocht je toch af en toe wat extra compute nodig hebben zou je ook naar onze buren in Duitsland kunnen en iets van Hetzner cloud afnemen, dat is significant goedkoper.
Goed om te horen dat jullie hier over nagedacht hebben, een onbezonnen migratie is natuurljik niet verstandig want elke situatie is weer anders.
[Reactie gewijzigd door Antipater op 22 juli 2024 14:57]
Ik vraag me af of het een stuk duurder is.
Door slim om te gaan met resources , wat zeker met een Nederlands platform mogelijk moet zijn, kan je kosten drukken.
Dwz vanaf 22:00 tot 07:00 op minder capacaciteit draaien. Datalayer is hierin waarschijnlijk de grootste uitdaging.
DTA spin je alleen op als je het nodig hebt omdat je je volledige infra geautomatiseerd (on demand) uitrolt.
Winst wordt niet alleen bepaald door financiele elementen en operationele kosten.
Het zit in ontwikkeltijd en flexibiliteit in je ontwikkelproces, faciliteiten voor blue-green deployments en a/b tests, en in zijn algemeen borging van kwaliteit door inzet van infra as code principes.
Misschien ben je onder de streep wel beter af met een hogere rekening
Dat er investering nodig is, is duidelijk natuurlijk
Gezien de grootte van Tweakers, en de mogelijkheid om zelf in-house expertise aan te houden denk ik dat private cloud alleen maar een stap achteruit is. De ruimte om zelf te blue-greenen of een hele dev-straat aan te houden is er, en de mogelijkheid om als het echt nodig is handmatig een server een corrigerende tik te verkopen is iets dat ik heel erg mis bij de (private) cloud. Het is echt someone elses computer, en dat betekent verminderde opties. Het feit dat je alles via een derde partij moet doen is en blijft een beperking, hoe hard ze ook proberen niet in je weg te zitten.
Dus ja het zal als het goed loopt een paar euro besparen, maar als het niet goed loopt ben je er langer mee bezig, en niks is frustrerender bij onverwachte downtime dan een ticket inschieten en maar wachten tot een externe helpdesk-sukkel je gaat vragen of je em al aan en uit hebt gezet, want hij mag de daadwerkelijke sysadmin pas inschakelen nadat zijn schriptje afgewerkt heeft.
Als je een goed beheerteam en een duidelijke strategie hebt dan is zelf aanschaffen van servers en die in een DC hangen nog steeds goedkoper dan het hosten in de cloud. De kosten voor zware servers lopen hard op in de cloud (zie de nosql server met 128GB ram, die gaat sowieso over de €10000 per jaar heen, als het al niet 15k of meer is) waardoor je na pak em beet 2 jaar een heel aardige server had kunnen kopen die je in 5 jaar afschrijft. Voor een site als Tweakers gaat egress waarschijnlijk ook hard in de papieren lopen.
Niet dat hosting in de cloud slecht is, in tegendeel zelfs maar het is sterk afhankelijk van het gebruiksscenario.
Je hoeft natuurlijk ook niet alles naar de cloud te brengen. Een enkele service in een autoscaling group kan wonderen doen voor bijvoorbeeld near realtime doorrekeningen op grote hoeveelheden data (berekeningen die nu batchmatig 1x per dag tussen 03:00 en 05:00 uur uitgevoerd worden oid). Mits je daar behoefte aan hebt natuurlijk 😁.
Een migratie alleen omdat het cool is natuurlijk niet te verantwoorden 😋 Cloud is geen "silver bullit", maar heeft features die mogelijkheden biedt.
Een volledige overstap naar (public) lijkt mij niet de beste oplossing. Het is al een paar keer aangehaald maar de kosten bij veel netwerkverkeer kunnen stevig oplopen.
Wel kan gekeken worden naar specifieke workloads en middels bijvoorbeeld VMware Cloud Foundation deze workloads eenvoudig verplaatsen zonder dat de management tooling veranderd.
Als je een beetje zoekt door de geschiedenis dan zul je merken dat deze opmerking regelmatig terugkomt en men telkens tot de conclusie komt dat het te kostelijk is en geen voordeel oplevert.
En je kan ook niet gaan vragen of een cloud aanbieder wil sponsoren, want wat als je dan wat te kritisch bent over die aanbieder in een bericht?
Het is ook niet alsof er met cloudoplossingen nooit problemen zijn, die zijn er ook. En dan heb je de oplossing ineens niet meer in eigen handen.
Klopt, dit is zeker niet de eerste keer dat ik deze discussie met @ACM voer En elke keer komen "de kosten" weer als voornaamste reden naar boven. Die in mijn ogen nog steeds opwegen tegen de voordelen die AWS in dit geval biedt aan de hele ontwikkelstraat van Tweakers.
Zelfs als de kosten lager zijn, waar ik gewoon op basis van @ACM reactie (met een toefje van eigen ervaring erbij) NIET vanuit ga. Wie zegt jou dat, dat volgend jaar nog steeds zo is? En dat AWS de prijzen niet met een factor 10 indexeert? En tegen die tijd zit je zo vast in het stramien van AWS dat je geen keus meer hebt. Hosting is duur, vendor lock in is duurder.
[Reactie gewijzigd door Ed Vertijsment op 22 juli 2024 14:57]
Ik noem er zo even een paar. De elasticiteit of schaalbaarheid. Je kan extreem flexibel met je resources omgaan. Alle heavy lifting zoals off-site backups komen standaard en hoef je niet lang over na te denken.
Accountability, wie heeft wat gedaan zit standaard ingebakken. En dan natuurlijk de voordelen van serverless waarmee je je helemaal niet meer druk hoeft te maken over resources maar alleen om je code.
Wat heb je aan die elasticiteit als de load blijkbaar (zie andere reacties auteur) vrij stabiel is.
Eens: zat toepassingen waar cloud veel voordelen biedt, maar niet altijd.
De stugheid waarmee je keer op keer hetzelfde zegt doet me denken dat je AWS salesboy of minimaal fanboy bent..
Je punt heb je duidelijk gemaakt.. laat het daarbij
In dit geval op dat vlak niet heel veel, klopt. Maar er is zoveel meer wat wel toevoegt.
Wat maakt het jou uit dat ik veel met AWS werk en de voordelen daarvan graag kenbaar maak? Zoals je ook kan lezen hier hebben veel mensen nog geen weet van wat de cloud hun kan brengen. Het is een eeuwige discussie die altijd voor en tegenstanders blijft houden. Ik ben een voorstander, prima toch?
[Reactie gewijzigd door Tristan op 22 juli 2024 14:57]
Leuk artikel. Wat was de oorzaak dat de site down ging een paar dagen geleden, zelfs met al deze redundancy?
En wat doen jullie qua monitoring? En hoe zijn de huidige uptimes?
De oorzaak dat de site plat lag was omdat alle drie de mongodb instanties binnen een half uur van elkaar keihard crashten. Daardoor werd de load op de database te hoog en trokken alle webservers zichzelf vol.
Qua monitoring gebruiken we nu (een behoorlijk aangepaste) Zabbix en daarnaast loggen we bijna alle logs naar Graylog toe.
Uptimes zijn niet heel erg belangrijk, ik reboot met enige regelmatig een server (zonder dat iemand daar last van heeft). De hoogste uptime dit jaar was een VM instantie bij Leaseweb die ik vergeten was (en die niet meer gebruikt werd). Die had een uptime van zo'n 1500 dagen.
Onze drie mongodb servers crashten binnen een half uur van elkaar. De frontpage cache staat hier ook in, waardoor de load op mysql te hoog werd en alles uiteindelijk down ging. Een fix releasen werd daarbij ook nog eens bemoeilijkt door ons deploy script, omdat er allerlei checks faalden.
Wat gaan we doen om dit te voorkomen in de toekomst:
- Een extra cache laag op de frontpage toevoegen. Deze hadden we vroeger, maar is met een refactor verdwenen.
- Emergency deploys kunnen doen, zonder dat er allerlei checks gedaan worden. Als de site plat ligt, heeft het weinig nut om dat allemaal te doen (stukker wordt het niet )
- Betere logging/monitoring
Daar bewaar ik dingen in als schroevendraaiers, tangen, wat kabels (netwerk, stroom, video), oordoppen, kooimoeren en bouten, tiewraps, casebadges en wat velcro.
Dan hoef ik niet perse eerst langs kantoor als ik erheen ga, en als ik wat vergeet mee te nemen dan hoef ik niet perse eerst weer terug naar kantoor.
Dat is een storagebox. Daar kan van alles in zitten, reserveonderdelen, installatie media, gereedschap of bijvoorbeeld de wietvoorraad van de tweakerscrew.
Het is niet ons gebouw, dus niet ons dak. De servers staan in racks in datacentra die aan diverse klanten tegelijk hun diensten aanbieden. Ik betwijfel echter of die daken groot genoeg zijn om een noemenswaardig verschil te maken met zonnepanelen ivt hun energieverbruik. Bovendien zitten de daken zo te zien aardig vol met allerlei (koel)installaties
Het is lastig te vinden, maar vziw gebruiken zowel Equinix als EUNetworks duurzame energie.
We doen verder geen hele grote moeite om de zuinigste servers uit te zoeken. Ze moeten tenslotte vooral ook voldoen aan de technische eisen die de belasting de komende 3-5 jaar aan ze stelt en we hebben ook niet de mankracht om allerlei experimentele systemen uit te proberen waarvan het maar de vraag is hoe goed de door ons gebruikte software erop werkt.
Gelukkig gaat het deels ook "vanzelf"; iedere keer dat we een van die machines met 12-15 harddisks konden uitzetten gaf dat een mooie daling in het energieverbruikgrafiekje
En ondertussen hebben vrijwel al onze servers ssd's en worden de andere componenten steeds een beetje efficiënter.
Equinix gebruikt inderdaad duurzame energie. Het dak van de datacenters wordt voor een aanzienlijk oppervlak gebruikt voor de koelingssystemen en hoewel er ruimte is voor wat zonnepanelen is het echt een druppel op de gloeiende plaat. Kijk eens op Google Maps
De MegaWatts verbruik terugdringen met zonnepanelen vereist een gigantisch oppervlak aan zonnepanelen.
Daarnaast is stabiliteit van de energievoorziening vele malen belangrijker dan besparing. En dat is nog wel een uitdaging met zonnepanelen.
En dat is nog wel een uitdaging met zonnepanelen.
Wat is dat voor onzin?
Geen datacenter, bedrijf of huis dat zonnepanelen in Nederland heeft die niet is aangesloten op de reguliere stroomvoorziening. Dus stabiliteit heeft er niks mee te maken.
Het gaat er niet om dat het niet kan, maar omvormers e.d. kunnen hooguit gezien worden als risico voor de voorziening, omdat ze echt niets bijdragen aan de energiebehoefte van een datacenter.
Het heeft hooguit zin voor het kantoorgedeelte, afhankelijk van de locatie.
Dank voor het uitgebreide antwoord! Ik snap dat het niet makkelijk is. Wat is het verbruik eigenlijk in energie? Er zijn wel providerz zoals de bron die duurzaam zijn. Succes!
We gebruiken zo te zien gemiddeld 7,04A en 9,21A bij de twee racks bij True. Wat het derde rack gebruikt weet ik niet, maar zal vergelijkbaar zijn met het eerste.
Als het zo simpel is als A*I = W (en dus zaken als 'power factor' negeert), dan zou dat neerkomen op een continu verbruik van zo'n ((7,04 + 9,21 + 7,04) * 230 = ) 5.400W of 129kWh per dag.
Met 30 servers, nog wat switches en andere apparaten die continu aan staan is zo'n verbruik niet eens heel onrealistisch, maar of het precies klopt weet ik niet
Marktplaats is bijvoorbeeld verkocht voor een astronomisch bedrag aan e-bay. Allemaal te lezen op wikipedia.
En kosten ach die waren wel te dragen. Soms durf kapitaal van iemand die er de ballen verstand van had. Maar wel een gokje wilde wagen. En dan er vroegtijdig uitstappen en een paar ton mislopen.
Succes is nooit het doel geweest. Toen keek men heel anders tegen het fenomeen internet aan. Het waait wel over. Nou niet dus. Het grijpt steeds dieper in op ons leven en zijn.
Zo ook anno nu weer. Want al die retour zendingen nekken de meeste bedrijven.
Daar heb je op Tweakers gelukkig geen last vast van. Maar wel weer van andere problematiek.
Het blijft mensenwerk ook al is het virtueel.
[Reactie gewijzigd door pentode op 22 juli 2024 14:57]
Ja, de bedenker geestelijk vader van z'n kindje Marktplaats, spreekwoordelijk gezegd, is na verkoop ook met vervroegd pensioen gegaan.
Wil ook absoluut niet in de publiciteit komen. Was uitgenodigd bij VPRO zomergasten maar heeft subiet geweigerd hier aan mee te werken.
Wel jammer het had onder andere een aardig kijkje in de keuken kunnen opleveren, imho.
Grappig, Tweakers draait nu op twee 6-core Xeon cpu's die 2 jaar geleden samen 3500 euro kosten. Nu zijn ze samen langzamer dan een 12-core AMD 3900X van 550 euro.
Dus je zal op zijn minst met de Epyc moeten vergelijken. En als je - zoals wij - een voorkeur voor snelle cores hebt, ipv veel langzamere, dan wordt het nog best lastig een goede Epyc-processor te vinden die hier goed mee concurreert. Althans, dat was het toen we deze server(s) samenstelden nog wel.
Ondertussen zijn er wel wat meer interessante Epyc-modellen op de markt gekomen (maar zo te zien nog niet erg goed leverbaar).
Ah, maar zijn die beschikbaar in het soort servers dat wij gebruiken? Bij Dell heb je iig alleen de Epyc als optie. Maar ook de (nieuwe) Epyc is wat minder hoog geprijsd dan de Intel cpu's; maar zoals ik aangaf nog niet heel goed beschikbaar.
Super interessant verhaal! En mooi hoe het gegroeid is door de jaren heen.
Sinds 2001 trouwe Tweaker en weet nog dat ik in het begin domme vragen stelde over het maken van scriptjes met als antwoorden 'zoek het zelf eerst maar uit' , en gelijk hadden ze.
De Tweakers server opstelling is toch wel erg strak. Het helemaal in eigen beheer hebben is natuurlijk ook wel fijn. Op de volgende 21 jaar!
Super interessant verhaal! En mooi hoe het gegroeid is door de jaren heen.
Dit verhaal is pas het begin. In aanloop naar de verjaardag komen we met nog een paar geschiedenisverhalen, met als kers op de taart komende week een gesprek met de drie oprichters van Tweakers: Floris, Daniël en natuurlijk Femme. Dat kun je gaan luisteren als podcast, zien op YouTube én lezen als artikel. Het was bijzonder om ze alledrie bij elkaar te hebben en ze te spreken over hun ervaringen uit de begintijd van Tweakers. Ik denk dat zelfs gebruikers van het eerste uur nieuwe dingen gaan horen
En voor de rest: ik denk niet dat we een tweede uur-durende-podcast-met-video gaan maken in een week; het kost best wat tijd in voorbereiding, opname, editing etc en dat zou ten koste gaan van andere dingen.
Maar: ik was van het weekend op de MoaM en enkele moderators hadden daar leuke ideeën voor andere podcastformats. Ik heb dat op de redactie overlegd en er is interesse voor om dat te gaan maken. Ik ga het dus even uitwerken en dan gaan we kijken of we dus in elk geval meer met audio kunnen doen dan nu. Stay tuned!
Ik ga zeker luisteren! Oa de Tweeakers podcast maakt de rit van Groningen naar Leeuwarden een heel stuk aangenamer.
En ik begrijp dat een 2 uur durende podcast niet haalbaar is. Misschien moet het ook niet willen. Het is nu zo voorbij en anders is het misschien ook wat overkill. Podcast-specials zo nu en dan lijkt me wel leuk.
Ben benieuwd naar de podcast Ik vind jullie podcasts sowieso altijd leuk om te beluisteren. Soms kijk ik de podcast als video op Youtube. Maar ook met grote regelmaat luister ik hem in de auto via Spotify.
Gefeliciteerd!!!
Is het weer 21 jaar geleden, tijd gaat snel. Super leuk om te lezen met welke hardware er begonnen is en wat de techniek nu achter is.
[Reactie gewijzigd door KOEKiEh op 22 juli 2024 14:57]
Het blijft leuk. Zou GoT er over 21 jaar nog zijn?
Ja zelfde hier, zit al weer meer dan 15 jaar op Tweakers, de site waar ik zo goed als iedere dag op kom, om te kijken naar nieuwe tech nieuws en meer, kan geen andere website die net zo goed is als Tweakers hier in NL.
Hoop dat Tweakers nog jaren vrij staat voor vrijheid van meningsuiting in de Forums en onder de nieuws berichten, als dat verdwijnt, verdwijnt ook Tweakers voor mij voor een grote gedeelte.
Ja dat vroeg ik me ook al af
of mijn geheugen mij in de steek laat kwa mijn oude geschiedenis
of de door jouw genoemde reden. de BC's
Ik kan me nog wel herinneren dat ik een @tweakers.net email adres had gekregen
voor welke reden of speciale actie dat was geen idee meer
die zal vast wel verdwenen zijn.
:strip_exif()/i/2003073744.jpeg?f=imagegallery)
/i/2003077274.jpeg?f=imagenormal)
:strip_exif()/i/2000621656.jpeg?f=imagegallery)
:strip_exif()/i/2000621657.jpeg?f=imagegallery)
:strip_exif()/i/2000621655.jpeg?f=imagegallery)
:strip_exif()/i/2000621666.jpeg?f=imagegallery)
:strip_exif()/i/2000621788.jpeg?f=imagegallery)
:strip_exif()/i/2000621789.jpeg?f=imagegallery)
:strip_exif()/i/2000621791.jpeg?f=imagegallery)
:strip_exif()/i/2000621790.jpeg?f=imagegallery)
/i/2003077290.jpeg?f=imagegallery)
/i/2003077292.jpeg?f=imagegallery)
/i/2002967914.jpeg?f=imagenormal)
:strip_icc():strip_exif()/i/2001246513.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/1223473000.jpg?f=fpa_thumb)
:strip_icc():strip_exif()/i/1222086466.jpg?f=fpa_thumb)
/i/1329915858.png?f=fpa)
/i/2000621227.png?f=fpa)
/u/475685/crop632ac89824470.png?f=community){kind=small}
:strip_icc():strip_exif()/u/253803/crop5bdafd26303ab_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/281880/crop59118f37e06d4_cropped.jpeg?f=community){kind=small}
. Echter is het wel zo wanneer je gebruik gaat maken van IaaS en PaaS je veel meer tijd overhoudt om gave dingen te bouwen en het platform te verbeteren.:strip_icc():strip_exif()/u/252258/Ability_paladin_judgementblue.jpg?f=community){kind=small}
:strip_exif()/u/1122/rrani.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/86796/ancientdragon60.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/92809/crop577f58c1b8795.jpeg?f=community){kind=small}
/u/1830/acm.png?f=community){kind=small}
/u/51919/Screen%2520Shot%25202013-03-28%2520at%252022.41.04%2520.png?f=community){kind=small}
/u/8/oog3.png?f=community){kind=small}
/u/27299/hoofd.png?f=community){kind=small}
:strip_icc():strip_exif()/u/25528/crop6262b474a9363_cropped.jpg?f=community){kind=small}
/u/395260/crop5942d74319718_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/223538/crop5e60c344da52b_cropped.jpeg?f=community){kind=small}
. Ik ben gaan walgen van de sales talks die de consultants uitkramen, niets is zoals het voorgeschoteld is, juist het tegenovergestelde.
:strip_icc():strip_exif()/u/269508/crop55c9d5fae106a_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/5964/crop56503163e97a5.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/6764/cergorach.jpg?f=community){kind=small}
/u/187392/logo_thumb_60x60.png?f=community){kind=logo}
:strip_icc():strip_exif()/u/15049/DC2-icon-klein.jpg?f=community){kind=icon}
/u/62416/crop602d199f06a2b_cropped.png?f=community){kind=small}
:strip_exif()/u/44466/0115455001290429971.gif?f=community){kind=small}
/u/49116/crop5ab3aba55abd9_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/174878/SCKnightMicro.jpg?f=community){kind=small}
:strip_exif()/u/45006/strat.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/78725/train-icon3.jpg?f=community){kind=small}
En elke keer komen "de kosten" weer als voornaamste reden naar boven. Die in mijn ogen nog steeds opwegen tegen de voordelen die AWS in dit geval biedt aan de hele ontwikkelstraat van Tweakers.
:strip_icc():strip_exif()/u/714982/crop566812d61015a_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/404349/avatar.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/430246/crop5ae7423808f32_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/567214/crop60759ec284fe4_cropped.jpg?f=community){kind=small}
/u/291122/crop5b7442d88a561_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/682908/crop58146b08b3bed_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/233767/crop5db03cbc075aa.jpeg?f=community){kind=small}
:strip_exif()/u/91615/hann1bal.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/84706/crop5f48f03c9fe53_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/124178/resizer-nl3fb5bbf8f442ce9.jpg?f=community){kind=small}
/u/256385/crop5c5841a6b363c.png?f=community){kind=small}
/u/199524/axva.png?f=community){kind=small}
/u/208684/crop5d9c7a25578e1.png?f=community){kind=small}
/u/947477/crop673c5f0c8579e.png?f=community){kind=small}
:strip_icc():strip_exif()/u/21203/tweak.jpg?f=community){kind=small}
/u/269377/arnoud8bit.png?f=community){kind=small}
/u/182977/crop65f9e5220f264_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/116283/crop5814e3224425d_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/173490/TheWall1klein.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/457/wolf60.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/1471/crop5dc6b5d41b240_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/3550/S2462.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/4795/pics_18_ziza.jpg?f=community){kind=small}
