Rispetto a qualche anno fa, la selezione, l’utilizzo e il mantenimento del software open source è molto cambiato.
La richiesta di componenti open source cresce ogni anno in modo esponenziale: nel solo ambito Java, gli sviluppatori hanno estratto 17 miliardi di componenti dal Central Repository nel 2014, 31 miliardi nel 2015 e 52 miliardi nel 2016. Un recente sondaggio su 2292 società IT ha evidenziato come l’OSS costituisce l’80-90% di un’applicazione.
Cosa succerebbe dunque se il software open source smettesse di funzionare?
La risposta dipende dal grado di efficacia della propria strategia di reazione in caso di problematiche relative all’uso di OSS.
Per poter mettere in atto una strategia efficace andrebbero considerati alcuni aspetti, tra cui:
1. Il supporto dell’implementazione
Un sondaggio IHS su 400 aziende medio-grandi ha riscontrato una media di 5 downtime al mese. Se a questi si aggiungono i problemi di performance e di scalabilità, è difficile garantire agli utenti un’elevata usabilità ed evitare l’abbandono del servizio.
Solitamente, quando si presenta un problema, in ambiente di sviluppo o in produzione, i team:
- Cercano di risolverlo da soli
- Si rivolgono all’autore
- Si appoggiano alla community
Tutti questi metodi fanno affidamento sulla speranza di trovare persone con le giuste competenze, che si dedichino al problema finché non viene risolto.
Un recente sondaggio ClusterHQ indica che il 43% degli sviluppatori dedica tra il 10 e il 25% del suo tempo a risolvere problemi individuati in produzione, anziché a sviluppare nuove funzionalità.
Molte domande rivolte alla community, invece, rimangono non risposte per settimane, mesi o anche anni.
Fare affidamento sulle proprie risorse interne, anche se dà la percezione di avere le cose sotto controllo, non è una soluzione vincente.
Un sondaggio condotto da Rogue Wave Software sui propri clienti ha rivelato come l’80% delle problematiche verificatesi erano dovute alla mancanza di conoscenza del funzionamento di un’applicazione in un particolare ambiente o a un’errata configurazione.
2. Il monitoraggio dell’implementazione
Scegliere un pacchetto, installarlo, configurarlo e mantenerlo funzionante è il normale uso dell’OSS; e per quanto riguarda l’ottimizzazione per il carico, le risorse e le performance? Spesso è più facile trovare le capacità di deploy, che non competenze per i continui monitoraggio e ottimizzazione.
3. L’aggiornamento seguendo la community
Si è a conoscenza delle ultime versioni e del contenuto dei pacchetti presenti nei propri sistemi? Se non c’è una persona dedicata, è difficile tenersi in aggiornamento, e si rischiano rilasci a pericolo di insuccesso.
4. La reattività alle notizie critiche di sicurezza
Come vengono mantenuti sicuri i pacchetti? Monitorare gli aggiornamenti di sicurezza può essere dispendioso e le capacità di selezionare e eseguire patch è solitamente difficile da trovare.
5. Il test completo dell’implementazione
Nel 2016, il deploy automatico è essenziale. Un aspetto indispensabile per CI e CD è lo unit testing automatizzato.
6. La reattività a problemi inaspettati
Soprattutto per i problemi relativi all’interazione tra pacchetti e il system environment, può essere difficile trovare le competenze per la risoluzione.
Viviamo in una “application economy” dove l’innovazione è cruciale, la velocità è critica e l’open source fa da protagonista.
Il 4 ottobre partecipa a Milano a “Next generation enterprise web applications: open, connected, secure.” Rogue Wave e Emerasoft illustreranno concetti e strumenti per dotarsi di web app pronte al futuro. Registrati all’evento gratuito.
