Serie Architetture evolutive, parte 4

"Gradiresti anche un caffè?"

"Architetture evolutive" è una serie di blog in quattro parti che illustra 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.

Il terzo post del blog ha descritto come la startup abbia iniziato a evolvere la propria architettura per arrivare a includere strumenti come pipeline CI/CD e l'infrastruttura come codice, oltre a implementare le best practice, in particolare in materia di sicurezza e autorizzazioni. Nella parte 4, vedremo Example Startup formalizzare la propria posizione di sicurezza e backup per soddisfare vari standard di conformità. Inoltre, verrà stabilita una strategia relativa ai dati per l'organizzazione e verranno esplorate ulteriori linee di impresa per diversificare il portafoglio di prodotti.

Utilizzo dei finanziamenti di serie B per le assunzioni, l'espansione e la crescita

Per Example Startup tutto sta andando per il verso giusto. Di recente ha chiuso un round di finanziamento di serie B con il quale prevede di effettuare alcune operazioni di assunzione, espansione e crescita davvero necessarie. Insieme ai finanziamenti e alla crescita del bacino di utenti, è aumentata anche la concorrenza. Le varie realtà affermate del settore stanno iniziando a vedere in Example Startup un serio competitor, pertanto stanno aumentando gli sforzi di marketing.

Example Startup inizia ad assumere persone per ampliare le aree funzionali e creare team dedicati per l'ingegneria dell'affidabilità del sito (SRE), la piattaforma, l'analisi e il data science. Poiché il mercato del lavoro risulta molto competitivo ed Example Startup non dispone di un dipartimento HR dedicato, si è rivolta nuovamente al team di account AWS per ottenere informazioni sulla ricerca di talenti tecnici esperti di AWS. Grazie a questa consulenza, Example Startup ha scoperto che il team AWS ha già aiutato altre startup in situazioni simili, suggerendo partner AWS in grado di assistere con le esigenze di assunzione. In breve tempo, la startup ha ricevuto e-mail da diversi candidati altamente qualificati con esperienza in AWS. Fortunatamente, molti dei colloqui si sono trasformati in offerte di lavoro ed Example Startup è stata in grado di spuntare la voce "assunzioni" dalla lista di cose da fare.

La rapida crescita delle assunzioni porta a un problema tecnico: i vari team si lamentano che il team responsabile della piattaforma di Example Startup impiega troppo tempo per creare nuovi account per scopi di test, ostacolando così l'innovazione. Il team responsabile della piattaforma spiega di non avere la capacità di creare account individuali ogni volta che qualcuno propone una nuova idea per una funzionalità. A questo punto del suo percorso con AWS, il team responsabile della piattaforma ha un incontro quindicinale con il team AWS e gli comunica questa problematica. L'AWS Solutions Architect (SA) suggerisce di creare un'unità organizzativa dedicata all'ambiente di sperimentazione (sandbox) all'interno dell'organizzazione AWS, per fornire rapidamente risorse e ambienti di test temporanei ad altri team che vogliono provare nuovi servizi e funzionalità AWS. Inoltre, per mantenere i costi sotto controllo, l'SA raccomanda di utilizzare l'automazione per arrestare automaticamente risorse come le istanze di Amazon EC2 al di fuori dell'orario di lavoro consueto. Il team della piattaforma di Example Startup segue il consiglio dell'SA. Così, è in grado di attivare rapidamente account per i vari team all'interno dell'azienda in modo efficiente dal punto di vista dei costi.

Successivamente, il team SRE appena assunto si rende conto che la startup può essere posizionata meglio dal punto di vista della disponibilità e del ripristino di emergenza. Riconosce che la startup sta crescendo rapidamente e che, man mano che inizia a rivolgersi a clienti più grandi, dovrà affrontare requisiti di sicurezza più rigorosi, che possono includere audit e revisioni della conformità. Ciò può comportare la necessità di alcuni cambiamenti infrastrutturali. Fortunatamente, gran parte del lavoro necessario per il ripristino di emergenza è stato completato quando Example Startup ha modellato la propria infrastruttura in Terraform ed è passata a un'architettura multi-account nella parte 3 della serie.

