Sinds enkele jaren neemt het aantal updates van programma's steeds meer toe. Dat dit de stabiliteit van ict-systemen geen goed doet mag duidelijk zijn. Hier volgt een opsomming van versies voor van alles, waarin menig nieuwe versie van iets nog ontbreekt
Tien jaar geleden was een jave-update nog een uitzondering inmiddels stuurt Oracle ieder half jaar een update. Firefox stuurt iedere vier weken een update, chrome geloof ik ook, dus edge mag volgen. Windows stuurt iedere maand updates en ieder half jaar een nieuwe build.
Deze tendens vindt je in bijna alle software terug, met als toefje slagroom op deze berg het software abonnement waar via internet gewerkt wordt.
Internet en Lamp-stack
Linux ieder half jaar een update, lts (long term support) vier jaar. Apache patches iedere paar maanden en NGinx patches iedere maand. Mysql 5.4, 5.5, 5.6, 5.7 en 8 (tellen heeft men verleerd) / Mariadb van 10.0, 10.1, 10.2, 10.3, 10.4 en 10.5 in nauwelijks twee jaar. PHP 5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 und sehr bald (november 2020) 8.0. Tel daarbij de javascript bibliotheken zoals Jquery met een hele rij aan versies.
Dan hebben we onze cms’en (WordPress, Joomla, Drupal, Typo3 et cetera) die ook allemaal hun versies hebben. WordPress als meest gebruikt ‘cms’ ieder half jaar, Joomla negen versies in zes jaar, Drupal in vijftien jaar negen versies met een hele rij onderversies zoals 8.0 tot 8.9.
Typo3 van 6.2 tot 11 in drie Jaar, heeft echter lts-versies.
Ieder cms heeft modules/addons/plugins en die hebben allemaal hun eigen versies die niet op alle versies van het cms lopen . . .
Dan krijgen we een aantal mogelijke combinaties die theoretisch in de duizenden loopt en in de praktijk minstens vijfhonderd telt.
Beheerspagaat
Een beheerder van een server met Lamp-stack en enkele websites die met een cms gebouwd zijn wordt natuurlijk regelmatig met incompatibiliteit tussen versies geconfronteerd. Zeker als daar nog enkele grotere webapplicaties bij komen. Zoals Moodle, EGroupware, Nextcloud, Jira et cetera.
Een voorbeeld, de leverancier van de r-server koos er voor om in plaats van mysql op mariadb in te zetten, echter een wat oudere versie. Daardoor kan een Moodle-update niet gedaan worden. Enige optie: hele installatie verhuizen naar een andere server waar mysql op draait met versie 5.7 en gelukkig niet 8 want die is weer te nieuw.
Conclusie
Het ziet er naar uit dat we op de tafel van de vernieuwing de stabiliteit geofferd hebben.
Een server met cms’en, financiële systemen, cloud software, webshops, planningsystemen en analysesoftware wordt op die manier een bijna avontuurlijke business-case en dan hebben we nog niet over koppelingen tussen systemen gesproken.
Interessante conclusie. Helaas niet juist.De grote regelmaat van updates en patches voor bijvoorbeeld het aangehaalde Windows en Chrome dient wellicht de functionaliteit, maar alleen in de zin van het waarborgen van de stabiliteit. Dit in tegenstelling tot wat het artikel suggereert.
Ik vermoed dan ook dat het artikel bedoeld is als aanloop naar een stuk reclame voor SaaS of virtualisatie/isolatie. Ik hoop dat dat artikel dan eerlijk is en duidelijk maakt dat het niet een oplossing is, maar alleen het probleem verplaatst.
Het tweede deel van de conclusie is overigens wel juist. Het is een knappe uitdaging..
Nee Peter, ik kom niet met een SaaS of virtualisatie oplossing. Het is een ergernis van een aantal kollega’s die net als ik de boel aan de gang moeten houden. Met SaaS of virtualisatie creeer je nog een beheerslaag extra die opnieuw updates krijgt en in mijn ervaring nog vaker met inkompatibiliteit kampt.
Je stelt “waarborgen van stabiliteit”, wellicht voor dat ene produkt maar nauwelijks voor de gehele stack, verander 1 produkt dat samenhangt met 8 andere en je krijgt bijna zeker een probleem.
Dependencies vermijden wordt lastig, je wilt niet het wiel uitvinden.
updates vermijden ook, je wilt tenslotte nieuwe features.
shared dependencies vermijden kan vaak wel, met containers. Geen shared DB servers meer, maar de 1 DB met 1 instance in een container dedicated voor de app.
misschien nog een extra container erbij tbv SSL offloading van de website.
Je data in persistent storage buiten de container.
Fixed versioning door image tagging zodat je zelf controle hebt.
Het gaat niet op voor elke app en elke situatie en container tech leren geeft natuurlijk nieuw lijden,
maar alleen als het uitzichtloos is mag de stekker eruit.
In Nederland dan.
Herkenbaar wat je schrijft Jan
Maar … is dit in bepaald opzicht niet de keerzijde van het succes van open source producten?
Zelf heb ik o.a. een aantal jaren een Joomla website beheerd, en werk ik vandaag de dag nog e.e.a. met Jenkins.
Kenmerk van beide pakketten is dat er een groot aantal plugins beschikbaar is waarmee heel veel extra functionaliteit geboden wordt.
Enerzijds heel krachtig natuurlijk, maar vanuit beheer een nachtmerrie … in die zin dat je op een gegeven moment afhankelijk bent van de goodwill van de eigenaar van zo’n plugin of hij/zij deze nog wil updaten om compatible te blijven met de laatste versie van het basispakket.
Bij Jenkins zie ik bij sommige plugins bijvoorbeeld wel eens verschijnen dat ze op zoek zijn naar een nieuwe “eigenaar” bijvoorbeeld.
Bij de closed source / commerciele pakketten heb je dan misschien niet altijd zoveel flexibiliteit en functionaliteit, maar hetgeen je aangeleverd krijgt is vaak wel een consistent en werkend geheel.
Dit laat overigens onverlet dat, wanneer je zelf er weer van alles omheen geknutseld hebt, je nog steeds een uitdaging houdt om alles draaiende te houden
Het Lifecycle Management van een platform is een groeiende beheer(s)last maar het waarborgt de stabiliteit en veiligheid. De problematiek gaat nog wat dieper als je ook de afstemming van alle drivers en firmware meeneemt in je beheer. Uitbesteding van dit beheer middels een PaaS model leert dat legacy geen goede kandidaat is voor de cloud. En voorstel van Dino om de stekker uit het ‘patchwork’ van gedeelde afhankelijkheden te trekken is een kijk op de non-functionele kant. Stabiliteit is tenslotte niet een functionele eis van de gebruiker, die wil dus alleen maar de snellere paarden.
Ik herken de last omdat ik – zoals vele vrijwilligers – het it-beheer voor vereniging(en) deed. Ik ga namelijk niet meer aan een dood paard trekken zonder uurtje-factuurtje, PaVaKe beschrijft het prikbord waar inzet zonder vergoeding gevraagd wordt voor het onderhoud van code. Continuïteit is net als stabiliteit een non-functionele eis als we kijken naar de uitdagingen in het Lifecycle management. En vaak wordt End-of-Life van een product al gecommuniceerd bij introductie, voor MySQL geldt Oracle’s Lifetime Support Policy. En als je klant geholpen hebt met MySQL 5.6 dan kun je al de afspraak voor een update inplannen.
Ik denk dat je nu duidelijk de business cases voor en bestaansrecht van RHEL (CentOS) en SLES door begint te krijgen.
Wat je als beheerder/it-toko moet ‘afdwingen’ is dat developers hun nieuwe dingetje du-jour op RHEL / SLES deployen.
RHEL is wat dat betreft ook onlangs overgestapt op ‘streams’ en ‘modules’ en heeft een minimale BaseOS die de komende 10j van security patches voorzien wordt:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/installing_managing_and_removing_user-space_components/introduction-to-modules_using-appstream
Doe er je voordeel mee.
@SWA
bedank voor de link, kijk ik naar.
Lang geleden heb ik op Ubuntu gezet, vanwege de fora, dat werkt nog steeds erg goed, meestal.
Een periode van 10 jaar met 1 versie OS komt me vandaag de dag als illusie voor.
Met de LAMP-stack moet je daar op een gegeven moment spaak lopen.
@jan
en toch is het zo en werkt het wel:
https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle
ikzelf ben nu de laatste CentOS 6 machines om aan het zetten naar CentOS 8 op hardware uit 2014.
heb zelf LAMP PHP code in beheer en in productie (en bak daar ook rpms voor) uit 2006 dat op CentOS/RHEL 4 begon en als een zonnetje op 7 draait nu, maar straks ook op 8 moet.
veranderingen in PHP vwb MySQL heeft me even werk gekost een fatsoenlijke compatible wrapper te vinden:
https://www.php.net/manual/en/mysql.php
https://github.com/e-sites/php-mysql-mysqli-wrapper/blob/master/mysql.php
kan daar het OS (CentOS/RHEL) toch niet de schuld van geven dan de PHP luitjes een API er uit gooien…
@swa
ziet er goed uit maar niet naar minder werk.
De webprogrammas waarmee ik werk hebben allemaal updates met security-patches die dan ook een hogere versie PHP vragen, de komplete stack is als een kluwe wol, trek je aan 1 draadje beweegt ook de rest . . . .
SWA,
Interessante oplossing maar idee van containers/streams biedt zoals Dino stelt een gedeeltelijke oplossing. Wat Dino ook zegt is dat de containers/streams een nieuw lijden geven en niet voor alles en iedereen geschikt zijn.1 PK business case van Jan gaat om de F van gratis met inderdaad aanzienlijk kortere lifecycles: https://linuxlifecycle.com/
Oja, uiteraard moet je ook lifecycles van de opstapeling van runtimes e.d. als geheel inzichtelijk maken om zo een idee van de roadmap te krijgen maar dat is geen goede business case voor Jan. Maak hem niet werkeloos door hem weg te automatiseren middels scripts.