Appunti lezioni Cloud Computing

POST PUT

per eliminare una risorsa;

DELETE

per ottenere lo stato corrente di una risosa.

GET

3. Messaggi auto-descrittivi:

Le richieste contengono le “context information” sufficienti a processare il messaggio;

Le risorse sono scollegate dalla propria rappresentazione, cosi che il contenuto può essere visualizzato in vari

formati (HTML, XML, JSON, plain text, PDF, JPEG, etc.)

4. Interazioni stateful tra gli hyperlinks:

Ogni interazioni con una risorsa è stateless

I server non contengono informazioni sui client, ogni sessione è tenuta sul client

Le interazioni stateful, si affidano sul concetto di trasferimento esplicito dello stato

ESEMPIO:

Il cliente vuole aggiornare il suo ultimo ordine di cibo.

Lezione 8 | REST 1

ESEMPIO 2:

Si vuole organizzare il prossimo venerdì sera.

Ogniuno aggiorna inserendo qualcosa

Content negotation

Essendo a carico del client, l’elaborazione dei dati ricevuti dal server, durante la negoziazione può venire specificato il

tipo di formato “gradito” per la descrizione dell’applicazione.

Progettazione URIs

Per la progettazione di una risorsa, ci sono 7 step da seguire:

1. Identifica le risorse da esporre come servizi.

2. Modella le relazioni tra le risorse utilizzando collegamenti ipertestuali.

Lezione 8 | REST 2

3. Definisci URI «puliti» per indirizzare le risorse.

4. Comprendi il significato delle operazioni GET/POST/PUT/DELETE per ciascuna risorsa (e se consentirle o meno).

5. Progetta e documenta le rappresentazioni delle risorse.

6. Implementa e distribuisci sul servizio Web.

7. Testa utilizzando un browser web.

Spazio di progettazione

Linee guida

Preferire nomi ai verbi

NO → GET /book?isbn=24&action=delete

SI → DELETE /book/24

Mantenere gli URIs piccoli

Utilizzare URI templates, per costruire e analizzare URIs parametrici

NON cambiare mai gli URIs, utilizzare reindirizzamenti se necessario.

Vantaggi e svantaggi | REST

Pro

Bassa curva di apprendimento:

Il REST sfrutta standard ben conosciuti (HTTP, XML, URI)

Le infrastrutture necessarie sono già presenti

Efficienza:

Protocollo leggero

Formati di messaggi piccoli e leggeri

Scalabilità:

Lezione 8 | REST 3

I servizi RESTful sopportano un’alto numero di clients

Cons

I client possono ottenere dati in eccesso o in difetto (over-/under-fetch data)

Limite sul numero di richieste client

Convenzioni di denominazione discordanti

Amazon API mandato

Dal 2002, Bezos attraverso una nota obbligo tutti i team di sviluppo ad utilizzare le inferfaccie come mezzo

comunicativo, oltre che renderle esternizabili.

1. D’ora in poi, tutti i team dovranno esporre i propri dati e funzionalità attraverso servizi ad interfacce

2. I teams devono comunicare tra di loro attraverso quest’ultime interfaccie

3. Non sarà consentita alcuna altra forma di comunicazione interprocesso

4. Non importa quale tecnologia si utilizza

5. Tutti i servizi a interfaccia, devono essere progettati per essere esternizabili

6. Chiunque non fa ciò, sarà licenziato

OpenAPI

Mira a creare un formato standard di tipo “vendor neutral description”, per REST API.

Un file JSON-based, che specifica gli HTTP API endpoints, come sono utilizzati e il tipo di

struttura che hanno i dati in entrata e in uscita.

MOTIVAZIONI:

1. Shorten lead time for new features and updates → accelerate rebuild and redeployment

2. Scale, effectively

Lezione 8 | REST 4

Essenza dei microservizi

Sviluppa applicazioni come insiemi di servizi:

ciascuno in esecuzione nel proprio container di processo;

che comunicano tramite meccanismi leggeri;

costruiti attorno a capacità aziendali;

con gestione dei dati decentralizzata;

distribuibili in modo indipendente;

scalabili orizzontalmente.

resistente ai guasti

DevOps

Metodologia di sviluppo software centrata su comunicazione, collaborazione e integrazione tra i vari sviluppatori,

mettendo assieme gli aspetti di sviluppo software (Dev) con le IT Ops.

Il team è responsabile dello sviluppo, della distribuzione e del managment.

Strumenti attualmente utilizzati per seguire questa filosofia:

VCS (Version Control Systems)

CI/CD (Continuous Integration/Continuos Deployment)

IaC (Infrastructure As Code)

Netflix

Il servizio Netflix è strutturato da microservizi che fanno capo ad API diverse a seconda del dispositivo con il quale

viene richiesto il servizio

Lezione 8 | REST 5

ELB: AWS Elastic Load Balancing

Zuul: proxy layer, performs dynamic routing

NCCP: legacy tier, supporting earlier devices

Netflix’s API gateway, calling all other services

Vantaggi e Svantaggi microservizi

Lezione 8 | REST 6

Lezione 9 | Kubernetes

Containers

Unità isolate che racchiudono un’applicazione e tutte le sue dipendenze, garantendo che essa funzioni in modo

coerente su ambienti diversi.

Si basano sulla virtualizzazione a livello di sistema operativo, utilizzando meno risorse rispetto alle VM.

Vantaggi:

Portabilità.

Velocità di avvio.

Isolamento e sicurezza.

Svantaggi:

Gestione complessa di ambienti multi-container senza strumenti di orchestrazione.