Come primo passo, il team di Example Startup acquisisce familiarità con AWS Resilience Hub per ottenere ulteriori informazioni sulla creazione di applicazioni resilienti su AWS. Il team ha ancora alcune domande in sospeso, quindi si mette in contatto con AWS, che a sua volta mette a disposizione un SA esperto in materia di resilienza. L'SA collabora con Example Startup per specificare i requisiti relativi all'obiettivo del tempo di ripristino (RTO) e all'obiettivo del punto di ripristino (RPO), così come per eseguire un'analisi costi/benefici dei vari scenari di ripristino di emergenza. Dopo alcune chiamate con l'SA e molte riflessioni fatte internamente, il team SRE stabilisce che i requisiti di RTO/RPO dell'azienda non richiedono ancora una configurazione multi-regione. Decide di spostare i dati transazionali da Amazon RDS per PostgreSQL ad Amazon Aurora per PostgreSQL, principalmente per la maggiore disponibilità che offre e per la funzionalità di Database globale Amazon Aurora, importante per il database di produzione. La startup utilizza anche Gestione audit AWS per valutare la propria aderenza agli standard di conformità pertinenti in vista del prossimo audit. La sua funzionalità di raccolta automatica delle prove consente al team di risparmiare molto lavoro manuale.

Creazione di un'esperienza cliente migliore

Dopo aver esaminato i feedback sui prodotti di vari clienti, il Chief Technology Officer (CTO) si rende conto che le funzionalità di creazione di dashboard offerte ai trader nell'applicazione di trading di Example Startup sono carenti. I servizi offerti dai concorrenti consentono agli utenti di consultare facilmente una rappresentazione visiva della cronologia e delle prestazioni di trading (rispetto ad altri trader) a livello di operazione. Il CTO segnala questo aspetto come una lacuna di funzionalità critica e il lavoro viene assegnato al nuovo team di analisi. Inoltre, il CTO desidera che il team consenta ai trader di generare report di trading a piacimento.

Il team di analisi ha già esperienza con Amazon Quicksight, quindi potrà facilmente migliorare il componente del pannello di controllo, inclusa una funzione di rilevamento delle anomalie per aiutare i trader a trovare operazioni specifiche che presentano outlier. Al contempo, trova la richiesta relativa ai report più complessa in quanto l'esecuzione di report sul database di produzione andrebbe a infastidire i team di sviluppo, né sarebbe considerata una buona pratica. Dopo aver consultato il white paper sull'architettura dei dati moderna su AWS, il team di analisi realizza che la soluzione migliore consiste nel caricare i dati di Amazon RDS per PostgreSQL in Amazon Redshift, un data warehouse. Avvalendosi del potente parallelismo di Amazon Redshift, il team sarà in grado di eseguire complesse aggregazioni sui dati transazionali con una latenza decisamente inferiore e con il vantaggio aggiuntivo di non creare colli di bottiglia nel database di produzione. Inoltre, è lieto di scoprire che può riutilizzare la maggior parte delle sue query, in quanto Amazon Redshift è costruito sulla base del motore PostgreSQL.

Aggiunta di una nuova linea di impresa alla startup

Sullo sfondo di questi cambiamenti, durante una riunione con un ex collega che lavora presso un'importante società di trading, la CEO apprende che c'è una carenza di trader competenti sul mercato e che questo sta penalizzando la società nell'ottica delle assunzioni e dei progetti futuri. Dopo aver consultato alcuni amici che lavorano in altre società di trading, la CEO si rende conto che si tratta di una carenza diffusa nel settore. Inizia quindi a considerare l'idea di fornire ai trader di Example Startup una formazione specifica che possa alimentare una pipeline di talenti per le società di trading interessate. In questo modo, i trader di Example Startup avrebbero maggiori opportunità di entrare nel mercato del lavoro, mentre le società di trading avrebbero a disposizione nuovi talenti.

Poiché una parte fondamentale della formazione consisterà nel raccomandare le giuste operazioni ai nuovi tirocinanti, il CEO organizza una chiamata con il team di data science per capire quanto velocemente può creare un modello di machine learning (ML). Fortunatamente, alcuni membri del team di data science hanno già esperienza nelle attività di creazione, addestramento e implementazione di modelli con Amazon SageMaker. Poiché Amazon Redshift è una delle origini dati disponibili per SageMaker, il team di data science non avrà bisogno di configurare un complesso processo di estrazione, trasformazione e caricamento (ETL). I membri del team di data science meno esperti con SageMaker sono stati invitati dal team di supporto AWS a partecipare a una giornata full immersion su SageMaker per acquisire rapidamente le competenze necessarie. Presto anche loro sono sulla buona strada per creare operazioni di addestramento, sviluppare modelli accurati e implementarli agli endpoint. Prevedendo una chiamata del team finanziario di Example Startup riguardo all'aumento dei costi di calcolo, il team di data science ha fatto qualche ricerca e ha scoperto che è possibile eseguire le operazioni di addestramento (che rappresentano circa l'80% dei costi totali) in modo efficace su istanze spot. Così facendo, riesce a ridurre notevolmente i costi.

