I suoi più di dieci sensori tra cui Lidar, TrueDepth Camera, telecamere, camere ad infrarossi ed permettono di catturare fedelmente la realtà e le interazioni dell’utente su di essa.

Per garantire un’ottima usabilità del prodotto i dati vengono elaborati in modo estremamente rapido grazie ai due processori separati, uno dedicato al sistema operativo mentre l’altro si concentra sulla gestione e sulla elaborazione dei dati dei sensori per poi farli visualizzare all’utente in tempo reale.

Un aspetto fondamentale del dispositivo è la sua continua connessione con la realtà possibile tramite la modifica del focus dei contenuti per passare a focalizzarsi sull’interlocutore. Inoltre, grazie alla tecnologia eye-sight al suo interno, il movimento degli occhi di chi lo utilizza viene tracciato e riprodotto sul display favorendo l’interazione con altre persone.  

Oltre alla modalità di realtà aumentata, ci si può immergere in un mondo completamente virtuale, sia dalla parte visiva che uditiva attraverso l’utilizzo dell’audio spaziale che simula a 360 gradi l’ambiente che ci circonda.

L’integrazione con la nuova interfaccia di VisionOS permette di utilizzare tutte le applicazioni Apple già disponibili per gli altri dispositivi in un’unica realtà utilizzando direttamente le mani, gli occhi e la voce.

Per Apple la sicurezza e la privacy sono fondamentali per questo ha creato una nuova modalità di sblocco denominata Optical ID che, tramite il riconoscimento della retina, permette solo all’utente proprietario di sbloccare il dispositivo. 

Sono proprio la reattività, le fedeltà di riproduzione e la facilità di utilizzo del dispositivo Apple Vision Pro che ha generato svariate opportunità: da contenuti come 2D e 3D a opportunità di business per le imprese.

Quali nuove opportunità si aprono con Apple Vision Pro?

In campo lavorativo è possibile grazie a questa tecnologia andare a rivoluzionare i meeting che saranno più immersivi e coinvolgenti dato che circonderanno l’utente che si potrà trovare in un qualsiasi luogo non essendo più vincolato dall’utilizzo di uno schermo, rendendo ancora più semplice per le persone lavorare da qualunque luogo.

Nel settore manifatturiero dà la possibilità di effettuare training mirati al personale tramite la capacità di far vedere ed analizzare macchinari e strumentazione a grandezza naturale posizionandola in qualsiasi ambiente o verificare ed approvare una linea di produzione prima di renderla definitiva.

In ambito sportivo apre nuovi scenari di fruizione dei contenuti mai visti finora, dove l’utente può essere coinvolto completamente nelle partite pur restando comodamente nel salotto di casa. Ad esempio sarebbe possibile posizionare più streaming che mostrano inquadrature diverse contemporaneamente dato che non si sarebbe più limitati dal singolo schermo della TV, o ricostruire le scene salienti in un modello in scala che l’utente può vedere posizionato sul suo tavolo.

Oppure l’utente potrebbe usare Vision Pro per rendere più interessanti ed interattivi gli allenamenti indoor immergendosi in contenuti che vanno a riprodurre l’ambiente esterno, come un passo di montagna per allenamenti su cyclette o tapisroulant.

Nel ramo education andrebbe a rendere più interattivo ed emozionante l’apprendimento mostrando ad esempio agli alunni ricostruzioni di eventi storici, o permettendo la visita ad un museo senza la necessità di doversi spostare fisicamente.

Oppure gli studenti possono anche vedere rappresentazioni 3D anatomiche o di qualsiasi altro ambito, permettendo di analizzarle nel dettaglio. 

Nell’ambito medico la rappresentazione 3D degli organi e la facile interazione con gli stessi permettono di pianificare in modo dettagliato una particolare e complicata operazione. Un altro utilizzo può essere quello delle operazioni a distanza andando ad integrarsi con le tecnologie già presenti permettendo ai medici di operare come se fossero all’interno della sala operatoria.

Questo strumento porterà anche a nuove shopping experience, dove potrà essere data la possibilità al cliente di vedere in prima persona i prodotti che sta acquistando anche in caso non sia presenti, oppure vedere il risultato della personalizzazione del prodotto. Ad esempio nel campo automotive si può usare Vision Pro per mostrare al cliente l’auto o la moto che sta configurando, davanti a lui, come se fosse già pronta, modificando le varie componenti in tempo reale per poter prendere la miglior decisione di acquisto.

Oppure è possibile, nel caso di shopping remoto, effettuare una video call con il cliente mentre si mostra in tempo reale gli oggetti in vendita, che verranno piazzati comodamente nello spazio a disposizione dell’utente finale, con ad esempio la comodità di effettuare shopping di capi di moda comprandoli direttamente dal proprio salotto.

Nel retail è possibile migliorare il modo in cui viene effettuato il training al personale di store dando la possibilità di andare oltre ad un video o una sequenza di foto, immaginiamo un fashion store che dà la possibilità ai propri dipendenti di vedere la sfilata in modo immersivo o di poter visualizzare i capi come se fossero davanti a loro, potendo vederne i dettagli da ogni angolazione; per uno store di arredamento potrebbe dare il valore aggiunto di poter piazzare un modello 3D nell’ambiente reale in modo da vederne l’abbinamento finale.

Anche se ad oggi in pochi possono dire di aver testato Vision Pro, ciò che è sicuro è che un prodotto come questo aprirà un grande numero di nuove opportunità di interazione, intrattenimento e fruizione dei contenuti che, sfruttati nel modo corretto, porteranno a nuove esperienze che gli utenti impareranno ad usare e diventeranno sempre più comuni nell’uso di tutti i giorni.

L'articolo Apple Vision PRO: applicazioni pratiche nel business proviene da Zero12.

Come discusso nell’articolo precedente “INFRASTRUCTURE AS CODE (IAC): COS’È?”, Cloud Development Kit è una delle scelte tecnologiche possibili quando si decide di utilizzare un approccio di Infrastructure As Code per una infrastruttura AWS.

In questo caso approfondiremo un esempio di progetto, che permetta di realizzare una infrastruttura completa e pronta all’uso.
Presupponendo che l’utente abbia configurato il proprio PC con le proprie credenziali AWS, si può installare prima NodeJS e poi CDK tramite pacchetto npm.
Se dovessero servire indicazioni aggiuntive, si può fare riferimento alla documentazione ufficiale: https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html.

Per ricevere il codice realizzato per questo articolo compilando il form a questo link, oppure puoi partire da una cartella vuota e seguire passo passo per ottenere un progetto completo.

Come creare il progetto

Partendo da zero, create una nuova cartella e datele un nome a vostro piacimento.
Cloud Development Kit permette di sviluppare con vari linguaggi, in questo caso useremo TypeScript, quindi all’interno della cartella aprite un terminale e lanciate il seguente comando: cdk init app –language typescript per inizializzare il progetto.

A questo punto avrete una cartella popolata con vari file, nella root ad esempio troviamo i comuni README.md e package.json tipici di un progetto NodeJS, ma anche un particolare file cdk.json che vedremo tra poco.

In questo articolo ci concentreremo in particolare sulle cartelle “bin” e “lib” in quanto qui andremo a definire i servizi AWS che vogliamo creare.
Non tratteremo l’argomento dei test in questo articolo, quindi ci concentreremo sulle attività di codifica e deploy dell’infrastruttura.
Partendo dal file “cdk.json”, qui il campo di interesse è il cosiddetto “context”. Al suo interno definiamo un contesto per ogni ambiente in cui vogliamo effettuare un deploy, nel nostro caso li abbiamo chiamati “dev” e “prod”. Qui definiamo quante più variabili ci possono servire, tenendo conto che se rendiamo il file troppo complesso, risulterà anche più difficile da leggere e da mantenere.

Definizione della struttura

Abbiamo individuato come buona prassi, quella di definire una struttura come la seguente, andando poi a personalizzare l’oggetto “stacks” in base alle necessità:

Nella cartella “bin” troviamo un unico file, che è l’entry point del progetto. Il nome del vostro file dipenderà dal nome della cartella dentro la quale avete eseguito il comando di init in precedenza. Di seguito uno snippet del file, senza gli import dei vari pacchetti, e con la definizione di un solo stack, per brevità.

Dato che ogni costrutto CDK deve essere istanziato in un determinato scope, qui troviamo l’inizializzazione di un oggetto “App” che farà da contenitore di tutti gli stack che andremo ad istanziare. I vari servizi che andremo a definire, invece, saranno realizzati nello scope del rispettivo stack di appartenenza.

Successivamente definiamo un oggetto “builConfig”, che contiene tutte le variabili d’ambiente del deploy che vogliamo eseguire. Il tipo di oggetto “BuildConfig” è definito nel file “/lib/common/build-config.ts”. In pratica è un’interfaccia che corrisponde 1:1 ai campi presenti nell’oggetto context del file “cdk.json”. In questo modo la costante “buildConfig” conterrà tutte le variabili d’ambiente del deploy che stiamo effettuando, e le avremo disponibili negli stack in cui passiamo tale oggetto.

Creiamo anche la costante “envDetails” che viene passata ad ogni stack istanziato, per fornire le informazioni su che account e regione AWS tale stack sarà creato.

La costante “prefix” invece è una pura comodità per facilitare la nomenclatura delle risorse, in modo da avere uno standard unico in tutto il progetto.

Arrivando alla dichiarazione dello stack, così come per i costrutti che rappresentano i servizi, il costruttore si aspetta:

• scope: che come detto per gli stack è l’App;
• id: un identificativo derivante dalla dipendenza da CloudFormation, che serve a garantire l’unicità della risorsa durante il deploy;
• proprietà: queste dipendono in numero e tipo da come abbiamo definito lo stack, quindi in questo caso ad esempio viene passato l’oggetto “buildConfig”, ma potremmo passare anche interi stack ad altri stack, creando così delle dipendenze;

Infine definiamo la funzione “addTagsToStack()” che serve per aggiungere dei tag allo stack CloudFormation che verrà creato. Dato che i costrutti che gli appartengono ereditano tali tag, ci troveremo anche i servizi creati taggati in questo modo e ciò faciliterà la manutenzione dell’infrastruttura e l’individuazione delle risorse create con IaC oppure no. Ovviamente tali tag possono essere aggiunti e modificati in base alle necessità.

Passiamo ora alla cartella “lib”, che contiene tutte le dichiarazioni degli stack. Queste seguono la seguente struttura:

Ogni stack è una classe TypeScript che estendiamo per definire le proprietà di interesse. Tutte le proprietà che vogliamo esporre agli stack che importeranno questo stesso stack, le dichiariamo come “public” e saranno accessibili come campi dell’oggetto, quindi ad esempio “networkStack.vpc” oppure “networkStack.privateSubnets”.

Le definizioni di questi campi, e tutti i servizi che appartengono a questo stack, li gestiamo all’interno del costruttore.

Partendo in ordine alfabetico, vediamo i file della cartella “lib”.

La documentazione dei costrutti è disponibile al link https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html. Unico appunto, nel caso si arrivi alla documentazione tramite link esterni (esempio Stack Overflow), fare attenzione a controllare di essere nella versione #2 di CDK, visto che è la più aggiornata.

Backup

Qui creiamo una chiave KMS per criptare i backup, decidendo la “retentionPolicy” in base all’ambiente in cui siamo. La chiave poi la passiamo alla vault che andiamo a creare, che sarà il raccoglitore dei backup.
La frequenza con cui vengono realizzati i backup deriva dalle regole del piano.

Nell’esempio prevediamo una regola giornaliera con retention 7 giorni, una regola settimanale con retention 3 settimane, ed una regola mensile con retention 3 mesi.

La selezione di quali risorse sono comprese in questo piano, avviene tramite tag, in particolare, se ipotizziamo di essere in ambiente “dev”, il tag che verrà considerato valido in questo caso sarà con chiave “aws-backup-active-dev” e valore “true”.

CloudFront

Qui creiamo un bucket S3 che useremo per salvare i file ad esempio di una Single Page Application (che potrebbe essere realizzata in Angular) che verrà distribuita dalla distribuzione CloudFront. In particolare il bucket sarà privato, ed i contenuti saranno accessibili dal web solo tramite la CDN, ciò è reso possibile definendo il “defaultRootObject” che cerca un file “index.html” nella root del bucket.

