AWS lambda con quarkus

[Mario Alexandro Santini]

Ciao a tutti,


per chi è interessato all'argomento in oggetto consiglio questo repo:


https://github.com/AdamBien/aws-quarkus-lambda-cdk-plain


Che può essere una base di partenza.


Io al lavoro presto lavorerò su GCE, ma sarei curioso di sapere se
qualcuno utilizza AWS lambda e se per caso c'è qualcuno che le utilizza
con Java.

Mi piacerebbe sentire un po' di info in merito, magari con una piccola
presentazione... ;)


Mario

[Chris Mair]

> Io al lavoro presto lavorerò su GCE, ma sarei curioso di sapere se
> qualcuno utilizza AWS lambda e se per caso c'è qualcuno che le
> utilizza con Java.
>
> Mi piacerebbe sentire un po' di info in merito, magari con una
> piccola presentazione... ;)

Ciao,

io avevo fatto una breve presentazione in un evento JUG/NOI 3 anni fa:

https://www.1006.org/misc/201806-aws-lambda-java/aws-lambda-java-intro.html

Poi alla fine ho usato meno lambda di quello che m'aspettavo... Forse
perche` sono un po` old-school e la soglia di dire "chi se ne frega, metto
su un'altra VM" e` bassa...

Un use case interessante che sto usando e` che funzioni lambda possono
essere triggerate da regole simil-cron. Quindi vanno molte bene per eseguire
script periodici senza una VM sotto.

Bye,
Chris

[Mario Alexandro Santini]

On 11/21/21 10:50 AM, Chris Mair wrote:
> Ciao,

Ciao Chris,

> io avevo fatto una breve presentazione in un evento JUG/NOI 3 anni fa:
>
> https://www.1006.org/misc/201806-aws-lambda-java/aws-lambda-java-intro.html



> Poi alla fine ho usato meno lambda di quello che m'aspettavo... Forse
> perche` sono un po` old-school e la soglia di dire "chi se ne frega, metto
> su un'altra VM" e` bassa...

C'è da dire che lo scopo di AWS lambda rispetto al resto dell'offerta
Amazon è un po' complicato da inquadrare.

Come l'ho capita io si tratta di un servizio che dovrebbe consentire
all'utilizzatore di risparmiare sul costo delle macchine virtuali,
quando si hanno task che sono discontinui, per i quali, quindi, non è
necessario avere un server sempre attivo.

Ma questi task, quando servono devono avviarsi rapidamente.

Cosa che rende le macchine virtuali un po' scomode spegnendo e riaccendendo.

Per quanto il processo sia sempre veloce non lo è abbastanza in fase di
accensione.

Anche nella mi esperienza questo genere di situazione non è molto comune.

Invece, il server che lavora costantemente per la fascia oraria
lavorativa 8-18 è più comune.

Ma per questo un vm che viene accesa la mattina e spenta la sera in
automatico è l'approccio più semplice.

> Un use case interessante che sto usando e` che funzioni lambda possono
> essere triggerate da regole simil-cron. Quindi vanno molte bene per eseguire
> script periodici senza una VM sotto.

E' questo è un caso interessante.

Infatti, ci sono sempre task di lavoro da fare periodicamente per
gestire un sistema ed il cron è lo strumento più semplice.

Mi piacerebbe sapere che vantaggi hai trovato rispetto al cron classico,
o se ci sono delle limitazioni.


> Bye,
> Chris
>

Mario

[Chris Mair]

> > io avevo fatto una breve presentazione in un evento JUG/NOI 3 anni fa:
> >
> > https://www.1006.org/misc/201806-aws-lambda-java/aws-lambda-java-intro.html
>
> > Poi alla fine ho usato meno lambda di quello che m'aspettavo... Forse
> > perche` sono un po` old-school e la soglia di dire "chi se ne frega, metto
> > su un'altra VM" e` bassa...
>
> C'è da dire che lo scopo di AWS lambda rispetto al resto dell'offerta
> Amazon è un po' complicato da inquadrare.
>
> Come l'ho capita io si tratta di un servizio che dovrebbe consentire
> all'utilizzatore di risparmiare sul costo delle macchine virtuali,
> quando si hanno task che sono discontinui, per i quali, quindi, non è
> necessario avere un server sempre attivo.
>
> Ma questi task, quando servono devono avviarsi rapidamente.
>
> Cosa che rende le macchine virtuali un po' scomode spegnendo e riaccendendo.
>
> Per quanto il processo sia sempre veloce non lo è abbastanza in fase di
> accensione.
>
> Anche nella mi esperienza questo genere di situazione non è molto comune.
>
> Invece, il server che lavora costantemente per la fascia oraria
> lavorativa 8-18 è più comune.
>
> Ma per questo un vm che viene accesa la mattina e spenta la sera in
> automatico è l'approccio più semplice.

Yes, ma per esempio accendere la VM alle 8 e spegnerla` alle 18 e` una
cos che puoi fare con lambda. Altrimenti ti serve un'altra VM con un cron
che fa solo quello :)

Poi un altro use case e` magari un sito statico hostato serverless, tipo S3
che pero` ha qualche elemento dinamico (pensa form di contatto). Quello
quindi puo` essere gestito bene con lambda.

> > Un use case interessante che sto usando e` che funzioni lambda possono
> > essere triggerate da regole simil-cron. Quindi vanno molte bene per eseguire
> > script periodici senza una VM sotto.
>
> E' questo è un caso interessante.
>
> Infatti, ci sono sempre task di lavoro da fare periodicamente per
> gestire un sistema ed il cron è lo strumento più semplice.
>
> Mi piacerebbe sapere che vantaggi hai trovato rispetto al cron classico,
> o se ci sono delle limitazioni.

L'unica limitazione che vedo e` che e` un pelino piu` complicato perche`
devi racchiuderlo tutto in una function call. Non hai il (relativo) lusso di
un /bin/bash con cui lanci svariatissime cose.

P.e. se serve un accesso a Postgres, non e` che ci metti al volo un psql -c,
ma piuttosto devi programmarlo, linkare col driver e` tutto. E` un attimo
meno spontaneo che fare un .sh al volo. Chiaramente forse e` anche
piu` strutturato...

Dalla docu, AWS Lambda supporta: Java, Go, PowerShell, Node.js, C#, Python,
e Ruby. Delle cose semplici tipo start/stop macchine la cosa piu` semplice e`
farle con Python, forse. Certi action sono anche built-in (penso ci sia start macchina,
ma non stop macchina se ricordo bene, p.e.).

Noto ora che c'e` Go, quindi quello potrebbe essere interessante :)

Bye,
Chris.

[Mario Alexandro Santini]

On Sun, Nov 21, 2021 at 3:11 PM Chris Mair <ch...@1006.org> wrote:

Yes, ma per esempio accendere la VM alle 8 e spegnerla` alle 18 e` una
cos che puoi fare con lambda. Altrimenti ti serve un'altra VM con un cron
che fa solo quello :)

Se ne hai solo 1 d'accordo, ma in genere sono di più...

In genere hai una vm per il database, una per il back-end e una per il front-end.

E poi hai una o due per l'ambiente di test e altre per il collaudo.

Se ne mantieni una sempre accesa per controllare gli ambienti magari va bene.

Ma concordo che con una lambda andrebbe bene, la decisione dipende solo dal mettersi a fare i conti sul costo.

Poi, c'è anche il fatto che magari la vm che controlla tutto ce l'hai su un server in casa che ti tieni sempre acceso...

 

Poi un altro use case e` magari un sito statico hostato serverless, tipo S3
che pero` ha qualche elemento dinamico (pensa form di contatto). Quello
quindi puo` essere gestito bene con lambda.

Anche questo è interessante.

Il sito sarebbe tirato su quando un utente prova a collegarsi e poi resta su per un po', così altre connessioni saranno servite senza pagare di nuovo il tempo di startup, giusto?

E poi quando passa questo tempo di inattività si spegne.

Anche qui, la convenienza va calcolata carta e penna... :)

 

L'unica limitazione che vedo e` che e` un pelino piu` complicato perche`
devi racchiuderlo tutto in una function call. Non hai il (relativo) lusso di
un /bin/bash con cui lanci svariatissime cose.

P.e. se serve un accesso a Postgres, non e` che ci metti al volo un psql -c,
ma piuttosto devi programmarlo, linkare col driver e` tutto. E` un attimo
meno spontaneo che fare un .sh al volo. Chiaramente forse e` anche
piu` strutturato...

Certo, dipende da cosa pensi di fare, leggo che ci sono aziende che sviluppano parecchi servizi come lambda e che dubito sarebbe comodo sviluppare in bash.

Ma in realtà dipende anche da cosa ti è più naturale, perché so che con bash si può fare molto...

 

Dalla docu, AWS Lambda supporta: Java, Go, PowerShell, Node.js, C#, Python,
e Ruby. Delle cose semplici tipo start/stop macchine la cosa piu` semplice e`
farle con Python, forse. Certi action sono anche built-in (penso ci sia start macchina,
ma non stop macchina se ricordo bene, p.e.).

Noto ora che c'e` Go, quindi quello potrebbe essere interessante :)

Già, molto interessante.

Se non mi sbaglio, mi pare che all'inizio si poteva utilizzare solo Node.js, poi con il successo hanno aggiunto altri linguaggi.

Java ha avuto un po' di problemi, che ora sono in gran parte superati.

I container sono stati difficili da digerire per Java, a causa della gestione della memoria, soprattutto.

Ma oggi le nuove versioni di Java non hanno più questo problema.

Ecco, questo potrebbe essere un buon motivo per aggiornare: se si vuole utilizzare un ambiente sui container o con AWS lambda!

 

Bye,
Chris.

 

Mario

[Chris Mair]

>> Poi un altro use case e` magari un sito statico hostato serverless, tipo S3
>> che pero` ha qualche elemento dinamico (pensa form di contatto).
>> Quello quindi puo` essere gestito bene con lambda.
>>
> Anche questo è interessante.
> Il sito sarebbe tirato su quando un utente prova a collegarsi e poi resta
> su per un po', così altre connessioni saranno servite senza pagare
> di nuovo il tempo di startup, giusto?
>
> E poi quando passa questo tempo di inattività si spegne.
> Anche qui, la convenienza va calcolata carta e penna... :)

No, semplicemente fai la parte statica di hosting su S3, per cui paghi spazio e
traffico, ma niente compute. Invece su Lambda c'e` solo un endpoint che prende
in carico i dati di qualche form.

Non ci sono VM coinvolte in questo caso.

Se guardi gli esempi della mia presentazione del 2018, il form lambda2fe.html
l'avevo messo su S3 e reso pubblico, mentre la Lambda3 era la classe
su Lambda che prendeva i dati del form (e li metteva su RDS). Questo
sarebbe il blueprint di un'applicazione "serverless".

Poi se segui AWS, loro ti ci mettono anche robe piu` proprietarie che ti
legano di piu`.

Ma il setup generico S3 + Lambda + qualche DB Open Source managed e`
ben portabile. Potresti portarli a altri (GCP, Azure o anche realta` piu`
piccole tipo Scaleway). Poi ci sono roba come Heroku ecc...

Il concurrente piu` grosso di questo approccio non sono probabilmente
le VM classiche, ma i container... ma questa e` un'altra storia per un altro
thread :)

Bye,
Chris.

[Mario Alexandro Santini]

On Mon, Nov 22, 2021 at 9:59 AM Chris Mair <ch...@1006.org> wrote:

No, semplicemente fai la parte statica di hosting su S3, per cui paghi spazio e
traffico, ma niente compute. Invece su Lambda c'e` solo un endpoint che prende
in carico i dati di qualche form.

Non ci sono VM coinvolte in questo caso.

Ok, quindi S3 fa da web server, non lo sapevo.

Mi pare che questo sia il servizio che offre Netlify, che va tanto di moda oggi con il JAM stack.

 

Ma il setup generico S3 + Lambda + qualche DB Open Source managed e`
ben portabile. Potresti portarli a altri (GCP, Azure o anche realta` piu`
piccole tipo Scaleway). Poi ci sono roba come Heroku ecc...

Vero, ma con un po' di lavoro. :)

Il concurrente piu` grosso di questo approccio non sono probabilmente
le VM classiche, ma i container... ma questa e` un'altra storia per un altro
thread :)

Già altro argomento interessante, io in sviluppo oramai da parecchi tempo ragiono solo con container, quando devo fare uno stub di qualche servizio che mi serve.

 

Bye,
Chris.

Mario