Author Archive

Home / Author's Article(s) / Manuel Fontana

Per tutti coloro nati agli inizi degli anni ‘90 era abitudine vedere in tv cartoni animati ambientati nel futuro, come ad esempio “Futurama”, nel quale era facile osservare navette spaziali parlanti (come la Planet Express ad esempio, la stessa utilizzata dai protagonisti per effettuare spostamenti interstellari), alieni e robot che coabitavano insieme agli essere umani, animali geneticamente modificati, ecc..in una realtà futurista ed in parte virtuale.

In questo caso è anche facile osservare lo stile “estremo” tipico di un ambiente Statunitense, ovvero tutto molto “troppo in grande”.

Ovviamente si trattava di un cartoon.

 

 

Ma parliamo invece dell’attualità.

Con l’ingresso di grandi colossi presenti sul mercato nel mondo Metaverso, le cose stanno cambiando.

Vivere il virtuale è un fattore che incuriosisce da un lato e dall’altro spaventa. 

Perchè?

Innanzitutto l’idea di trasformare il proprio aspetto carnale, tangibile e percepibile dai nostri sensi in un avatar modificabile a proprio piacimento, intriga. 

Il concetto di trascendenza umana, di materializzazione e di smaterializzazione del corpo è senza ombra di dubbio qualcosa di affascinante. 

Dall’altro lato, siamo davvero sicuri che il metaverso rappresenta e rappresenterà il luogo di sicurezza nel quale gli utenti troveranno la loro dimensione?

Quali saranno le conseguenze che l’essere umano, a livello sociale, a livello di gruppo sociale, andrà in contro? 

Il costrutto di una realtà virtuale e di uno spazio di movimento virtuale trova le sue origini nei social network, strumenti di comunicazione nati con scopi ben precisi e che, a seguito di un utilizzo eccessivo, usati con scopi diversi.

Se da un lato il social può rappresentare il luogo sicuro di chi è timido, non ha il coraggio di esporsi, ha una bassa autostima, ecc, dall’altro, può essere usato da coloro che hanno voglia di distruggere: distruggere le persone, le loro reputazioni, il loro stato emotivo, insomma, i così chiamati haters e/o leoni da tastiera.

Inoltre, quali tipi di valori continuano a diffondere ed a comunicare i social ai giovani?

Prendiamo Instagram ad esempio: offre la possibilità di APPARIRE perfetti; esatto, la perfezione della bellezza estetica è ricercata nella stra gran maggioranza degli utenti (specialmente giovani).

 

 

 

Si viene catturati dall’algoritmo stesso che, in modo irrefrenabile, ci spinge a controllare quanti like riceviamo, quante visualizzazioni alle nostre storie raggiungiamo, chi ha commentato, che cosa ha scritto, e via dicendo…

Il bombardamento mediatico di modelli ispiratori di perfezione e bellezza estetica riguardano principalmente i nostri giovani, che vogliono raggiungere ed imitare influencer, per raggiungere la loro fama ed il loro successo.

Più sei bello, più sei perfetto, più sei accettato e seguito: questo è l’algoritmo mentale dei giovani di oggi, ed è completamente negativo e sbagliato.

L’uso improprio di qualsiasi strumento può compromettere davvero seri problemi alla vita delle persone, figuriamoci dei giovani soprattutto in età adolescenziale; quanti sono stati i casi di giovani che hanno accettato sfide estreme vivendo il loro corpo con disagio e vergogna?!

I social, se mal usati, portano i valori umani negativi, quali l’invidia, la rabbia, la gelosia, ad aumentare a livelli esponenziali, compromettendo le relazioni sociali. 

Allo stesso tempo però, se usati con coscienza, sono ottimi strumenti di collaborazione, unione (anche se spesso uniscono persone distanti fisicamente tra loro, ma allo stesso tempo rappresentano il ponte tra queste persone), integrazione sociale. ricerca della propria identità (grazie a gruppi di interessi attraverso i quali è possibile poter scambiare opinioni e punti di vista costruttivi).

La diffusione di prototipi e modelli di bellezza fisica da seguire e da imitare trovano spazio dove ci sono due mancanze precise: l’autostima e la mancanza di una propria identità.

Entrare a far parte del Metaverso è sicuramente un’innovazione che segna la storia dei tempi, ma bisogna farlo con seguendo valori etici ed equilibrio, senza lasciarsi “mangiare” completamente dalla novità di quel mondo, un mondo che rimane comunque virtuale, NON fisico!

Il metaverso sarà per tutti un’occasione, un’opportunità, non un rischio, limitando al massimo tutte le conseguenze che socialmente rappresenteranno un pericolo per ciascun individuo.

 

 

Questo articolo è volto a presentare in maniera generica le tappe che, nel mondo dell’informatica, hanno portato alla containerizzazione dei servizi e, di conseguenza, a Kubernetes.

Innanzitutto è bene definire Kubernetes come una piattaforma open-source utilizzata per la gestione di servizi containerizzati che facilita da un lato la configurazione dichiarativa di questi e, dall’altro, l’intero processo di automazione.

Kubernetes è una piattaforma estensibile, dotata di un grande e vasto ecosistema in esponenziale crescita: tutto il supporto, gli strumenti ed i servizi sono disponibili all’interno di questo mondo.

Prima di parlare delle fasi che hanno portato all’ideazione di Kubernetes, spieghiamo l’origine del nome; Kubernetes è un termine che deriva dal greco e vuol dire pilota; la piattaforma è stata resa open source da Google nel 2014 ed unisce una pluridecennale esperienza nell’esperienza di carichi di lavoro di produzione su scala mondiale, grazie all’utilizzo delle migliori idee e pratiche della comunità.

Perché Kubernetes è diventata così utile oggigiorno?
STEP BY STEP developers!, Dividiamo la sua evoluzione in 3 fasi principali:

1. Fase del deployment classico/tradizionale: le applicazioni usate dalle organizzazioni, erano eseguite su server fisici; di conseguenza non c’era il modo di definire eventuali limiti delle risorse!
Questo comportò nel tempo molti problemi in termine di allocazione delle risorse.
Per quale motivo???
Dunque, immaginate che un numero elevato di applicazioni vengano eseguite sullo stesso server fisico; ci potrebbe essere la possibilità che una di queste (in particolare) possa assorbire maggiori risorse, togliendo alle restanti applicazioni la possibilità di offrire le prestazioni attesa.
La soluzione sarebbe quindi quella di eseguire ogni applicazione su server fisico, ma DIVERSO!
La conseguenza sarebbe un aumento dei costi per le organizzazioni (più software fisici presenti da mantenere —>più costi ingenti da sostenere) ed un sottoutilizzo delle risorse!

2. Fase della virtualizzazione del deployment: ecco che, per far fronte al problema di cui sopra abbiamo accennato, entrò in gioco la virtualizzazione.
Si presentò da subito come una buona soluzione che permise di eseguire più macchine virtuali (le VM) su una singola CPU fisica.
Di conseguenza, il beneficio fu quello di isolare le applicazioni su più macchine virtuali, fornendo così un livello di sicurezza nettamente superiore, dal momento in cui le informazioni di un’applicazione non sono accessibili da un’altra applicazione.
Quali sono stati altri benefici che la virtualizzazione ha portato?
Migliore utilizzo delle risorse con riduzione dei costi per hardware
Migliore scalabilità
Ogni VM rappresenta una macchina completa che esegue tutti i componenti (compreso il proprio sistema operativo).

