# Serverless

https://intranet.vidiemme.it/argomenti-sessione-ottobre-2022/

---

## Lista della spesa:
- [x] Istanza DB Aurora => Usato DB maker che postgres è public (per il momento)
- [ ] Permessi per rilasciare con SAM (attualmente abbiamo problemi di permessi con cloudformation)
- [x] Access token per dialogare con Gitlab => glpat-YsLQN1nwhPiKLkh9dyJU

---

## Obiettivi e Deliverable
Il deriverable sarà quello di implementare alcuni endpoint (che verranno poi usati all'interno della documentazione su Confluence) in grado di restituire immagini WebP di grafici generati su diverse KPI. Un esempio delle KPI da realizzare è il seguente:

### Estratte da GitLab:

- Numero di merge request per repository (pesato per il numero componenti all'interno del repository) --> Grafico mensile/settimanale
- Media di quello sopra raggruppatto per practice --> Grafico mensile/settimanale
- Numero di pipeline eseguite con successo VS numero di pipeline fallite (per repository ) --> Grafico mensile/settimanale
- Media di quello sopra raggruppatto per practice --> Grafico mensile/settimanale
- Numero di progetti attivi per practice --> Semplice numero

### Estratte da Jira:

- Numero di epiche, storie, task e bug per progetto --> Grafico mensile/settimanale
(tutti i progetti non archiviati)

### Estratte da Sonarqube:

- Numero di bug rilevati da sonarqube per singolo progetto --> Grafico mensile/settimanale
- **(futuro)** Percentuale di coverage per singolo progetto --> Grafico mensile/settimanale

## Argomenti

- Quali sono i trigger possibili di una lambda
- Come rendere raggiungibile una funzione lambda su internet?
- Quali sono i limiti: applicativi e di risorse utilizzate (tempo e memoria)
- Quali sono i limiti del paradigma Serverless?
- lambda
- **paradimga**
- **Test unitari**
- Come automatizzare il deploy
- Come testare una lambda in locale
- Serverless Application Model (SAM) cos'è, come usarlo blabla...
- **Struttura di progetto (repository)**
- **Eseguire Typescript e build Java**
- **Casi d'uso, vantaggi e svantaggi nell'usare serverless**

### Perché utilizzare il serverless?

**Nessuna gestione di server**: non è più necessario allocare o gestire server. Non è necessario installare, gestire e amministrare alcun software o runtime.

**Scalabilità e flessibilità**: le risorse dell'applicazione saranno ricalibrate automaticamente, oppure la capacità sarà ottimizzata in base alle unità necessarie (ad esempio di memoria o di throughput), piuttosto che a unità di singoli server.

**Prezzi in base al valore**: paga per throughput coerente o durata di esecuzione piuttosto che per unità di server.

**Disponibilità elevata automatizzata**: il serverless fornisce elevata disponibilità e funzionalità di tolleranza ai guasti. Non è quindi più necessario progettare l'integrazione di queste caratteristiche, perché sono garantite di default dai servizi che eseguono l'applicazione.

### Quali sono i trigger possibili di una lambda

https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html

#### Metodi di invocazione diretti:
- Lambda console
- function URL HTTP(S) endpoint
- Lambda API
- AWS SDK
- AWS CLI
- AWS toolkits

#### Metodi di invocazione indiretti:

- Trigger (Una Lambda può avere più di un trigger)

Nei metodi indiretti si può creare un event source mapping per triggerare la Lambda. Un event source mapping può essere applicato a code e flussi (DynamoDB, Kinesis ecc).

#### Una lambda può essere invocata in modo SINCRONO o ASINCRONO.

### Come rendere raggiungibile una funzione lambda su internet?
- function URL HTTP(S) endpoint
- Api Gateway
- Cloudfront Lambda@edge

### Quali sono i limiti: applicativi e di risorse utilizzate

#### Limiti del paradigma Serverless

TODO

#### Limiti della Lambda (tempo e memoria)
https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html

### Organizzazione repository

[Best practices - organizing larger serverless applications](https://aws.amazon.com/blogs/compute/best-practices-for-organizing-larger-serverless-applications/)
Il repository può essere strutturato come monorepo con singola lambda (applicazione monolitica) oppure con più repository ciascuno che contiene il codice di una lambda specifica (modello micorservizi). L'esigenza di favorire un approccio monorepo o con più repository dipende dalle esigenze di progetto e di team di sviluppo. SAM o Serveless Framework possono aiutare a mappare ciascuna risorsa lambda con il suo repo.

### Compilazione e build lamba

- [Lambda Typescript](https://docs.aws.amazon.com/lambda/latest/dg/lambda-typescript.html). Il runtime della lambda è nodejs e il codice deployato è javascript. AWS SAM può aiutare il processo di build e transpilazione del codice typescript con il comando `sam build`, si può specificare il compiler (tsc o esbuild) nel template sam. [Esempio](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-build-typescript.html)
- [Lambda Java](https://docs.aws.amazon.com/lambda/latest/dg/java-package.html) I runtime java per aws lambda sono Java 8 e Java 11. Per l'handler è necessaria una dipendenza di aws. Per compilare la lambda si può usare maven o gradle (con maven è necessario il plugin shade): ad esempio con maven usando il comando `mvn package` e deployando il file .jar

## Progetto

### API

- [GitLab](https://docs.gitlab.com/ee/api/api_resources.html)
- [Sonarqube](https://next.sonarqube.com/sonarqube/web_api/api/projects)
- [Jira](todo)

### Flussi

- [Diagramma flusso](https://drive.google.com/file/d/1UvYmuAo4BJ9fKJnPH4CkJVXgNJ3dOuW1/view?usp=sharing)

#### Proposta KPI SonarQube

GitLab ---> estrai progetti (attivi?)
- per ogni progetto
- A: chiami **Find project by Id**
---> estrai `projectKey`
---> chiami **Issue**
---> estrai `total`
- B: *Comune a tutti*: numero di persone che lavorano sul progetto
- ---> ritorni A/B (*es XXX bug/uomo nel progetto ABC*)

### Struttura

*bozza*

- API Gateway
- Lambda per ogni kpi
- Cloudfront per la cache delle foto generate?
- metriche? come?
- deploy come?

## Richieste

- [X] Account AWS per i test e deploy finale (https://vidiemme.awsapps.com)

## Citazioni

- Nella Lambda il tempo è denaro

## Link utili

- https://aws.amazon.com/it/getting-started/deep-dive-serverless/
- https://medium.com/swlh/everything-you-need-to-know-about-serverless-architecture-5cdc97e48c09
- https://shinesolutions.com/2020/03/12/dynamically-resize-your-images-using-cloudfront-origingroup/
- APM https://www.elastic.co/guide/en/apm/agent/nodejs/current/lambda.html
- Grafici https://www.chartjs.org/
- https://serverlessland.com/

## KPI

- Numero di progetti attivi per team --> Semplice numero

LINK DOC: https://docs.gitlab.com/ee/api/groups.html

Se per team si intende i gruppi o i sottogruppi, si può ottenere l'informazione con la seguente chiamata REST:

https://git.vidiemme.it/api/v4/groups/[GROUP_ID]/projects?access_token=[TOKEN_ID]&per_page=[NUM_PAGINATED]&include_subgroups=true

Per recuperare l'access token, generarlo dalla seguente pagina con i vari GRANT che servono:
https://git.vidiemme.it/-/profile/personal_access_tokens

---

# KPI
1. Numero di merge request per progetto (pesato per il numero componenti all'interno della practice) --> Grafico mensile/settimanale
2. Numero di pipeline eseguite con successo VS numero di pipeline fallite (per team di practice) --> Grafico mensile/settimanale
3. Numero di progetti attivi per practice --> Semplice numero
4. Numero di epiche, user story, task e bug per progetto (pesato per niente) --> Grafico mensile/settimanale
5. Numero di bug rilevati da sonarqube per progetto (pesato per nulla) --> Grafico mensile/settimanale

___

# Lista lambda

## Lambda importer

0. api genitore 1
Questa è la prima lambda import da chiamare per popolare la lista dei progetti attivi: si considera un progetto attivo un progetto con last_activity > xxx gg (o altre logiche per scremare i progetti attivi tramite last_commit_date)
a = lista: **projectId**, practice

## Lambda KPI

1. /kpi/xxxx/:projectId/:period
kpi = a/b
a = numero di **merge request** in GitLAb/:projectId
b = distinct author (**commit** nel :peririod in GitLAb/:projectId)

2. /kpi/xxxx/:projectId/:period
kpi = a/b
a = numero di **pipeline** con successo in GitLAb/:projectId
b = numero di **pipeline** fallite in GitLAb/:projectId

3. /kpi/xxxx/:practice
kpi = a
a = count form 0.a where practice = :practice

4. /kpi/xxx/:projectId/:period
kpi = a/b
a = numero di **bug** in Jira/:progjectId --> **//TODO:** capire il mapping Jira-GitLab
b = distinct author (**commit** nel :peririod in GitLAb/:projectId) = 1.b

5. /kpi/xxx/:projectId/:period
kpi = a/b
a = numero di **bug** in SonarQube/:progjectId
b = distinct author (**commit** nel :peririod in GitLAb/:projectId) = 1.b

## DB

### DEV:
Nome: vidiemme_gildaserverless_dev
Versione: PostgreSQL 12.9
Ambiente: dev
User: vidiemme_gildaserverless_dev
Host: srvitr.vidiemme.lan
Porta: 5432
Password: zbgnIIFA

### Aurora DB

HOST: vidiemme-serverless-aurora-serverless.cluster-c7dwqqrwxjg4.eu-west-1.rds.amazonaws.com
User: postgres
Password: t%F2qH&9WC2g
Nome: serverless_kpi

---

## Crezione Lambda su AWS Vidiemme
Region => eu-west-1
### Lista tag:
- Customer => vidiemme
- Project => serverless
- Env => dev
- CodiceCommessa => VDM017_VDM

# Capitoli PPT
1. Introduzione al paradigma serverless e alle sue applicazioni
2. Introduzione a AWS Lambda e alle sue funzionalità
3. Creazione di una funzione Lambda su AWS
4. Configurazione di un trigger per l'esecuzione della funzione
5. Esecuzione e debug della funzione
6. Integrazione con altri servizi AWS per l'elaborazione dei dati
7. Demo: estrazione KPI da più sorgenti esterne utilizzando AWS Lambda
8. Considerazioni finali e prospettive future per l'utilizzo di serverless in azienda.

cron

lambda root -> importa i progetti
-- n lambda -> importano le stat

up
---- RDS
------- view
down

n lambda -> leggono i dati aggregati (dalle view?) -> per ora response json poi chartjs.org
api gateway -> indirizza l'endpoint alla lambda (es. /api/xx -> lambda xx)

user