Necessità di orchestratori per il bilanciamento, scalabilità e resilienza.

Automated Deployment | Container Orchestration

Automated Deployment

Automatizza il processo di rilascio e aggiornamento del software.

Strumenti: Jenkins, GitLab CI/CD, GitHub Actions.

Vantaggi:

Rilascio rapido e continuo.

Riduzione degli errori umani.

Svantaggi:

Gestione limitata di ambienti complessi.

Mancanza di funzionalità native per la scalabilità e il bilanciamento del carico.

Container Orchestration

Coordina l'esecuzione di più container in ambienti distribuiti.

Gestisce scalabilità, bilanciamento del carico, resilienza e comunicazione tra i container.

Strumenti: Kubernetes, Docker Swarm.

Vantaggi:

Automazione completa per grandi cluster di container.

Supporto per l'autoscaling e l'auto-riparazione.

Svantaggi:

Curva di apprendimento più ripida.

Complessità nella configurazione e manutenzione.

Lezione 9 | Kubernetes 1

Kubernetes

Piattaforma open-source per la gestione automatica di container su larga scala (orchestratore)

Funzionalità principali:

Scalabilità automatica.

Self-healing (riparazione automatica dei container difettosi).

Gestione del carico e networking.

Aggiornamenti senza downtime.

Applicazione a microservizi:

Il raggruppamento dei pod in uno o più nodi, aventi risorse e potenza diversa a seconda delle necessità,

permette il

funzionamento dell’applicazione.

K8s objects

Kubernetes viene anche chiamata come K8s per via dei sui eight design principles:

Declarativeness

Definiamo semplicemente lo stato desiderato del nostro sistema.

Kubernetes (K8s):

Rileverà quando lo stato effettivo del sistema non soddisfa le nostre aspettative e

Interverrà per risolvere il problema, rendendo il sistema auto-riparante (self-healing).

Lo stato desiderato è definito da una raccolta di oggetti:

Ogni oggetto ha:

Una specifica, in cui si fornisce lo stato desiderato.

Uno stato, che riflette lo stato attuale dell'oggetto.

Kubernetes controlla costantemente ogni oggetto per assicurarsi che il suo stato attuale corrisponda alla specifica.

Se un oggetto non risponde, Kubernetes avvierà una nuova versione per sostituirlo.

Se lo stato di un oggetto diverge dalla specifica, Kubernetes emetterà i comandi necessari per riportare l'oggetto

allo stato desiderato.

Distribution

K8s fornisce un’interfaccia unificata per interagire con un cluster di macchine.

Non dobbiamo preoccuparci di comunicare con ogni macchina individualmente

Decoupling

I container devono essere sviluppati con l’obiettivo di un’architettura a microservizi.

Lezione 9 | Kubernetes 2

Kubernetes supporta nativamente l'idea di servizi disaccoppiati, i quali possono essere

scalati e aggiornati in modo indipendente.

Immutable infrastructure

Per sfruttare al massimo i container e l'orchestrazione, si dovrebbe implementare un'infrastruttura immutabile.

Cioè, invece di accedere a un container su una macchina per aggiornare una libreria, è

meglio creare una nuova immagine del container, distribuirla e discontinuare la vecchia.

Durante il ciclo di vita di un progetto (sviluppo - test - produzione) si deve usare la

stessa immagine del container, modificando solo le configurazioni esterne all’immagine. (montando un file di

configurazione)

I container sono progettati per essere effimeri ⇒ sostituiti in qualsiasi momento.

Un'infrastruttura immutabile semplifica il rollback delle applicazioni a uno stato precedente:

è sufficiente aggiornare la configurazione per usare una versione precedente dell'immagine del container.

Pod

Un Pod è composto da:

Uno o più container (strettamente correlati).

Un livello di rete condiviso.

Volumi del file system condivisi.

Deployment

Un oggetto Deployment include:

Una raccolta di Pod definiti da un template.

Un replica count (numero di copie del template che vogliamo eseguire).

n

Il cluster cercherà sempre di avere Pod disponibili.

n

Ad esempio, se definiamo un deployment con un replica count di 10 e 3 di quei Pod si arrestano, altri 3 Pod verranno

pianificati per l'esecuzione su una macchina diversa nel cluster.

Esempio: object deployment per eseguire 10 istanze di un container che serve un ML model attraverso un’interfaccia

REST.

Lezione 9 | Kubernetes 3

Service

A ogni Pod è assegnato un indirizzo IP univoco, utilizzato per comunicare con esso.

Per mantenere la connessione con i Pod, anche dopo uno scaling, aggiornamento o guasto, la comunicazione viene in

realtà effettuata ad un endpoint, responsabile di quel set di Pod,

e che indirizza il traffico.

Endpoint che si occupano di indirizzare il traffico in base alle label (coppie chiave-valore).

Queste coppie di valori, sono contenute nei metadati dei Pod.

Esempio:

Servizio costruito attorno all’esempio precedente.

Ingress

permette di esporre le applicazioni dietro un endpoint che però è disponibile solo per il traffico interno al

Service

cluster, per esporre l’applicazione al traffico esterno si utilizza Ingress.

Possiamo selezionare quali Servizi rendere disponibili pubblicamente.

Lezione 9 | Kubernetes 4

Esempio:

Control plane

In un cluster kubernet ci sono 2 tipi di macchina:

master node (control plane): si occupa di orchestrare tutti gli altri nodi.

assegna il lavoro ai nodi e gestisce tutto il traffico API sia interno che esterno

worker node: m