Per rendere il sito più sicuro agganciamo un WAF, il servizio di firewall di AWS, che essendo un servizio globale sarà deployato sulla regione Nord Virginia. Per recuperare l’arn in maniera automatica, utilizziamo l’oggetto “parameterReader” definito nella cartella “common” che eseguirà una chiamata API.

EC2

In questo progetto di esempio, il servizio EC2 lo utilizziamo solo per la creazione di un’istanza ponte per poterci collegare alle risorse che saranno in sottoreti private, in particolare il database RDS. Nel costrutto EC2 decidiamo il tipo di istanza da utilizzare, l’AMI (quindi il sistema operativo), la quantità di storage, la posizione nella rete VPC, ed il security group che definisce le regole di accesso a questa istanza.

Come accortezza, verificare che l’AMI scelta sia disponibile nella regione di deploy, e che la chiave PEM sia già stata creata sulla console AWS. Per comodità successivamente agganciamo un Elastic IP per avere un IP pubblico statico a cui connettersi.

ECS

Questo è probabilmente il file che contiene più definizioni di risorse.

Nella prima parte definiamo il bilanciatore come pubblico, e creiamo un listener HTTPS su porta 443. Il listener è unico perché i target group sono differenziati tramite “host-header” nelle regole del listener. Il traffico sarà quindi in HTTPS dal bilanciatore verso internet, mentre in HTTP dal bilanciatore verso i servizi ECS.

Nella seconda parte andiamo a definire il cluster ECS con i rispettivi servizi e task.

Per facilitare la configurazione, cicliamo sugli oggetti “buildConfig.stacks.ecs.services“ definiti in “cdk.json”. Questo è uno dei vantaggi maggiori di un approccio IaC, in quanto con un minimo sforzo, possiamo replicare la configurazione per tutti i servizi eliminando gli errori umani che potrebbero verificarsi eseguendo le operazioni da console o definendole una ad una. Per ogni servizio ECS è previsto un Log Group, un repository ECR ed il proprio Task Definition.

Come detto, le configurazioni principali vengono prese dal “cdk.json” quindi non è necessario modificare il codice a meno di cambiamenti strutturali.

Network

Lo stack Network prevede la creazione della rete VPC, ed all’interno due sottoreti private e due pubbliche. I range di IP e l’AZ da utilizzare sono definiti sul “cdk.json” quindi anche qui si può evitare di modificare il codice, trovandosi tutte le risorse nominate correttamente in base alle configurazioni.

RDS

Per il database il costrutto dipende dal tipo di engine scelto (esempio MySQL o PostgreSQL) e dalla scelta tra istanza RDS o cluster Aurora, quindi alcune modifiche lato codice sono possibili se si vogliono cambiare queste configurazioni. In questo caso creiamo un’istanza singola di RDS MySQL, con autoscaling dello storage definito tramite parametri del “cdk.json”. Da notare come vengono disabilitati i backup automatici di RDS impostando “backupRetention: Duration.days(0)” perché aggiungiamo il tag apposito che abbiamo previsto per la selezione di AWS Backup, in modo da non avere un costo doppio per lo storage dei backup stessi.

Security

Per abitudine raccogliamo le definizioni dei Security Group in un unico stack, per prevenire dipendenze circolari nel codice. Infatti è buona prassi utilizzare nelle regole gli ID dei Security Group dei servizi da cui vogliamo abilitare le connessioni, ed è quindi più comodo e semplice da mantenerli configurarli in un unico file.

Qui ad esempio abilitiamo le richieste verso il DB solo dai servizi ECS e dall’istanza EC2 ponte.

WAF

Il Web Application Firewall è un servizio che può essere agganciato sia a CloudFront che ad un Application Load Balancer, in base a se viene deployato a livello globale o sulla regione dell’ALB. Viene previsto un IP set per avere delle sorgenti in whitelist, e poi delle regole gestite da AWS che coprono casi d’uso tipici come, ad esempio, un attacco di SQL Injection.

Viene salvato un parametro su SSM con l’arn del WAF appena creato, che verrà poi richiamato dalla funzione “parameterReader” nel modulo di CloudFront descritto in precedenza.

Essendo da deployare a livello globale, lo stack dedicato al WAF dovrà essere in Nord Virginia, quindi c’è da fare attenzione ad eseguire il bootstrap di CDK anche in tale regione.

Arrivati al momento del deploy, vengono previsti degli script npm che facilitano l’operazione in modo da non dover ricordare la sintassi completa:

• “cdk-diff-dev”: “cdk context –clear && cdk diff $npm_config_stack -c config=dev –profile PROFILE_NAME”,
• “cdk-deploy-dev”: “cdk context –clear && cdk deploy $npm_config_stack -c config=dev –profile PROFILE_NAME”,
• “cdk-destroy-dev”: “cdk destroy $npm_config_stack -c config=dev –profile PROFILE_NAME”,

Quindi ad esempio per eseguire il deploy di un singolo stack  in ambiente dev il comando da eseguire sarebbe: “npm run cdk-deploy-dev –stack STACK_NAME”.

Prendendo come esempio lo stack “ec2” che ha come parametri del costruttore anche gli stack “network” e “security”, CDK vedrà la dipendenza e li eseguirà prima dello stack “ec2” in modo da trovare pronti tutti i parametri necessari.

I principali vantaggi

Come avete potuto capire dall’esempio precedente un approccio di gestione architetturale tramite Infrastructure As Code permette di creare, controllare, aggiornare e gestire via codice un’infrastruttura rendendo programmabile quello che tipicamente veniva svolto manualmente. Alcuni dei numerosi vantaggi derivanti sono:

• Flessibilità
• Chiarezza sulle operazioni svolte
• Maggiore controllo
• Sicurezza
• Replicabilità
• Riduzione degli errori
• Documentazione sempre aggiornata

Tutto ciò però è possibile con competenze trasversali che vanno da aspetti sistemistici e infrastrutturali fino allo sviluppo software che, grazie all’approccio IaC, sarà sempre più integrato con gli applicativi sviluppati.

