Archivi tag: Paas

High Performance Computing (HPC)- tornare ad investire sull’Edge Computing

OK, con questa dichiarazione si capirà che sono un sistemista di vecchia scuola, per l’appunto ho iniziato ad occuparmi di sistemi HPC/Cluster nei primi anni 2000 ed ho realizzato il mio primo importante sistema Cluste HPC nel lontano 2004, da quel momento ho lavorato nello stesso ambito per grosse aziende in ambiti bancario, assicurativo, editoria, pubblica amministrazione etc…… ; ho potuto dunque analizzare per esperienza diretta che quello che legava tutti questi ambienti, che si stavano aprendo al mondo dell’offerta di servizi web online per i loro clienti (outsourcing), era la “ovvia” gestione in loco (on premise) dei dati aziendali, nonostante questo comportasse un forte investimento in hardware/network e sviluppo del software. Tutto ciò permetteva di tenere sotto controllo l’andamento dei progetti perchè per far funzionare tutti quegli avanzamenti tecnologici serviva far crescere anche il livello di preparazione tecnologica del proprio personale IT, seppur con le dovute integrazioni esterne di consulenti ad hoc, atti a portare uno slancio alla realizzazione finale del prodotto.

Dunque in un’azienda servivano un tot persone skillate in vari ambiti che procedessero di pari passo nel far avanzare il progetto fungendo anche da beta tester per i colleghi degli altri team, team solitamente suddivisi in:

  • Sistemisti
  • Database Administrator
  • Networking
  • Sviluppo (developer)
  • Cyber Security

Ogni gruppo testava se stesso e faceva da tester per gli altri così da arrivare , step by step, ai vari rilasci di pre-produzione e produzione, diminuendo, a mio avviso, di gran lunga il Bug da errore umano.

Credo che tutto ciò abbia funzionato piuttosto bene, in una specie di “status quo” fino all’arrivo della crisi del 2008 ed in particolare degli strascichi sui budget i cui effetti si sono visti negli anni subito successivi, nel frattempo il maggior sviluppo di piattaforme Cloud proposte dai Big come Gloogle Cloud ed Amazon AWS (in particolare) hanno portato alla decisione sempre più massiccia dei Manager di esternalizzare tutti i processi verso queste piattaforme per massimizzare gli sforzi nello sviluppo (programmazione) dei servizi eliminando dai budget le spese hardware, quelle per le location da dedicare alla ridondanza dei dati ed ai sistemi di backup integrati. Tutto questo ora era possibile pagarlo in un forfait di servizi on chain offerti dalle piattaforme Web-Cloud che hanno invaso il campo di gioco con acronimi di ogni genere, tra cui i primi furono le PaaS, SaaS, IaaS, CaaS, DaaS etc…. (solo la fantasia li può fermare) tagliando così anche le competenze dirette dei team poichè adesso le piattaforme web, la loro gestione, il mantenimento software, gli aggiornamenti, i backup, le problematiche di rete, i DNS, le connessioni VPN, la sicurezza e quant’altro potevano essere preoccupazione ed appannaggio di altri.

Tutto ciò per me ha solo impoverito il nucleo di esperti IT, smembrando i suddetti team e generando nuovi mostri poichè le aziende diventarono prede di “metodologie” di lavoro in stile Silicon Valley (ma ehi la verità è che funzionano solo in Silicon Valley) come la Agile, è da li sono partiti inglesismi lavorativi come lo “stand up meeting”, il “parking lot”, arrivando oggi all’uso di Framework per supportare l’Agile come lo “Scrum” che ha introdotto la figura dello “scrum master” e via di questo passo.
Ma quello che si è potuto vedere è che mentre prima i Team IT aziendali necessitavano di specifiche competenze , adesso posson bastare come capo progetto uno sviluppatore Senior con conoscenze da sistemista o un sistemista con conoscenze di programmazione per mandare avantiil 70% dei progetti perchè il resto lo prepara la piattaforma Cloud che ti aiuta a gestirlo con comodi tool grafici Plug ‘n Play e se qualcosa non funziona c’è il blog/tutorial o il call center…….. semplice giusto?

