Come risparmiare attraverso l’automazione del database

ID-100429110È risaputo che adottare i tool e le metodologie DevOps è una componente essenziale nella transizione dell’azienda verso l’economia digitale.

I manager potrebbero mettere pressione riguardo all’implementazione del DevOps e richiedere di stilare un ROI di questa mossa. Sia l’azienda che i manager conoscono le ragioni per cui è conveniente estendere il DevOps al database, tra le quali i tempi di produzione e il time to market più rapidi, una produzione di maggior qualità, ecc.

Ma come si può assestare il valore completo dell’implementazione del DevOps, senza sapere cosa si otterrà da queste vaghe promesse di miglioramento? Anche se si potesse quantificare l’apporto di queste KPI, come si trasformano in denaro?

Molti calcoli tendono a presentare le efficienze del DevOps nei processi di sviluppo, ma il calcolo dei risparmi nell’intera automazione del rilascio, sia nel codice che nel database, è molto più impegnativo e scarso. Questa mancanza di trasparenza porta alcune aziende a pensare – erroneamente – che investire nel database per come lo si fa insieme al resto dell’ecosistema di sviluppo non è necessario.

Calcolatore ROI di DBmaestro

La buona notizia è che ora è possibile calcolare facilmente l’intero processo di automazione del rilascio.

DBmaestro è fiero di presentare il calcolatore ROI per DevOps. L’unico calcolatore che integra la ricerca industriale (i record degli IT di Gartner e TCO) e le migliori pratiche raccolte da DBmaestro dalla base su 1000 clienti Fortune.

Si può usare questo tool per calcolare il ROI del proprio programma DevOps, compresi:

  • Il costo del tempo di inattività dell’applicazione nelle grandi aziende (circa 7.900 $ al minuto).
  • Il costo medio dell’eliminazione delle barriere tra sviluppo e operation.
  • Il costo degli errori umani che portano a crash devastanti e centinaia di migliaia di dollari spesi in fix non necessarie.

Scopri lo spreco, scopri l’opportunità

Molte aziende hanno scoperto, ad esempio, che i tempi di inattività del database stavano esercitando un peso gravoso sulle loro spese operazionali. Un cliente ha scoperto che stavano perdendo 500.000 $ all’ora a causa di errori critici nell’applicazione. Una volta scoperto, gli sono bastate sei ore per sistemare il guasto, ed evitare uno spreco non necessario di 3M $ all’anno.

Come calcolare un’analisi costi-benefici del database?

Mentre molti studi sono stati intrapresi nel tentativo di identificare il ROI dell’automatizzazione del database e dei processi di rilascio – come il calcolatore TCO di Gartner – sarebbe necessaria un’analisi ulteriore. In modo particolare bisognerebbe anche calcolare i risparmi sulla produttività del team, quelli generati dall’automazione e quelli dalla riduzione del pericolo di tempi di inattività.

Usando il calcolatore ROI di DBmaestro per valutare il database, l’analisi costi benefici mostra un ampio spettro di fattori e considerazioni, che presentano una rottura di ciò che si sta spendendo in costi non necessari e dove c’è bisogno di miglioramenti.

Far combaciare i numeri dell’azienda con le proprie condizioni operazionali, permette di essere più orientato ai dati nel prendere decisioni. Può anche dare un’immagine più chiara di quanto più efficiente possa essere la propria azienda e quanto si possa risparmiare implementando un programma DevOps completo.

CLICCA QUI PER CALCOLARE IL ROI DEL TUO PROGRAMMA DEVOPS.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of cookie__cutter at FreeDigitalPhotos.net

Come risparmiare attraverso l’automazione del database

I 7 step per un DevOps di successo

Il DevOps è un tema sempre più di rilievo nell’ambiente IT.

L’implementazione del DevOps nelle aziende di grandi dimensioni non è semplice e richiede una grande collaborazione tra settori diversi, oltre all’integrazione di piattaforme che consentano di gestirlo e ad un cambiamento significativo della cultura aziendale. Per poter implementare una strategia DevOps di successo occorre, infatti, partire dal presupposto che il DevOps non è un approccio che coinvolge singoli team o dipartimenti, bensì un metodo che abbraccia molti aspetti della gestione aziendale. Insomma, approcciarsi al DevOps implica uno sforzo non banale.

Considerato l’impegno necessario ad implementare il DevOps al meglio, vale davvero la pena investirci? Certo!

devops di successoI cambiamenti dovuti all’implementazione del DevOps portano grandi benefici all’azienda, permettono di migliorare il lavoro in termini di tempistiche e qualità e creano un ambiente collaborativo e ottimale per la massima resa di ogni singolo individuo. La filosofia del DevOps non a caso si fonda sui tre pilastri del successo di un’azienda: collaborazione, comunicazione e automazione. Rilasci rapidi, controlli qualità continui, comunicazione tra i settori e tra gli individui, trasversalità delle competenze, sono solo una parte dei benefici del DevOps e rappresentano la più alta realizzazione di questi tre grandi concetti.