3. La fase del deployment containerizzato: first of all, è bene definire il concetto di container, ovvero: i container sono molto simili alle macchine virtuali ma dispongono di un modello di isolamento più leggero e condividono il sistema operativo (OS) tra tutte le applicazioni.
Ecco perché i container sono considerati leggeri ed, inoltre, sono disaccoppiati dall’infrastruttura sottostante, risultando portabili tra diversi cloud e varie distribuzioni.

Perché i container nel tempo hanno raggiunto popolarità?
Ovviamente per i loro vantaggi, quali ad esempio:

1. Creazione e distribuzione di applicazioni in modalità Agile: si ha maggiore facilità e maggiore efficienza nella creazione di immagini containerizzata rispetto a quelle VM;

2.Utilizzo di pratiche per lo sviluppo/test/rilascio continuativo: grazie a ciò è possibile creare e distribuire container image con un alto livello di affidabilità, offrendo allo stesso tempo la possibilità di effettuare rollback veloci e semplici (grazie al fatto che l’immagine rimane la stessa e non cambia);

3. Dev ed Ops SEPARATI: tutte le container image sono prodotte nel momento in cui avviene la compilazione dell’applicativo piuttosto e non nel momento di rilascio; questo fa sì che si presenta un disaccoppiamento tra le applicazioni dell’infrastruttura sottostante.

4. Parola d’ordine? COERENZA: esatto, perché tra i diversi ambienti (sviluppo, test e produzione), c’è coerenza ed i container funzionano allo stesso modo, sia su un pc portatile, sia sul cloud.

5. Portabilità tra cloud e sistemi operativi diversi: il medesimo container funziona su Ubuntu, RHEL, CoreOS, on-premise.

6. Libertà di combinazione dei microservizi: i microservizi sono liberamente combinabili e liberamente distribuiti con un’elevata scalabilità: tutte le app sono divise in parti più piccole ed indipendenti tra loro che possono essere gestite in maniera dinamica (no ad eventuali stack monolitici che girano su una singola grande macchina).

7. Risorse isolate: tutte le prestazioni delle app sono facilmente prevedibili;

8. Uso delle risorse: i container garantiscono efficienza e densità.

Ma perché è bene usare Kubernetes?

I container rappresentano un ottimo modo per la distribuzione e l’esecuzioni delle applicazioni.
All’interno di un ambiente di produzione, ad esempio, è prioritario gestire container che eseguono applicazioni garantendo l’assenza di interruzioni di servizi.
Pensate alla situazioni in cui un container si interrompe e bisogna avviarne un altro.
Tutto sarebbe più facile se fosse gestito SOLO da un sistema, giusto?

ECCO! E’ per questo che Kubernetes entra in gioco.
Kubernetes fornisce un framework per il funzionamento dei sistemi che vengono distribuiti in modo resiliente ed, inoltre, si occupa di garantire scalabilità, distribuzione e failover.

Kubernetes è fonte di vantaggi e benefici, come ad esempio:
1. Usando Kubernetes si ha la possibilità di esporre un container usando un DNS o l’indirizzo IP (qualora il traffico diretto ad un container fosse alto, Kubernetes interviene distribuendo il traffico su più container garantendo stabilità a tutto il sistema);

2. Storage Orchestrato: grazie a Kubernetes si ha la possibilità di montare in maniera automatica un sistema di archiviazione a scelta: che sia locale, con dischi forniti da public cloud, ecc

3. Rollout e rollback automatizzati: Kubernetes è in grado di cambiare lo stato attuale dei propri container per raggiungere quello che si desidera con una velocità controllata.
Se, ad esempio, il tuo team IT sta creando nuovi container per alcuni tuoi servizi, Kubernetes permette di rimuovere i container già esistenti, adattandoli alle risorse che vengono richieste da quelli nuovi.

Kubernetes è dotato di un sistema intelligente di Self-Healing, in grado di sostituire i container che si bloccano e di terminare quelli che non rispondono agli health checks, evitando di fare arrivare traffico ai container che non sono in grado di rispondere correttamente.

La privacy è importante: Kubernetes consente di memorizzare e di gestire le informazioni sensibili come token OAuth, password,….
Inoltre, è possibile distribuire ed aggiornare le informazioni sensibili configurando le applicazioni senza dover ricostruire le immagini dei container evitando quindi di svelare le informazioni sensibili nel momento di configurazione del sistema.
Se vuoi anche tu passare a Kubernetes, contattaci!
Saremo lieti di aiutarti e di guidarti passo dopo passo in questa tua scelta.

Il koda engine è il componente che si occupa di interfacciarsi con il docker-engine.

E’ stato scelto docker come “backend” per via della sua ampia diffusione, in quanto container engine mette a disposizione tutti gli strumenti necessari per sviluppare e buildare immagini.

Ma non solo, docker è di fatto lo standard nell’industria, in particolare la maggior parte degli sviluppatori utilizza proprio questo container engine.

Scegliere un altro engine avrebbe soltanto ridotto la potenziale platea.

Ci teniamo anche a dire che per esempio in Kubernetes docker non è l’engine più diffuso; infatti il supporto a docker-shim è stato rimosso se non fosse stato per Mirantis con cri-dockerd quest’ultimo sarebbe stato tagliato fuori.

 

Quindi, nel concreto, questo koda-engine cosa fa?

 

KoDa Engine è principalmente un server api, si basa sulla Docker SDK per python e su flask-RESTful.

La SDK ci permette di connetterci alle api di docker-engine, questi api possono essere in locale oppure su un server remoto,

mentre flask-RESTful data la sua minimalità ci permette di sviluppare in fretta le api.

 

Come si gesticono le risorse con la SDK?

 

Per implementare la CRUD è sufficiente connetersi all’engine e interrogarlo.

Le risorse che abbiamo deciso di gestire sono:

 

– Images

– Networks

– Volumes

– Containers

 

Dato che sotto la scocca del SDK vengono effettuate chiamate REST al’engine, per ogni classe di risorse abbiamo gratis i metodi CRUD.

Eventualmente stiamo anche valutando se può essere utile aggiungere un database per salvare i metadati.

 

Come si creano ambienti di sviluppo con la SDK?

 

Questo passaggio è quello più macchinoso nel senso che si divide in questi passaggi:

 

– Buildare / Pullare le imagini da un registry;

– Creare una network;

– Far partire i container collegandoli alla rete creata nel passo precedente.

 

Questi passaggi ricalcano le funzionalità di docker-compose in un certo senso, ma permettono anche una maggiore configurabilità.

Vorremmo fare anche una precisazione sui volumi, la SDK è agnostica rispetto allo storage backend, perciò se sull’host ad esempio c’è installato CEPH KoDa funzionarà lo stesso.

 

Come si creano le build automatiche?

 

Per creare le build sono necessarie due dipendenze, la SDK come sempre e python-jinja2.

Jinja2 è un template engine, quindi nel nostro caso è sufficiente creare una libreria di immagini per i casi d’uso più frequenti:

 

– react

– node.js

– python

– larave

– golang

– dotnet

 

Successivamente, creati questi template, si passeranno i parametri di build alle api di KoDa-engine, quest’ultimo eseguira i seguenti passaggi:

 

– Parserà i template valorizzandoli;

– La SDK, usando le Low-Level API creerà un’ immagine;

– Sempre la SDK, potrà o pushare su un registry oppure farà partire il container.

 

Ovviamente, per creare le immagini è necessario passare a KoDa un archivio di tutto il sorgente.

 

Per il momento questo è tutto, a presto con nuovi aggiornamenti

 