Per riuscire a trarne il massimo vantaggio, le organizzazioni devono iniziare a pensare alla gestione dei sistemi informativi come servizi in continua evoluzione e creare team estesi composti da tecnici, persone di business interne e partner in grado di evolvere e seguire il mercato con la stessa velocità dell’evoluzione tecnologica spinta ancora di più dai servizi cloud.

Se vuoi condividere la tua esperienza su questo ambito e le tue opinioni usa la funzione commenti!

Questo è il secondo articolo della serie a cui stiamo lavorando per trattare vari argomenti legati al mondo AWS ed in particolare sugli approcci di Infrastructure As Code.

Contattateci all’indirizzo hello@zero12.it, per richiedere degli articoli o per chiederci di trattare argomenti specifici… oppure seguite i nostri canali social per restare informati sulle prossime pubblicazioni.

Ciao

L'articolo Un approccio IaC con Cloud Development KIT (CDK) proviene da Zero12.

Prima di approfondire l’Infrastructure as Code (IaC) è importante sottolineare che quando un’azienda si approccia al voler utilizzare l’infrastruttura AWS, gli scenari più comuni sono principalmente due:

• 1. l’azienda potrebbe voler migrare interamente o parte dei propri servizi esistenti gestiti in quel momento on premise;
• 2. l’azienda preferisce partire da zero con un nuovo progetto direttamente sul Cloud.

Possono sembrare casi completamente diversi, ma in entrambi ci sono spesso valide ragioni per le quali l’azienda potrebbe avere la necessità di terminare la propria transizione in tempi stretti: un contratto in scadenza presso il datacenter attuale, dei limiti tecnici dell’infrastruttura on premise che non permettono all’azienda di operare pienamente, una startup che ha bisogno di lanciare il proprio prodotto per potersi rendere fruibile dai propri clienti e molto altro.

IaC: come individuare l’approccio migliore

Spesso si rischia di farsi prendere dalla fretta e scegliere un approccio manuale che può sembrare inizialmente più semplice e veloce. Il problema di questo approccio è la facilità con cui si può perdere traccia delle modifiche fatte in fase di configurazione e fine tuning. Questo può comportare varie problematiche. Nel breve periodo, ad esempio, il non riuscire a replicare interamente l’ambiente di test su quello di produzione ritrovandosi problemi inaspettati a ridosso delle scadenze di go-live/migrazione. Oppure a lungo andare la difficoltà di manutenzione dell’infrastruttura in quanto il personale tecnico, potenzialmente diverso nel tempo, non avrà tutte le indicazioni necessarie per poter operare.

Per ridurre e/o risolvere queste problematiche l’approccio migliore è definire dei template di codice per la propria infrastruttura, tramite tecnologie come AWS CloudFormation, AWS CDK (Cloud Development Kit) e Terraform.
Con l’Infrastructure As Code (IaC) quindi intendiamo la definizione dell’infrastruttura tramite dei file con linguaggi e sintassi specifici che permettono un approccio programmatico alla gestione dei servizi Cloud.
Sono tecnologie diverse tra loro e non è oggetto di questa discussione andarle ad approfondire tutte, ma è utile vedere brevemente le loro caratteristiche principali.

AWS CloudFormation

CloudFormation è a tutti gli effetti un servizio AWS, ed il primo riguardo IaC in linea temporale, e può quindi essere visitato sulla console. Il funzionamento si basa sulla definizione di file scritti in linguaggio JSON o YAML con una sintassi ben precisa, che vengono poi caricati manualmente sulla console oppure automaticamente tramite delle pipeline apposite di CI/CD (Continuous Integration e Continuous Delivery). Di seguito un esempio di istanza EC2 in CloudFormation, utilizzando il linguaggio YAML. I campi dati inseriti sono stringhe, oppure riferimenti a variabili dichiarate precedentemente e la formattazione ha una struttura molto rigida.

AWS Cloud Development Kit (CDK)

AWS CDK è un sistema di templetizzazione costruito ad un livello più alto di CloudFormation e che permette l’utilizzo dei linguaggi di programmazione più diffusi tra gli sviluppatori come Javascript, Typescript, Python, Go, Java ed altri ancora.
Un progetto CDK ha una struttura ben definita, che facilita la suddivisione dell’infrastruttura in più aree di interesse. Di seguito un esempio di istanza EC2 in CDK, utilizzando il linguaggio TypeScript. Le variabili possono essere di qualsiasi tipo permesso dal linguaggio, oppure provenire da stack differenti che sono stati importati.

Terraform

Terraform è un progetto open source, inizialmente sviluppato da HashiCorp.
É una tecnologia molto matura, che permette la definizione delle risorse infrastrutturali tramite un linguaggio di programmazione appositamente sviluppato chiamato HCL (HashiCorp Configuration Language) con una struttura simile al JSON, che è agnostico rispetto al Cloud Provider scelto. Di seguito un esempio di istanza EC2 in Terraform, utilizzando il linguaggio HCL. Anche qui le variabili possono essere dichiarate in altri moduli o parti del codice e poi importate.

Costi

Riguardo l’argomento costi questi approcci non comportano una spesa diretta, nel senso che non si pagano le operazioni di deploy, ma richiedono chiaramente di pagare per le risorse che verranno create tramite i template IaC secondo le tariffe standard di quei servizi espresse da AWS.

I vantaggi dell’approccio IaC

Qualunque sia la tecnologia scelta si potranno ottenere dei template uniformi, replicabili, versionati e testabili. Tutti gli approcci permettono il riuso del codice, così che si possa anche risparmiare tempo per non dover reinventare la ruota ed usare componenti magari provenienti da altri progetti precedenti dell’azienda, ma che con poche modifiche possono essere adattati, riducendo ampiamente i tempi di sviluppo e gli errori umani.
Ad esempio questo significa che se in un progetto l’ambiente di test è stato ben definito e templetizzato si può passare al rilascio e quindi alla creazione dell’ambiente di produzione in rapidità, con la sicurezza che le configurazioni codificate verranno replicate sul nuovo ambiente.

Precisiamo che con il termine ambiente possiamo intendere sia un’infrastruttura che contiene tutte le risorse in un unico account, sia un progetto che è diviso su più account AWS. Il valore aggiunto della replicazione delle configurazioni che viene dato dall’utilizzo dell’approccio IaC persiste, in quanto semplicemente il template IaC verrà configurato con tutti gli account sui quali dovrà essere rilasciato.

Problematiche dell’approccio IaC

Ovviamente il rilascio di un progetto è solo l’inizio del suo percorso. La manutenzione dell’infrastruttura è spesso dove l’approccio manuale inizia a mostrare i propri difetti in quanto diventa sempre più difficile applicare le modifiche che si rendono necessarie nel tempo. I motivi possono essere i più disparati: dal cambio di personale tecnico che si occupa del progetto alla scarsa documentazione realizzata per tenere traccia delle modifiche fatte manualmente, o magari più semplicemente, una mancanza di competenze approfondite.

Ci possono comunque essere delle problematiche nello scegliere di utilizzare un approccio Infrastructure as Code (IaC). In primo luogo la dipendenza dal codice, che comporta la necessità di avere almeno una figura di riferimento all’interno dell’azienda con le competenze per poter operare le modifiche sul template che si renderanno necessarie nel tempo.
Come secondo aspetto è bene tenere a mente che ci sarà una porzione di tempo iniziale in cui lo sviluppo potrebbe essere più lento rispetto ad un approccio manuale, in quanto il personale dovrà acquisire le competenze necessarie e tracciare le configurazioni che dovranno essere templetizzate.

Quando pensiamo a tutti gli steps necessari al rilascio di un’applicazione, essere in grado di operare con rapidità ed automazioni è la chiave per garantire un rilascio veloce e di successo. La stessa mentalità deve essere applicata all’infrastruttura che sorregge tale applicazione, in quanto è chiaramente una parte fondamentale che però spesso si tende a vedere più distaccata ed in sottofondo.

Vale la pena affrontare i punti critici di un approccio IaC in quanto i benefici sono decisamente maggiori: la possibilità di versionamento dei template infrastrutturali, il poter collaborare e riusare il codice prodotto con i comuni strumenti usati dagli sviluppatori, automatizzare task complessi riducendo gli errori umani, e facilitare la manutenzione e gli aggiornamenti dei vari ambienti in uso.

IaC: trend di crescita

Dati i trend di crescita del Cloud, in futuro possiamo aspettarci che gli strumenti di IaC assumeranno sempre più importanza, sia per ambienti puramente Cloud, sia per soluzioni ibride in cui le aziende vogliono integrare la propria infrastruttura privata con il provider scelto.
Che si tratti di una multinazionale oppure di una startup, ogni azienda che ha intenzione di spostare la propria infrastruttura sul Cloud ha la possibilità di beneficiare enormemente dall’utilizzo di un approccio IaC.

Non perdere i prossimi articoli dove parleremo degli approcci dell’Infrastructure as Code (IaC) con riferimento al mondo AWS.

Per ricevere aggiornamenti su questi temi contattateci all’indirizzo hello@zero12.it, oppure seguite i nostri canali social per restare informati sulle prossime pubblicazioni!

Ciao

Se vuoi approfondire il Cloud Development Kit attraverso un esempio pratico clicca qui per leggere l’articolo

L'articolo Infrastructure as Code (IaC): cos’è? proviene da Zero12.

Anche quest’anno rinnoviamo la partnership con l’Osservatorio Cloud Transformation del Politecnico di Milano giunto alla sua dodicesima edizione.

L’Osservatorio si pone l’obiettivo di analizzare gli strumenti tecnologici a disposizione e di comprendere i percorsi di adozione, le opportunità di innovazione e gli impatti sul sistema informativo e sulla gestione dell’IT.

SECONDO CLOUD COMMUNITY TALK DELL’EDIZIONE 2022 DELL’OSSERVATORIO CLOUD TRANSFORMATION

17 Maggio, ore 09.30 – 13.00

I Cloud Community Talk sono eventi tematici interattivi dal format innovativo che coinvolgono la Community Cloud e i sostenitori della ricerca che discutono insieme temi rilevanti nell’ambito dei progetti di Cloud Transformation condotti in azienda e proposti dalla Community stessa. Nel secondo incontro saranno discussi temi relativi alla gestione dei costi e della security nel Cloud e all’acquisizione di competenze per accompagnare l’organizzazione nel percorso di Cloud Transformation.

NON PERDERTI I PROSSIMI APPUNTAMENTI DELL’OSSERVATORIO:

• ​14 Settembre, ore 9.30 – 13.00 Secondo Cloud Summit: La gestione dei costi del Cloud – incontro con la community di C-level e IT Executive delle imprese e i sostenitori della ricerca.
• 6 Ottobre, ore 9.30 – 13.00 Convegno conclusivo di presentazione dei risultati della ricerca: evento finale di presentazione dei risultati della Ricerca.
• ​13 Ottobre, ore 9.30 – 13.00 Use Case Virtual Session: Evento online a porte aperte in cui i sostenitori potranno presentare un caso d’uso cliente.

L'articolo Secondo Cloud Community Talk: Evoluzione applicativa e dati nel Cloud proviene da Zero12.

Se stai valutando la migrazione sul cloud di workload Windows o cerchi maggiori informazioni sull’ottimizzazione delle licenze, iscriviti al nostro webinar by Zero12 Var Group Company che si terrà il 15 giugno alle ore 14.30.

Scopri come OLA (Optimizing & licensing assessment) ti aiuta a risparmiare dal 20 al 50% sui costi di licenza sul cloud AWS.
OLA attraverso l’analisi dell’effettivo utilizzo delle risorse on prem e su cloud, oltre che le licenze di terze parti in uso e delle dipendenze tra le applicazioni, fornisce un report con i possibili spunti di ottimizzazione.

Programma OLA | 15 Giugno ore 14.30

DURANTE IL LIVE TI RACCONTEREMO:

• Confronto sulle dinamiche tipiche del passaggio in cloud
• Introduzione al programma OLA
• Come affrontare un’assessment
• Perché non perdere l’opportunità di svolgere un assessment OLA
• Q&A

OSPITI:

• Stefano Dindo – CEO di Zero12 – Var Group Company – Advanced partner AWS
• Tommaso Calosi – Acquisition Specialist – Migration Workloads – AWS

Spiacenti iscrizioni chiuse.
Non hai potuto seguire il webinar?

L'articolo Partecipa al live streaming “Riduci i costi delle licenze Windows su AWS” proviene da Zero12.

Parentsmile è una piattaforma di prenotazione unica che integra servizi sanitari, formativi, educativi e di benessere psicofisico onnicomprensivo, concentrandosi sul settore dell’assistenza familiare.

Il ruolo di Zero12, azienda del gruppo Var Group oltre che AWS SaaS Competency Partner che ha seguito la progettazione della piattaforma, è stato quello di analizzare l’idea ed il modello di business del cliente, guidandolo nella scelta dei servizi da utilizzare e assicurandosi che lo sviluppo del codice fosse integrato ai servizi Amazon Web Services (AWS).

L’obiettivo era quello di fornire agli utenti finali un servizio che gestisse in maniera sicura i dati , oltre che essere affidabile e scalabile grazie ai servizi serverless.

Questo post dimostra come Zero12 ha costruito la piattaforma SaaS di Parentsmile; esponendo i principali servizi e logiche di sviluppo utilizzati, quali Amazon Elastic Container Service (Amazon ECS), (Amazon ECS), il processo di continuous integration e continuous delivery (CI/CD) ed il workflow asincrono utilizzato per i pagamenti ed i reminders.

Cos’è Parentsmile

La piattaforma Parentsmile consente a genitori, nonni e altri membri della famiglia di prenotare un’ampia gamma di servizi di supporto e orientamento, forniti da professionisti specializzati nel settore dell’assistenza familiare. Questi professionisti sono convalidati dal team di Parentsmile e forniscono le loro prestazioni sia in casa che tramite video in diretta, giorno o notte compresi i fine settimana.

La piattaforma offre un’offerta altamente differenziata, che consente agli utenti di trovare il supporto di cui hanno bisogno in un’unica piattaforma. Attualmente Parentsmile offre servizi di ostetriche, logopedisti, psicologi e psicoterapeuti, osteopati, nutrizionisti, educatori e presto includerà anche infermieri pediatrici, personal trainer, educatori e operatori dell’infanzia.

L’esperienza di acquisto unica di Parentsmile include molteplici servizi forniti da una rete di professionisti accuratamente selezionati, un’esperienza utente seamless (UX) e conferme di prenotazione in tempo reale.

Gli algoritmi di intelligenza artificiale (AI) associano automaticamente ogni utente al servizio più adatto in base alle sue esigenze, facendo risparmiare alle persone ore trascorse a navigare tra centinaia di profili professionali.

Figura 1 – Design del front-end dell’applicazione.

Parentsmile si rivolge principalmente a tre tipologie di personas:

• Consumatori o utenti finali che effettuano prenotazioni, acquistano i servizi della piattaforma in tempo reale, e possono gestire le proprie prenotazioni in autonomia dalla propria area riservata.
• Professionisti che forniscono e fatturano i loro servizi direttamente ai consumatori.
• Lo staff di Parentsmile che gestisce l’ambiente di back-office.

Parentsmile adotta un modello di business Saas basato sul pagamento di commissioni, ciò significa che la piattaforma trattiene una percentuale prestabilita sugli importi pagati dagli utenti finali.

Parentsmile Partnership

La piattaforma Parentsmile è stata sviluppata da Zero12, società specializzata nella progettazione e sviluppo di soluzioni SaaS basate sulle tecnologie AWS.
È uno dei pochi partner ad aver ottenuto l’AWS SaaS Competency, che certifica la loro capacità nello sviluppare soluzioni software sostenibili e scalabili. Parentsmile ha deciso di affidarsi a Zero12 grazie alle skill dimostrate, quali:

• Capacità di trasformare le idee in soluzioni software.
• Capacità di sviluppare software cloud-native con caratteristiche di scalabilità, efficienza operativa e resilienza.
• Metodologia di lavoro che coniuga la puntualità nel rispetto del piano di sviluppo con la flessibilità necessaria nella creazione di una nuova soluzione digitale.

Architettura dell’applicazione SaaS di Parentsmile

La piattaforma di Parentsmile è stata progettata utilizzando un approccio a microservizi in modalità serverless che consente una perfetta integrazione tra software e architettura cloud.

La piattaforma è completamente serverless e offre la massima flessibilità e affidabilità grazie ai servizi gestiti AWS, che includono:

• Amazon ECS on AWS Fargate per l’orchestrazione dei container serverless.
• Amazon DocumentDB con compatibilità MongoDB  per il database principale.
• Amazon Simple Email Service (Amazon SES) e Amazon Simple Notification Service (Amazon SNS) per inviare, rispettivamente,  e-mail e messaggi di testo.
• Amazon Simple Storage Service (Amazon S3) per archiviare file e consentire agli utenti di recuperarli tramite URL pre-signed.
• Amazon Cognito per l’autenticazione degli utenti.
• AWS Lambda per eseguire operazioni asincrone che verranno descritte più avanti in questo post.

Figura 2 – Applicazione front-end e infrastruttura principale back-end.

L’applicazione viene distribuita utilizzando Amazon ECS, mentre le attività in esecuzione su AWS Fargate vengono replicate su due sottoreti private per essere altamente disponibili su almeno due Zone di Disponibilità (AZ) AWS .

Esistono tre piattaforme: una per gli amministratori di Parentsmile, una per i fornitori di servizi (ad esempio, operatori sanitari e di assistenza all’infanzia) e una per i consumatori.

Ciascuna è accessibile tramite Amazon CloudFront, che distribuisce i file statici contenuti in Amazon S3. Utilizzando questi due servizi, aiutiamo a garantire scalabilità e affidabilità per gli utenti, nonché prestazioni elevate a livello globale.

Uno dei servizi offerti da Parentsmile è la videoconsulenza, detta anche visita a distanza. Per sviluppare questa funzionalità, Zero12 Amazon Chime che ci ha permesso di concentrarci sulla logica di business.

