Serie Architetture evolutive, parte 3

"L'obiettivo è il successo 🚀"

"Architetture evolutive" è una serie di blog in quattro parti che mostra come la progettazione delle soluzioni e le relative decisioni evolvono man mano che le aziende attraversano le diverse fasi del ciclo di vita delle startup. In questa serie, seguiamo il percorso di Example Startup (Startup di esempio, un nome di fantasia quantomai calzante) che sta sviluppando un'applicazione di "fantamercato azionario" sulla falsariga dei campionati di fantacalcio. L'idea prevede l'organizzazione di quattro "tornei" all'anno.

Nel secondo post del blog viene descritto come la startup ha iniziato a sviluppare le proprie soluzioni tecniche mentre i fondatori si preparavano per la raccolta fondi. Nella terza parte, viene esaminato il modo in cui Example Startup progredisce ulteriormente, mettendo a punto lo stack tecnologico e posizionandosi correttamente per il dimensionamento.

Scalabilità efficiente mediante la transizione a un'architettura di microservizi

Il team di fantamercato azionario sta crescendo e vengono creati nuovi componenti e soluzioni. Man mano che il portafoglio tecnico si amplia iniziano a comparire alcune crepe che richiedono l'attenzione del team.

"Le vecchie abitudini sono dure a morire" e il team inizia a comprendere come ciò possa causare problemi alla crescita della startup: le tempistiche aggressive e la voglia di raggiungere maggiori risultati con meno risorse stanno portando a un aumento del debito tecnologico. Un aspetto di questo debito tecnologico è la graduale proliferazione di monoliti, a differenza dell'architettura basata su microservizi che il team aveva inizialmente deciso di adottare. I problemi legati ai monoliti, come quelli in termini di scalabilità e i rallentamenti delle prestazioni, iniziano a manifestarsi durante i test e quando si introducono nuove funzionalità. Fortunatamente, il team riconosce rapidamente le sfide che questo approccio monolitico pone alla scalabilità ottimale dei carichi di lavoro. Pertanto, decide di fare un passo indietro e riconsiderare le proprie pratiche di sviluppo. Uno degli sviluppatori ricorda che l'AWS Solutions Architect (SA) aveva anticipato alcuni di questi problemi in una conversazione precedente. Il team di Example Startup pianifica una chiamata con AWS per ricevere assistenza.

Il passaggio dai monoliti a un paradigma basato sui microservizi rappresenta un argomento ampio, quindi l'AWS SA consiglia al team di Example Startup di partecipare alla "Giornata full immersion sulla modernizzazione delle app". Questa giornata parte da un workshop dedicato, rivolgendo una particolare attenzione ai carichi di lavoro relativi alle startup. L'evento è frequentato da quasi tutti gli sviluppatori dell'azienda e finisce per essere un vero punto di svolta. Nel corso di una sola giornata, il team è in grado di imparare a definire, progettare e implementare correttamente i microservizi. Apprende anche come tracciare un percorso di migrazione graduale da un'applicazione monolitica a un set di microservizi, senza dover rifare tutto in una volta. Il team è lieto di individuare tempestivamente i propri errori e di scoprire alcune best practice che torneranno utili strada facendo. Il Solutions Architect condivide anche un white paper di AWS incentrato sulle strategie di modernizzazione attraverso le quali è possibile colmare eventuali lacune nelle competenze del team di Example Startup.

L'esperienza positiva della modernizzazione delle app ha portato un grande valore a Example Startup, tanto che il team ha deciso di applicare lo stesso approccio basato sulle best practice anche ad altre aree funzionali in futuro. Per evitare che i membri del team si sovrappongano e lavorino sullo stesso aspetto, gli ingegneri e il product manager hanno programmato una chiamata con AWS per condividere la loro roadmap per il resto dell'anno. Dato che Example Startup ha già firmato un accordo di non divulgazione reciproco con AWS, durante la conversazione c'è stato un libero scambio di idee estremamente produttivo da entrambe le parti. Inoltre, sono affiorate alcune ottime notizie: si è scoperto che una funzionalità che Example Startup stava considerando di sviluppare è già prevista nella roadmap di AWS per il prossimo trimestre, liberando così del tempo per il team in fase di progettazione.

L'argomento successivo nell'elenco delle aree da migliorare di Example Startup riguarda l'infrastruttura come codice (IaC), l'integrazione continua e distribuzione continua (CI/CD) e i test automatizzati. Due neoassunti addetti alle operazioni di sviluppo (DevOps) non sono soddisfatti di molti degli attuali meccanismi operativi presso la startup, in particolare di aspetti come la creazione e il test di ambienti e la gestione degli artefatti del codice. Con l'espansione del team di Example Startup, sempre più persone hanno accesso ai processi sensibili, il che aumenta il rischio di errori e potenziali vulnerabilità. I due nuovi membri del team hanno già una certa esperienza con Terraform come approccio all'IaC. Sono felici di apprendere che AWS è ben supportato da Terraform e di scoprire altri strumenti come AWS CloudFormation e AWS CDK nel caso in cui sia necessaria un'alternativa. Tuttavia, hanno ancora bisogno di aiuto con il processo di CI/CD. I tentativi di migliorare la coesione tra il loro strumento di compilazione e quello di implementazione si sono rivelati difficili, compromettendo l'efficacia delle due funzionalità. Inoltre, stanno ancora cercando un approccio adeguato per gestire le immagini dei container. Il team AWS consiglia di utilizzare AWS CodePipeline perché può soddisfare le esigenze di integrazione ottimale di uno strumento di compilazione e implementazione, includendo anche test automatizzati, il tutto abbinato al supporto per vari ambienti. L'uso di CodePipeline consente l'integrazione con soluzioni che non sono state necessariamente create in modo nativo su AWS, oltre a un supporto affidabile per altri strumenti come AWS CodeBuild, AWS CodeDeploy e strumenti di terze parti. Implementando CodePipeline, Example Startup può cancellare dalla lista un altro importante obiettivo.