Come anticipato nell’articolo precedente, quando le aziende decidono di affidarsi a qualche figura esterna, è bene fare molto attenzione ad un elemento chiave che unirà le due realtà, ovvero la fiducia, necessaria in ogni tipo di relazione.

Per valutare la fiducia è bene tenere in considerazione alcuni fattori, SPECIALMENTE quando si ha a che fare con ingenti investimenti e si delocalizza il proprio budget (parzialmente o totalmente) al di fuori.

Per scegliere il partner ideale bisogna prendere in considerazione realtà che certificano le proprie competenze e NON solo con le parole.

In questo articolo seguirà un’interessante intervista rilasciata da 3 dei nostri tecnici che ci spiegheranno con parole semplici e comprensibili, l’importanza di ottenere la certificazione Azure DevOps e cosa rappresenta il DevOps secondo il loro punto di vista.

Prima di mostrare le domande fatte, facciamo un piccolo chiarimento sul concetto di DevOps, che rappresenta un approccio culturale relativamente nuovo, che nasce dall’integrazione di Dev (development) e Ops (Operators), ovvero unisce il mondo dello sviluppo e degli operatori IT in modo CONTINUO, facilitando i processi, la risoluzione di eventuali bug di sistema, ecc, rendendo il sistema Agile ed è  una logica integrata in cui i diversi aspetti di pianificazione, sviluppo, test, deploy, produzione e monitoraggio si relazionano all’interno di un processo organico e continuo.

 

A tal proposito, presentiamo Matteo Sposato (Team Leader), Eduardo Zapata (Team Leader) ed infine Ivan Soreca (Developer) che hanno risposto ad alcune domande, quali: 

 

  1. Come definireste il DevOps?
  2. Perché è necessario certificarsi? 
  3. Qual è stata la difficoltà che avete riscontrato durante il vostro percorso verso la certificazione?
  4. Qual è il valore aggiunto/pratico che dà la certificazione?
  5. Pensate che il DevOps sia il futuro dell’informatica? 

 

Matteo Sposato (Team Leader): 

 

  1.  Il devops lo definirei come una metodologia di lavoro,  basata sulla collaborazione tra figure complementari. Per essere più chiari, se uno sviluppatore e un sistemista collaborano nella maintenance di un applicativo è più probabile che i problemi che emergono vengano risolti grazie al fatto che i due “rami” lavorano all’unisono.
  2. Non credo che certificarsi sia necessario a livello personale, la necessità sorge quando ci si deve rapportare con realtà enterprise, poiché queste ultime,  per come sono strutturate, hanno bisogno di avere delle certezze!
  3. La difficoltà più grande è quella di dover imparare come vengono fatte le domande all’esame dato che non c’è parte pratica!
  4. Il valore aggiunto come dicevo prima è la possibilità di prender parte a progetti enterprise, che, di conseguenza, comporta anche il dover rapportati con persone molto competenti. Sicuramente studiare ti permette di avere anche una panoramica dei servizi, quindi più consapevolezza nella scelta della tecnologia.
  5. Penso che il DevOps sia un nuovo modello per una piccola parte del mondo informatico, principalmente se si forniscono servizi. Credo anche che la collaborazione a qualsiasi livello sia una cosa auspicabile in generale.

 

Eduardo Zapata (Team Leader): 

 

  1. Il DevOps è un concetto molto difficile da spiegare; è utile e va bene sia per tutti coloro che hanno nel loro bagaglio una serie di competenze IT, sia per la programmazione, perciò sia per il team degli sviluppatori, sia per il team Operation, un po’ come succede tra Matteo, Ivan ed io (come Matteo Ivan ed io) e quindi possiamo mettere mano al DevOps direttamente senza passare da un’analista funzionale.
    Un altro approccio relativo al DevOps facile fa spiegare è che una persona che non conosce nulla di programmazione, grazie ai tool offerti da Microsoft, può arrivare ad ottenere gli stessi risultati e gli stessi obiettivi perché si hanno molti elementi già precompilati.
  2. E’ un piccolo traguardo personale (ce l’ho fatta, ho una certificazione e gratificazione personale); dal punto di vista aziendale invece è stata necessaria per poterci offrire la possibilità di gestire progetti molto più grandi e ci avrebbe aperto le porte a future ed ottimali collaborazioni con partner di una certa notorietà.
  3. Il tempo, perché per prepararsi era molto difficile ed il tempo, era quasi inesistente! L’impegno e la volontà di raggiungere questa certificazione però, hanno abbattuto ogni ostacolo ed ogni presunta difficoltà.
  4. Il valore aggiunto si ritrova nella possibilità di gestire progetti di grande valore, potendo collaborare con clienti importanti! Ormai si sta passando tutto al Cloud e quindi avere persone competenti in materia ed orizzontali allo stesso tempo sulle tecnologie utilizzate, risulta essere un plus a livello aziendale.
    Le persone competenti hanno quindi la possibilità di gestire il progetto in tutte le parti di esso!
  5. Secondo me sì, rappresenta una parte del futuro dell’informatica! Avere coesione tra il team di sviluppo e di operation è davvero un punto di forza da riconoscere alle aziende IT.

 

Ivan Soreca (Developer): 

  1. Il DevOps a mio avviso lo identifico come l’insieme delle capacità e delle conoscenze di strumenti generici, nel senso che non c’è una vera e propria e singola specializzazione che comprende TUTTO ciò che viene fatto oggi in termini di infrastruttura, che confluiscono in un’unica persona.
  2. Di certo la soddisfazione personale di avere raggiunto un traguardo così importante!
  3. Direi il tempo e le domande! Il DevOps non è un argomento facile e le domande all’esame sono davvero toste! Inizialmente poi alcuni concetti non erano per niente semplicissimi (configurazione di file ad esempio) e non è come imparare un qualsiasi linguaggio di programmazione nuovo; una volta che impari un linguaggio di programmazione lo conosci e continui senza problemi; hai delle perplessità? Trovi le risposte con un’infinità di dispense online che ti aiutano; il DevOps no!
  4. La certificazione ti porta (non solo come detto prima ad una tua soddisfazione personale), ma a poter lavorare per clienti grandi gestendo progetti di una certa portata.
  5. Secondo me sì, può rappresentare il futuro dell’ informatica che è un campo che cambia moltissimo in base a quello che piace di più e si sta puntando su questa soluzione (devops) avendo una figura unica che fa più o meno tutto e alle aziende fa comodo e più stabile perché non hai tante persone che fanno cose diverse.

E’ molto importante poter dare voce a chi nel settore se ne intende: ciò può essere utile a tutti (chi già sa e chi no) di poter imparare nozioni nuove ed approcciarsi al mondo del DevOps a piccoli passi.

Se devi scegliere un partner esperto, fallo in maniera intelligente: ascolta le parole, ma guarda i fatti!!

 

Openshift: alcuni semplici concetti

Introduciamo il concetto di Openshift definendolo come una piattaforma Kubernetes Entreprise che consente, a chi la utilizza, di poter godere di un’esperienza simile al cloud in tutti i tipi di ambienti.

Openshift offre una serie di possibilità: puoi scegliere dove creare, dove distribuire e dove eseguire le applicazioni mantenendo sempre un’esperienza coerente, realizzando un’ottimale collaborazione tra il mondo Dev ed il mondo Ops (Developers ed Operations), ottenendo la massima efficienza!

Dev ed Ops vi ricorda qualcosa? Abbiamo parlato diverse volte di DevOps, sottolineando che per descriverlo, esistono svariate definizioni.