Man mano che la notizia di questa iniziativa di formazione dei talenti come nuova linea di impresa e flusso di entrate si diffonde nel settore, sempre più società di capitale di rischio iniziano a esprimere interesse per Example Startup, e questo ancor prima che la startup palesi l'intenzione di avviare un altro round di finanziamento.

Dopo alcuni trimestri, promossa dagli sforzi di marketing, dalla collaborazione con AWS e dal passaparola dei clienti esistenti, l'iniziativa di sviluppo dei talenti di Example Startup è cresciuta rapidamente. Sebbene l'aumento della base clienti sia stato favoloso, ancora più entusiasmante è il fatto che la startup è finalmente in attivo per la prima volta dalla sua fondazione. La scoperta che la ricerca di personale è un'attività redditizia ha permesso alla startup di crescere di giorno in giorno. Il team dirigenziale ha compreso che questo flusso costante di profitti potrebbe supportare altri ambiti del business. Pertanto, lavora diligentemente su ulteriori piani di espansione e innovazione, con grande entusiasmo per il futuro incredibile che si prospetta.

Riepilogo

Nel corso di questa serie divisa in quattro parti, Example Startup passa attraverso le fasi principali del ciclo di vita di una startup, dalla nascita alla trasformazione in un'azienda consolidata. La maggior parte delle startup spesso nasce semplicemente dal coraggio di un'idea e dall'entusiasmo di un team di fondatori. Le startup realizzano un prodotto minimo funzionante (MVP) con un'infrastruttura serverless che consente loro di testare la propria idea in un modo che il team dei fondatori possa gestire in autonomia.

Man mano che la startup acquisisce clienti paganti e ottiene finanziamenti post-seed passa alla fase in cui "l'idea sembra valida", la sua architettura si evolve e inizia a pensare seriamente al dimensionamento, alla sicurezza e all'agilità di sviluppo. Ciò significa apportare miglioramenti come l'utilizzo di strumenti di compilazione e la configurazione di sistemi di monitoraggio e database dedicati.

Durante queste fasi, una delle lezioni più importanti da apprendere è quella di interagire con il team AWS spesso e sin dalle fasi iniziali, anche prima di intraprendere i progetti, per risparmiare tempo e ricevere aiuto nella valutazione delle opzioni a disposizione. L'accesso alle risorse aziendali e tecniche può accelerare le tempistiche e aiutare i team della startup nella fase iniziale a raggiungere i propri obiettivi.

Dopo la fase di adattamento del prodotto al mercato, le startup possono iniziare ad assumere più personale e a concentrarsi principalmente sulla scalabilità, entrando nella fase in cui "l'obiettivo è il successo". In questo momento, iniziano a considerare una strategia multi-account, utilizzando un'architettura orientata ai servizi, la memorizzazione nella cache e altre modifiche architetturali per ottimizzare la propria applicazione e migliorare l'esperienza del cliente dal punto di vista tecnico.

Infine, le startup entrano nella fase di iper-scala, dove possono iniziare ad assumere in modo massiccio e a sviluppare ulteriori linee di impresa. Dal punto di vista tecnico, le startup hanno investito molto tempo e risorse sotto il profilo ingegneristico per migliorare la sicurezza, i controlli e le autorizzazioni per il proprio ambiente. Probabilmente hanno una versione codificata del loro ambiente che possono utilizzare per una rapida espansione internazionale e per il ripristino di emergenza, tra gli altri casi d'uso. Hanno anche sviluppato una strategia per i dati e stanno utilizzando analisi e machine learning per comprendere meglio i loro clienti e il loro business. Questa fase finale può avere esiti differenti. Alcune startup seguono la strada dell'acquisizione, mentre altre perseguono la redditività e il dominio di mercato.

La tua startup è pronta per iniziare il percorso? Iscriviti ad AWS Activate per creare e dimensionare la tua startup con le risorse giuste, al momento giusto.

Dai un'occhiata a tutte le serie Architetture evolutive:

• Architetture evolutive, parte 1 - "Ho una grande idea!"
• Architetture evolutive, parte 2 - "L'idea sembra valida."
• Architetture evolutive, parte 3 - "L'obiettivo è il successo."