Architetture,  Cloud,  Software,  Vetrina

Guida rapida in 10 passi per la migrazione al serverless

Il 2017 è stato un anno enorme per l’adozione serverless e il 2018 non mostra segni di rallentamento. Una recente analisi dei clienti di AWS ha rilevato che l’adozione delle architetture serverless ha una crescita doppia rispetto a quella dell’adozione delle architetture a containers.

“Tra gli utenti di Amazon Web Services, l’adozione di architetture a containers è cresciuta del 246% durante il quarto trimestre del 201 … Nel quarto trimestre del 2017 l’adozione di architetture serverless è cresciuta del 667% tra i siti monitorati …” – ZDNet

Ecco quindi dieci semplici passi per passare al serverless:

1. Comprendere il problema

Nelle parole immortali di Simon Sinek, inizia sempre con il perché.

Qual è il problema aziendale che stai cercando di risolvere passando a serverless? La consegna rallentata delle funzionalità comporta la perdita di clienti e iniziative di mercato? I problemi di scalabilità e stabilità stanno danneggiando il tuo brand? Stai cercando di ridurre i costi di gestione del tuo sistema? O vuoi ridurre il sovraccarico delle operazioni sui tuoi sviluppatori per aiutarli a concentrarsi sulla creazione di valore aziendale?

Qualunque cosa sia, comprendi l’impatto sul business che vuoi creare passando a serverless. Questo ti aiuta ad avere discussioni più produttive con le parti interessate e ad impostare aspettative realistiche.

Una volta identificato l’obiettivo per passare a serverless, renderlo esplicito e compreso da tutto il team. Questa comprensione condivisa guiderà le decisioni future quando è necessario scendere a compromessi.

2. Identificare le aree di business a basso rischio per iniziare

Riconoscere che l’innovazione e il cambiamento richiedono apprendimento. L’apprendimento richiede assunzione di rischi e errori.

Riduci al minimo i rischi aziendali ed evita errori costosi. Inizia migrando i processi aziendali a basso rischio e non critici.

Evita la migrazione di tipo “big bang”, ove possibile. Potrebbe sembrare più semplice sulla carta, ma apportare grosse modifiche in una volta sola è spesso rischioso. È anche più difficile sradicare i problemi di migrazione quando molte cose cambiano contemporaneamente.

I progetti di migrazione sono maratone e comportano un certo grado di rischio in base alla progettazione. È necessario il supporto da parte degli stakeholder per avere successo, quindi evitate rischi inutili e teneteli dalla vostra parte.

3. Prototipa, impara, ripeti

Le tecnologie serverless come AWS Lambda offrono molta “componibilità”. Con questa vengono la scelta e il compromesso.

Ad esempio, è possibile implementare pub-sub utilizzando Lambda con SNS, Kinesis Streams o DynamoDB Streams. Quale fonte di eventi dovresti scegliere? La tua scelta può avere un profondo impatto sulla scalabilità, il parallelismo, la resilienza e il costo.

Sfortunatamente, non c’è una sola risposta “migliore” qui, ci sono molti fattori da considerare.

Invece, costruisci proof-of-concepts per testare e convalidare le tue ipotesi. Questi progetti di proof-of-concept sono da considerare un “parco giochi”, dove puoi imparare velocemente e fallire a poco prezzo. Non confonderli con il codice di produzione! Eliminali dopo aver estratto il massimo apprendimento da essi.

4. Continuous Delivery

Prima si applica il Continuous Delivery (CD) al progetto serverless, meglio è.

Scegli un framework di implementazione comprovato. Resisti all’impulso di creare il tuo, è proprio ciò che si deve evitare.

Il framework Serverless è il più popolare e si prende cura della maggior parte delle operazioni a basso livello. Supporta molti fornitori di servizi cloud e offre molte “best practices” pronte all’uso. La sua killer feature è il potente sistema di plugin che lo rende molto estensibile. Sono già disponibili molti plugin “community-lead”.

La tua pipeline di CD dovrebbe essere catturata come codice version controlled.

Le build dovrebbero essere riproducibili. Le dipendenze, comprese le dipendenze dei transitori, dovrebbero essere bloccate alle versioni esatte. Se gli aggiornamenti delle versioni minori / patch possono insinuarsi tra 2 build, la build non è riproducibile!

5. Test Automatici

Il paradigma serverless presenta un profilo di rischio diverso rispetto alla sua controparte serverful. È necessario cambiare di conseguenza il proprio modo di pensare per quanto riguarda i test.

L’ambiente di esecuzione vincolato limita la complessità di una funzione. La gestione della concorrenza viene spostato a livello di piattaforma. Rendendo così superflui i vari e complessi framework web.

Di conseguenza, il codice diventa più semplice che mai.

Così la complessità non scompare, ma si muove. Ora è nella configurazione e nella sicurezza delle “functions” e in che modo interagiscono con le dipendenze esterne. Queste sono le cose che più facilmente possono bloccare una applicazione. Ciò che testiamo dovrebbe riflettere questo cambiamento nel profilo di rischio.

Gli unit tests non dovrebbero più essere il cavallo di battaglia della tua strategia di test. Hanno un ritorno sull’investimento (ROI) più basso che mai.

Invece dovremmo concentrarci sull’integrazione e sui test di accettazione.