Il DevOps (link di seguito se siete curiosi e volete sapere di cosa si tratta e quali sono i vantaggi che si ottengono https://www.bluecube.it/devops-significato-definizione/), rappresenta una nuova cultura, un nuovo approccio, un’evoluzione che migliora ed ottimizza i tempi, le risorse ed i processi aziendali ed ha come obiettivo principale il miglioramento della collaborazione tra sviluppatori ed operations per velocizzare la realizzazione di software e rendere più efficienti i relativi processi.

Il fatto di poter ottenere un illimitato ed imminente accesso alle informazioni (grazie ad un maggior numero e varietà di canali disponibili), ha contribuito a creare quindi un metodo di lavoro composto da ritmi frenetici e dalla necessità da parte degli utenti di avere un risposte ed informazioni immediate.
Il tempo è tutto quindi! La velocità è uno dei fondamenti di questo processo, così che DevOps ha creato un modello in grado di velocizzare l’innovazione del business aziendale in termini digitali.

Ecco che il DevOps si presenta come un approccio (culturale) più efficiente allo sviluppo del software che sfrutta le potenzialità di un insieme di processi (che insieme delineano una metodologia) che aumenti la velocità e la flessibilità con cui nuove funzionalità e nuovi servizi vengono forniti.
In tutto ciò, non va dimenticato che la metodologia DevOps offre SICUREZZA al 100% su servizi software molto innovativi.
La filosofia del DevOps si basa sul sistema Agile, consentendo una riduzione dei tempi di sviluppo ed una messa in produzione automatica e continua, apportando miglioramenti al time-to-market.
Ecco che è possibile anche ottenere un’elevata qualità del software con molti meno bug e molte più funzionalità.
Il DevOps, per un’architettura Cloud Native, è un elemento fondamentale!

Openshift: i microservizi

Per microservizi si intende una serie funzionalità importanti che sono alla base dell’approccio architetturale con cui si suddividono le funzionalità di un applicativo, rendendo quindi il servizio di piccole dimensioni ed indipendente dagli altri in termine di implementazione, manutenzione e codice.
Ciò rende possibile il fatto per cui si hanno diversi team occupati su microservizi diversi in modo indipendente e parallelo, comportando un vantaggio esponenziale sia nello sviluppo evolutivo, sia nella manutenzione ordinaria del software che viene realizzato.
Andiamo ora ad analizzare alcuni dei microservizi come segue.

Openshift: virtualizza le tue idee con i container!

I container rappresentano un’evoluzione dell’idea di virtualizzazione tradizionale; sfruttano le capacità del kernel di un sistema operativo (specialmente Linux) , rendendo la coesione di più istanza isolate ed autonome nello spazio utente, permettendo di conseguenza di isolare un’applicazione e tutte le sue dipendenze in un ambiente autonomo.
I container possono essere eseguiti su ogni tipo di piattaforma e server (per lo sviluppo, per il test ed anche per la messa in produzione), garantendo un vantaggio competitivo per moltissime aziende.

Openshift: Automatizza la tua Infrastruttura

Automatizzare un processo e/o un insieme di processi è una funzionalità che spesso viene sottovalutata ma che, in realtà, all’interno di un ambiente Cloud Native, è di fondamentale importanza.
Quali sono i vantaggi che ne derivano?
1. Temporale: il tuo business ha più tempo di lavoro per lo sviluppo effettivo;
2. Gestione di ambienti complessi: noterai una rapida scalabilità ed una diversificazione complessiva degli ambienti.
3. Dev ed Ops: grazie all’automazione, i due team (Dev ed Ops) potranno dedicare meno tempo a svolgere attività di supporto e più tempo al miglioramento continuo del sistema; inoltre, si velocizzano in termini generali, i tempi di modifica ed esecuzione dei test in maniera più rapida progettando efficienti pipeline di CI/CD (leggi anche https://www.bluecube.it/perche-e-necessario-usare-le-pipelines/).

Openshift: la nuova orchestrazione

Oggigiorno tutte le moderne applicazioni si estendono su più macroservizi che vengono containerizzati e distribuiti su una serie di cloud pubblici e privati, senza mai rinunciare alla disponibilità: l’orchestrazione è un’operazione non poco complessa ed è qui che troviamo i famosi orchestratori di Container, come ad esempio Kubernetes.
Kubernetes è uno strumento che consente di automatizzare e controllare attività che vanno dalla gestione stessa del container al provisioning automatico, scalando molto velocemente verso l’alto o il basso.
In linea generale però, va anche sottolineato utilizzare un orchestratore di container è indispensabile per gestire sistemi distribuiti che fanno uso di un gran numero di container e di seguito elenchiamo i vantaggi:
Un orchestratore di container permette di gestire moderne applicazioni strutturate a micro-servizi;
Un orchestratore di container facilita la gestione di un gran numero di micro-servizi in un cluster di server e risolve problemi legati al deployment combinato dei container;
Utilizzando Openshift come orchestratore di container, è più facile ottenere lo scaling selettivo delle singole componenti di un’applicazione a micro-servizi.

Openshift: IaaS, PaaS, e SaaS

Con IaaS, PaaS e SaaS, indichiamo tre macrocategorie di servizi che si basano sull’infrastruttura Cloud che vengono utilizzate dalle aziende per ottenere semplicità d’uso e flessibilità e che, grazie alle loro potenzialità, hanno segnato la svolta per il business aziendale, migliorando anche il processo di digitalizzazione.
E’ bene però analizzare questi termini nel dettaglio in modo tale da costruire un quadro completo:

  • IaaS: Infrastructure-as-a-Service: grazie a questo le aziende possono usare in egual misura e maniera sia le tecnologie sia le funzionalità di un data center tradizionale senza doverle tenere/manutenere/gestire fisicamente poiché è il provider che fornisce un’infrastruttura di cloud computing, compresi server, reti, sistemi operativi, storage, ecc. Alcuni esempi sono Microsoft Azure, Amazon Web Services (AWS).
  • PaaS: Platform-as-a-Service: siamo di fronte ad un ibrido (tra IaaS e SaaS) dove il provider mette a disposizione la piattaforma per creare il software. In questo modo lo scenario è differente, perché da un lato abbiamo i developer che hanno la completa e totale libertà di concentrarsi sullo sviluppo software senza dover badare ai suoi aggiornamenti, allo storage, all’intera infrastruttura, ecc….Esempi? Windows Azure, AWS Elastic Beanstalk ed il nostro OPENSHIFT.
  • SaaS: Software-as-a-Service, tutta l’intera applicazione è messa a disposizione dal provider via web e. per poterla utilizzare, non serve sapere scrivere codici.

Cioè?

Il modo più semplice per illustrarne il funzionamento è farvi pensare ad esempio a Gmail: per accedervi, lo si può fare gratuitamente tramite Internet o acquistando una licenza ma senza scaricare file!
Altri esempi sono: Google Docs, Salesforce, Microsoft Office.

Openshift: le sue caratteristiche

Openshift è molto semplice da installare: l’importante è disporre di un cluster di macchine che utilizzi come sistema operativo RHEL.
Per quanto riguarda i server non c’è nessuna importanza di come siano fatti (che siano fisici, VM, macchine su cloud privati o pubblici); Openshift ha la capacità di trattare il cluster di server come risorse di calcolo e di storage creando un’astrazione nella quale coabitano le applicazioni precedentemente containerizzate.
Openshift è un sistema composto da diverse parti e, ciascuna di esse è installabile in modo tale da avere solo punti di forza (no single point of failure) ed è costruito a partire da Kubernetes sfruttando però altri diversi progetti e tecnologie open source (anche Kubernetes è un aggregato di prodotti open source)

Openshift: il modo più facile per…..

E’ bene ora identificare quali siano alcuni dei vantaggi che Openshift offre, quali ad esempio:

  1. Mostra diverse interfacce utente ed API che consentono di gestire ogni aspetto della piattaforma ed una successo di runtime che facilita la creazione di app containerizzate.
  2. Offre un ricco catalogo di linguaggi e server che costruiscono sistemi distribuiti complessi ed app a micro-servizi in modo semplificato;
  3. Openshift è stato pensato per migliorare la collaborazione tra utenti minimizzando le interfacce indesiderate.
  4. E’ la piattaforma ideale per ottimizzare la cooperazione tra Dev ed Ops.
    Openshift consente agli sviluppatori di approvigionarsi in modo autonomo di tutti gli strumenti necessari per costruire app e workflow di build e deploy a proprio piacimento.
    E’ anche vero che il team Ops ha il pieno controllo dell’intera piattaforma (dal suo utilizzo, dall’esecuzione delle app, ecc)…

Openshift: prendi la scelta giusta

Se tu dovessi pensare di ottenere una serie di vantaggi derivati da una tua scelta specifica, la prenderesti?
Se tu dovessi pensare che dai vantaggi ottenuti dalla scelta specifica dovessi ottenere un miglioramento della tua vita, la prenderesti?
Se tu dovessi pensare di ritrovarti in una situazione di generale miglioramento ed appagamento derivato da una scelta precisa, la prenderesti?
Ora è tempo di portare tecnologici miglioramenti al business, giusto?
Ora è il tempo di scegliere Openshift senza pensarci due volte!

Contattaci per avere maggiori informazioni, ora!

Ti sei mai chiesto perché la tua azienda ha bisogno di utilizzare le pipelines?

Facciamo un piccolo passo indietro per capirci di più.

Innanzitutto con “pipeline” si intende una successione di passaggi orchestrati con la capacità di portare il codice sorgente fino alla produzione. 

I passaggi sono: creazione, confezionamento, test, convalida verifica dell’infrastruttura ed infine, implementazione in tutti gli ambienti necessari.

Una pipeline si può attivare nel momento in cui viene richiesto un determinato evento, ad esempio dalla richiesta di modifica del codice. 

E’ più facile immaginare il concetto di pipelines affiancandolo al suo significato tradotto, ovvero “conduttore” ed il concetto è molto simile: un “tubo” nel quale scorrono e fluiscono una successione di dati.

Oggi giorno i dati si moltiplicano in maniera esponenziale, molto velocemente, ed il mondo dell’IT e del digitale corrono con ritmi frenetici; questo comporta la necessità di avere pipelines di dati all’interno della propria azienda, necessarie anche per ottimizzare il proprio tempo ed il potenziale dei dati stessi, soddisfando, in maniera ideale, i bisogni richiesti dai propri clienti. 

Sono infiniti i dati presenti all’interno di database, applicazioni ed altre sorgenti di informazioni (si pensi anche solo ai fogli di calcolo di Excel); tutti i dati devono essere fruiti all’interno di tutte le sorgenti utilizzate. 

Una pipeline di dati include e racchiude in sé una successione di azioni che iniziano dall’acquisizione di dati grezzi (provenienti da una sorgente) per essere poi trasformati nel minor tempo possibile, in dati pronti per essere analizzati.

Quando si parla di pipelines, si fa riferimento ad Azure Pipelines che integra e combina l’integrazione continua (indicata con CI) ed il recapito continuo (CD) al fine di testare e compilare il codice spedendolo a qualsiasi destinazione.

Vantaggi della pipeline CI/CD:

Utilizzando le pipelines si ottengono numerosi vantaggi; pensiamo al mondo delle applicazione ad esempio: è raro che due applicazioni (compresa l’infrastruttura di supporto) siano uguali; l’attività di sviluppo e la consegna del software sono esercizi ripetitivi ed iterativi e le pipelines dovrebbero essere eseguite più volte al giorno (specialmente per la correzione di eventuali bug si sistema).

Quando si adotta una pipelines CI/CD, il team di sviluppo e quello operativo adottano una comprensione più chiara di ciò che è necessario per concretizzare le proprie idee. 

Inoltre, adottando un approccio sistematico con questa tipologia di pipelines, gli stessi bug possono essere facilmente individuati e risolti, poiché il processo è coeso ed unito e non disgiunto. 

Fasi di una pipeline CI/CD:

Le pipelines CI/CD si suddividono in fasi??

Assolutamente sì, e di seguito ve le mostriamo: 

1) Build – La fase in cui viene compilata l’applicazione.

2) Test – La fase in cui viene testato il codice.