Da dove partire, quindi, per divulgare in azienda la corretta filosofia DevOps e mettere in piedi una strategia vincente? 

Recentemente Eddy Pauwels, SVP di Clarive, si è interrogato sul DevOps e ha stilato una lista di 7 step per implementarlo al meglio nelle aziende. Qui di seguito riportiamo la lettera di presentazione dell’eBook ”My 7 Step strategy for successful DevOps in the evolving enterprise.

“Il DevOps  un tema caldo. Molte aziende sono nel pieno del processo di implementazione del DevOps o stanno stanziando un budget per poterlo fare in un futuro prossimo. Ad oggi molti analisti scrivono di DevOps, ma allo stesso tempo continuo a notare molta confusione su cosa sia davvero.

È un processo? Un metodo di lavoro? Una cultura aziendale? Un approccio? O riguarda tool e automazione? Consente progetti Agile o può essere applicato solo a progetti tradizionali?

Con questo eBook voglio presentare la mia visione del DevOps e condividere la mia strategia a 7 step, per un’implementazione di successo del DevOps nelle aziende in crescita.

Il contenuto di questo eBook si basa sulle molte conversazioni che ho avuto con persone esperte, durante la mia personale esperienza come consulente e formatore DevOps, con clienti e analisti e nei molti anni passati a leggere ed informarmi sull’argomento.

Spero che il contenuto di questo eBook sia fonte di ispirazione per il lettore e aiuti nell’introduzione al DevOps. Chi appartiene a grandi aziende spesso si trova nel processo di transizione delle proprie applicazioni, delle architetture per i servizi e dai processi di delivery che diventano interconnessi ai micro servizi. Spesso sono molto entusiasti dei benefici del DevOps, ma altrettanto spesso temono che sia un obiettivo difficile da raggiungere, per esempio a causa della scarsa adozione dell’agile di cui hanno fatto esperienza, di un approccio di gestione dei rilasci top-down e di una grande varietà di piattaforme con cui devono avere a che fare.”

Questo eBook presenta in maniera molto pratica ciò che spesso viene solo teorizzato. Se hai intenzione o hai già pianificato di passare al DevOps nella tua azienda, devi necessariamente conoscere a fondo l’argomento, al fine di massimizzarne la resa e trarne il massimo dei benefici. Come?

I 7 step per un DevOps di successo

DevOps e sicurezza anche per il database

“In quanto CTO e cofondatore di DBmaestro, ho speso gli ultimi anni a capire e imparare come ottenere uno sviluppo agile, la continuous delivery e l’integrazione per il database, noto anche come DevOps per il database” afferma Yaniv Yehuda.

ID-100435764Dopo aver sostenuto innumerevoli conversazioni con leader del campo, CIO e CTO, Yehuda ha concluso che la ragione primaria per cui le aziende decidono di non adottare il DevOps per il database è di preservare la sicurezza del database stesso. Se la sicurezza del database avesse un ruolo più importate nel DevOps, le grandi aziende, soprattutto quelle che gestiscono dati sensibili, sarebbero più aperte all’adozione dell’agile e delle pratiche di continuous per il database.

DBmaestro si propone di aiutare le aziende a raggiungere i propri obiettivi di rilascio rapido, gestendo al contempo i rischi. La soluzione è il DevSecOps, che permette ai processi di sviluppo delle applicazioni di essere accelerati, sottoposti a test e rilasciati in modo controllato e organizzato.

Il bisogno di velocità

La sfida del DevSecOps per il database è di aumentare velocità ed efficienza senza perdere il controllo. Com’è possibile per le aziende essere più veloci e restare protetti allo stesso tempo? Chi pratica mountain bike conosce questo problema: per andare veloci, si deve mettere in conto qualche rischio.

Esiste un’ovvia ragione che spiega questo bisogno di velocità: i clienti non hanno pazienza. Ai tempi della metodologia waterfall, le soluzioni per le aziende testate a fondo venivano lanciate una o due volte all’anno. Ora, con l’adozione dell’agile e dei processi continui, hanno tutti fretta. Le aspettative sono alte e il tempo per dedicarsi ai dettagli è poco.

Le aziende che continuano ad avere successo nell’era del DevSecOps hanno imparato a rilasciare rapidamente applicazioni senza intoppi, in modo efficiente e con successo, grazie all’automazione. Tuttavia il database veniva trascurato, continuando a svolgere molte attività in modo manuale. Gli amministratori del database si sono ritrovati a dover svolgere l’incarico impossibile di tenere il passo con i processi continui, usando implementazioni manuali.

L’automazione del database è sicura?

