Buone pratiche relative al software fuori produzione in produzione (OpenDS)?

Quanto è male usare OpenDS , che non è attivamente gestito, che ha avuto l'ultima patch nel 2010 e che richiede JDK6 (che è anche obsoleto) in un ambiente di produzione? (Anche se sul backend e non direttamente esposto agli utenti finali ).

Se è già lì, in genere vale il tempo e i soldi necessari per trovare un sostituto, eseguire test di integrazione e simili? Quali sono i criteri comuni per fare questo passo, per quanto riguarda il software obsoleto in produzione in generale?

Ti suggerisco di valutarlo in termini di rischio aziendale / operativo.

L'uso di vecchi software non supportati comporta spesso questi potenziali rischi.

• Nessun supporto fornitore
• Nessun aggiornamento ai bug
• Nessuna patch di sicurezza
• Gli aggiornamenti del sistema operativo potrebbero essere incompatibili
• Le opzioni di ripristino di emergenza possono essere limitate.
• Problemi di licenza possono causare problemi di ripristino / operativi.
• Incapacità di ridimensionare / espandere le operazioni basate su questo servizio.

Gli ultimi due sono spesso trascurati.

Anni fa, ho avuto un caso in cui un cliente utilizzava un software MTA proprietario legacy. Si sono assicurati un nuovo importante contratto di email marketing e avevano bisogno di accelerare rapidamente la loro server di posta.

Non erano in grado di ottenere una licenza per il loro MTA. L'MTA aveva alcune funzionalità e un'API speciale che si integrava profondamente nella loro piattaforma di email marketing.

Abbiamo dovuto clonare manualmente i dischi e inserirli in nuovi server più potenti per ridimensionare il sistema. Lo sviluppo di un nuovo server avrebbe avuto più senso, ma non era una soluzione praticabile a causa del software legacy.

Pertanto, se non si prevede di eseguire l'aggiornamento a breve, potrebbe essere necessario valutare i rischi e almeno disporre di piani sperimentali su come mitigare i problemi che dovessero insorgere.

Le persone spesso menzionano la sicurezza. Tuttavia, il vecchio software, purché non ne abbia, gli exploit attivi noti non sono intrinsecamente più sicuri di una sostituzione moderna.

Il rischio per la sicurezza non è che il software possa essere sfruttato ma che non si possa ricorrere facilmente se viene identificato un problema di sicurezza.

Personalmente, preferirei aggiornare alcune componenti chiave delle operazioni in modo pianificato piuttosto che provare a progettare urgentemente una nuova soluzione.