Spesso, nelle conversazioni con gli imprenditori locali, il Cloud viene percepito come una moda tecnologica o, nel peggiore dei casi, come un modo per perdere il controllo dei propri dati. “Se non vedo il server, come faccio a sapere che è al sicuro?” è il dubbio legittimo di chi ha costruito il proprio business sulla concretezza.
Nel mondo della digitalizzazione aziendale, esiste una trappola molto comune: la ricerca del risparmio immediato. Molti imprenditori, messi di fronte alla scelta tra un software “pronto all’uso” da 50€ al mese e una soluzione personalizzata da migliaia di euro, scelgono la prima opzione senza esitare.
Il tuo vecchio software gestionale ti impedisce di vendere online? Scopri come la modernizzazione in Cloud può sbloccare il tuo e-commerce e abbattere i costi manuali.
Ti è mai capitato di chiedere un preventivo per un sito web e ricevere una proposta da 8.000€ per un sito WordPress “all-inclusive”? Per molte agenzie di web marketing, WordPress è la “mucca da mungere”. È facile da installare per loro, ma costoso da mantenere per te. Spesso, queste proposte non nascono da un’analisi delle tue esigenze, ma dalla necessità dell’agenzia di venderti un servizio di assistenza ricorrente.
In un mondo monolitico, una stack trace era solitamente sufficiente per diagnosticare un fallimento. In un ambiente Go cloud-native, dove una singola richiesta potrebbe innescare tre microservizi e un’attività in background asincrona, la stack trace è morta. Il nuovo “Filo D’Oro” è context.Context. Se non stai gestendo correttamente il tuo context, non stai solo perdendo visibilità; stai perdendo il controllo sul ciclo di vita del tuo sistema.
Un mito architetturale molto comune è che Cloud Run sia solo per API stateless “leggere”, mentre il lavoro “reale” e ad alte prestazioni appartenga a GKE. Questo malinteso spesso deriva da una configurazione errata piuttosto che da limitazioni della piattaforma. Quando si abbina l’efficiente runtime di Go alla scalabilità serverless di Cloud Run, si può raggiungere un throughput incredibile, a patto di comprendere la “simpatia meccanica” richiesta tra i due.
Hai mai guardato una base di codice che hai scritto anni fa, e il tuo unico pensiero è: “Ma a cosa stavo pensando?” Nel 2020 mi stavo tuffando a capofitto in Kubernetes e nel mondo cloud-native per costruire un sistema di notifiche. Ero così entusiasta di poter finalmente distribuire la mia app nel cloud, ed ero determinato a renderla la migliore possibile.
Se hai trascorso del tempo nell’ecosistema Go, hai sicuramente visto i meme. Il “muro di if err != nil” è la critica più comune mossa al linguaggio. Per gli sviluppatori provenienti da Java, Python o TypeScript, la gestione degli errori in Go sembra un passo indietro, un ritorno ai tempi dei controlli manuali e del codice boilerplate.
Molti di noi ci sono passati. Stai disegnando un nuovo sistema alla lavagna. Deve essere containerizzato, deve scalare e deve essere resiliente. La mano si avvicina al pennarello e disegna il familiare esagono: Kubernetes. È lo standard del settore. È ciò che fanno i “grandi player”. Ma io credo che l’infrastruttura debba essere una risposta a un requisito, non un’impostazione predefinita.
Quando veniamo colpiti da dati ad alto volume in Go, di solito ricorriamo al classico pool di worker. È affidabile, veloce e funziona… fino a quando l’ordine di esecuzione non conta davvero. Il momento in cui si menziona “l’ordine”, vedo molti team iniziare a sovra-ingegnerizzare la propria configurazione cloud. Iniziano a partizionare le code a livello di infrastruttura, avviando pool di consumatori dedicati per ogni partizione e aggiungendo una massiccia complessità alle loro pipeline di monitoraggio e distribuzione.