Il problema riscontrato è che automatizzare il database non era come automatizzare il codice. Il database non è una raccolta di file su un file system, perciò, a differenza del codice, il database non può essere copiato. È questa la caratteristica che contribuisce alle inconsistenze tra gli ambienti come le derive di configurazione e le modifiche esterne ai processi. Gli sviluppatori di codice sono incoraggiati a sbagliare in fretta e sbagliare spesso, ma se gli sviluppatori del database adottassero questa filosofia per il database, le aziende ne pagherebbero il prezzo.

A causa di questi rischi il team DBA è diventato un collo di bottiglia. Prima del DevSecOps per il database, i team di sviluppo erano frustrati perché avrebbero voluto essere più agile e autosufficienti. I DBA, responsabili della salute e delle operazioni di continuous del database, dovevano prestare attenzione alla valutazione e alla gestione dei rischi delle modifiche, portando via tempo prezioso.

Quando le aziende applicano il DevSecOps per il database, sia i team di sviluppo, sia i DBA, condividono le responsabilità di custodia dei preziosi dati nel database. Lavorando insieme, possono stabilire delle regole di base e dei controlli dei processi, nonché creare processi ripetibili. Il lavoro collaborativo richiesto dal DevSecOps aiuta le aziende a superare in sicurezza le sfide dell’automazione dello sviluppo e del deploy del database per stare al passo con i sempre più rapidi tempi di rilascio.

DevSecOps in azione

Il DevSecOps per il database crea le condizioni per un rilascio sicuro degli script del database. Ciò significa prepararsi alle derive di configurazione, alle modifiche esterne ai processi, aderire alla conformità normativa e alle richieste di revisione. Tutto ciò permetterà rilasci sicuri e rapidi in ambienti strutturati.

Per prima cosa, i team devono essere conformi alle regole della policy e capire i ruoli di ogni membro. In secondo luogo, è fondamentale impostare le regole per prevenire le modifiche che non sono conformi con la policy organizzativa. Inoltre, i cambiamenti ammessi dalle audit in fase di esecuzione degli aggiornamenti aggiungeranno un’ulteriore linea di difesa per prevenire errori del codice e inattività del database. In altre parole, qui ci si concentra sull’analisi d’impatto e non sul controllo dei danni.

Abilitare il rollback durante questa fase è imperativo per avere modifiche al database sicure. Per ottenere un processo sicuro, rapido e attendibile, questi step devono essere eseguiti alla perfezione. Dopo questo processo, comprendere chi ha fatto quale modifica, quando, dove e perché, è fondamentale per esaminare se questo processo può essere ripetuto (o automatizzato) o se il team DevSecOps deve tornare alla fase di pianificazione.

Non tralasciare il database

Non si tratta semplicemente di avere a che fare col database, ma con le intere applicazioni. La stessa rete di sicurezza costruita per i rilasci del codice può essere applicata al database avendo attivato una giusta pipeline di continuous delivery. Una delle maggiori preoccupazioni per le aziende che hanno a che fare con informazioni sensibili – in particolare il settore finanziario – è l’inattività, costosa sia in termini di denaro, a causa dei milioni di dollari persi, sia in termini di tempo, dovendo l’azienda tornare a ricostruirsi una reputazione.

Aziende che, come può essere comprensibile, non vogliono avvicinarsi all’automazione per evitare questi rischi, verranno superate perché non soddisfano le richieste dei clienti. Le aziende finanziarie devono capire che esiste una soluzione sicura e attuabile per automatizzare i rilasci del database e il ROI che ne deriverà ricompenserà i loro sforzi.

Per approfondire il tema scarica il wehitepaper: “DevOps per il database: pregiudizi e Best Practices“.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of yodiyim at FreeDigitalPhotos.net

DevOps e sicurezza anche per il database

Perché i database non sono automatizzati?

Sebbene il concetto di continuous delivery esista da diversi anni, i professionisti IT che la adottano spesso considerano il database un elemento non compatibile con questo metodo. Perché?

database-automationUn sondaggio condotto da DBmaestro ha coinvolto più di 200 persone tra sviluppatori, DBA, IT Operation manager e altri professionisti aziendali, indagando la loro opinione sull’implementazione della continuous delivery. Le risposte raccolte fanno luce sulla questione:

Perché i database non sono automatizzati?

Dal sondaggio è emerso che la maggioranza degli intervistati implementa la continuous delivery nelle applicazioni, ma di questi solo una metà include il database nelle procedure. Nonostante questo, il sondaggio mostra che l’81% crede possibile l’implementazione della continuous delivery nel database.

Quando è stato chiesto quale fosse l’ostacolo maggiore per l’implementazione della continuous delivery nel database, il 36% ha risposto di avere problemi con la fiducia nell’automatizzazione del database e il 18% ha ammesso che fosse per mancanza di consapevolezza. Il 17% motiva la sua risposta con l’incapacità di cambiare la cultura aziendale e il 22% lo attribuisce o a un budget ristretto o al conflitto tra team di gestione e di sviluppo.

Adozione aziendale trasversale

