PHP Serverless in ambiente AWS

Gianfranco Castro
Digital CTO @ Tecniche Nuove
Da sempre appassionato di Web Development,
SEO e Digital Marketing, docente di numerosi
corsi in ambito sviluppo Web e Mobile.
Background da sviluppatore, dai lontani tempi
del Commodore 64, poi Amiga 500 (Amos e
Pascal) mentre studia ragioneria capisce che la
sua passione è l’informatica e il web, passioni
che lo portano ad affrontare il percorso
universitario in ingegneria informatica; qui si
rafforza la passione per lo sviluppo software, i
database e IT Project Management.

In questo talk vedremo come far girare un applicativo basato su PHP in ambiente AWS mediante il framework
Serverless, con l’obiettivo di:
- riclicare le conoscenze già in essere nel team di sviluppo
- riclicare il codice pre-esistente e collaudato
- migliorare il processo di deploy
Per fare questo utilizzeremo Bref come tool di creazione del progetto serverless, sfruttando il meccanismo del Layer
esecutivi di AWS.
Ma procediamo per gradi:
- recap su come funziona Serverless
- esploreremo struttura di progetto basato su nodejs
- cosa viene creato sul nostro account AWS
- iniziare ad utilizzare Bref su un progetto PHP
- considerazioni per far girare un applicativo basato Laravel
PHP Serverless in ambiente AWS
Introduzione

Una delle innovazioni legate al cloud computing è sicuramente rappresentato dall'ecosistema del Serverless: è un
ecosistema di servizi e metodi di progettazione cui, negli ultimi anni, abbiamo assistito a una diffusione di questo
paradigma di sviluppo, alimentato da motivazioni sia tecniche che commerciali.
Il serverless è un modello di cloud computing che prevede l'accesso a potenza computazionale, storage e processi
automatizzati, la cui gestione è organizzata in modo da liberare il suo fruitore da ogni responsabilità del sistema e
dal livello minimo di servizio.
L’accesso a tale modello, deve quindi permettere l'uso di risorse senza limiti evidenti e tramite una struttura di costo
strettamente chiara sulle risorse godute.
Quindi non c'è un coinvolgimento diretto nella gestione delle risorse, nè tantomeno abbiamo alcuna responsabilità
in termini di manutenzione di server e degli applicativi che rendono disponibili tali risorse.
Inoltre deve essere garantita una certa qualità del servizio indipendentemente dalla quantità di risorse utilizzate.
Si presuppone anche, che il modello di vendita di prodotti basati su Serveless, deve permettere un calcolo preciso
dei costi in base alla reale quantità di risorse fruite, basato su una tariffazione pay-per-use.
Introduzione a Serverless

Possiamo sfruttare i servizi messi a disposizione da Amazon Web Service per implementare il nostro applicativo su
Serverless, e in particolare useremo:
Serverless: cosa ci offre AWS
AWS Lambda AWS API Gateway AWS S3
AWS Lambda è una piattaforma di calcolo senza server (serverless), event driven, fornita da Amazon come parte di
Amazon Web Services.
Ci consente di incapsulare il nostro codice in task di esecuzione isolati, pagando per l'effettiva quantità di risorse
impiegate (RAM e durata del processo), infatti è un servizio di calcolo che esegue codice in risposta ad eventi e
automaticamente gestisce le risorse richieste dal codice di programmazione.
Introdotta nel 2014, lo scopo di Lambda, comparato ad AWS EC2, è di semplificare la costruzione di applicazioni
on-demand che rispondono ad eventi (ad esempio caricamento di un file su S3, invocazione di un end-point di API
Gateway, etc).

AWS ha come obiettivo l'inizio di una istanza Lambda nel raggio di millisecondi di un evento. I linguaggi supportati
ufficialmente sono Node.js, Python e Java, mentre altri linguaggi sono supportati via Layer, che consentono di
eseguire una specifica tecnologia:
https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html
Sul funzionamento dei Layer lo affronteremo tra qualche slide, dove andremo ad utilizzare PHP mediante uno
specifico Layer messo a disposizione da Bref.