Certo qualcuno potrà giustamente dire che così è tutto più mirato, perchè no più comodo, e le aziende possono essere più verticali sullo sviluppo e sul risultato finale, FORSE, ma se devo cedere capacità cognitive, conoscenza dei sistemi e competenze di problem solving solo perchè è più pratico allora forse sto sbagliando mestiere. Non parliamo poi del nuovo arrivato, la A.I. , con ChatGPT e compagnia bella… quella unita ai movimenti No-Code, non fanno ben sperare per una futura esistenza delle ultime figure rimaste (gli sviluppatori) che credo si dovranno preparare a periodi di transizione poco rosei.

Il futuro non lo si può arrestare, arriva comunque dunque è giusto imparare a conoscerlo per capire come e quali cose sono vantaggiose da utilizzare, e che cosa invece determinerà la perdita di competenze apprese con fatica, studio ed esperienza lavorativa. Si potrebbe fare qualcosa per riprendere un minimo il controllo? Credo di SI, innanzitutto diminuendo la dipendenza dai sistemi Cloud esterni e tornando a volersi sporcare le mani in casa, quindi spazio alla rinascita dei data center aziendali costruiti su misura dei progetti reali ed implementati dalle persone che li gestiranno e li faranno crescere e scalare nel tempo, quindi riprendiamoci il controllo dei dati, in primis, e dei sistemi con loro, più sistemi on premise e Edge Computing e meno esternalizzazione con il Cloud Computing.

Vantaggi dell’ Edge Computing

L’edge computing è preferibile al cloud computing in molte situazioni e per diversi motivi chiave, tra cui sicurezza, controllo dei dati e velocità di elaborazione dei dati.

  1. Sicurezza: Nell’edge computing, i dati sono elaborati più vicino alla loro origine, riducendo il rischio di esposizione a minacce esterne. Questo approccio migliora la sicurezza dei dati sensibili.
  2. Controllo dei Dati: Con l’edge computing, le organizzazioni mantengono un maggiore controllo sui propri dati. I dati rimangono locali o in prossimità dei dispositivi, consentendo un controllo diretto sull’accesso e sulla gestione.
  3. Velocità nell’Elaborazione dei Dati: Poiché i dati vengono elaborati localmente nell’edge computing, la latenza è ridotta al minimo. Questo è fondamentale per applicazioni in tempo reale, come il monitoraggio industriale o i molti sistemi di monitoraggio delle città moderne (IoT), dove ogni millisecondo conta.
  4. Risparmio di Banda: Elaborare i dati in loco riduce la necessità di trasferire grandi quantità di dati in cloud, risparmiando banda e costi associati.
  5. Affidabilità: L’edge computing migliora l’affidabilità delle applicazioni. In caso di interruzione della connettività cloud, i dispositivi edge possono continuare a funzionare autonomamente.
  6. Scalabilità: L’edge computing è altamente scalabile. È possibile aggiungere dispositivi edge in modo modulare per gestire carichi di lavoro crescenti.
  7. Privacy: Per alcune applicazioni, come il monitoraggio della salute in tempo reale, la privacy dei dati è essenziale. L’edge computing mantiene i dati locali, riducendo le preoccupazioni sulla privacy.

In sintesi, l’edge computing è una soluzione vantaggiosa per applicazioni che richiedono velocità, sicurezza e controllo dei dati. Tuttavia, è importante notare che non esclude completamente il cloud computing, ma piuttosto lo integra in un modello ibrido per massimizzare i benefici.