Dal sondaggio è anche emerso che i rispondenti considerano l’adozione della continuous delivery uno sforzo trasversale all’azienda, che deve comprenderne tutti i settori. Il 46% afferma che i DBA dovrebbero incaricarsi dell’adozione, mentre il 40% afferma che sia compito del management. Ciò contraddice la credenza comune secondo la quale sono gli sviluppatori o i top executive i responsabili dell’adozione di nuovi metodi di sviluppo.

La continuous delivery è un concetto che racchiude un processo e un’automazione ben definiti nel software. Tramite l’automatizzazione le attività possono essere ripetute dinamicamente senza errori o sviste umane, assicurando sempre i risultati attesi.

L’automatizzazione permette di spezzare le parti più difficili di un’attività in azioni più piccole e semplici. Inoltre permette di risparmiare tempo, così che i membri del team possano dedicarsi ad altro.

Conclusione: fiducia e consapevolezza sono fondamentali

I risultati del sondaggio sono rivelatori. La continuous delivery negli ultimi anni è diventata ormai una norma, con una grande maggioranza delle aziende che la implementa. D’altro canto, nonostante la grande maggioranza di professionisti in azienda che credono che i database possono essere inclusi nel processo di continuous delivery, molti ancora sono contrari.

L’implementazione della continuous delivery nel database viene ignorata principalmente a causa della mancanza di fiducia e consapevolezza riguardo all’automatizzazione dello sviluppo del database.

Voi avete già pensato di automatizzare il DB?

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Perché i database non sono automatizzati?

Fare la scelta “sana” porta benefici anche alle pratiche DevSecOps

Quando si parla di cibo, tutti sanno cos’è considerato “sano” e cosa “non sano”.

Quando viene offerto cibo fritto, in pastella, burroso o cremoso – che è la categoria dei dolcetti – è ovvio che si tratta di cibo “non sano”. Se invece viene proposto cibo fresco, grigliato, cotto al vapore o in forno, verdure e altri cibi buoni allora è “sano”.

Quando si mangia è facile capire il concetto, ma quando si parla di sviluppo software, le semplici regole e i consigli per una sana alimentazione non bastano: regole come usare componenti open source “sani” e non componenti “non sani” (quindi vulnerabili, sorpassati, con licenze rischiose) quando si fanno le build e i deploy delle applicazioni.

Per rispettare la necessità di velocità, praticamente tutte le moderne aziende di sviluppo utilizzano componenti open source e di terze parti per assemblare le applicazioni piuttosto che ricostruire ogni funzione da zero. Secondo il report del 2016 della Software Supply Chain, una comune azienda di sviluppo utilizza circa 229.000 componenti Java open source all’anno, ma dati simili sono stati registrati nel campo di sviluppo di JavaScript, Python, Ruby e .NET. Se il vantaggio di questa ghiottoneria è il miglioramento della produttività, il lato negativo è che i componenti vengono utilizzati senza l’adeguata percezione della qualità.

Dietro l’utilizzo di componenti software open source e di terze parti nello sviluppo, la stessa guida vale per i contenuti utilizzati dai team DevOps. Ad oggi sono disponibili oltre 100.000 applicazioni gratuite su Docker Hub e l’utilizzo di queste applicazioni nelle catene di tool e nelle infrastrutture DevOps spesso non è controllato.

Il lato negativo dell’efficienza

Mentre componenti e container sorgente possono accelerare gli sforzi dello sviluppo, molte aziende non monitorano abbastanza da assestare la propria qualità e sicurezza. Il report del 2016 della Software Supply Chain indica inoltre che 1 componente su 15 usato nelle applicazioni contiene almeno una vulnerabilità nota di sicurezza. Ciò significa che non tutti i componenti e i container sono stati creati nello stesso modo e quindi che pratiche di utilizzo cieco possono avere conseguenze immediate e sul lungo tempo, per le aziende che utilizzano componenti software open source e applicazioni containerizzate.

Secondo il sondaggio DevSecOps Community del 2017, il 57% delle aziende che vogliono migliorare la qualità dei componenti utilizzati nelle proprie pratiche di sviluppo hanno implementato una pratica di governance open source. Questo dato è appena al di sopra del sondaggio del 2014 che mostrava che il 57% delle aziende aveva policy open source in vigore. Per quelle senza policy in vigore, non ci sono regole su pratiche di utilizzo “sane” e “non sane”. Avere una policy in vigore può aiutare a migliorare la qualità delle applicazioni che vengono prodotte, ridurre le vulnerabilità di attacco e eliminare l’uso di componenti con tipologie di licenza rischiose.

devsecopsCibo spazzatura e mal di pancia