API Gateway è un prodotto che fa esattamente quello che il suo nome dice: ci permette di creare uno strato
applicativo composto da diversi endpoint singolarmente configurabili.
Possiamo decidere di abilitare specifici metodi HTTP e indirizzare le chiamate sugli endpoint verso una determinata
sorgente, come un altro servizio HTTP, S3 o una funzione Lambda.
Inoltre possiamo impostare la trasformazione in entrata e in uscita dei dati e la validazione degli errori.

API Gateway è quindi uno strumento di comunicazione applicativa con il quale possiamo gestire anche grandi
progetti di API.
Il servizio ci offre poi, per ogni gateway definito, un indirizzo HTTPS che possiamo facilmente associare a una
direttiva del nostro DNS per avere così un punto di accesso per le nostre API in cloud.
Il risultato finale è un connettore di servizi eterogenei che viene gestito dal provider e per il quale non abbiamo
necessità di impostare funzioni di scalabilità o affidabilità.
Queste sono caratteristiche estremamente importanti che rendono API Gateway un prodotto molto versatile.

Amazon S3 è di fatto un prodotto serverless, infatti fornisce un accesso scalabile a un servizio (la memorizzazione di
dati) senza sostanziali limiti di fruizione.
In parole povere "rompe" un vincolo hardware pesantissimo rappresentato dallo storage dei server: i limiti di spazio,
la velocità di accesso ai dati e la durabilità sono tutti aspetti che possono essere facilmente compromessi da una
rottura fisica del supporto.
S3 si presenta quindi come servizio in grado di liberarci da questi vincoli; la sua importanza all'interno
dell'ecosistema Amazon è di primo piano, non a caso è stato uno dei primissimi servizi introdotti dalla piattaforma
nel 2006.

Basato su un concetto di storage chiave-valore ed accessibile attraverso il protocollo HTTP, l'utilizzo di S3 è
estremamente banale: si inviano (o si richiedono) file per poi organizzarli attraverso le consuete SDK, la console
WEB e le API del servizio.

Adesso andiamo a creare una prima applicazione Servers su AWS, gli step sono:
- Avere a disposizione un account AWS
- Configurare le chiavi di accesso
Serverless: creazione prima applicazione

Successivamente:
- Installazione Serverless CLI ( https://serverless.com/framework/docs/getting-started#installing-via-npm )
$ npm install –g serverless
- Via CLI possiamo creare un nostro primo applicativo
$ sls create --help
Plugin: Create
create ........................ Create new Serverless service
--template / -t .................... Template for the service. Available templates: "aws-clojure-gradle",
"aws-clojurescript-gradle", "aws-nodejs", "aws-nodejs-typescript", "aws-alexa-typescript", "aws-nodejs-ecma-script",
"aws-python", "aws-python3", "aws-groovy-gradle", "aws-java-maven", "aws-java-gradle", "aws-kotlin-jvm-maven",
"aws-kotlin-jvm-gradle", "aws-kotlin-nodejs-gradle", "aws-scala-sbt", "aws-csharp", "aws-fsharp", "aws-go",
"aws-go-dep", "aws-go-mod", "aws-ruby", "aws-provided", "tencent-go", "tencent-nodejs", "tencent-python", "tencent-php",
"azure-nodejs", "azure-python", "cloudflare-workers", "cloudflare-workers-enterprise", "cloudflare-workers-rust",
"fn-nodejs", "fn-go", "google-nodejs", "google-python", "google-go", "kubeless-python", "kubeless-nodejs",
"knative-docker", "openwhisk-java-maven", "openwhisk-nodejs", "openwhisk-php", "openwhisk-python", "openwhisk-ruby",
"openwhisk-swift", "spotinst-nodejs", "spotinst-python", "spotinst-ruby", "spotinst-java8", "twilio-nodejs",
"aliyun-nodejs", "plugin", "hello-world"
--template-url / -u ................ Template URL for the service. Supports: GitHub, BitBucket
--template-path .................... Template local path for the service.
--path / -p ........................ The path where the service should be created (e.g. --path my-service)
--name / -n ........................ Name for the service. Overwrites the default name of the created service.

Come primo passo dobbiamo comunicare a Serveless, di quale account su AWS si tratta, quindi possiamo eseguire;
$ sls config credentials --help
$ sls config credentials -n pugmilano --provider aws --key XXXXXXX –secret YYYYYY
Dove:
- sls è un alias di serverless
- Il parametro -n pugmilano è appunto il nome del profilo associato a questi accessi su AWS
Quello che ottieniamo è il file ~/.aws/credentials
[default]
aws_access_key_id = KKKKKKKK
aws_secret_access_key = ZZZZZZZZZZZZ
[pugmilano]
aws_access_key_id = XXXXXX
aws_secret_access_key = YYYYYYY

Quindi lanciando il comando:
$ serverless create --template aws-nodejs --name sls-pugmilano-demo --path
./sls-pugmilano-demo
andiamo a creare il nostro progetto, cosi strutturato:
.
├── handler.js
└── serverless.yml
Il file serverless.yml contiene le informazioni che riguardano il nostro applicativo, handler.js è la lambda
che verrà invocata dall’applicativo

serverless.yml:
# --- Nome del service
service: sls-demo
# --- Definizione del provider
provider:
name: aws
runtime: nodejs12.x
profile: pugmilano # --- Profilo utente
# --- Definizione dell'elenco delle funzioni
functions:
# --- Nome della funzione
hello:
# --- Handler della funzione
handler: handler.hello
# --- Evento su come richiamare la funzione
events:
- http:
path: test-lambda
method: get
'use strict';
module.exports.hello = async (event, context) => {
return {
statusCode: 200,
body: JSON.stringify({
message: 'PUG Milano - Esempio applicazione',
input: event,
}),
};
};
handler.js:

Possiamo fare subito un primo deploy con il comando:
$ serverless deploy --aws-profile pugmilano
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (3.5 KB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
Serverless: Stack update finished...
Service Information
service: sls-demo
stage: dev
region: us-east-1
stack: sls-demo-dev
api keys:
None
endpoints:
GET - https://d448vysdu3.execute-api.us-east-1.amazonaws.com/dev/test-lambda
functions:
hello: sls-demo-dev-hello
Endpoint del nostro applicativo

Andiamo a controllare cosa è avvenuto sul AWS sul pannello di amministrazione Web:

Andiamo a controllare cosa è avvenuto sul AWS sul pannello di amministrazione Web: la definizione della nostra
API sul pannello di API Gateway
Riferimento alla
Lambda

Dopo aver visto la facilità d’uso di creazione di una API su Serverless, adesso passiamo all’esecuzione di PHP
all’interno di una Lambda; purtroppo PHP è uno dei linguaggi attualmente NON supportati:
Serverless: esecuzione di PHP da una Lambda
Per far funzionare PHP in una Lambda abbiamo due strade:
- sfruttare una call-out verso un interprete PHP, come qui
documentato
https://aws.amazon.com/blogs/compute/running-exec
utables-in-aws-lambda/
(notate la data della documentazione: 2015)
- utilizzare un layer applicativo come qui documentato

Nel caso di call-out possiamo includere PHP binary come parte della Lambda; questo binario deve essere compilato
su una AMI di Amazon, che verrà utilizzata dalla Lambda a runtime.
Abbiamo diversi modi per fare questo, tra cui quello messo a disposizione da ArtisanHost disponibile al repo
https://github.com/ArtisanHost/php-cgi-lambda-build-script che ci consente di fare il build su Docker (vedi il
dockerfile) che possiamo personalizzare ulteriormente.
Per lanciare la build, dobbiamo scegliere che versione di PHP intendiamo utilizzare, ad esempio:
$ sh ./buildphp.sh 7.2.1
Inoltre abbiamo a disposizione dei build già pronti di PHP disponibili sul repository
https://github.com/ArtisanHost/php-cgi-lambda-binaries
C’è da dire che l’eseguibile PHP ottenuto non funzionerà se non dentro la Lambda, in quanto costruito all’interno di
una AMI di Amazon Linux (amazonlinux:2017.03) come visibile sul dockerfile.

Una volta ottenuto l’interprete PHP, andiamo a considerare il seguente handler.js, dove testiamo l’esecuzione
dell’interprete PHP all’interno della Lambda:
'use strict';
var child_process = require('child_process');
exports.handler = function(event, context) {
// ---- https://nodejs.org/dist/latest-v10.x/docs/api/child_process.html
// --- richiamo interprete PHP
var proc = child_process .spawn('./php-cgi', ['-v']);
var output = '';
proc.stdout.on( 'data', function(data) {
output += data.toString('utf-8');
});
proc.on('close', function() {
context.succeed( output);
});
};

A partire da questo ragionamento possiamo quindi eseguire il nostro codice PHP direttamente su una Lambda; in
riferimento a Laravel dobbiamo fare diversi accorgimenti e aggiustamenti di configurazione, ma da punto di vista
concettuale abbiamo sempre:
Request API
Gateway
Lambda PHP
Response
serverless.yml handler.js Codice PHP
In base al quale applicativo dobbiamo far eseguire, possiamo avere la necessità di compilare PHP e aggiungere
moduli e questo ci va a complicare le cose.

Nel caso di Layer applicativo possiamo utilizzare Bref: installabile via Composer in un progetto PHP aiuta ad
effettuare il deploy e la configurazione dell’infrastruttura su AWS; il package contiene:
- la documentazione
- PHP runtimes per AWS Lambda via Layer
- Deployment tooling
- PHP frameworks integration
I casi d’uso per l’utilizzo di Serverless e Bref possono essere raggruppati in:
- Sviluppo di APIs
- Workers
- Processi batch
- Erogazione di siti
Serverless: esecuzione di PHP da una Lambda con Bref

Bref è una soluzione per eseguire codice PHP all’interno di una Lambda, saltando tutte le problematiche di:
- Dover compilare manualmente PHP
- Scrivere e mantenere un handler.js abbastanza complesso per far eseguire PHP
- Conoscere nel dettaglio gli oggetti event e response per gestire le richieste HTTP
- Mettere in piedi un sistema di deploy efficiente per gestire anche le dipendenze del nostro applicativo
Per cominciare dobbiamo avere a disposizione PHP cli e composer; successivamente in una cartella di progetto
possiamo eseguire:
$ composer require bref/bref
Che andrà a creare i seguenti:
.
├── composer.json
├── composer.lock
└── vendor

Nella cartella vendor, tra le varie dipendenze abbiamo la cartella "bin" dove c’è lo strumento di scaffolding di Bref;
Per creare il nostro progetto Bref dobbiamo lanciare:
$ vendor/bin/bref init
What kind of lambda do you want to create? (you will be able to add more
functions later by editing `serverless.yml`) [PHP function]:
[0] PHP function
[1] HTTP application
[2] Console application
> 0
Creating serverless.yml
Creating index.php
[OK] Project initialized and ready to test or deploy.

Nel file serverless.yml vado a specificare quale profilo AWS voglio utilizzare (vedi file ~/.aws/credentials) e il nome
del nostro applicativo/servizio, quindi il nostro file avrà:
service: pugmilano-bref-demo # --- Nome del'applicativo
provider:
name: aws
region: us-east-1
runtime: provided
provider: pugmilano # --- Nome profilo AWS
plugins:
- ./vendor/bref/bref
functions:
function:
handler: index.php
description: 'Esempio function' # --- Descrizione della function
layers:
- ${bref:layer.php-73} # --- Nome del layer PHP, identifica una ARN

Adesso possiamo editare il file index.php che conterrà il codice che vogliamo far eseguire alla Lambda, di default
abbiamo:
<?php declare(strict_types= 1);
require __DIR__.'/vendor/autoload.php';
lambda(function ($event) {
return 'Hello ' . ($event['name'] ?? 'world');
});
Possiamo già eseguire il deploy di questo applicativo eseguendo, ma prima dobbiamo ottimizzare la vendor, quindi
$ composer install --prefer-dist --optimize-autoloader --no-dev
successivamente

Il risultato è:
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
........
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service pugmilano-bref-demo.zip file to S3 (3.15 MB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
...............
Serverless: Stack update finished...
Service Information
service: pugmilano-bref-demo
stage: dev
region: us-east-1
stack: pugmilano-bref-demo-dev
resources: 6
api keys:
None
endpoints:
None
functions:
function: pugmilano-bref-demo-dev-function
layers:
None
Serverless: Run the "serverless" command to setup monitoring, troubleshooting and testing.
Viene creato un file .zip che contiene
tutto il nostro applicativo e caricato su di
un bucket di S3.
Successivamente viene scompattato e
viene creata l’infrastruttura

Di conseguenza ci ritroviamo il tutto configurato sul pannello Lambda di AWS:

Adesso andiamo a costruire un’applicazione HTTP e dobbiamo cambiare impostazioni su serverless.yml
service: app
provider:
name: aws
region: us-east-1
runtime: provided
provider: pugmilano
plugins:
functions:
website:
handler: index-http.php
layers:
# --- Qui vado a impostare PHP 7.3 fpm
- ${bref:layer.php-73-fpm}
# --- Qui vado a definire gli endopoint che verranno mappati su API Gateway, in questo caso ‘ANY’
events:
- http: 'ANY /'
- http: 'ANY /{proxy+}'
Imposto un altro handler, dove dentro creo un
applicativo basato su Slim framework, per andare a
gestire meglio le request.

Qui il contenuto di index-http.php
<?php
use PsrHttpMessageResponseInterfaceas Response;
use PsrHttpMessageServerRequestInterfaceas Request;
use SlimFactoryAppFactory;
require __DIR__ . '/vendor/autoload.php';
$app = AppFactory::create();
$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
$name = $args['name'];
$response->getBody()->write("Hello, $name");
return $response;
});
$app->run();

Rieffettuando il deploy:
…
Service Information
service: pugmilano-bref-demo
stage: dev
region: us-east-1
stack: pugmilano-bref-demo-dev
resources: 15
api keys:
None
endpoints:
ANY - https://07ksgvf7z4.execute-api.us-east-1.amazonaws.com/dev
ANY - https://07ksgvf7z4.execute-api.us-east-1.amazonaws.com/dev/{proxy+}
functions:
function: pugmilano-bref-demo-dev-function
website: pugmilano-bref-demo-dev-website
layers:
None
Serverless: Run the "serverless" command to setup monitoring, troubleshooting and testing.

Andando a controllare su AWS abbiamo:
Qui la documentazione sulle HTTP applicativo
https://bref.sh/docs/runtimes/http.html
mentre per la gestione del routing
https://bref.sh/docs/runtimes/http.html#routing

L’elenco dei layer esecutivi di PHP:
${bref:layer.php-74}
${bref:layer.php-74-fpm}
${bref:layer.console}
https://bref.sh/docs/runtimes/#usage
Riepilogando:
- i layer con “fpm” per le applicazioni HTTP
- i layer senza “fpm” per le function Lambda (quindi NO URL su API Gateway)
- il layer console per le applicazioni CLI (immagina artisan di Laravel)

Nel caso di una applicazione Laravel, bisogna apportare delle modifiche, in particolare astrarre il filesystem, mappandolo su S3; infine
non cambia di molto la struttura del progetto Laravel, ma soltanto del file serverless.yml:
service: bref-demo-laravel
provider:
name: aws
region: us-east-1
environment:
# Laravel environment variables
APP_STORAGE: '/tmp'
plugins:
functions:
website:
handler: public/index.php
timeout: 28 # in seconds (API Gateway has a timeout of 29 seconds)
layers:
- ${bref:layer.php-73-fpm}
events:
- http: 'ANY /'
- http: 'ANY /{proxy+}'
artisan:
handler: artisan
timeout: 120 # in seconds
layers:
- ${bref:layer.php-73} # PHP
- ${bref:layer.console} # The "console" layer
Serverless: esecuzione di Laravel da una Lambda con Bref
Sul nodo “environment” vado ad impostare le
variabili di environment che verranno recuperate da
$_ENV
Dettaglio sullo storage su
https://bref.sh/docs/environment/storage.html
Dettaglio sul deploy di Laravel
https://bref.sh/docs/frameworks/laravel.html
Layer esecutivo per i comandi di artisan:
https://bref.sh/docs/runtimes/console.html

Sono disponibili inoltre diversi Cost Calculator per valutare anche questo genere di impatto, ad esempio
considerando 80.000.000 di chiamate/mese
https://s3.amazonaws.com/lambda-tools/pricing-calculator.html
Performance e costi

Corsi di Accademia TN
Sono in partenza i seguenti corsi:
- Programmare con Laravel 6
il corso ha come obiettivo l’esplorazione del framework per la realizzazione applicativi CRUD e API; il programma ha come
argomenti: Esplorazione del Framework, Gestione del routing, Gestione delle view con Blade, Comunicazione con i Database e
Eloquent ORM, Binding dei dati tra Database, Logiche di Deploy
- Programmare con Javascript
acquisire le conoscenze e le competenze per lo sviluppo web tramite la programmazione con Javascript (ES6/7/8); tra gli
argomenti: Gestire la manipolazione del DOM, sia mediante Vanilla Javascript sia mediante jQuery, gestire le chiamate HTTP, i
motori di templating, Creare e gestire Web Component secondo gli standard HTML5, utilizzare nodejs per la creazione di web
server, gestire il deploy di un applicativo.
Si pone come base per affrontare lo sviluppo con framework quali Vue, React, Angular, Svelte
- Wordpress e WooCommerce
Creare il proprio sito di ecommerce con WooCommerce, gestire il proprio magazzino di prodotti sia fisici che virtuali, le varianti,
gestire gli ordini e i pagamenti.
Utilizzare e configurare i gateway di pagamento, modificare il tema StoreFront, esplorare i plugin fondamentali per la gestione e
l’integrazione dei prodotti.

We are HIRING !!!
Stiamo espandendo il nostro team IT e stiamo cercando urgentemente le seguenti figure:
Full Stack Developer
Siamo alla ricerca di un Full Stack Developer che possa affiancare il Digital
CTO nella progettazione e sviluppo di applicativi, sviluppare API per la
gestione dei contenuti, manutenzione e sviluppo su WordPress e
WooCommerce, creazione di SPA e PWA, creazione di applicativi di Data
Integration.
Skill richiesti:
Apache HTTP Server e nginx, PHP7, Javascript (ES7+, TypeScript) e/o
Python 3.x, Wordpress, API Development, Laravel, Docker, AWS, Bash
scripting, MySQL e PostgreSQL, nodejs, Vue
Gradita esperienza nella gestione di caching di contenuti (Redis, Varnish,
Memcached)
Frontend Developer
Siamo alla ricerca di un Frontend Developer, con buone doti di UX/UI design,
che possa affiancare il reparto marketing nella creazione di soluzioni e layout
per la creazione di landing page, HTML specifico per DEM e Newsletter e che
sia in grado di progettare interfacce grafiche.
Inoltre affiancherà gli sviluppatori per la creazione di layout e soluzioni grafiche
per la realizzazione di web application, anche ottimizzate per mobile; quindi la
conoscenza di HTML5, CSS3 sono ritenute fondamentali.
Skill richiesti:
Adobe Photoshop, XD, Illustrator, Sketch App, Zeplin o altro software
Buone doti creative e Conoscenza di UX/UI design, Creazione di pagine
ottimizzate per DEM e Newsletter, HTML5 e CSS3 (Media Queries, Flexbox,
Transitions e Animations), Creazione temi per Word Press
Per candidarsi: Gianfranco Castro (gianfranco.castro@tecnichenuove.com )

Prossimamente in libreria
In riferimento a Serverless e AWS, a fine marzo verrà pubblicato il libro
Prenotazioni: https://forms.gle/9PmBNhod993jh9i57
Architetture serverless con AWS vi introdurrà al modello serverless e vi aiuterà a lavorare con
Lambda, il servizio di elaborazione serverless.
Fra le varie funzionalità il manuale esamina Amazon Athena, un servizio di query interattivo
serverless che semplifica l’analisi dei dati nel Simple Storage Service (S3 Amazon) utilizzando
SQL standard.
Scoprirete anche AWS Glue, un servizio per la classificazione dei dati semplice ed economico.
Imparerete in che modo Amazon Kinesis consenta di liberare il potenziale di analisi dei dati in
tempo reale con varie funzionalità.
A chi si rivolge
Per analisti, IT manager e sviluppatori di applicazioni serverless, il libro è concepito per chi ha
già una precedente esperienza di programmazione pur senza alcuna conoscenza di AWS.

Grazie per l’attenzione
Per contattarmi:
Gianfranco Castro
https://www.tecnichenuove.com
gianfranco.castro@tecnichenuove.com
https://www.linkedin.com/in/gianfrancocastro/

PHP Serverless in ambiente AWS

More Related Content

Similar to PHP Serverless in ambiente AWS (20)

PHP Serverless in ambiente AWS