3) Rilascio – La fase in cui l’applicazione viene consegnata al repository.

4) Distribuzione – In questa fase il codice viene distribuito in produzione.

5) Convalida – In questa fase avviene la convalida del software come la presenza di vulnerabilità.

Cosa c’è dentro una pipeline?

Come già sopra accennato, una pipeline di dati contiene l’intero percorso che i dati stessi compiono all’interno dell’azienda.

All’interno di una pipeline di dati quindi, si hanno tre fasi principali: 

  1. Fase di raccolta di dati grezzi: i dati vengono rilevati ed estratti da un numero di sorgenti diverso, arrivando in formati molto diversi da loro (da tabelle, a code, a nomi di file, ecc).
    In questa prima fase quindi i dati non hanno una loro identità ed una loro forma, ed è per questo che vengono definiti come “grezzi”

  2. Fase di governance dei dati: dopo la fase di raccolta dei dati grezzi, le imprese stabiliscono una governance di dati, ovvero devono decidere delle regole per organizzare i dati grezzi precedentemente raccolti; solitamente i dati grezzi raccolti vengono connessi al contesto aziendale al fine di assumere un significato.
    Questa è la fase di controllo della qualità dei dati e della sicurezza, organizzandoli poi per il consumo di massa.

  3. Fase di trasformazione dei dati: è la fase decisiva, in cui i dati vengono puliti, viene data loro una forma ed un’identità, ottengono quindi il formato di report corretto; tutti i dati sterili vengono eliminati.

La missione e l’obiettivo delle pipelines di dati consiste nell’integrare i dati per fornire ai consumatori informazioni facilmente e velocemente fruibili in tempo reale.

 

 

Perché scegliere noi? 

Se si vuole stare al passo con l’innovazione, bisogna concretizzare questa idea e per farlo, bisogna scegliere persone qualificate ed esperte.

Il team Bluecube dispone di personale CERTIFICATO Azure DevOps ed è per questo che i nostri Partner che sono leader di mercato in hosting, housing e cloud hanno scelto noi, perciò, non stare con le mani in mano, contattaci!

 

Necessità iniziale del cliente/Obiettivo 

 

Per Moresi.com leader nel settore della digital transformation, abbiamo sviluppato un PoC (proof of concept)), per automatizzare e centralizzare i processi di provisioning e di configurazione delle risorse degli ambienti On-Premise ed in Cloud, sfruttando le potenzialità della metodologia DevOps.

L’obiettivo è quello di verificare la possibilità di provvedere alla gestione IT delle risorse infrastrutturali sfruttando le potenzialità di Azure DevOps come punto centralizzato, utilizzandolo per orchestrare e gestire tutte le componenti software coinvolte nell’operatività.

Per rendere il POC più completo, per ogni sistema, oltre a verificarne le possibilità di accesso si forniranno anche esempi di casi d’uso pratico.

Ora però, andiamo per step, partendo dagli ambienti e dalle tecnologie utilizzate.

 

Ambienti  e tecnologie utilizzati 

 

Gli ambienti che abbiamo preso in analisi sono i seguenti: 

 

On-Premise

  • Hypervisor

VMware  xSphere

VMware vCloud Director

ESXi (Bare Metal Hypervisor)

  • Network

Fortinet

Fortimanager

Cloud

  • AWS (Amazon Web Services): AWS simple Instance, AWS Multi Region deploy, 
  • Microsoft Azure

 

Sistemi Operativi

  • Linux: LAMP stack deployment using Ansible, LAMP stack deployment using Bash
  • Windows:  deploying IIS and ASP.NET using PowerShell
  • ForiOS: Apply to a FortiOS some firewall rules using Ansible and the self-hosted agent of azure devops

Ci siamo avvalsi dell’utilizzo del paradigma IaC (acronimo di Infrastructure as Code) che consente la gestione e la configurazione completa dell’infrastruttura in tutte le sue parti: reti, macchine virtuali, servizi di bilanciamento del carico e tipologia di connessione, circoscritti in un modello descrittivo.

Per poter raggiungere la nostra meta e soddisfare in maniera ottimale l’esigenza del cliente e la sua ambizione, abbiamo sfruttato le potenzialità di una serie di tecnologie che fanno parte del nostro DNA e che ci caratterizzano, quali: 

  1. Docker: Docker permette di costruire, impacchettare e poi distribuire applicazioni con facilità e velocità attraverso contenitori con le tutte le dipendenze necessarie invece di macchine virtuali. Elimina le banali attività di configurazione e favorisce la collaborazione efficace del team.

I contenitori Docker possono essere eseguiti ovunque, in locale, nel data center, in un provider di servizi esterno o nel cloud. I contenitori di immagini Docker possono essere eseguiti in modo nativo in Linux e Windows.

 

  1. Git: Git è uno strumento per il controllo della versione usato per tenere traccia dei cambiamenti nel codice sorgente e coordinare efficacemente il lavoro fra i componenti del Team.

 

  1. Ansible: Ansible è uno strumento di automazione IT. È possibile configurare sistemi, distribuire software ed eseguire attività IT più avanzate come distribuzioni in sequenza o aggiornamenti senza tempi di inattività utilizzando file di configurazione in formato YAML (YAML Ain’t Markup Language) sotto forma di Playbook Ansible, che permettono di descrivere le configurazioni desiderate in un linguaggio colloquiale.

 

  1. Terraform: Terraform è uno strumento per creare, modificare e aggiornare l’infrastruttura in modo sicuro ed efficiente utilizzando un linguaggio di configurazione di alto livello chiamato HCL (HashiCorp Configuration Language) che consente di descrivere ed attuare lo stato desiderato.

Terraform è in grado di gestire fornitori di servizi noti ed esistenti, nonché soluzioni interne personalizzate.

 

  1. Scripts: Qualora qualche particolare configurazione non sia attuabile con i moduli disponibili per strumenti sopracitati è possibile sfruttare i linguaggi di scripting propri del sistema da configurare:

        Bash: CLI (Command Line Interface) usata nei sistemi operativi Unix e Unix-Like;

        Powershell: CLI (Command Line Interface) usata prevalentemente sei sistemi operativi Windows;

     VMware PowerCLI: modulo di powershell per la gestione, la configurazione e l’automazione dei prodotti VMware.

  1. Azure DevOps: Azure DevOps è una piattaforma Software as a Service (SaaS) di Microsoft che fornisce un insieme di strumenti per lo sviluppo e la distribuzione di software. Si integra inoltre con la maggior parte degli strumenti DevOps presenti sul mercato, ed è un’ottima opzione per orchestrare una Toolchain DevOps.

 

  Metodologia ed approccio utilizzato

 

Inoltre, per poter sviluppare il PoC al meglio, ci siamo avvalsi di una metodologia che, da diversi anni  è presente nel mondo dell’IT a livello internazionale; stiamo parlando dell’approccio DevOps. 

Quando si parla di DevOps bisogna far riferimento ad una nuova cultura, ad un cambiamento radicale applicato al mondo Dev (development) ed Ops (Operations) e, quindi, un approccio rivolto all’automazione dei processi e ad una modalità collaborativa tra i membri del team coinvolti. 

E’ un paradigma che descrive le metodologie da adottare per accelerare i processi di un’idea da concretizzarsi passando in maniera facile dalla fase di sviluppo e progettazione, a quella di produzione. 

Che cosa deve essere chiaro per approcciarsi al DevOps? 

Il team deve essere solido, compatto, collaborativo, con un buon livello di comunicazione ed una continuità nel medio-lungo periodo.

Elemento chiave? L’empatia e la capacità di comprendere tutti i membri del team per affinare al meglio la propria cooperazione, giungendo alla perfezione operativa nel minor tempo possibile. 

Grazie al DevOps si hanno una serie di vantaggi:

  1. Efficienza, passando dal self-service e l’automazione;
  2. Velocità: gli sviluppatore lavorano a stretto contatto con l’anima operativa per velocizzare le fasi di creazione, collaudo, rilascio dei software e delle infrastrutture ad essi correlate
  3. Affidabilità: riduzione degli errori dovuti all’intervento umano.

Come già accennato, quando parliamo di DevOps, parliamo di cambiamento; ogni cambiamento richiede impegno e richiede la capacità di sfruttare al meglio le competenze, le capacità e le tecnologie adeguate.

L’elemento da non dimenticare mai quando si parla di DevOps è l’automazione. 

Perché?

E’ grazie all’automazione che si verifica l’ottimizzazione del tempo per integrare, in maniera agile, eventuali modifiche effettuate al software, scalando ed adattando in maniera flessibile tutte le componenti dell’infrastruttura sottostante. 

Che altro OFFRE il DevOps?

L’automazione permette a tutti i professionisti IT di dedicarsi alle attività importanti, garantendo loro coerenza e riducendo le possibilità di errore, evitando quindi di perdere il loro tempo in compiti banali e ripetitivi. 

I servizi offerti da Azure DevOps sono:

    • Azure Board : Usato per la pianificazione del team basato sulla filosofia Agile/Scrum;
  • Azure Repos : Usato per l’hosting dei repository e la gestione del versioning;
  • Azure Pipelines : Usato per automatizzare le compilazioni e le distribuzioni;
  • Azure Test Plans : Usato per il testing pianificato ed esplorativo;
  • Azure Artifacts : Aggiunge la gestione dei pacchetti integrata alle pipeline;

Tra questi, per la PoC, ci concentreremo su Azure Repos, come contenitore dei repositories, e su Azure Pipelines, come aggregatore di pipeline.

Questi due servizi sono essenziali per seguire la metodologia di lavoro GitOps, la quale necessita che tutto il sorgente sia centralizzato in un repository e che per certi eventi sul sorgente venga eseguita una Pipeline alla quale viene delegato il compito di eseguire azioni finalizzate eventualmente al deploy.

 

Per ogni casistica definita nel paragrafo precedente verrà realizzata una repository che conterrà il codice necessario per conseguire l’obiettivo definito, ad ogni repository è associata una pipeline.

Tutte le pipeline vengono triggerate ad ogni nuovo “commit” sul “branch” principale della repository.
Per ogni casistica si concorderà quali permessi sono necessari per eseguire le pipelines.

Un’organizzazione così modulare del sorgente permette di:

  • Rende lo sviluppo più semplice e veloce, permettendo allo sviluppatore di concentrarsi solo sul sorgente necessario
  • Permette un maggior controllo sulle feature/fix che vengono effettuate e riduce i permessi necessari per eseguire le pipelines.

 

Se volete conoscere i risultati ottenuti, seguiteci e leggete il prossimo, capitolo…

 

Coming soon…

 

Conosciuto come TI-99/4A o TI99/4A, il Texas Instruments TI-99/4A fu uno dei primi home computer che vennero prodotti e lanciati sul mercato da parte della Texas Instruments tra il 1981 e il 1983.

La sua diffusione avvenne soprattutto negli USA ma, a seguito di una guerra commerciale contro la Commodore International, la Texas Instruments non raggiunge un livello significativamente alto di vendite e, con il successo del Commodore 64, la Texas Instruments vide la cessazione della produzione dopo solo due anni dal lancio. 

Il Texas Instruments TI-99/4A a differenza di alcuni home pc e macchine d’epoca che richiedevano una specifica espansione con tastiera ad escursione, supportava la scrittura in minuscolo ed era basata sul TMS-9900, CPU a 16 bit con clock a 3 MHz. 

Altre caratteristiche relative alla grafica erano:

  1. Presenza di 16 colori 
  2. Risoluzione video di 256*192 pixel (32 colonne * 24 righe)
  3. Caratteri 8*8 pixel (ASCII o definibili dall’utente).

Com’era composto l’hardware? 

L’ hardware del Texas Instruments TI-99/4A era stato costruito intorno ad unico blocco.

All’interno di esso c’era la CPU, la scheda madre ed uno slot a cartucce.

Disponeva inoltre di un drive per floppy da 5.25”, una scheda seriale RS-232 con due porte seriali ed una parallela, una scheda P-Code per supportare il linguaggio di programmazione Pascal, un accoppiatore acustico, una stampante termica ed una coppia di joystick per videogames (memoria espandibile fino a 32 kB)  L’ azienda chiamava l’apertura per la coppua di Joystick, “wired remote controllers”, in italiano “controlli a distanza”.

Ciò che caratterizzava il Texas Instruments TI-99/4A era la sua vendita: l’esemplare veniva venduto con tanto di monitor incluso poiché l’adattatore RF utilizzato per collegarlo ad una normale TV non ebbe mai la certificazione da parte della Federal Communications Commission. 

Solo in Italia veniva venduto sprovvisto di monitor perché l’uscita video era compatibile con le televisioni dell’epoca. 

Per non dimenticare un’altra delle particolarità che hanno caratterizzato il Texas Instruments TI-99/4A era la presenza di un sintetizzatore vocale opzionale, come quello dell’Atari 2600, fornito in maniera gratuita ai clienti dopo l’acquisto di un numero determinato di cartucce.

Il sintetizzatore vocale opzionale permetteva di dotare il software o i giochi di sintesi vocale (venne infatti molto utilizzato da numerosi videogames, lanciati dalla Texas Instruments).

Ed il software? 

Il Texas Instruments TI-99/4A utilizzava il TI BASIC come linguaggio di programmazione, che poteva essere espanso anche in TI Extended BASIC (si trattava di una versione più avanzata di quello BASIC che venivano usati dai precedenti pc prodotti dalla Texas Instruments).

L ’home pc non permetteva però di utilizzare il linguaggio macchina creato dall’utente e neppure di scrivere programmi che accedevano in maniera grafica in alta risoluzione.

Per fare ciò bisognava acquistare il modulo “MINIMEMORY” in maniera separata (sempre prodotto dalla Texas Instruments), oppure si poteva espandere grazie al Peripheral Expansion box (prodotto sempre dalla Texas Instruments) con previa espansione anche della RAM da 32 KB.

Come si utilizzava il Texas Instruments TI-99/4A? 

Una cosa molto particolare del Texas Instruments TI-99/4A era che il manuale di istruzione in realtà era una vera e propria guida all’uso e alla programmazione del linguaggio di programmazione TI BASIC.

All’interno del manuale di istruzione è tutto spiegato molto in dettaglio (con tanto di esempi di programmazione); è scritto in modo molto semplice per dare a tutti gli utilizzatori, la possibilità di apprendere tale linguaggio senza avere nessun tipo di nozione nel mondo della programmazione. 

Qual era il “difetto”?

Il TI BASIC è molto lento e limitato, soprattutto per il Texas Instruments TI-99/4A e ciò faceva nascere la necessità di fare un cambiamento e di avere una marcia in più per avere un rapporto di funzionalità/velocità ottimale. 

La Texas Instruments era al corrente di questo problema e si era già portata avanti, preparando una cartuccia, l’Extended Basis, che dava la velocità necessaria!

Qui sotto, un’immagine delle istruzioni del Texas Instruments TI-99/4A.

 

KoDa é un progetto che nasce dal desiderio di sperimentare, ma di cosa si tratta? 

Il nome stesso significa Container (Qui la C diventa K) e Da (che nelle lingue slave vuol dire si), l’idea nasce da queste due immagini:

 

 

Il desiderio è quello di creare un prodotto che sia in grado di ottimizzare l’uso dei container e che comunque permetta di sperimentare, quindi di “giocare” con essi.
Una menzione speciale va alla lettera K del nome, infatti oggi va di moda usarla per i prodotti cloud, secondo noi questo deriva dalla fama di Kubernetes, per fare qualche esempio: Knative, Kubeflow, Katacoda, Kind.

Architettura

KoDa non sarà un progetto monolitico, sarà composto da 3 componenti:

– Il front end, aiuterà gli utenti meno esperti a muoversi in questo mondo

– La cli, sarà dedicata ad utenti più avanzati

– L’engine, avrà il compito di eseguire tutte le operazioni 

Feature

Le feature principali che vorremmo implementare sono queste:

– La visualizzazione delle risorse dei container, quindi le reti, i volumi, le immagini e i container stessi. Questa feature di per se non è nulla di innovativo dato che la stessa linea di comando di docker lo fa

– La creazione di ambienti di sviluppo, l’idea è quella di creare dei template di configurazione degli ambienti. Per chiarire il concetto: se la tua app è in php e deve usare postgres come db allora ti crea sia il db, che adminer che il container con php-fpm

– L’auto creazione di immagini partendo dal codice, per fare questo sarà necessario un file in cui si descrivono le proprietà e KoDa.

Partendo da una libreria di template genera l’immagine, che puoi può essere integrata nell’ambiente di sviluppo

Obiettivi

KoDa è pensato per una vasta platea, partendo da chi non ha mai usato i container fino a chi ne conosce in maniera approfondita le potenzialità. Se si dovesse parlare di roadmap il passo iniziale è quello di arrivare a semplificare il loro sviluppo, quindi è pensato per girare in locale, in un futuro ci aspettiamo di renderlo installabile su un server condiviso e da un unico punto centrale gestire gli ambienti. A questo punto sarebbe necessaria non solo la gestione degli utenti ma anche un’integrazione con un registry.

Lo sviluppo completo delle 3 componenti è previsto per la fine del 2022, il progetto sarà open-source e disponibile su github. Non ci aspettiamo chiaramente di ricevere pull request esterne dato che siamo ancora a gli inizi, ma in ogni caso sarebbero bene accette.

Engine

L’engine ad alto livello si preoccupa di parlare con le API di docker e da queste gestire la CRUD delle risorse e questa sarebbe la prima feature nella sua interezza. Le altre due feature invece sono più sfidanti, la creazioni di ambienti di sviluppo richiedono la gestione di più risorse contemporaneamente per fare un esempio più pratico: per creare un ambiente per un app con il db è necessario creare la rete per i due container, creare il volume per il db e infine i due container.

Per gestire questi ambienti l’idea era quella di creare dei template, anche se al momento sono in corso analisi per capire quale può essere il modo migliore.

L’auto creazione delle immagini è la feature su cui puntiamo di più per questi motivi:

– Creare un libreria di immagini per i framework più utilizzati

– Non perdere tempo a reinventare la ruota 

Attualmente non abbiamo ancora deciso che strada prendere per questa feature, l’idea appunto era quella di creare un file in cui si descrivono le proprietà del progetto, in questo modo l’engine scegliendo dai template può generare l’immagine, una cosa importante è che il codice che viene passato deve rispettare degli standard altrimenti non è possibile far funzionare il workflow della build. Seguire uno standard nei progetti è comunque una cosa che va oltre KoDa ma è auspicabile in generale.

CLI

La cli la possiamo vedere come un estensione della cli di docker e del frontend, ci teniamo a fare questa perché per noi la linea di comando è l’interfaccia che utilizziamo di più.

Frontend

Il front end servirà ad agevolare quanto spiegato sopra. Verrà implementata un’interfaccia grafica in modo tale che tutti gli utenti, anche quelli meno esperti, possano interagire in maniera chiara e semplice con il nostro progetto. L’interfaccia grafica comprenderà un’area nella quale sarà possibile vedere i vari container che si hanno, quali sono attivi e quali no. Avrà inoltre una sezione dedicata per esporre sotto forma di “manuale” i vari passaggi che devono essere svolti per poter configurare un container in maniera autonoma e i passi che sono stati svolti per implementare le nostre feature in modo tale che l’utente non debba andare per forza a vedere il codice su github.

Proseguo

Nel prossimo aggiornamento approfondiremo lo sviluppo del componente Engine,
Fino ad allora restate sintonizzati.

 

Una personalità da scoprire

Il motto di Bluecube è sempre questo: prima di considerare collaboratori e dipendenti, consideriamo l’aspetto umano e quindi il concetto di persona e di quello che realmente è ogni singolo individuo.

Tutto funziona secondo logiche empatiche e relazionali.

Come si può pretendere collaborazione ed efficienza se non ci si conosce?

Il team Bluecube si sta espandendo ed abbiamo deciso di dare voce questa volta ad un nuovo arrivato, Francesco Sblendorio, Technical Lead. 

Grazie all’intervista da Francesco rilasciata, è stato possibile cogliere sfumature del suo carattere molto interessanti.

Animo eclettico, dai mille interessi e dalle mille capacità, solare, simpatico, con voglia di fare e di costruire, trasmettendo i suoi valori (personali e professionali) all’interno dell’azienda e nel suo team. 

Conosciamo più da vicino Francesco: 

 

Come hai trovato Bluecube?

“Vi ho conosciuti tramite Fabrizio Lodi, un mio amico da qualche anno. La cosa che ci accomuna è l’hobby dell’informatica e dei videogiochi, in particolare la storia dell’informatica, non limitata quindi solo alla tecnologia. 

In tale ambito ho prodotto alcuni software che Fabrizio stesso ha apprezzato (anche lato nuovi pc).

Ciò che è davvero bello è che dall’hobby di nicchia sono arrivato a qualcosa di concreto di professionale”. 

 

Come si è composto il tuo percorso professionale? 

“Il mio percorso professionale è una storia di lunga data, mi spiego: sin dalle elementari io nutrivo questa passione e questo hobby ed ero chiamato come quelli che spregevolmente (negli anni 80 non era bello) si chiamavano “nerd”, coloro che erano appassionati di informatica.

Ero già da bambino appassionato “di computer” (specifico, non “di videogiochi”); compravo riviste specializzate e le studiavo, ma non giocavo a pallone…

Poi nella mia carriera professionale ho fatto anche l’attore, recitando in un film comico”. 

 

Che cosa ti appassiona di più del tuo lavoro? 

“Anni fa mi appassionava tantissimo la tecnologia in sé quindi, ogni volta che c’era qualcosa di nuovo, io lo sperimentavo; ora invece è il desiderio di vedere la soluzione, il frutto del mio lavoro, applicata al mondo reale.

Direi che nel tempo è cambiato l’obiettivo”. 

 

Qual è il valore aggiunto di Bluecube secondo te?

“Il valore aggiunto è tantissimo: sto coordinando un gruppo di ragazzi giovani e che, come me, hanno la propensione a scoprire nuove tecnologie, scoprendo i punti di forza e di debolezza del mercato dell’informatica ed in più sono GIOVANI, sono MOLTO più flessibili. 

Nell’informatica ogni mese esce qualcosa di nuovo; sono ragazzi svegli e dover interagire con loro mi fa crescere molto e mi fa capire come far crescere ancor di più una squadra.

Questo è il mio obiettivo nel breve-medio termine”. 

 

Credi nel team giovane e nelle nuove generazioni? 

“Io penso che bisogna mettere i giovani in grado di esprimere le loro potenzialità: questa è la mia responsabilità e di chi fa un lavoro simile al mio. Bisogna mettere i giovani nella posizione tale per cui si possano esprimere: in questo io credo moltissimo.

Non si può andare avanti su gente che è sempre la stessa”. 

 

Cosa vuoi trasmettere a Bluecube dall’alto della tua esperienza?

“Ciò che voglio trasmettere: ho tante esperienze in settori molto diversi tra di loro: dal bancario, al content management, alla salute. Conoscendo tutto ciò e quindi tanti e diversi domini applicativi che richiedono diverse capacità, posso dare informazioni su ciò che accade. 

Se parlo di ambito bancario, la novità tecnologica passa in secondo piano, mentre la sicurezza conquista il primo posto; se parlo di content management invece è la tecnologia a prendere il primo posto”. 

 

Ho visto che hai un passato da attore anche, ben diverso dalla realtà di adesso: quale nesso connette due mondi così diversi? 

“Nesso non c’è; io sono un eclettico: ho tantissimi interessi, molti ma molto diversi tra loro, come ad esempio la storia contemporanea; non sono un esperto, ma leggo e mi informo.

Non sono un attore ma è qualcosa che mi diverte e ho avuto la fortuna di incontrare un regista, Marcello Macchia, che mi ha dato questa possibilità.

Siamo diventati amici e quando un giorno ero in vacanza, la produzione mi ha chiamato proponendomi una parte nel film “Italiano Medio”. 

Con Marcello è stata una bella cooperazione. 

Ho poi ricoperto altri ruoli ma sempre comici!”.

 

Cosa ti ha insegnato la tua esperienza da attore?

“Ad avere a che fare con persone completamente diverse da me, che rappresenta una soft skill importante nel mondo del lavoro.

Nel mondo informatico c’è lo stereotipo della persona che lavora solo davanti al pc.

Nel mondo del cinema ci sono tantissime figure: di scena, di audio, ecc ed io mi divertivo davvero tanto e pensavo: “ma che figata” (mentre io mi divertivo c’erano attori che facevano proprio quello come lavoro e lo prendevano nello stesso modo in cui io prendo il mio).

È stata un’esperienza di vita e sicuramente tutto ciò mi ha arricchito”.