Svantaggi dell’uso del Cloud Computing

  1. Aumento della Latenza: Nel Cloud, i dati devono viaggiare attraverso una rete molto estesa fino ai server remoti, causando ritardi (latenza) nell’elaborazione. Nel modello di Edge Computing, la distribuzione delle risorse di elaborazione avviene all’edge della rete, vicino ai dispositivi o ai sensori. Ciò elimina la necessità di trasmettere dati su lunghe distanze ai server remoti del Cloud, riducendo significativamente la latenza. Questa bassa latenza è essenziale per applicazioni in tempo reale come il controllo industriale, la guida autonoma e la realtà virtuale, migliorando notevolmente l’efficienza e la reattività dei sistemi.
  2. Dipendenza dalla Connessione Internet: Il Cloud richiede una connessione Internet costante, mentre l’Edge Computing funziona anche offline, garantendo continuità operativa.
  3. Controllo sull’Infrastruttura: Nel Cloud, hai meno controllo sull’infrastruttura sottostante, poiché è gestita dal provider. Con l’Edge Computing, hai maggiore controllo su hardware e sul software.
  4. Sicurezza e Privacy: Il Cloud può presentare rischi di sicurezza dovuti alla memorizzazione dei dati su server remoti. L’Edge Computing può offrire un maggiore controllo sulla sicurezza, poiché i dati rimangono locali.
  5. Costi Operativi: Il mantenimento di server remoti nel Cloud può comportare costi operativi elevati, mentre l’Edge Computing può essere più economico in particolare per piccole implementazioni locali.
  6. Complessità della Gestione: La gestione di ambienti Cloud complessi può richiedere competenze specializzate, mentre l’Edge Computing può essere più semplice da gestire localmente.

Certo tutto questo può essere solo un parere soggettivo determinato dalle mie personali esperienze lavorative, per altre persone potrà essere l’esatto contrario, rimango comunque dell’avviso che ciò di cui ho parlato descrive, in un paragone calzante, le stesse problematiche che il mondo sta affrontando per l’eccessiva deindustrializzazione dell’occidente che ha deciso decenni addietro di esternalizzare i processi produttivi sull’onda del concetto di “globalizzazione”, per il quale si è arrivati oggi ad essere dipendenti dei nostri fornitori (vedi la Cina solo per fare l’esempio più lampante) senza i quali non potremmo assemblare un PC o un telefonino, produrre abbastanza energia elettrica etc….

Alla fine un’azienda non è così diversa da uno Stato, lo Stato per essere definibile come tale deve avere un popolo che lo contraddistingue ed un territorio su cui esercita la sua sovranità; un’azienda necessità di proprio personale che apporta lavoro ed intelletto, che crea e genera idee da cui scaturiscono know-how e magari anche brevetti e deve essere la proprietaria di tutto ciò che produce e/o trasforma, altrimenti per entrambi i casi parliamo solo di “Colonie”.

GO il nuovo linguaggio web di Google

Google-GO

Google-GO new Web language

Che cosa è Go?
Go (chiamato anche GoLang) è un linguaggio di programmazione realizzato da Google. La progettazione è cominciata nel 2007. Tra gli ideatori del linguaggio ci sono anche nomi come Ken Thompson, Rob Pike, Robert Griesemer (i primi due sono stati anche tra i creatori del sistema operativo Unix). Il progetto è stato annunciato pubblicamente nel novembre 2009, e la versione 1.0 è uscita nel marzo 2012.

 

Le caratteristiche di Go
Go è un linguaggio statically-typed, significa che la verifica dei tipi di variabili è effettuata durante la compilazione (cosi come accade per C, Java, Scala e Pascal) e non durante il run-time (come accade per JavaScript, PHP, Python e Ruby).
Go soddisfa le esigenze della programmazione concorrente ed è stato progettato per ottimizzare i tempi di compilazione anche per hardware modesti. La sintassi è vicina al C eccetto per la dichiarazione dei tipi e per la mancanza di parentesi tonde nei costrutti for e if. Ha un sistema di garbage collection che si occupa autonomamente della gestione della memoria. Non include l’intercettazione di eccezioni, l’eredità dei tipi, la programmazione generica, le asserzioni e l’overloading dei metodi.

 

Go, linguaggio ideale per i webservices
Come accennato poco sopra, Go nasce come linguaggio generalista, ma negli ultimi anni di sviluppo si è affermato come linguaggio ideale per i webservices. Il motivo di questo successo si deve principalmente a tre aspetti:

  • facilità di deployment,
  • efficienza nell’uso della memoria,
  • gestione della concorrenza

Facilità di deployment
Rispetto ad altri linguaggi, Go ci permette di effettuare un server deployment estremamente semplice. Sulla macchina di produzione non è dunque necessario installare alcun webserver (Apache o Nginx), alcuna Virtual Machine (come in Java), alcun tipo di wrapper (come l’WSGI per il Python) e neppure nessuna componente del linguaggio Go.
Sara’ sufficiente copiare l’eseguibile Go e farlo girare sul server come un normale servizio.

Il file eseguibile di Go contiene gia tutto al suo interno:

  • il codice, il Go runtime,
  • il webserver,
  • eventuali libraries

Le dimensioni sono cosi’ particolarmente ridotte, in genere intorno ai 10 MB, ed i tempi di compilazione sono tra l’altro immediati, tipicamente meno di 1 secondo, ed è possibile fare cross-compilation da e per qualunque tipo di sistema operativo: Linux, Mac, Windows.

 

Efficienza nell’utilizzo della memoria
In termini di efficienza nell’utilizzo della memoria, Go è comparabile al linguaggio C, eliminando però molta della complessità tipica del C, utilizzando pattern di programmazione più solidi e intuitivi. Il garbage collector in Go è estremamente performante e, dalla versione 1.5 (oggi Maggio 2017 siamo alla versione 1.8.3) ha raggiunto una latenza molto vicina allo zero.

Comparata a quella di Java, l’impronta in memoria di Go è una frazione minuscola. Questo permette alle applicazioni scritte in Go di essere, oltre che semplici da scrivere, anche estremamente performanti, e di richiedere risorse hardware molto ridotte, ottimo ad esempio per ambienti su Docker.

 

Concurrency
Il fiore all’occhiello di Go è necessariamente l’estrema facilità con cui si possono scrivere applicazioni che utilizzano codice concorrente. Infatti, oltre ad essere sintatticamente semplici da scrivere, sono anche estremamente performanti. Nessun’ altro linguaggio di programmazione si avvicina a Go in questo aspetto.

La concorrenza in Go si può implementare in due modi: tramite i canali, che si ispirano alle teorie CSP (Communicating Sequential Processes) di C. Hoare, e tramite le goroutines, funzioni che possono essere eseguite in modo concorrente anche nell’ordine di molte migliaia.

Go inoltre offre uno strumento molto efficace per identificare eventuali data-race, ossia le situazioni in cui due
go-routine accedono alla stessa variabile in modo concorrente e almeno uno dei due accessi è in scrittura.

Altra novità molto interessante: Go è uno dei linguaggi ufficiali per la programmazione su Google App Engine – il servizio PaaS (Platform-as-a-Service) del Cloud di Big G – oltre a Python, PHP e Java. Proprio in questi giorni è stato annunciato che il supporto per Go sulla piattaforma non è più in fase beta ma risulta disponibile tra i servizi GA (Generally Available).

 

Non resta che provare ad adattarlo alle nostre esigenze !.

 

 

Docker – costruire i contenitori

Docker costruire i contenitori

Docker costruire i contenitori

Recentemente abbiamo parlato della virtualizzazione tramite Docker (vedi articolo Docker – cosi cambia la virtualizzazione) e, prima di proseguire sara’ meglio rifare una piccola introduzione.

Docker e’ indubbiamente una valida alternativa alla virtualizzazione tradizionale nel mondo Linux. Questo tipo di virtualizzazione, detta a “container” non emula un’ intero hardware come fanno invece gli hypervisor tipo VMware, Virtualbox, Xen o KVM, ma crea invece dei “contenitori” nel sistema operativo dove possono essere messe in esecuzione applicazioni di vario genere in modo del tutto separato una dall’altra.

Dato che con il cloud il ruolo del sistema operativo diventa sempre meno importante perchè si punta più sullo strato applicativo, PaaS, rendendo il tutto più flessibile. A questo punto se dovessimo far girare 1000 clienti su un ambiente condiviso, diventerebbe interessante disporre di una tecnologia di virtualizzazione che riduca al minimo fisiologico gli overhead.

La virtualizzazione classica non è così, perchè per ogni ambiente applicativo, riservato ad un cliente, si dovrebbe  lanciare una intera macchina virtuale con dentro l’intero sistema operativo. E allora perchè non condividere lo stesso sistema operativo e invece isolare solo gli ambienti di esecuzione delle applicazioni , tipo application server, DB ecc…

I container sono dunque alla base dei moderni servizi cloud di tipo PaaS (Platform as a service) che usano questo tipo di virtualizzazione per misurare il consumo di risorse ed assegnarne i limiti.

Ad esempio, se su uno stesso server fisico, con una soluzione di virtualizzazione di tipo hypervisor si possono ospitare, supponiamo 50 virtual machines, con la virtualizzazione a container si potra’ arrivare anche a 1000 container. Questo perchè un container di per sè è solo un contenitore di processi, mentre una virtual machine completa contiene tutto un ambiente operativo emulato.

Il container può anche essere portabile, infatti ci basta copiare la directory che contiene il filesystem modificato dall’utente dopo la creazione del container, un piccolo file di configurazione, ed il container diventera’ eseguibile su qualsiasi sistema che supporti LXC.

Il concetto è talmente interessante, che qualcuno ha pensato di fare un sistema operativo Linux interamente basato sui container, in cui non c’è nemmeno un package manager perchè si assume che gli applicativi saranno solo in forma di container. Coreos è nato proprio con il principio di supportare ambienti di esecuzione a container, togliendo dal sistema tutto quello che non è strettamente necessario per farlo funzionare.

INSTALLAZIONE

Abbiamo tre possibili metodi d’installazione :

1) Centos

sudo yum -y install docker-io

2) Debian/Ubuntu

sudo apt-get update 
sudo apt-get install docker.io 
sudo sudo apt-get install lxc-docker

3) Download con Curl

sudo curl -sSL https://get.docker.io/ubuntu/ | sudo sh

* Linkiamo docker alla nostra bash

ln -sf /usr/bin/docker.io /usr/local/bin/docker
sed -i '$acomplete -F _docker docker' /etc/bash_completion.d/docker.io

* Rendiamo docker attivo all’avvio

update-rc.d docker.io defaults

P.S.: Ci sono molti contenitori già disponibili nella community docker, che possono essere trovati attraverso una ricerca. Ad esempio con questo comando cerchero’ la parola debian:

# docker search debian

NAME    DESCRIPTION      STARS     OFFICIAL   AUTOMATED
debian  Debianbaseimage  310         [OK]
google/debian            31                     [OK]

….e molte altre che potrete leggere dall’output completo.

** Installiamo e facciamo provisioning con una immagine Centos

# docker pull blalor/centos  # GitHub blalor/docker-centos-base  image

oppure per chi fosse interessato ad una immagine con gia inserito il tool Ansible (per il Configuration Management ed IT Automation) di cui ho da poco parlato, potra’ scegliere quest’altra immagine.

sudo docker pull ansible/centos7-ansible # GitHub Ansible on Centos7
Pulling repository ansible/centos7-ansible
fff2afd18a57: Download complete

Avviamo un container docker

Attiveremo ora un contenitore centos-base con una shell bash, utilizzando il comando run. Docker eseguira’ questo comando in un nuovo contenitore, -i attribuisce stdin e stdout, -t assegna un terminale.

docker run -i -t centos /bin/bash

Questo è tutto! Adesso stai usando una shell bash all’interno di un contenitore centos.
Per scollegarsi dalla shell la sequenza di escape e’ : Ctrl-p + Ctrl-q.

Diamo un’occhiata ai processi attivi tramite :

# docker ps -a
CONTAINER   ID IMAGE          COMMAND     CREATED
fff2afd18a57     blalor/centos     /bin/bash         About an hour ago

Il Dockerfile
Per automatizzare la procedura di creazione e modifica di un container docker, possiamo utilizzare il Dockerfile, che è una delle parti principali di Docker, infatti attraverso il Dockerfile è possibile non solo fare il deploy istantaneo automatizzato di più istanze e più container, ma è anche possibile eseguire il provisioning di queste istanze, automatizzando task di gestione del sistema, installazione del software e molto altro.

Nel prossimo articolo vedremo un esempio utile, utilizzando ad esempio un’applicazione leggera, che puo’ lavorare molto bene in un contenitore, come NGINX, il noto server web/cached per la gestione di siti web/proxy ad alto carico.

#DockerContainerAvviato

Docker – cosi’ cambia la virtualizzazione

docker_logoPREMESSA

Docker, inizialmente sviluppato per la piattaforma PaaS (Platform as a Service) di dotCloud, e’ oggi disponibile su Red Hat Fedora e sulla soluzione enterprise OpenShift. Grazie a questa tecnologia, la virtualizzazione passerà al livello applicativo, impacchettando quanto necessario per eseguire le applicazioni su differenti tipologie d’infrastrutture. Ecco quindi come si estendera’ il concetto del Linux Containers LXC , di cui abbiamo trattato in un prededente articolo (vedi link LXC).Docker è il nome di un nuovo ed impotante esempio di progetto, e di start-up, che ha stupito il mondo dell’open source ed ha attirato l’interesse finanziario, e non solo, di grandi gruppi del settore come Red Hat, e non solo.

Per chi non lo conoscesse, Docker è un progetto che automatizza il deployment delle applicazioni fra differenti piattaforme Linux based. L’obiettivo della piattaforma è quello di consentire la distribuzione e l’esecuzione agevole di un app su differenti tipologie di macchine, dotate di differenti sistemi operativi Linux, dai server virtuali, ai cloud-server presenti fra le nuvole private e pubbliche, fino ai bare-metal server, e fin’anche alle macchine fisiche.

Docker è stato inizialmente sviluppato per DotCloud la startup proprietaria di un’infrastruttura PaaS (Platform as a Service) multilingua.

Docker: ecco come funziona

Il funzionamento di base di Docker è alquanto semplice: il tool è capace di impacchettare un’applicazione e le sue dipendenze in un contenitore virtuale che può essere mandato in esecuzione su qualsiasi versione di Linux.Il risultato di questo processo è una maggiore flessibilità e portabilità delle applicazioni e l’opportunità di eseguirle ovunque senza alcuna problematica, dal proprio laptop, ai cloud server privati e pubblici, ai server virtuali fino ai server fisici.

Dockers non effettua la portabilità delle macchine virtuali o dei sistemi operativi, ma rende portabile il codice con cui l’applicazione è scritta, permettendo così una maggiore mobilità fra le macchine virtuali, anche nelle infrastrutture di cloud computing.

Dockers estende un formato comune di package già presente in Linux e noto come Linux Containers o LXC e Dockers per l’appunto utilizza il formato LXC, e le funzionalità kernel di Linux stesso, mentre lascia all’infrastruttura sottostante il compito di provvedere alle funzionalità del sistema operativo.

Docker sembra sposarsi perfettamente con OpenShift, con cui condivide alcuni aspetti tecnologici e architetturali fondamentali, come i namespace del kernel Linux e la gestione delle risorse tramite cGroups. Lo stesso Openshift, infatti, è costruito su Red Hat Enterprise Linux a già offre un sistema di “cartridge” basato sul formato LXC attraverso l’utilizzo delle Red Hat Enterprise Gears, che sara’ in grado di aumentarne l’usabilità e portabilità.

Il progetto Docker sta riscuotendo un alto livello d’ interesse anche fra i colossi del Web e dell’IT a tal punto che aziende del calibro di Microsoft, Red Hat (gia citata), IBM, Mesosphere, CoreOS, SaltStack e Google hanno iniziato a collaborare su un progetto open source pensato a Mountain View e conosciuto con il nome in codice Kubernets.

In pratica, Google e gli altri attori citati vogliono agevolare la gestione e l’uso dei contenitori Docker e Mountain View è fra le prime a sfruttare in modo massivo la tecnologia pensata da Docker all’interno dei suoi data center.

Insomma, per concludere, grazie ai signori di Docker passeremo presto ad un nuovo concetto di virtualizzazione, tutto ancora da scoprire, ma a vedere i nomi delle aziende che vogliono scommeterci , non resta che iniziare a prepararsi.

Bye