I test di integrazione dovrebbero esercitare le nostre funzioni localmente e parlare con i sistemi reali a valle. Lo scopo di questi test è testare il nostro codice contro le nostre dipendenze. Riservare l’uso di mock e stub per testare la gestione degli errori nel nostro codice. Parlare con i sistemi a valle reali altrimenti, per convalidare le nostre ipotesi sul loro comportamento.

I test di accettazione dovrebbero esercitare il sistema end-to-end senza chiamare il suo codice interno. Ciò significa che se stai testando un’API, i test dovrebbero comunicare al sistema tramite la sua interfaccia HTTP.

6. Costruire osservabilità nel sistema

Invia i log ad un servizio di aggregazione in cui possono essere facilmente cercati.

Utilizza la registrazione strutturata con JSON. Arricchisci i messaggi di log con i dati contestuali utili per il debug e la ricerca dei log correlati. Ad esempio, includi l’ID ordine come attributo in ogni messaggio di log relativo a un ordine.

Disattiva la registrazione di debug in produzione. Invece, cattura log di debug per, diciamo, uno su mille chiamate di funzioni.

Registra un messaggio di errore con l’evento di chiamata come attributo per invocazioni non riuscite. Ciò consente di acquisire e riprodurre invocazioni non riuscite.

Registra metriche personalizzate a livello di applicazione.

Crea dashboard e allarmi per i KPI. Connetti gli allarmi a un sistema di alerting e gestione degli incidenti come OpsGenie o PagerDuty.

Acquisisci e inoltra gli ID di correlazione tramite origini evento sincrone e asincrone e includi gli ID di correlazione acquisiti in ogni messaggio di registro. In questo modo, puoi trovare tutti i registri relativi a un’azione dell’utente anche quando l’azione si estende su più funzioni. Ne hai bisogno per il debug di interazioni complesse all’interno di un’applicazione serverless.

Inoltre, cattura log di debug per l’intera catena di chiamate. Prendi la decisione di campionamento a monte e passa la decisione come ID di correlazione. La funzione di ricezione rispetterà questa decisione e abiliterà anche la registrazione di debug per l’invocazione.

Cattura il tracing delle prestazioni per le tue invocazioni di funzioni. Ad esempio, utilizzando Amazon X-Ray con Lambda.

7. Sicurezza

Segui il principio del minimo privilegio. Ogni funzione dovrebbe avere solo i permessi di cui ha bisogno, niente di più, niente di meno.

Applicare l’isolamento a livello di account. Ogni ambiente dovrebbe avere un account separato, in modo da contenere una violazione della sicurezza.

Usa git commit hook per interrompere la perdita di credenziali dell’account.

I dati sensibili come le chiavi API e le credenziali non dovrebbero mai essere controllati nel controllo del codice sorgente in plain text.

Utilizzare servizi automatici come Snyk per analizzare continuamente le dipendenze per vulnerabilità note.

Ripulisci e convalida l’input dell’utente e l’output della funzione. L’uscita della “funzione di pulizia” interrompe i dati indesiderati. Se più funzioni sono concatenate, previene anche che i problemi vengano trasmessi lungo la catena.

Se sai che una funzione non è più utilizzata, eliminala. Anche se non vengono utilizzate, continueranno ad esistere come possibile obiettivo d’attacco. È inoltre probabile che le funzioni non utilizzate diventino vulnerabili nel tempo a causa della mancanza di patching.

8. Continuous learning

Sei in produzione, congratulazioni! Ma non fermarti qui. Continua a sperimentare, apprendere e iterare sui tuoi progetti.

Condividi le tue conoscenze con altri team e con la più ampia community di sviluppatori. Aiuta a stabilire un circolo virtuoso di apprendimento e miglioramento per tutti.

9. Standardizzare

Identifica modelli comuni e preoccupazioni trasversali. Cerca modi per standardizzare il modo in cui gestisci queste preoccupazioni.

Cerca modi per standardizzare il modo in cui gestisci queste preoccupazioni.

L’utilizzo di motori middleware come middy è un buon modo per standardizzare come fai le cose. Ad esempio, come gestisci gli errori o come acquisire e inoltrare gli ID di correlazione.

Inizia a costruire una piattaforma per fornire funzionalità che tutti i tuoi team vorranno utilizzare.

10. Automatizza tutto!

Usa la potenza del serverless per automatizzare operazioni e monitoraggio della sicurezza.

Ad esempio, puoi adottare ChatOps utilizzando AWS Lambda con integrazione Slack.

È possibile utilizzare CloudTrail, CloudWatch Events e Lambda per allertare attività sospette. Ad esempio, gli accessi alla console in momenti bizzarri della giornata o da località in cui non ci sono dipendenti. O avviso sulle attività EC2 nelle regioni remote che non stai utilizzando. Da quello che ho sentito, gli aggressori hanno più probabilità di estrarre bitcoin con credenziali rubate a San Paolo e Tokyo.

Conclusioni

Ci sono sfide tecniche da superare, sicuramente. Ma queste sfide sono tutte risolvibili e le piattaforme migliorano continuamente.

La sfida più difficile affrontata dalla maggior parte delle squadre consiste nell’adattare la loro mentalità. Come testiamo le nostre applicazioni, come le gestiamo in produzione e come creiamo resilienza in esse.

A seconda del punto di partenza, potresti dover affrontare sfide molto diverse durante la migrazione.

Un’architettura serverless è quasi sempre un’architettura a microservices. Significa che le persone che migrano da un sistema monolitico dovrebbero migrare verso un nuovo ambiente di esecuzione e un nuovo stile di architettura.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *