Cloud Native Kubernetes: Flusso e opportunità di lavoro

Questo nuovo articolo vuole indicare le nuove opportunità di lavoro create da un ambiente cloud-native.

L’immagine n°1 mostra i quattro livelli principali necessari all’architettura per funzionare correttamente (parte rettangolare sinistra).

Sul lato destro (cerchi) sono rappresentati le occupazioni dell’operatore rispetto ad ogni singolo livello.

Immagine 1

Dal basso verso l’alto:

1- Gli Storage and Network Operator (SNO) hanno la responsabilità di gestire l’architettura hardware.

Il numero dell’attività del ruolo può diminuire in caso di implementazione in un cloud pubblico o IaaS (Infrastructure as a Service)

2- L’Operatore del sistema operativo (OSO) lavora al livello del sistema operativo in cui viene eseguito il servizio k8s.

L’OSO ha bisogno di competenza in Linux e Windows. Sono spesso richieste competenze nell’architettura di virtualizzazione come VMware, RedHat, Nutanix, ecc.

Se l’architettura è stata affittata dal cloud pubblico o in generale in un IaaS, le competenze devono coprire questa nuova architettura.

3- L’operatore di orchestrazione (OO) lavora con il nucleo dell’ambiente di amministrazione cloud-native. Questo mondo ha bisogno di molte nuove abilità.

L’automazione è il figlio dell’orchestrazione.

Il concetto principale è che l’OO dovrebbe avere competenze sufficienti per riuscire a seguire tutti i processi di “Integrazione Continua” e “Consegna Continua” (spesso chiamata CI/CD).

L’immagine 2 dà un’idea a riguardo

Le frecce centrali mostrano il flusso per consentire l’erogazione di un servizio.

Per ogni singola freccia ci sono nuovi strumenti da conoscere per gestire l’intero rilascio del servizio.

Solo alcuni esempi: per testare l’ambiente è possibile lavorare con cetriolo o Cypress.io, per la distribuzione e la costruzione è possibile utilizzare Jenkins… e così via…

Immagine 2

Nota 1: ci sono così tante piattaforme disponibili che la scelta di quella giusta potrebbe essere molto impegnativa

4- L’operatore di sviluppo è il ruolo delle persone che sono scritte righe di codice. Spesso usano software per gestire attività come Jira Core e Trello.

Nota 2: A mio parere personale, il fornitore che crea un livello software in grado di gestire centralmente tutte queste 6 attività principali avrà un vantaggio competitivo rispetto ai concorrenti.

I grandi fornitori stanno già giocando: RedHat sta lavorando dall’inizio con la sua piattaforma (OpenStack), VMware ha rilasciato Tanzu, Nutanix con Carbonite e Microsoft giocherà il suo ruolo con la nuova versione di Windows 2022.

L’unico buon suggerimento che posso darti è quello di studiare questo nuovo e fantastico mondo.

A presto e abbi cura di te

Kubernets: Perchè adottarlo?

Kubernetes (k8s), è una piattaforma open source, introdotta da Google, introdotta come un semplice strumento di orchestrazione di container ma è diventata di fatto la piattaforma cloud-native.

Perché “k8s” viene così ampiamente utilizzato?

Poichè  è in grado di rispondere efficacemente alle richieste di qualità di servizio degli utenti,  di adattarsi alla creatività dei cloud-architect e di essere così stabile da soddisfare le richieste delle operation.

Tali vantaggi possono essere così riassunti:

  • Affidabile
  • Scalabile
  • Auto-guarigione
  • Veloce
  • Efficiente
  • Sicuro
  • Agile
  • Trasportabile

Nel presente articolo svilupperemo le 8 argomentazioni appena indicate:

1- Affidabilità significa un’architettura in grado di funzionare anche se una parte di essa non è più disponibile. K8s è stato pensato con una filosofica nativamente clusterizzata.

2- La scalabilità è necessaria per gestire qualsiasi picco di carico di lavoro. In altre parole, è in grado di risponde a richieste di nuove risorse on-demand.

