Avete qualche applicazione contrassegnata da criptici segnali di allarme e innumerevoli ragnatele che gira su hardware legacy, nascosta da qualche parte nel vostro datacenter? Se lavorate nell’IT di una azienda enterprise, le possibilità che la risposta sia affermativa sono alte. Queste piattaforme obsolete sono spesso considerate una maledizione. Ma, soprattutto, le applicazioni legacy possono rappresentare un reale mal di testa quando si cerca di far evolvere persone, processi e strumenti per abbracciare il modello del cloud ibrido.
 
Gli strumenti di self-service o i workflow automatizzati sono solo alcuni degli attributi per la realizzazione di un cloud ibrido. Immaginate di provare ad applicare queste idee a una tecnologia legacy, dove l’interfaccia richiede l’impiego di una console arcaica e di software che sembra scritto per Windows 3.1. Non è divertente e spesso causa il fallimento di qualunque sforzo volto a offrire servizi che girano su un software-defined data center (SDDC) on-premise o in ambiente public cloud.

È responsabile anche della divisione di un team che opera in base a un modello culturale di tipo DevOps, perché concetti quali infrastructure-as-code, configurazione stateless e code check-in collaborativi si sbriciolano. Per la maggior parte delle persone con le quali mi interfaccio, le applicazioni legacy vengono supportate da un piccolo drappello di esperti che ne mantiene il funzionamento su hardware ormai datato.

L’eterogeneità è una realtà per la maggior parte delle infrastrutture. Ed è qui dove l’importanza di DevOps e di avere una mentalità API-first si amplifica. Adottare un approccio API-first non è necessariamente legato a un'unica tipologia di codice o a un’unica applicazione che “fa tutto”. Si tratta di sfruttare le API su molteplici repository e applicazioni per realizzare un’unica software fabric programmatica in cui tutto può comunicare e integrarsi indipendentemente dalla natura legacy o cloud-native.


Il modo per porre fine al caos indotto dalla complessità dell’ibrido è uno stato progressivo e policy-driven, implementato come si deve. Ecco quattro consigli per integrare il personale legacy con il team DevOps per dare vita a un modello hybrid cloud estremamente funzionale.

Trovare strumenti che lavorano bene con altri

Le applicazioni legacy non devono essere il macigno che vi impedisce di adottare una strategia DevOps. Cercate soluzioni che gestiscono applicazioni legacy, moderne e cloud-native come se fossero tutte cittadini di prima classe. Le applicazioni legacy girano su OS obsoleti, compresi alcuni che non vengono più supportati. Nel tempo questa configurazione diventa sempre più fragile e richiede cure e attenzioni manuali. Adottare una strategia di automazione può ridurre i rischi associati a costruire, testare, implementare, rimediare e monitorare.

Scegliete la semplicità, non create silos

Assicuratevi che i workflow che offrono servizi siano applicabili alla maggior parte dei casi d’uso. Storicamente non ci sono stati incentivi per la messa a punto di meccanismi condivisi in azienda. L’approccio di sistema implica che ci siano dipendenze, ma se si migliora solo un’applicazione all’interno del cluster, non ci sarà alcun beneficio. L’intero cluster deve essere indirizzato affinché il progresso sia positivo. L’utilizzo di RESTful API sta modificando le cose, permettendo l’uso di un unico set di strumenti per applicazioni, piattaforme e servizi. Condividete i dati all’interno dell’azienda; sfruttate le API per semplificare il modo in cui il team interagisce con i workload legacy estraendo i dati dalle architetture legacy.

Adottate una mentalità one-team

Se si decide di accogliere il modello DevOps, allora deve essere l’intera azienda a farlo. DevOps non ha niente a che fare con sviluppatori e persone della divisione operation che collaborano, piuttosto si tratta di due silos che diventano un team. Focalizzatevi sul migliorare la comunicazione e mettete da parte un po’ di tempo per la formazione.

Evitate soluzioni infrastructure-specific

Astraete storage e computing; lavorate invece sullo strato applicativo e sul modo di offrire i servizi per quelle applicazioni. Le applicazioni legacy sono spesso strettamente accoppiate alle componenti hardware sottostanti, rendendo rischiosa e complessa la gestione di ciascun componente applicativo singolarmente. Questo significa che manutenzione e aggiornamenti sono time-consuming, difficoltosi e anche costosi. L’adozione del modello infrastructure-as-code, sia on-premise che nel cloud, offre ai team autorizzazioni e tool per provisioning di infrastrutture on-demand. Non tutte le applicazioni legacy possono essere migrate facilmente verso questa tipologia di infrastrutture, ma molte sì.

L’uso dell’automazione aumenta l’agilità dell’azienda riducendo l’interazione umana e orchestrando le dipendenze. L’utilizzo self-service dell’infrastruttura elimina altri silos. DevOps non è incompatibile con le applicazioni legacy, ma richiede che l’organizzazione valuti ciò che questa implementazione realmente significa e come affrontare questa trasformazione. Non abbiate paura: potete sempre dipendere da un’app legacy e abbracciare i DevOps. Sono necessarie però considerazioni di progetto aggiuntive, olio di gomito e un po’ di creatività. L’elemento fondamentale sta nell’applicare questi principi in modo coerente ed efficace nel contesto di tutte le applicazioni, legacy e moderne.

Rebecca Fitzhugh è Principal Technologist di Rubrik