Mentre il team sta facendo progressi nella corretta implementazione dei microservizi, l'attenzione si sposta su alcune delle altre sfide complesse ancora da risolvere. Nello specifico, la presenza di più servizi che operano in modo indipendente ha sollevato la questione della comunicazione tra questi servizi. Il team sta esaminando se le chiamate tra servizi debbano essere sincrone o asincrone, e come è possibile adottare modelli di best practice come la messaggistica di pubblicazione/sottoscrizione (PubSub). Il team ha chiaramente compreso che l'adozione di un'architettura basata sugli eventi, in particolare con l'allontanamento dai monoliti, sarebbe vantaggiosa. Al contempo, l'infinita gamma di servizi AWS correlati a tale architettura, tra cui Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS) e Streaming gestito da Amazon per Apache Kafka (Amazon MSK), può richiedere uno sforzo nel trovare lo strumento giusto. Fortunatamente, il team ha trovato alcune risorse utili, come workshop e blog, che lo aiutano ad affrontare questo aspetto. L'adozione del paradigma "basato sugli eventi" sta lentamente diventando un altro strumento importante per il team.

Sviluppare una strategia di sicurezza più affidabile

La sicurezza ha continuato a essere una priorità per la nostra startup e strumenti come AWS Startup Security Baseline (AWS SSB) agevolano una partenza di slancio. Sfortunatamente, la sicurezza non è mai troppa. L'implementazione iniziale di AWS WAF è stata una buona partenza, ma il team deve cominciare a pensare in modo più proattivo alla prevenzione, al rilevamento e alla correzione. Pertanto, può partire dal migliorare le proprie competenze sui numerosi servizi AWS incentrati sulla sicurezza che possono contribuire a implementare una strategia di sicurezza affidabile.

La crescita del team e il coinvolgimento dei partner rendono il controllo degli accessi, i permessi e la governance argomenti che richiedono sempre più attenzione. Il team sta cercando di adottare best practice come il principio del minimo privilegio quando si applicano i permessi. Come minimo, desidera spostare i carichi di lavoro di produzione in vari account separati. Con l'adozione di queste best practice, appare visibile l'aumento della complessità operativa dovuta ai livelli aggiuntivi di gestione e permessi con cui si trova a confrontarsi. Diventa rapidamente evidente la necessità di un approccio automatizzato alla struttura degli account. Qualcuno menziona AWS Organizations, che sembra un passo nella giusta direzione, quindi il team si rivolge al proprio AWS SA di fiducia per un consiglio. L'SA condivide alcuni suggerimenti pertinenti, come valutare AWS Organizations e AWS Control Tower per un approccio più semplice alla gestione di più account. Poiché questo è il primo di molti passi verso il raggiungimento di una solida strategia multi-account, l'AWS SA ha anche condiviso con il team la guida prescrittiva "Transizione a più account AWS". Questa guida include le best practice riguardanti la migrazione degli account, la gestione degli utenti, la rete, la sicurezza e l'architettura quando si passa a un'impostazione con più account.

Ottimizzazione dei carichi di lavoro per le prestazioni

Attualmente, il team sta lavorando per garantire che la startup sia pronta a crescere al giusto ritmo. Mentre alcuni elementi importanti sono stati già completati nell'elenco delle cose da fare, altri hanno già piani d'azione in atto. Gli sviluppatori stanno compiendo ogni sforzo possibile per ottimizzare le prestazioni dei loro carichi di lavoro, ma hanno individuato alcune opportunità di miglioramento che vanno al di là del codice, come ad esempio l'utilizzo di servizi di memorizzazione nella cache come Amazon CloudFront per il caching a livello di edge, Amazon ElastiCache per il caching a livello di applicazione e non da ultimo il caching del database. Inoltre, il team sta sempre più utilizzando i Servizi gestiti AWS (AMS) per fornire le funzionalità necessarie, mantenendo la complessità operativa al minimo. Batch AWS è un altro servizio gestito che alcuni sviluppatori hanno scoperto e trovano sorprendentemente facile da usare. A causa dell'aumento esponenziale del volume di dati da elaborare, l'approccio iniziale all'elaborazione dei feed con AWS Lambda sta raggiungendo i suoi limiti. Tuttavia, gli sviluppatori hanno sperimentato e trovato un modo per utilizzare Batch AWS in modo efficace, il che consente loro di continuare a crescere con un aumento relativamente contenuto del carico operativo e di mantenere bassi i costi.

Dimostrare la proposta di valore della propria startup

Tutto il lavoro svolto in Example Startup non è passato inosservato. La capacità dell'azienda di sviluppare in modo agile ma sostenibile, senza fare affidamento su soluzioni alternative a breve termine, dimostra la sua propensione al lungo termine, la sua maturità e la capacità di fornire risultati concreti. Queste qualità, unite a una soluzione innovativa e a un'adeguata adattabilità del prodotto al mercato, costituiscono il cuore della proposta di valore dell'azienda. I fondatori sono riusciti a trasmettere con successo il valore della loro azienda a diverse società di venture capital, riuscendo a chiudere il loro primo round di finanziamento di serie A. Example Startup è sulla buona strada per raggiungere un grande successo.

Dai un'occhiata al primo e al secondo post del blog della serie Architetture evolutive.