Il modello di architettura sul quale si basa è il disaccoppiamento. Ogni singolo componente ha le proprie caratteristiche e può essere facilmente aggiunto all’ambiente k8s.

Attraverso i file di configurazione i vari oggetti sono autorizzati a comunicare tra loro.

I componenti principali dell’architettura k8s sono i nodi, i componenti dei servizi k8s sono i bilanciatori del carico, i name-spaces e così via (vedi prossimi articoli)

3- Guarigione: K8s agisce per assicurare che lo stato corrente corrisponda automaticamente allo stato desiderato dell’architettura.

4- Veloce: K8s è in grado di distribuire i componenti immediatamente. In questo modo è possibile rispondere ad una richiesta di gestione del sovraccarico e/o necessità di implementare velocemente nuovi servizi.

5- L’efficienza è il rapporto tra il lavoro utile e la quantità totale di energia utilizzata per ottenere il risultato. K8s per la sua architettura ha il miglior rapporto perché ha l’essenzialità nel suo DNA.

6- La sicurezza lavora a stretto contatto con k8s.

a- Le immagini che girano nei contenitori sono per la loro definizione immutabili. Questo approccio ha un grande vantaggio perché:

Nessuna modifica viene implementata a livello di sistema (contenitore).

-Niente può modificare il nucleo del servizio a meno che l’intera immagine non venga eliminata e ridistribuita.

Confrontiamo questo approccio con un ambiente standard, dove è presente una VM  Linux.

Se su quest’ultima volessimo installare, modificare, aggiornare un’applicazione, dovremmo agire via apt-get sui pacchetti necessari.

Così facendo modificheremo l’ambiente aprendo di fatto una breccia in ambito sicurezza.

In K8s non viene modificata l’immagine ma cancellata e ricreata.

b- Un altro grande vantaggio è che le modifiche alla configurazione sono gestite tramite file dichiarativi (file di configurazione). Questi file hanno una descrizione dello stato finale del sistema. Il risultato è che mostrano l’effetto della configurazione prima che venga eseguita.

7- Agilità significa maggiore facilità ed efficienza nella creazione di immagini container rispetto all’utilizzo di immagini VM. Lo sviluppatore può scrivere codice indipendentemente dai problemi di compatibilità.

8- La portabilità crea lo standard del ciclo di vita dello sviluppo software.

Nota 1: la prima versione di Kubernetes risale al 2014 ed è stata creata per rispondere alla necessità di implementare una solida soluzione di cluster per ambienti container.

Statemi  bene e a presto

Modern Applications – Episod 1: Foundamentals

Introduction

This is the first of a group of articles about the technologies that can modernize the applications.

The scope is helping the reader to understand the potentiality of this new way to make business allowing the Companies to be more competitive.

These articles follow my personal approach and studies of Kubernetes.

I’m paying attention to how to make services available and protected by exploiting internal and external native technologies

Let’s start !!!

What is a container

It’s a way to package the applications with their pertinent dependencies and configurations in just one block.

There are at least two big advantages of this approach:

  • The container for his native architecture is portable. It means you can run it in any architecture wherever they are located. (please read the  article Digital Transformation and Cloud Mobility to get all detail)
  • Deploying services prove easier and more efficient than in the traditional world because there are already plenty of software images ready to be used.

Where can I download images to run to the containers?

There are public and private Repositories (please do not mess it with a VBR Repository).

The most famous container technology is Docker that has a public repository called docker hub.

What is a container exactly?

A container allows isolated images to run to an operating system.

Container vs Virtual Machine

The difference between the two architecture seems to be very tiny but actually, they represent two worlds.

The two technologies are virtualization tools but if Docker focuses on the applications layer (picture 1),  VM puts its attention to Kernel and application (picture 2)

Picture 1

Picture 2

Which are the main advantages of this new approach:

  • The container has a small footprint (few MB compare to GB).
  • The boot is faster.
  • Easier compatibility list.
  • It can run in all common operating systems, such as Windows, Mac-OS, Linux.

Container vs Image

It’s crucial to the next articles to have very clear the difference between a container and an image.

Let’s help ourselves through picture #3 that shows the application composition.

There are four main elements:

  1. Image: It’s the code written by developers. It is downloaded from Repositories.
  2. Configuration: It represents the setup created to allow the application to run.
  3. File System: It’s the place where the application and its data are stored.
  4. Network: It allows all components to talk to each other.

The container is where the application runs.

Picture 3

Note 1: Images are part of the container. Think of the container as a multitasking OS specialized to run applications simultaneously.

Note 2: To get info about Docker, please refer to the official website.                I.E.: to run an image just launch the following command:                                  docker run image-name

Note 3: There are more Container technologies; the most common are:

  • RTK (CoreOS)
  • LXC
  • LXD (Canonical)
  • Linux VServer
  • OpenVZ/Virtuozzo 7
  • runC

That’s all for now,  see you soon and take care.

Digital Trasformation & Data Mobility

Se negli ultimi 5 anni, la parola Cloud è stata quella più utilizzata (anche in modo inappropriato), negli ultimi cinque mesi la parola che sta rieccheggiando di più nel mondo IT  è Digital Transformation.

Da Wikipedia:

Digital Transformation (DT o DX) è l’adozione della tecnologia digitale per trasformare servizi e aziende, sostituendo processi non digitali o manuali con processi digitali o sostituendo la tecnologia digitale precedente con la tecnologia digitale più recente”.

Ancora: la Digital Transformation deve aiutare le aziende ad essere più competitive attraverso la rapida implementazione di nuovi servizi sempre in linea con le esigenze aziendali.

Nota 1: La trasformazione digitale è il paniere, le tecnologie da utilizzare sono le mele, i servizi sono i mezzi di trasporto, i negozi sono i clienti/clienti.

1. Tutte le architetture IT esistenti possono funzionare per la Trasformazione Digitale?

Preferisco rispondere ricostruendo la domanda con parole più appropriate:

2. La trasformazione digitale richiede che dati, applicazioni e servizi si spostino da e verso architetture diverse?

, questo è un must ed è stato nominato Data Mobility.

3. La Data-Mobility significa che i servizi possono essere indipendenti dall’infrastruttura sottostante?

La miglior risposta credo che sia: nonostante al giorno d’oggi non esista un linguaggio standard che permetta a diverse architetture/infrastruttura di dialogare tra loro (on-premises & on cloud), le tecnologie di Data-mobility sono in grado di superare tale limitazione.

4. La Data Mobility è indipendente dai fornitori?

Quando uno standard viene rilasciato, tutti i fornitori vogliono implementarlo al più presto perché sono sicuri che queste funzionalità miglioreranno le loro entrate. Attualmente, questo standard non esiste ancora.

Nota 3: penso che il motivo sia che ci sono così tanti oggetti da contare, analizzare e sviluppare che lo sforzo economico per farlo non è al momento giustificato

5. Esiste già una tecnologia Ready “Data-Mobility”?

La risposta potrebbe essere piuttosto lunga ma, per farla breve, ho scritto il seguente articolo che si compone di due parti principali:

Livello applicazione (contenitore – Kubernetes)
Livello dati (backup, replica)

Application Layer – Container – Kubernetes

Nel mondo IT, i servizi sono eseguiti in ambienti virtuali (VMware, Hyper-V, KVM, ecc.).

Vi sono ancora alcuni servizi che girano su architetture legacy (Mainframe, AS400 ….), (vecchi non significa che non siano aggiornati ma solo che hanno una storia molto lunga)

Nei prossimi anni i servizi verranno implementati in un’apposita “area” denominata “container”.

Il contenitore viene eseguito nel sistema operativo e può essere ospitato in un’architettura Virtuale/Fisica/Cloud.

Perché i contenitori e le competenze su di essi sono così richiesti?

a. L’esigenza degli IT Manager è quella di spostare i dati tra le architetture al fine di migliorare la resilienza e ridurre i costi.
b. La tecnologia Container semplifica la scrittura del codice dello sviluppatore perché ha un linguaggio standard e ampiamente utilizzato.
c. I servizi eseguiti sul container sono veloci da sviluppare, aggiornare e modificare.
d. Il contenitore è “de facto” un nuovo standard che ha un grande vantaggio. Superare l’ostacolo della mancanza di standard di comunicazione tra le architetture (private, ibride e cloud pubblico).

Un approfondimento sul punto d.

Ogni azienda ha il proprio core business e tutte hanno bisogno della tecnologia informatica.

Qualsiasi dimensione dell’azienda?
Sì, basti pensare all’ uso del cellulare, per prenotare un tavolo al ristorante o acquistare un biglietto per un film. Sono anche abbastanza sicuro che ci aiuterà a superare la minaccia Covid.

Questo è il motivo per cui continuo a pensare che l’IT non sia un “costo” ma un modo per ottenere più successo e denaro migliorando l’efficienza di qualsiasi azienda.

Anche Kubernetes ha delle  funzionalità specifiche per consentire la mobilità dei dati?

Si, un esempio è Kasten K10 perchè ha tante e avanzate funzionalità di migrazione dei workload (l’argomento sarà ben trattato nei prossimi articoli).

Data-LayerCloud Backup Restore Icona - Download gratuito, PNG e vettoriale

E i servizi che non possono essere ancora  containerizzati?

C’è un modo semplice per spostare i dati tra diverse architetture?

Sì, è possibile utilizzando copie dei dati di VM e Server Fisici.

In questo scenario aziendale, è importante che il software possa creare backup/repliche ovunque si trovino i carichi di lavoro.

È abbastanza? No, il software deve essere in grado di ripristinare i dati all’interno delle architetture.

Ad esempio, un cliente può dover ripristinare alcuni carichi di lavoro on-premise della sua architettura VMware in un cloud pubblico o ripristinare un backup di una VM situata in un cloud pubblico in un ambiente Hyper-V on-premise.

In altre parole, lavorare con Backup/Replica e ripristino in un ambiente multi-cloud.

Le immagini successive mostrano il processo dei dati.

L’ho chiamato “Il ciclo dei dati” perché facendo leva su una copia di backup è possibile spostare liberamente i dati da e verso qualsiasi Infrastruttura (Cloud pubblico, ibrido, privato).

Le immagini 1 e 2 sono solo esempi del concetto di mobilità. Possono essere modificati aggiungendo tutte le piattaforme supportate dal software di cloud mobility.

Il punto di partenza dell’immagine 1 è un backup in locale che può essere ripristinato in locale e nel cloud. L’immagine 2 mostra il backup di un carico di lavoro sito in un cloud pubblico ripristinato su cloud o in locale.

È una via circolare in cui i dati possono essere spostati tra le piattaforme.

Nota 4: Un buon suggerimento è quello di utilizzare l’architettura di mobilità dei dati per configurare un sito di ripristino di emergenza a freddo (freddo perché i dati utilizzati per ripristinare il sito sono backup).

Immagine 1

Immagine 2

C’è un ultimo punto per completare questo articolo ed è la funzione Replica.

Nota 5: Per Replica intendo la possibilità di creare un mirror del carico di lavoro di produzione. Rispetto al backup, in questo scenario il carico di lavoro può essere avviato senza alcuna operazione di ripristino perché è già scritto nella “lingua” dell’host-hypervisor.

Lo scopo principale della tecnologia di replica è creare un sito di ripristino di emergenza a caldo (DR).

Maggiori dettagli su come orchestrare il DR sono disponibili su questo sito alla voce Veeam Disaster Recovery Orchestrator (conosciuto anche con il nome di Veeam Availability Orchestrator)

La replica può essere sviluppata con tre diverse tecnologie:

  • Replica Lun/Archiviazione
  • Split I/O
  • Snapshot

Tratterò questi scenari e i casi aziendali di Kasten K10 in articoli futuri.

A presto