Continuous Integration and Continuous Delivery

La piattaforma Parentsmile è composta da un componente front-end e un componente back-end. Il processo di CI/CD viene avviato su AWS CodeCommit.

Per il front-end ed il back-end, vengono eseguiti rilasci costanti del codice modificato, in questo modo sarà distribuito solo il micro servizio modificato e non l’intero codice.

A tale scopo, la prima pipeline crea immagini Docker per ogni micro servizio aggiornato e le invia a Amazon Elastic Container Registry (Amazon ECR). Quindi, per ogni immagine Amazon ECR,  Amazon CloudWatch attiva una pipeline che crea e distribuisce ogni immagine in Amazon ECS.

Figura 3 – Architettura di Continuous integration e continuous delivery con servizi di sviluppo AWS.

Serverless Asynchronous Workflows

La piattaforma utilizza la potenza di calcolo asincrono offerto da AWS Lambda e le funzionalità di AWS Step Functions per l’orchestrazione. Grazie a questi servizi, Zero12 è riuscita a gestire tutte le operazioni asincrone e a raggiungere sia gli obiettivi di ottimizzazione dei costi che una migliore esperienza utente.

La Figura 4, di seguito, mostra in maniera semplificata un  workflow di Step Function, che viene normalmente utilizzato per pianificare i pagamenti (48 ore prima della data dell’appuntamento), le fatture mensili, le notifiche utente e creare la riunione Chime minuti prima dell’appuntamento.

Figura 4 – Scheduling dell’infrastruttura con AWS Step Functions.

Per la pianificazione dei pagamenti è stato utilizzato Stripe, che, grazie ai suoi webhook, si integra con il flusso di lavoro asincrono attivando Amazon API Gateway. Questo attiva AWS Lambda ogni volta che viene avviata un’azione.

I webhook Stripe forniscono notifiche anche quando un pagamento viene eseguito o rifiutato, o quando vengono eseguite azioni sull’account  dei professionisti, come ad esempio il pagamento mensile delle prestazioni eseguite.

Considerando il caso d’uso, la piattaforma Parentsmile necessita di un’infrastruttura altamente sicura, per questo abbiamo utilizzato il servizio AWS Key Management Service (AWS KMS) per la crittografica dei dati at rest mentre per quelli in transito, utilizziamo il protocollo HTTPS per comunicare con le nostre API.

Per quanto riguarda, invece, l’autenticazione e l’autorizzazione degli utenti ad accedere alle loro informazioni private utilizziamo Amazon Cognito. Sono presente anche degli utenti autorizzati possono eseguire operazioni amministrative.

L'articolo Parentsmile lancia la prima piattaforma SaaS su AWS specializzata nei servizi assistenziali per le famiglie proviene da Zero12.

Parentsmile is a unique reservation platform that integrates healthcare, training, educational, and all-encompassing psychophysical well-being services, focusing on the family care sector.

The role of Zero12, a Var Group company and AWS SaaS Competency Partner, in designing the Parentsmile platform architecture was to analyze the client’s idea and business model, lead them in the choice of services to use, and ensure the development of code was integrated with Amazon Web Services (AWS).

The goal was to provide end users with service reliability and data security, as well as the stability and scalability of the server-free solution.

This post demonstrates how Zero12 built Parentsmile’s SaaS platform; exploring the main infrastructure with Amazon Elastic Container Service (Amazon ECS), the continuous integration and continuous delivery (CI/CD) process, and the asynchronous workflow for payments and reminders.

About Parentsmile

The Parentsmile platform allows parents, grandparents, and other family members to reserve a wide range of support and orientation services provided by professionals specialized in the family care sector. These professionals are validated by the Parentsmile team and available to the whole family either at home or through live video day or night including the weekends.

The platform provides a highly differentiated offer, which allows users to find the support they need in a single platform. Currently, Parentsmile offers the services of midwives, speech therapists, psychologists and psychotherapists, osteopaths, nutritionists, educationists, and will soon include pediatric nurses, personal trainers, educators, and childcare workers.

Parentsmile’s unique shopping experience includes multiple services provided by a network of carefully selected professionals, a seamless user experience (UX), and real-time booking confirmations.

Artificial intelligence (AI) algorithms automatically associate each user with the most suitable service depending on their needs, saving people hours spent browsing hundreds of professional profiles.

Figure 1 – Front-end application design.

Parentsmile is focused on three main personas:

• Consumers or end users who make reservations, purchase the platform services in real-time, and can manage their own reservations autonomously from their reserved area.
• Professionals who provide and bill their services to consumers directly.
• Parentsmile operators who manage the back-office environment.

Parentsmile adopts a commission-based SaaS business model, meaning the platform retains a given percentage of the amount paid by end users to professionals for the services.

Parentsmile Partnership

The Parentsmile platform was developed by Zero12, a company specializing in the design and development of SaaS solutions based on AWS technologies.

As one of few AWS Partners to have the AWS SaaS Competency, which certifies their ability to develop scalable and sustainable cloud-native software solutions, Parentsmile decided to use Zero12’s skills, including:

• Ability to turn ideas into software.
• Ability to develop cloud-native software that takes advantage of cloud services to have a scalable, efficient, and robust software solution.
• Working methodology that combines punctuality with flexibility and necessary changes with respect to the development plan of a new digital solution.

Parentsmile SaaS Application Architecture

The Parentsmile platform was implemented using a microservice-based approach, leveraging the most recent serverless development paradigms. This helped ensure a seamless integration between software and cloud architecture.

The platform is completely serverless and offers the highest flexibility and reliability of AWS managed services, which include:

• Amazon ECS on AWS Fargate for serverless container orchestration.
• Amazon DocumentDB with MongoDB compatibility for the main database.
• Amazon Simple Email Service (Amazon SES) and Amazon Simple Notification Service (Amazon SNS) to send emails and text messages, respectively.
• Amazon Simple Storage Service (Amazon S3) to store files and let users retrieve using a pre-signed URL.
• Amazon Cognito to authenticate users.
• AWS Lambda to perform asynchronous operations which are described later in this post.

Figure 2 – Front-end application and back-end main infrastructure.

The application is deployed using Amazon ECS. Tasks running on AWS Fargate are replicated on two private subnets to be highly available on at least two AWS Availability Zones (AZs).

There are three platforms: one for Parentsmile administrators, one for service providers (for example, healthcare and childcare professionals), and one for consumers. Each is accessible using Amazon CloudFront, which serves static files from Amazon S3. Using those two services, we help ensure scalability and reliability for users, as well as high performance on a global level.

One of the services offered by Parentsmile is a video consultation, also referred to as a remote examination. To develop this feature, Zero12 evaluated the Amazon Chime managed service, which allowed us to focus on the business logic.

Continuous Integration and Continuous Delivery

The Parentsmile platform consists of a front-end and a back-end component. The CI/CD process starts on AWS CodeCommit.

For front-end and back-end, constant releases are performed for the code that’s been changed, so that if only one microservice is modified, then only the updated microservice will be deployed.

To do this, the first pipeline builds Docker images for every updated microservice and pushes them to Amazon Elastic Container Registry (Amazon ECR). Then, for each Amazon ECR image, a pipeline is triggered by Amazon CloudWatch and it builds and deploys each image to Amazon ECS.

Figure 3 – Continuous integration and continuous delivery architecture with AWS developer tools.

Serverless Asynchronous Workflows

The platform leverages the asynchronous calculation power offered by AWS Lambda and orchestration using AWS Step Functions. Using Lambda functions, Zero12 managed to handle all asynchronous operations and achieve both goals of cost optimization and an improved user experience.

Figure 4 below shows an over-simplified setup of our Step Function workflow, which is normally used to schedule payments 48 hours prior to the appointment date, monthly invoices, user notifications, and create a Chime meeting minutes prior to the appointment.

Figure 4 – Scheduling infrastructure with AWS Step Functions.

Stripe was used for payment scheduling, which, thanks to its webhooks, integrates with the asynchronous workflow triggering Amazon API Gateway. This turns to AWS Lambda whenever an action is triggered.

Stripe webhooks also provide notifications when a payment is done or has been rejected, or even when there are actions on the professional connected account, such as the professional monthly payout.

Considering the use case, the Parentsmile platform needs the infrastructure to be highly secure. We use encryption at-rest with AWS Key Management Service (AWS KMS) and to protect data in transit, we use HTTPS protocol to communicate with our APIs.

Moreover, we use Amazon Cognito to authenticate and authorize users to access their private information. Authorized users can perform administrative operations.

L'articolo Parentsmile Launches First Family Care SaaS Platform on AWS proviene da Zero12.

Dopo la prime due puntate che hanno evidenziato la forte evoluzione digitale delle aziende negli ultimi anni con attore principale il cloud, il SAP Cloud Journey continua con il terzo appuntamento dedicato al mondo SAP on AWS.

Tra gli scenari proposti nella prime due puntate abbiamo parlato del Public Cloud, in questa terza approfondiamo lo scenario Public con Amazon Web Services e con le potenzialità del Cloud AWS per SAP.

Non mancheranno esperienze reali attraverso success cases approfonditi direttamente dai clienti protagonisti. A coordinare il tutto resta Var Group che ha tutte le competenze per supportare al meglio lo scenario complessivo.

SAP on AWS | 31 Maggio ore 11.00

DURANTE IL LIVE TI RACCONTEREMO:

• I possibili scenari e le caratteristiche di una soluzione Cloud AWS
• Gli aspetti fondamentali da considerare per adottare SAP on AWS
• Esperienze dirette e concrete con aziende che hanno scelto una soluzione in Cloud AWS
• L’approccio consulenziale di Var Group

CON OSPITI:

• Angelo Amoroso –Cloud Advisory Manager – Var Group Digital Cloud
• Paola Gambina – SAP Solution Architect Specialist – Amazon Web Services
• Luigi Lipparini –Enterprise Sales Specialist SAP – Amazon Web Services
• Gabriele Ballarin – CIO – UNOX
• Francesco Cavarero –CIO – Miroglio Group
• Gabriele Mutti – SAP Product Sales Specialist – SUSE

E RICORDATI CHE…IL JOURNEY CONTINUA:

Durante l’evento ti comunicheremo tutti i dettagli del prossimo appuntamento.
Non ci fermiamo qua! Stay Tuned!

Spiacenti iscrizioni chiuse.

Non hai potuto seguire il webinar?

L'articolo Partecipa alla Terza puntata del SAP Cloud Journey “SAP on AWS” proviene da Zero12.

Innovatori e appassionati di tecnologia si incontrano per creare connessioni, collaborare e approfondire le opportunità del cloud Amazon Web Services.

Zero12, centro di competenza Digital Cloud di Var Group, è Gold Sponsor dell’AWS Summit Milano, il principale evento annuale dedicato ai servizi cloud di Amazon Web Services (AWS) che torna in presenza per approfondire come il cloud sta abilitando opportunità di innovazione, imprenditorialità e trasformazione digitale per aziende di ogni dimensione e settore.

Non perdere questa occasione!

Passa a salutarci allo stand G5 e scopri quale sorpresa abbiamo preparato per i nostri visitatori che accoglieranno la sfida “Stop & Play”.

Segui la nostra sessione “Sviluppare una unified retail experience con i servizi AWS”.
Con Stefano Dindo parleremo del ruolo sempre più centrale del Retail e dell’importanza dello spazio esperenziale nella Customer Journey.

Appuntamento il 21 e 22 Giugno
ore 8:30 – 17:00 – MiCO (Milano Convention Centre)
Stand G5

L'articolo Zero12 e Var Group Gold Sponsor all’AWS Summit Milano 2022 proviene da Zero12.

Il Cloud ha ridefinito, e lo farò ancora di più nel prossimo futuro, i paradigmi di sviluppo del software e le dinamiche di provisioning delle risorse.​

Per questo motivo abbiamo pensato di creare un momento di confronto dove, insieme ad Amazon Web Services, condivide le esperienze di modernizzazione di software applicativi nati in altre epoche informatiche.

Non hai potuto seguire il webinar?

L'articolo Rivedi il live streaming “Application Modernization” – Guarda ora il video! proviene da Zero12.