Per enfatizzare ulteriormente il bisogno di valutare la qualità e la sicurezza dei componenti, si potrebbe analizzare cosa è emerso dal sondaggio del 2014. Oltre 2.700 partecipanti al sondaggio avevano indicato che più di 1 azienda su 10 (14%) aveva subito o aveva sospettato una violazione nelle applicazioni dovuta a un componente software open source. Probabilmente il numero di violazioni registrato è così alto a causa del noto componente software open source OpenSSL (anche noto come “Heartbleed”), uscito lo stesso mese del sondaggio, la cui vulnerabilità era stata annunciata. Sorprendentemente il sondaggio del 2017 mostra che il 20% delle aziende (1 su 5) ha subito o sospettato una violazione legata a componenti software open source nelle applicazioni. Negli scorsi tre anni, nonostante il numero di violazioni confermate o sospette legate a componenti open source vulnerabili sia aumentato del 50%, il numero delle aziende che hanno regole in vigore per governare l’uso di componenti sicure è rimasto lo stesso.

Nella comunità DevOps si nota una crescente attenzione nei confronti della sicurezza e molte più aziende stanno cercando metodi nuovi per automatizzare le pratiche già nell’SDLC. Uno degli approcci adottati è quello di automatizzare la valutazione di componenti open source e di terze parti, contro le regole designate nelle policy di governance open source. Avere una policy automatizzata in vigore per rafforzare la governance e guidare i rimedi non è l’unica risposta alle richieste del DevSecOps, ma può ripagare molto bene in termini di prevenzione.

le scelte giuste possono offrire benefici a breve e lungo termine. Nel campo dei componenti e dei container fare la scelta “sana” porta benefici anche alle pratiche DevSecOps.

Scarica l’infografica “DevSecOps Community Survey”

 

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Fare la scelta “sana” porta benefici anche alle pratiche DevSecOps

Continuous Integration e DB: le Best Practice da seguire

Continuous Integratione e DBRecentemente è comparso un articolo molto interessante sulla continuous integration, che tratta la CI come pratica e non come strumento.

Quest’articolo intende riprenderne le fila, ma con un’attenzione particolare al database.

Siate smart, siate continuous

Insieme al DevOps, il continuous deploy e altri, la CI è uno dei molti metodi che gli sviluppatori hanno cominciato a utilizzare di recente.

Alcuni di questi metodi, come l’Agile, sono già molto noti e tenuti in buona considerazione, ma altri, come la CI, continuano ad essere relativamente sconosciuti ai team di sviluppo. La chiave, quindi, è la conoscenza.

Nell’articolo precedentemente citato, l’autore presenta una serie di raccomandazioni sulle migliori pratiche per la continuous integration. Già nel titolo avvisa di “non fare il check-in in una build non funzionante”. Inoltre viene spiegato perché l’uso della CI porta così tanti benefici nel lungo tempo: prima si viene a sapere che la build non funziona e se ne capisce la causa, e prima verrà sistemata, perché lo sviluppatore che se ne occupa ha il problema fresco nella memoria.

Come gestire le modifiche del database

Per gli sviluppatori del database comunque rimane la questione di come combinare le modifiche del database con le attività della CI. In verità dipende tutto da come vengono gestite le modifiche del database. Di solito avvengono secondo tre modalità:

  1. Sviluppare le modifiche con degli script e eseguirli nel database

In questo scenario non è prevista una vera “gestione” delle modifiche del database. Tutto viene fatto manualmente e viene solo gestito lo script.

Il problema di questo approccio è che il database e il repository non sono adeguatamente sincronizzati tra di loro. Inoltre quando viene eseguito lo script, o anche solo una parte di esso, non può essere eseguito nuovamente poiché è cambiato il punto di partenza.

  1. Usare il database source control e il compare & sync

Alcuni team di sviluppo del database usano il database source control per la creazione di oggetti, poi impiegano un semplice tool di compare & sync per generare ed eseguire lo script di deploy. Se viene utilizzato questo approccio è possibile che la visibilità risulti limitata e che si resti intralciati da due sistemi che non si integrano bene.

Ad esempio i tool di compare & sync non possono godere delle importanti informazioni fornite dalla soluzione di database source control. Ciò pone il problema della mancanza di riferimenti al sorgente delle modifiche, quindi gli sviluppatori non possono sapere quali modifiche devono essere promosse, ignorate o unite.

  1. Modificare direttamente il database

In questo scenario, il check-out e check-in, gli stessi principi di controllo del sorgente che per decenni sono esistiti nello sviluppo di applicazioni, devono essere applicati al database. Inoltre il modulo di deploy (che è più di un semplice compare & sync), responsabile della generazione degli script, deve essere integrato completamente con il repository del database source control. Questa integrazione fornirà informazioni importanti, come ad esempio quando due ambienti del database sono stati uniti in uno solo, pronto e disponibile per gli sviluppatori.

Senza un database source control attivo, è facile che i team che lavorano sul database si sovrascrivano accidentalmente il codice a vicenda. Un database source control completo, nel contempo, renderebbe noto ad ogni sviluppatore chi ha fatto cosa, quando, come e perché.

Fare progressi

Ciascuno dei tre approcci appena citati ha i propri vantaggi, ma senza dubbio i primi due creano gravi colli di bottiglia e costrizioni quando si cerca di produrre risultati efficienti.

La soluzione? Rendere il database parte della risposta invece che solo la domanda. Con un piccolo know-how e seguendo queste migliori pratiche per la continuous integration, si può ottenere una migliore gestione delle change, in cui le modifiche vengono gestite e modificate direttamente nel database.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of ddpavumba at FreeDigitalPhotos.net

Continuous Integration e DB: le Best Practice da seguire

DIGITAL AGILITY: TRA TEORIA E PRATICA

devops-digital-agility-defined

Il concetto di digital agility, e più nello specifico di DevOps, ancora oggi viene considerato una novità, un salto generazionale, nonostante sia messo in pratica dalla maggior parte delle organizzazioni da una decina di anni a questa parte e nonostante sia un’idea nata nei primi anni novanta.

Molto è stato detto e dibattuto sul tema della digital agility, nonostante questo, molte aziende faticano a stare al passo con un programma ben strutturato e implementato correttamente: è per questo che, nonostante la storia relativamente lunga alle sue spalle, la realizzazione del DevOps resta un concetto nuovo.

Gli executive si sono affezionati alla teoria della digital agility, tuttavia si trovano in difficoltà di fronte all’applicazione pratica all’interno del ciclo di vita del software – dall’idea alla consegna. In più, come spesso accade, se si parla di DevOps, uno dei punti principali da considerare, che viene spesso sottovalutato, è il database.

Dimenticarsi i passaggi chiave nel life cycle quando si implementa il DevOpsdigital-agility-in-sdlc

I database sono i custodi delle informazioni aziendali più importanti ed è necessario dargli l’importanza che meritano – considerato che sono più vitali dello stesso codice scritto per un software aziendale. Quindi è fondamentale chiudere il gap tra automazione del codice sorgente e automazione del database. Per raggiungere questo obiettivo bisogna implementare i processi del continuous delivery del codice sorgente nel DevOps per il database.

Il DevOps per il database richiede le stesse buone norme del codice sorgente:

  • Rafforzamento di pratiche di utilizzo;
  • Rafforzamento del controllo di versione;
  • Creazione di processi di automazione sicuri;
  • Inclusione del database nei processi continui e nel loop di feedback, ecc.

La cosa più importante è assicurarsi di avere un modo per controllare questi processi e, se qualcosa deve essere sistemato, disporre di notifiche automatiche e bandiere rosse che indichino il problema.

Un buon DevOps: andiamo al nocciolo della questione

Come già affermato in precedenza, un continuous delivery del database non è così semplice. I database non sono una semplice raccolta di file, ma contengono informazioni sui clienti, dati di transizione, contenuto delle applicazioni, ecc. Per permettere all’automazione di lavorare al meglio, c’è bisogno di un codice di transizione solido, creato per gestire la struttura dello schema e il codice del database e contenuti come i metadati.

devops-collaborationInoltre esistono modifiche del livello di organizzazione richieste per assicurare un continuous delivery del database adeguato. Sia i DBA che i manager C-level dovranno adottare questi metodi di sviluppo per il database. Non è certo un lavoro che si può gestire da soli: entrambe le parti devono essere sostenute dall’automazione del database.

Comporre il puzzle

L’importanza del database per l’organizzazione è evidente. È per questo che i DBA sono terrorizzati all’idea dell’automazione e il management non la sta forzando.

Paradossalmente dovrebbe essere l’esatto opposto: i DBA dovrebbero essere più positivi riguardo all’automazione e al controllo del database. Ci si chiede sempre cosa potrebbe andare storto se si utilizzasse il continuous delivery per il database, ma forse sarebbe meglio chiedersi cosa accadrebbe se NON si introducesse il continuous delivery nel database.

Pur ammettendo che l’automazione dell’utilizzo del database non è un processo semplice, bisogna considerare che, assicurando il continuous delivery, la produttività verrebbe incrementata, il time to market si ridurrebbe, verrebbero ridotti i rischi e la qualità migliorerebbe. Se le pratiche e i principi non sono comuni ad ogni area dell’impresa e ad ogni stage del life cycle, la digital agility è un obiettivo ancora lontano.

Il DevOps è un processo continuativo e presenterà ad ogni azienda sfide diverse a seconda della propria cultura. Inoltre è una delle tendenze di più lunga data nel mondo IT, ma considerato che molti ancora non riescono a combinare la teoria e la pratica, è meglio tenersi in ascolto sulle novità del DevOps.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

DIGITAL AGILITY: TRA TEORIA E PRATICA

6 ERRORI NEL DEVOPS CHE FRENANO LE AZIENDE

mistake-876597-220504-edited

L’adozione del modello DevOps è un must per le aziende che vogliono cavalcare la cresta dell’innovazione. Tuttavia insieme ai miglioramenti in termini di velocità ed efficienza, il DevOps porta anche grandi responsabilità.

Ecco i 6 errori nel DevOps che l’IT dovrebbe evitare:

Preferire la velocità alla qualità

Molti degli executive alle prime armi col DevOps si preoccupano troppo di rilasciare velocemente le applicazioni, senza però preoccuparsi di eseguire dei test. Per trovare il miglior equilibrio tra velocità, qualità e sicurezza, gli executive IT dovrebbero lavorare a stretto contatto con sviluppatori, gli operator e i database administrator. Quando non accade, potrebbe capitare che l’applicazione presenti errori e che il database sia vulnerabile ad attacchi. 

Eseguire i test alla fine del ciclo produttivo

I test non vanno eseguiti alla fine del ciclo produttivo. Troppo spesso sono fonte di sorprese spiacevoli (glitch) e problemi imprevisti per chiunque sia convolto. Gli sviluppatori, grazie ai moderni tool open source e ai linguaggi di dominio specifico, possono effettuare test di performance.

Gli sviluppatori si stanno responsabilizzando e stanno adottando dei test di performance su piccoli volumi per esaminare le funzionalità e performance tramite API endpoint. Questi diventano poi i blocchi essenziali per l’integrazione automatizzata, i deploy e i test di post produzione. In più, per risparmiare tempo, molti test possono essere eseguiti contemporaneamente. 

Limitare agli sviluppatori l’uso dei tool

Nelle aziende con ampie sezioni IT, i team DevOps potrebbero patire l’uso condiviso di un unico ventaglio di strumenti. Se compreso e implementato correttamente, il DevOps permette alle aziende di creare team più piccoli e autosufficienti,  dalla costante comunicazione interna e con gli altri team e gruppi di progetto. In questo modo ogni unità può personalizzare il DevOps e gli strumenti di continuous delivery secondo le proprie necessità.

Supporre che i tool non siano compatibili

Tra gli sviluppatori l’uso di strumenti open source è molto diffuso e molti hanno delle particolari preferenze. Molti tool sono ora compatibili uno con l’altro, soprattutto se è presente un framework di gestione unificata che permette di formare una catena DevOps senza limitare le scelte personali degli sviluppatori.

social-media-1744854

Non condividere le responsabilità

Con il DevOps i ruoli e le responsabilità dei team di sviluppo e operation sono fluidi nel caso migliore e mal definiti nel caso peggiore. La volontà di collaborare e sporcarsi le mani in compiti che prima il lavoro non prevedeva sono i presupposti per il successo.

Considerate per esempio la responsabilità di creare team uniti e performanti: tutti i compiti fondamentali – incluso l’abbattimento dei silos creati dal sistema waterfall – ricadono sulle spalle di tutti, dal CIO al DBA.

Dimenticarsi del database

Un elemento fondamentale dell’ecosistema IT – spesso sottovalutato quando si adotta il DevOps –  è il database. Questo accade a causa di un’idea sbagliata sullo sviluppo automatizzato dei database, che risulta infondata se l’infrastruttura automatizzata è ben strutturata, implementata in modo intelligente e completamente trasparente.

Se le aziende IT adottassero il codice automatizzato per i processi manuali del database, l’intero ciclo di sviluppo verrebbe rallentato, su questo non ci sono dubbi. Il DevOps deve essere messo in atto in tutti i settori e in tutto l’ecosistema software per lavorare. Un’automazione del database di questo tipo non solo è realizzabile, ma è essenziale per il successo di un vasto programma DevOps.

Per evitare errori nel DevOps, non resta che mettere tutto insieme

Il modo più efficace per implementare strategie di integrazione continuativa è evitare errori nel DevOps, che è un programma molto impegnativo, ma cominciando a prestare attenzione a questi primi sei errori comuni, l’obiettivo si avvicinerà.

Cambiare i processi di organizzazione col DevOps vi permetterà un’automazione sicura che consentirà rilasci veloci e senza errori, ma per avere il massimo dei risultati dalla metodologia DevOps non bisogna dimenticarsi del database.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

6 ERRORI NEL DEVOPS CHE FRENANO LE AZIENDE

DevOps e Security danno vita al DevSecOps

Bug. Falle di sicurezza. Rallentamenti. Si tratta d’imprevisti costosi, difficili da riparare, e che possono causare una reputazione negativa da cui è complicato liberarsi.

I team DevOps e di Security come possono lavorare insieme per gestire questi rischi?

Le risorse operanti in ambito DevOps e i team di Security hanno bisogno di soddisfare i propri obiettivi: il DevOps mira a sviluppare e rilasciare il software rapidamente, la Security intende mitigare e gestire il rischio controllando accuratamente qualsiasi elemento fragile o violabile all’interno del software.

La combinazione dei due si chiama “DevSecOps”.

Il “DevSecOps” è un approccio volto a perseguire un perfetto allineamento tra il DevOps e il mondo della sicurezza informatica, con l’obiettivo di:

  • ottimizzare il Risk Management;
  • accelerare l’individuazione di falle di sicurezza;
  • automatizzare e orchestrare le change necessarie nelle catene dei servizi di sicurezza.

