Buone notizie per i dev! Abbiamo messo in Open Source il nostro skeleton serverless per diversi linguaggi (Node.js, PHP, Python) che permette di iniziare subito a creare API senza preoccuparsi dell’infrastruttura. Una repository – creata da Davide De Sio, AWS Solutions Architect (Professional) e Senior Full Stack Developer di ELEVA – che unisce approccio serverless, IaC (Infrastructure as code ) e buone pratiche DevOps è ora a disposizione della community Dev. Obiettivo: migliorare l’esperienza di sviluppo di chi fa codice. In questo articolo ti spieghiamo come lavorare meglio ai tuoi progetti digitali, anche grazie alle risorse create dai nostri tecnici certificati AWS. 

• A chi e cosa serve il nostro skeleton
• Serverless: quando conviene
• Gestire l’architettura: problemi comuni nelle Software House 
• Migliorare l’esperienza dei developer 
• Conclusioni 

Prima di continuare, se vuoi approfondire le caratteristiche e le differenze tra infrastruttura monolitica e a microservizi basati su funzioni serverless, abbiamo scritto anche questo articolo.  

A chi e a cosa serve il nostro skeleton 

Sei sei alla guida di una Software House, il tuo core business è quello di realizzare prodotti digitali per i tuoi clienti, in grado di soddisfare alcuni requisiti.  

Tutto questo richiede anche competenze avanzate in ambito DevOps che non è semplice reperire, ma che dovrebbero semplificare la vita degli sviluppatori. 

Il nostro skeleton serverless offre un’enorme opportunità per avere una piattaforma di sviluppo e una buona Developer Experience (DX), consentendo agli sviluppatori di concentrarsi sulla scrittura del codice (e dei test!), senza perdere il controllo su infrastruttura, sicurezza, CI/CD e così via. 

Ti sarà di grande aiuto se nel tuo team non ci sono DevOps con esperienza o se i tuoi sviluppatori junior hanno bisogno di strumenti semplici per velocizzare il loro apprendimento in termini di infrastruttura e cultura DevOps. Si tratta di uno schema replicabile, da cui partire per iniziare direttamente a creare le proprie API, ma anche per acquisire buone pratiche su sicurezza del codice, alta affidabilità e scalabilità. 

Serverless: quando conviene 

Passare da un approccio monolitico a un approccio a microservizi serverless con AWS ti conviene in diversi casi: 

• Non voglio pagare quando non utilizzo risorse (idle time).  

Utilizzare lambda permette di non pagare server quando non sono utilizzati, ma di pagare esclusivamente ad esecuzione della singola funzione (pay per use) e delle risorse applicate.  

• Voglio che l’architettura scali in automatico (auto-scaling) 

Utilizzare lambda permette di non dover dimensionare a priori il server per i picchi di carico ma di «atomizzare» le esecuzioni. 

• Voglio che gli sviluppatori si concentrino nello scrivere la business logic 

Voglio che il team di sviluppo si concentri su quello che conta davvero, potendo far affidamento su una piattaforma di sviluppo che massimizzi la Developer Experience e la renda semplice, piacevole, ripetibile e manutenibile. 

Gestire l’architettura: problemi comuni nelle Software House 

Gestire l’architettura richiede competenze avanzate specifiche e continuo aggiornamento. L’adozione di un approccio monolitico, inoltre, è spesso all’origine di sfide e problemi comuni che le software house si trovano ad affrontare. 

Turnover nel team  

Caso frequente: lo sviluppo e gestione delle modifiche all’infrastruttura è affidato a una persona, mentre tutto il resto del team di developer si occupa del front-end. Se il back-ender cambia vita ed è l’unico a lavorare sul nostro stack sarà molto complesso sostituire le sue competenze e gestire eventuali problemi al codice lasciati in “eredità”. Una situazione che è molto più semplice da gestire con un’architettura a microservizi basata su funzioni serverless. 

Progetti ambiziosi  

La Software House acquisisce un nuovo cliente che le affida un progetto complesso, con notevoli responsabilità. Ci si aspetta che il business cresca rapidamente nel tempo, acquisisca utenti, gestisca crescenti flussi di dati. Come adottiamo uno stack affidabile e scalabile? Come conteniamo i costi? L’architettura serverless permette di concentrarsi solo sulla business logic e sull’esperienza utente, accelerando il time to market del progetto. Non solo, consente di consegnare un prodotto più sostenibile a livello di costi, in grado di scalare o ridimensionarsi con la domanda di mercato. 

Posizionamento  

Il mercato delle case di sviluppo software è ampio e variegato. Come possiamo essere più verticali e identificabili per le nostre competenze? Se il team può concentrarsi meglio sull’aggiornamento di competenze legate a specifici linguaggi di sviluppo e tecnologie emergenti, sarà in grado di offrire un servizio sempre più apprezzato. L’infrastruttura dovrebbe facilitare lo sviluppo del business, non ostacolarlo. Ed è proprio quello che serverless permette di fare. Non solo: l’esperienza dei developer migliorerà sensibilmente e, con essa, la qualità del prodotto realizzato. 

Migliorare l’esperienza dei developer 

Con l’approccio serverless e l’acquisizione di best practice DevOps su AWS, l’infrastruttura diventa parte del codice e l’esperienza dei developer può migliorare sensibilmente. Lo scopo del nostro skeleton in Open Source è proprio quello di offrire strumenti per migliorare la curva di apprendimento di questo approccio, consentendo di continuare a scrivere codice al massimo delle proprie potenzialità. 

L’Infrastructure as Code (IaC), infatti, è un approccio alla gestione e configurazione dell’infrastruttura IT che avviene tramite codice anziché con processi manuali. I file di configurazione creati con l’IaC contengono le specifiche dell’infrastruttura e semplificano la modifica e la distribuzione delle configurazioni. Questo permette di automatizzare parte delle funzioni dell’infrastruttura, per consentire agli sviluppatori di dedicarsi a ciò che sanno fare meglio. Ma non si tratta dell’unica Best Practice DevOps che potrai acquisire e che migliorerà il tuo lavoro, mentre sviluppi la tua app.  

Le principali includono:  

• Documentation as code 
  Documentazione dichiarata come codice 

• Automated Testing 
  Test automatici basati sulla documentazione 

• CI/CD 
  Pipelines di distribuzione automatizzate 

• DR 
  Procedure di Disaster Recovery 

• Versioning 
  Traccia degli aggiornamenti del singolo micro-servizio 

• Security By Design 
  Best practices di sicurezza 

• Monitoring 
  Monitoraggio continuo 

Conclusioni 

La piattaforma che abbiamo messo in OpenSource punta a migliorare l’esperienza degli sviluppatori, ma può essere compresa anche dai colleghi DevOps. Questo strumento può aiutare il team di sviluppo a comprendere tutte le operazioni cloud necessarie che potrebbero mancare. Forse non avremo risolto l’eterna battaglia tra dev e ops, ma almeno stiamo costruendo un ponte con solide basi.  

Se vuoi approfondire con un caso d’uso, ti segnaliamo quello realizzato per Revo Digital, recentemente presentato al nostro evento Go Serverless! in collaborazione con AWS: Build a serverless EU-Driving Licences OCR with Amazon Textract on AWS  

Vuoi andare in profondità dal punto di vista tecnico (aka: vedere il codice)? Da’ un’occhiata agli articoli scritti da Davide su Dev.to Superpower REST API DX with Serverless ⚡ and DevOps Best Practices on AWS