Veel organisaties vertrouwen nog steeds op een oud model server dat sinds jaar en dag trouw ergens in een kelder staat te snorren en vaak al drie keer is afgeschreven. Veelal draaien daar nog belangrijke applicaties en een oud besturingssysteem op, want if it ain’t broke… don’t fix it!
Ik vergelijk zulke situaties vaak met je eigen, oude auto. Je weet dat ie niet perfect is en dat hij wel wat reparatie kan gebruiken, maar hij brengt je nog steeds van A naar B. Maar onder de motorkap van die auto, en dus ook van die oude server, zitten allerlei gevaren en risico’s die kunnen resulteren in serieuze problemen. En die komen altijd op een moment waarop het niet uitkomt.
Serieuze kwetsbaarheden
De belangrijkste gevaren van het gebruik van verouderde technologie zijn wat mij betreft veiligheidsrisico’s. Hoe ouder je besturingssysteem of applicatie is, hoe langer de bad guys de tijd hebben om een kwetsbaarheid te vinden. Dit is al helemaal het geval wanneer de producent niet langer actieve support levert voor de bewuste software. Een recent onderzoek van securitybedrijf Cenzic, laat zien dat de applicatielaag nog steeds een aantrekkelijk doelwit is voor cyberaanvallen. 69 procent van alle applicaties die in 2013 zijn getest, bevatten één of meerdere serieuze kwetsbaarheden.
Het gemiddelde aantal kwetsbaarheden per app is gestegen van dertien vorig jaar naar veertien nu. En die gevaren bevinden zich over het gehele, vaak verouderde applicatieplatform. Oudere versies van SQL Server lopen gevaar. Misschien draait er nog ergens een oude ftp-server zonder dat iemand dat in de gaten heeft. Of er is nog wat verouderde netwerkapparatuur of appliances in gebruik. Het komt er eigenlijk op neer dat alles wat op of aan het netwerk hangt, een potentieel gevaar is voor jouw server en dus voor de business. En wanneer je de software en/of firmware op die server niet up-to-date hebt gehouden is het risico op een serieus security-incident dubbel zo groot.
Raid-arrays
Harde schijven zijn over het algemeen de zwakste schakel bij oudere hardware. Simpelweg omdat ze bewegende delen bevatten. Een probleem met een harde schijf resulteert meestal in het verlies van data en als een data recovery-actie niet correct wordt uitgevoerd, ben je nog verder van huis. Het gebruik van solid state drives (ssd) lost dit probleem voor een deel op en zorgt ook voor betere prestaties. Raid-arrays zijn uitgevonden om je te beschermen tegen uitvallende disks.
Hoewel dit al een veel betere situatie is dan helemaal niets doen, is het geen garantie dat alles weer als vanouds wordt wanneer je een kapotte disk vervangt. Zo kunnen er fouten zijn op andere disks die aan het licht komen tijdens het opnieuw opbouwen. Het probleem is alleen dat je er pas achter komt wanneer je je array echt goed checkt op fouten, wat niet veel mensen doen, of wanneer je dus een array opnieuw gaat opbouwen. In dat geval zit je dus met een kapotte array én dataverlies. Niet echt wenselijk.
Rottende bits
Er bestaat zoiets als rottende bits. Dat is het geval wanneer bits in het geheugen of op een disk staan in verval raken. Wikipedia beschrijft het als volgt: ‘Dankzij steeds maar groeiende capaciteit van disks, grotere bestanden en toenemende groei in data die op disks worden opgeslagen, is het steeds waarschijnlijker dat bit-rot of een andere vorm van incorrecte en onvindbare data zal voorkomen.’ Terwijl de nieuwste enterpise grade hardware steeds stabieler en betrouwbaarder wordt, is de kans dat dit voorkomt wanneer je daar steeds grotere hoeveelheden data op opslaat en mee verwerkt steeds groter. Het vervangen van disks helpt, maar wat ook helpt is het verplaatsen van kritische data naar meer geavanceerde storagesystemen, zoals die van EMC of NetApp.
Legacy-systemen kunnen ook slachtoffer worden van ‘software-rot’. Dit is het rottingsproces dat bestaat uit het alsmaar langzamer worden van de softwareprestaties of het feit dat de software langzamer reageert en uiteindelijke fouten maakt en onbruikbaar wordt. Dan is de term legacy echt van toepassing en zal er snel vervanging moeten komen.
Strategische issues
Wanneer bovenstaande zaken actueel zijn, kan zich op elk moment een probleem voordoen. De consequenties kunnen verlies van productiviteit zijn, of erger, verlies van kritische data dat zorgt voor negatieve impact op de bedrijfsvoering. Maar er zijn nog meer gevaren die op de loer liggen en waar je wellicht nooit aan hebt gedacht. Het blijven vertrouwen op oudere technologie en infrastructuur zorgt ervoor dat je organisatie achterblijft op enkele strategische punten.
Je concurrenten zijn je liever kwijt dan rijk. Ze willen jouw klanten en waarschijnlijk maken zij gebruik van technologie om concurrentievoordeel te behalen. Dit kun je niet doen door gebruik te maken van oude technologie. Door de inzet van moderne applicaties op een moderne infrastructuur kunnen je concurrenten beter communiceren, sneller reageren, meer deals sluiten en relaties verstevigen.
Oudere technologie kan simpelweg minder dan een moderne infrastructuur. Dit zorgt voor minder flexibiliteit op allerlei gebieden, zoals het kunnen analyseren van data voor het nemen van beter onderbouwde beslissingen, communicatie en samenwerking of het ontwikkelen van nieuwe applicaties.
Ben je in staat om snel en eenvoudig nieuwe applicaties uit te rollen en nieuwe medewerkers in te werken? En kun je op nieuwe initiatieven binnen enkele uren reageren in plaats van enkele dagen, weken of zelfs maanden? Misschien besteed je al je tijd wel aan het beheren van de infrastructuur en ‘het licht aanhouden’ in plaats van te focussen op nieuwe initiatieven. Oude it staat het tijdig kunnen voorzien in de juiste it-oplossing serieus in de weg.
Samenvattend zijn de (verborgen) risico’s van het gebruik van oude technologie als volgt:
- Een toename in beveiligingsbedreigingen en kwetsbaarheden
- Het falen van harde schijven die kunnen leiden tot catastrofaal dataverlies
- Bit-rot dat kan leiden tot het onbruikbaar worden van data
- Software-rot dat kan leiden tot instabiliteit, meer downtime en het verlies van productiviteit
- Je bent minder concurrerend
- It is minder flexibel
- De organisatie kan minder snel reageren
Problemen voorkomen en verhelpen
Organisaties doen er dus goed aan om werk te maken van het upgraden en onderhouden van hun systemen. Wat draait er? Is de software up-to-date? En is het echt nodig dat die bepaalde software draait op die bepaalde hardware en wat zijn de alternatieven?
Er zijn legio mogelijkheden om deze problemen te voorkomen of te verhelpen. Het vervangen van alle soft- en hardware is er één van, maar denk ook eens aan het uitbesteden van (delen van) je infrastructuur, serverpark en het hosten van applicaties in een (hybride) cloudmodel bij een betrouwbare hostingpartner.
Maar het begint bij het besef dat ‘goed’ niet perse de beste optie is.
Er is nog een belangrijk punt vergeten. Oude bestandsformaten zijn vaak niet meer of alleen met veel moeite leesbaar, wanneer je dan naar nieuwe hardware/software wil draait het oude pakket niet meer en het extraheren van je data wordt een hindernisloop om nog een oud programma te vinden dat je data er uit kan halen.
Dat kost tijd en geld.
De besparing van langdurig gebruik kan zich zo in lucht oplossen.
Herkenbaar verhaal. In mijn praktijk heb ik een aantal van dergelijke situaties meegemaakt. Totdat de boel echt crashend. Dan is er een groot probleem. Maar wat erger is, je bent dan overgeleverd aan de helpende hand van je leverancier. Voor menig MKB bedrijf een horror scenario.
Maar de andere kant van het verhaal: menig opdrachtgever ziet er tegen op om een dergelijk traject te starten. Waar begin je en hoe pak je het aan. Welke stappen moet ik doorlopen. Maar ook hier weer een horror scenario: hoe bepaal ik de adviezen van mijn (potentiële) leveranciers? Onwetendheid over de aanpak van een dergelijk traject is vaak de reden dat vervanging wordt uitgesteld. Je kop in het zand steken.
Terwijl de aanpak op zich niet zo moeilijk is. Natuurlijk heb je de leveranciers nodig, maar belangrijk is dat je zelf de regie in handen houdt.
Nogal doorzichtig artikel. Inspelen op de angsten van de mensen en hiermee een oplossing aandragen die het symptoom niet aanpakt maar hoogstens verplaatst.
Dataverlies en uitval is prima op te vangen met diverse architectuur keuzes met elk hun prijskaartje.
Afhankelijkheden met legacy kan worden aangepakt door het zoveel mogelijk vermijden van vendor lock-ins en gebruik te maken van open standaarden.
Of je dit zelf doet of uitbesteed maakt in deze niet gek veel uit behalve dan dat je de expertise zelf hebt of over laat aan een professional.
De genoemde verborgen risico’s zijn op zich correct, maar het verhaal laat maar één kant van de medaille zien.
Nieuw hoeft niet per sé beter te zijn, ook nieuwe producten hebben hun kinderziektes. Je hebt dan misschien geen bit- of software-rot, maar sommige combinaties van de nieuwste hard- +softsoftware kunnen ook tot de nodige ellende en dataverlies lijden.
Als je systeem na 3 jaar financieel is afgeschreven, maar nog steeds voldoet, kan het lonend zijn nog een jaar of 2 door te draaien en in plaats van in nieuwe systemen te investeren te investeren in borging van je data integriteit en backup. Hiermee kun je aanzienlijk besparen.
Vergelijk het met de eerder genoemde auto: wat is het risico van de oude auto? Als je alleen maar 1 keer in de week boodschappen doet en 1 keer in de maand naar je schoonmoeder gaat, is het een minder groot probleem als de auto kapot is dan als je koerier bent en iedere week 2500km moet rijden.
Vervanging van technologie moet mijns inziens een kosten-baten-risico afweging zijn, en niet “vervangen om het vervangen” omdat er weer nieuwere technologiën en versies van je omgeving zijn.
(ik vergelijk het wel eens met MSWord; het kan veel meer dan 10 jaar geleden, maar ik gebruik bar weinig van alles wat in die tijd is toegevoegd)
Zeven praktische punten van waar je ook aan moet denken. Hoewel ik wel het gevoel heb dat elk punt het gevolg is van die daarboven. Bovenaan, puntje 0, zou dan kunnen staan beheer en onderhoud van systemen. En dan zou je al klaar zijn. Maar dat zeg je eigenlijk onderaan, onder het laatste kopje.
De suggestie dat dit niet of minder nodig is, als het maar nieuw is, lijkt me iets te kort door de bocht. Maar dat was vast de bedoeling.
@Pa Va Ke
Je hebt gelijk als je over priodes van vijf jaar kijkt. Mijn opmerking komt uit een situatie waar software uit de periode voor 2000 nooit een update had gekregen en de gehanteerde database-engine eigenlijk niet meer bestaat.
Wie zijn updates regelmatig laadt kan software gebruiken die zo 10 jaar meegaat afhankelijk van de business.
Ook hardware kan vaak verrassend lang mee, met behoorlijke back-ups is dat nauwelijks een probleem zolang je je bewust bent van het risico.
Dat je met oudere software ‘minder concurerend’ zou zijn, waag ik te betwijfelen.
Angelo,
Op zich praktische punten die wel herkenbaar zijn.
Alleen sluit ik mij wel enigzins aan bij Pa Va Ke en Johan Duinkerken.
Bit-rot is niet altijd onlosmakelijk verbonden met legacy en oud. Bit-rot wordt in mijn optiek erg vaak door menselijke fouten ( slecht beheer/programmering/kennis gebrek etc. ) of verkeerde architectuurkeuzes verspreid.
@Anna
Uiteraard heb je gelijk, maar beheer en onderhoud is niet sexy en innovatief. Daarmee scoor je niet als ict-auteur of cio en wordt je getypecast als oubollig en out-of-touch.
Kleine toevoeging nog.
Alles staat en valt met een goede back-up.
Deze back-up dient geregeld getest te worden. En er dient geborgd te worden dat de data ook over een x aantal jaar nog in te lezen is. Want alleen data veiligstellen is leuk, maar je moet het ook nog terug kunnen halen. Hier voor zijn de keuze qua hardware en programmatuur van cruciaal belang. Zijn deze eenmaal gemaakt dan is overstappen lastig en tijdrovend.
Tevens dient er ook op operationeel vlak wel wat veranderd worden. Voor het patchen, aanpassen of installeren van een nieuwe release dient er een correcte back-up/copie gemaakt te worden. Mocht er ‘bit-rot’ onstaan dan kan je altijd nog terug. En ‘bit-rot’ is soms pas heel laat te ontdekken.
Als een server die een werkend systeem oplevert een risico is als deze omvalt dan zit het probleem niet in de server, maar in je organisatie.
En dit geldt eigenlijk voor de rest van het artikel. Er wordt angst aangepraat, maar die angst zou zich niet moeten richten op de techniek, maar op de organisatie.