Partendo dal presupposto secondo cui la sicurezza è e sempre sarà una parte integrante del ciclo di vita del software, il SecDevOps integra misure di sicurezza nella filosofia dello sviluppo e del deployment automatizzato.

La transizione verso il “DevSecOps” aprirà le porte ad un modo più dinamico e sicuro di gestire le infrastrutture e il deployment automatizzato, facendo della sicurezza una responsabilità condivisa da tutta l’organizzazione e una realtà ben salda a tutte le tappe del processo di sviluppo.

Come approcciarsi al DevSecOps?

Segui il webinar “New Frontier in DevSecOps”.

Scarica il whitepaper “Security and Compliance: Six Ways to Ensure Your Database Is Not a Vulnerability”.

Scopri la nuova feature di DBmaestro in ambito DevSecOps: “Policy Control Manager”.

DevOps e Security danno vita al DevSecOps

DEVSECOPS: UN SOFTWARE MIGLIORE, PIÙ VELOCE

Secondo una ricerca condotta da Sonatype, su 16 componenti open source e di terze parti almeno uno possiede una vulnerabilità nota. Questo dato potrebbe non sembrare eccessivo finchè non ci si rende conto che una società media scarica oltre 200.000 componenti all’anno. Questi componenti vengono scaricati dai team di sviluppo, i quali sono spesso inconsapevoli di eventuali vulnerabilità.

 Come verificare la qualità dei componenti utilizzati?

Ovviamente, è fuori discussione rivedere manualmente ogni componente che si desidera scaricare e utilizzare: infatti, questo genere di review richiederebbe 2/4 ore per ogni componente e nessuna azienda ha tempo o risorse per farlo.

Tuttavia, esiste un modo più semplice (e gratuito) per capire se il repository contiene componenti con rischi noti di vulnerabilità di sicurezza o di licenza. Si tratta del Repository Health Check, una soluzione che permette di analizzare il proprio repository e individuare componenti con vulnerabilità o a rischio.

screen-shot-2015-08-05-at-2.06.33-pm

Proteggere la porta d’ingresso, la casa e la porta posteriore

  • Proteggere la porta d’ingresso.

Attivando la funzionalità del Repository Health Check, il report elaborato permette di rivelare la presenza di componenti indesiderati. Inoltre, grazie a Nexus Firewall, è possibile implementare un “controllo cyber” verso la “porta d’ingresso” del repository, con l’obiettivo di prevenire futuri download di componenti con vulnerabilità note, a rischio o non aggiornati.

  • Proteggere la casa.

Il software dura quanto il latte, non quanto il vino. Ciò che è perfettamente accettabile un giorno, può diventare estremamente rischioso il giorno dopo. Pertanto, è possibile continuare ad utilizzare i report del Repository Health Check per verificare automaticamente nel corso del tempo ogni possibile cambiamento del proprio repository.

  • Proteggere la porta posteriore.

Per coloro che utilizzano repository di staging nelle proprie configurazioni, Nexus Firewall può aiutare ad analizzare le possibili release. La suite di staging (disponibile nella versione commerciale di Nexus Repository) consente ad un’azienda di creare un repository temporaneo di staging e gestire la promozione dei componenti dallo staging ad un repository di rilascio. La possibilità di creare un repository isolato di potenziali release, che possono essere scartate o promosse, permette di supportare le decisioni che vanno a certificare una determinata release. Ciò consente di controllare meglio l’esatta serie di binari che alla fine sarà rilasciata.

Inoltre, con la soluzione Nexus Firewall, ogni componente nel repository di staging può essere valutato in base alle vulnerabilità note di sicurezza, alle versioni non aggiornate/indesiderate, o alle licenze rischiose. Utilizzato in questo modo, Nexus Firewall non solo protegge la “porta d’ingresso” del repository nel momento in cui si effettua il download dei componenti, ma custodisce anche la “porta posteriore” prima degli effettivi rilasci.

screen-shot-2016-01-25-at-11.38.41-am

Risolvere grandi problemi

Come affermato da Deming, pioniere del DevOps, “per risolvere un grosso problema, è necessario innanzitutto rendersi conto di avere uno”.

Tutti noi abbiamo una supply chain del software che alimenta i componenti all’interno dei nostri repository manager ed è per questo motivo che una migliore visibilità sui componenti utilizzati potrebbe permetterci di individuare e risolvere le problematiche esistenti, a favore di un software migliore, ancora più veloce.

Questo topic copre solo un aspetto della DevSecOps. Infatti, c’è molto di più da imparare su questo argomento.

Partecipa al DevSecOps survey: rispondi ad alcune brevi domande e potrai vincere il nuovo MacBook Air.

DEVSECOPS: UN SOFTWARE MIGLIORE, PIÙ VELOCE